Website Speed Optimization That Starts at the Server, Not a Plugin

What you get with BigRed's website speed optimization services

Every speed job includes these, in this order:

• A baseline from real visitors. I pull field data (measurements from real Chrome users, not a lab test) from PageSpeed Insights and Search Console before touching anything. That's the "before" half of your report.
• Server and caching fixes. PHP version, OPcache (PHP's built-in memory for compiled code), a page cache at the server level, an object cache where it helps, and compression. This is where most of the time usually hides.
• Browser caching headers. Images, fonts, CSS and JavaScript get long cache lifetimes, so returning visitors don't download them twice.
• Image fixes. The main image on key pages loads first and isn't lazy-loaded, oversized photos get resized, and images get width and height set so the layout stops jumping.
• Script fixes. Tag managers, chat widgets, booking tools and sliders get checked for what they cost on a phone. Some get delayed, some get removed with your OK.
• A plugin cleanup. Duplicate caching, optimization or "speed" plugins get switched off. Two caches fighting each other is a common cause of a slow and occasionally broken site.
• A before-and-after Core Web Vitals report in plain English, plus a short list of anything I found but didn't change.

How it works, from questionnaire to faster site

1. You fill in the questionnaire. Your URL, your host, and what feels slow (the whole site, the admin, or one page like your booking form).
2. I reply with a plan and a fixed quote within one business day.
3. You give me access. Hosting control panel (cPanel, Plesk or similar), WordPress admin, and Search Console. I take a full backup first.
4. I do the work in the order above. Typically two to four working days of hands-on time for a standard WordPress site. A page builder with heavy add-ons, WooCommerce, or a host that won't let me change server settings makes it longer, and I'll say so up front.
5. You get the report. Lab results right away. Field data takes longer, because PageSpeed Insights reports real visits over the previous 28-day collection period. I check back once the new numbers have had time to settle.

Why server-side caching comes first

Here's the mechanic in plain English. When someone opens a page on a typical WordPress site, the server runs PHP, asks the database a few dozen questions, builds the page, and only then sends the first byte. That wait is called TTFB (time to first byte). Google's web.dev team says most sites should aim for a TTFB of 0.8 seconds or less, and anything over 1.8 seconds is poor.

Every other speed fix waits in line behind that number. Your largest image can't start downloading before the HTML arrives. So the main content can't show up quickly either.

A page cache skips the whole build. WordPress's own documentation calls caching the fastest way to improve performance, and notes that serving pages as static files can help "several hundred times over" for fairly static pages. That's a big claim, but for a contractor's site where the services page changes twice a year, it's roughly what happens.

Server cache vs. plugin cache

There are two places a page cache can live. A plugin cache still wakes up PHP on every visit to check whether it has a saved copy. A server cache (LiteSpeed's built-in cache, Nginx FastCGI cache, Varnish, or your host's own layer) answers before PHP even starts. When the host offers one, I use it. On LiteSpeed servers that means the LiteSpeed Cache plugin, which is really a remote control for the server cache rather than a cache of its own.

Next comes the object cache (Redis or Memcached keeping database answers in memory). It helps logged-in users, WooCommerce carts and busy admin screens. A brochure site often doesn't need one. Where it does help, I set it up with something like Redis Object Cache and check that the host actually runs Redis.

Then the boring win: PHP itself. WordPress.org recommends PHP 8.3 or greater. I still find sites on versions that stopped getting security fixes years ago, which are slower and riskier at the same time.

How I check it

This is what I run before and after, from any terminal:

# Measures time to first byte for one page, three times (the first hit may be uncached).
# Read-only. Safe to run against your own site.
for i in 1 2 3; do curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://example.com/; done

# Shows whether a cache answered: look for x-litespeed-cache: hit, cf-cache-status: HIT, or an age header.
curl -sI https://example.com/ | grep -iE "cache|^age|x-litespeed"

If the second and third TTFB numbers stay above a second and no cache header shows up, the server is building every page from scratch. That's the first thing I fix.

What comes after the server: images, scripts, then plugins

Images. The biggest element on screen when a page loads is usually a hero photo. Google's guidance is blunt: never lazy-load your LCP image (LCP, Largest Contentful Paint, is when that main element finishes showing). Some themes and plugins lazy-load everything, including the one image that should load first. I fix that, resize the 4,000-pixel phone photo that's displayed at 800 pixels, and serve modern formats like WebP.

Scripts. Responsiveness to taps and clicks is measured by INP (Interaction to Next Paint). It's usually hurt by JavaScript hogging the browser. Any task over 50 milliseconds counts as a long task, and while it runs, the page can't react to the visitor. Chat widgets, heat-map tools and stacked tracking tags are the usual suspects. Some can load later. Some aren't earning their keep.

Plugins, last. By now the site is often fast enough that the "optimization" plugin isn't needed at all. Fewer moving parts means fewer things to break on the next update. My guide to Core Web Vitals for small business owners explains what each of the three scores means, if you'd like the background.

Who this is for (and who it isn't)

This is a good fit if you run a WordPress site on cPanel, Plesk, a VPS or managed WordPress hosting, and:

• Search Console shows Core Web Vitals marked "Poor" or "Needs improvement" on your main pages
• Pages take a few seconds to appear on a phone, especially the first visit
• The admin is sluggish, or your host keeps warning you about resource limits
• You've installed two or three speed plugins and it's no faster (or something broke)

I work with contractors, clinics, law firms, local retailers and SaaS startups across the US and Canada, all remotely.

It isn't for you if your site runs on Wix, Squarespace or Shopify. Those platforms control the server, so the biggest lever isn't yours to pull. It also isn't worth paying for if your field data already passes. Google says a good score in reports like Search Console's doesn't guarantee top rankings, and chasing a perfect score just for SEO "may not be the best use of your time." I agree. If you pass, spend the $500 elsewhere.

Website speed optimization pricing

As of October 2026:

Bigger jobs cost more: WooCommerce stores, sites with many page templates, or a move to a better host when the current one simply can't go faster. I quote those before starting, and you decide. All prices are in USD. Everything else is on the pricing page.

If speed is one problem among several (indexing, redirects, duplicate pages), a technical SEO audit looks at all of it at once and might be the better first spend. And if you'd like someone keeping updates and caches healthy afterward, that's what monthly WordPress care is for.

Why hand it to me

I've spent 20+ years in search marketing, and much of it inside servers: cPanel/WHM, Plesk, Cloudflare and Linux (LAMP) setups, server-side and browser caching, and a lot of .htaccess work. Speed sits right on that border between hosting and SEO, which is where I like to work.

Most speed services are plugin services. They tune what the plugin can reach. I start at the layer the plugin can't reach, and I tell you plainly when the real fix is a different host.

You also deal with one person from first email to final report.

Website speed optimization FAQ

How much do website speed optimization services cost?

At BigRed, a WordPress speed job starts at $500 and includes server and page caching, image and script fixes, a plugin cleanup, and a before-and-after Core Web Vitals report. Larger WooCommerce stores, sites with many templates, or a host change cost more, and I quote those before starting. When comparing quotes elsewhere, ask one question: will anyone touch the server, or only install a plugin?

Will a faster site improve my Google rankings?

It can help, but don't expect a jump from speed alone. Google says Core Web Vitals are used by its ranking systems, and also that good scores don't guarantee top positions. In practice, a faster site helps most when your content is already competitive. The more reliable payoff is people: fewer visitors leave before the page appears, and forms and tap-to-call buttons respond when tapped.

Why does PageSpeed Insights show a different score every time I run it?

The big score at the bottom is a lab test from one simulated phone at one moment, so it moves with network noise. The field data at the top comes from real Chrome visitors over 28 days and is far steadier. Google's Core Web Vitals assessment uses the field data. If your site is too small to have field data, the lab score is still useful for finding problems, just not for measuring success.

Do I need a caching plugin if my host already caches pages?

Usually not a second one. If your host runs a server cache (LiteSpeed, Nginx or Varnish), the plugin's job is mainly to clear that cache when you edit a page. Adding a separate caching plugin on top often means two caches disagreeing, which can serve stale pages or break layouts. I check which layer is actually answering before deciding what to keep.

How long until I see the improvement in Search Console?

Lab results improve the same day. Search Console and PageSpeed Insights field data use a rolling 28-day window of real visits, so the numbers shift gradually over about four weeks. Low-traffic sites may not have enough visits for page-level field data at all, and then Google shows site-wide numbers instead. I tell you which one you're looking at in the report.

Next step

If your site is slow and you'd like it fixed at the layer where the time actually goes, send me the details through the speed questionnaire. I'll come back with a plan and a fixed quote within one business day.