WordPress speed optimization: what I do, in short
WordPress speed optimization means using measurements to find out why a slow WordPress site is slow, then fixing those causes. When possible, I try changes on a test copy separate from the live site first. Some settings, like a CDN or server caching, can only be changed on the live site, and I tell you about those in writing beforehand. No change goes live without your approval. When the work is done, I report the before and after measurements.
This service is for slow WordPress sites: business websites, WooCommerce e-commerce websites, sites built with a page builder like Elementor and sites someone else built. I also work on agencies’ client sites on their behalf.
The work covers images and fonts, code files that delay page loading, plugins, the database and cache settings. If part of the slowness comes from the server, I show that with measurements too. The measurements decide how much effort each area needs.
The price depends on the state of the site and the scope of the work. Write your site’s address and a short description of the problem in the free quote form, and I’ll get back to you within one business day. The exact scope, timeline and price are settled after a technical review and our exchange of messages.
I measure first: the data I look at
PageSpeed Insights shows two kinds of results: what your real visitors experienced over the last 28 days, and a one-time lab test. For its Core Web Vitals assessment, Google looks at real visitor data, so that’s where I start too.
Google rates a metric as “good” when at least 75% of visits fall within the threshold below:
| Metric | What it measures | “Good” threshold |
|---|---|---|
| LCP (Largest Contentful Paint) | How long it takes for the largest image or text block on the first screen (often the main image or heading) to appear | 2.5 seconds or less |
| INP (Interaction to Next Paint) | How quickly the page responds to a click or tap | 200 milliseconds or less |
| CLS (Cumulative Layout Shift) | How much the content on the page shifts unexpectedly | 0.1 or less |
On low-traffic sites, there often isn’t enough real visitor data. If PageSpeed Insights can’t find enough data for a page, it shows data for the whole site. If there’s no site-wide data either, it shows none. In that case, I measure by repeating lab tests several times under the same conditions.
I also look at the server’s initial response time (TTFB). By comparing cached and uncached pages, I can tell whether the slowness comes from the server or from the site itself.
Speeding up your WordPress site, one cause at a time
I’m the kind of person who can’t let it go until I find out why an image shows up half a second late. Measurement shows how much load each plugin, script, font or page builder element adds. I base my fixes on that data:
- Images: Resizing them to the right dimensions, converting them to WebP (or AVIF if your server supports it) and adding width and height so the layout doesn’t shift. I never set the page’s main image (the LCP image) to load late. I make sure it loads with priority.
- Fonts: Removing font weights you don’t use, preloading the critical fonts and setting up fallback fonts so text doesn’t jump when the font changes.
- CSS and JavaScript: Cutting down the files that block the page from appearing, loading each script only on the pages that need it and deferring what can wait.
- Plugins and page builder: Removing duplicate plugins and ones that repeat what WordPress already does. WordPress now gives priority to the likely main image on its own, so a plugin that interferes with this slows your site down instead of speeding it up. If you use a page builder like Elementor, I start with its own performance settings and unused elements.
- Database: The size of the settings that load automatically on every page, leftover records from deleted plugins and expired temporary data. WordPress’s Site Health screen shows a warning when these autoloaded settings get too big, and that’s one of the things I check. I also clean up old revisions of posts and pages that have piled up, though this usually makes little difference to the speed your visitors see.
- Caching: Page and browser caching. Instead of several plugins that clash with each other, I set up one properly configured system.
- WooCommerce: Cart, checkout and account pages are personal to each visitor, so they can’t be served from the page cache. Their speed depends on server response, plugin load and queries like product filters or search. I measure these pages separately and set the cache rules so they don’t break the cart or checkout.
- Server and PHP: If part of the slowness comes from the server, I show it with measurements. If there’s a setting you or your hosting company need to change, I send you written instructions. If the site isn’t on a current PHP version recommended by WordPress, I try the upgrade on the test copy first.
- CDN and third-party scripts: If your visitors come from different regions or your files are heavy, I use measurements to show whether a CDN (content delivery network) would help. I also measure how third-party scripts, like live chat bubbles, tracking pixels and embedded videos, affect how quickly the page responds to clicks.
Without breaking your design or features
Shrinking (minifying), combining or deferring CSS and JavaScript files can break forms, sliders and the WooCommerce cart if it’s done carelessly. That’s why I start by backing up the site and, when possible, make changes on a test copy separate from the live site first.
Before anything goes live, I test the contact form, the menus, the mobile view and, if you have them, the cart and checkout steps one by one. I only apply changes to the live site after you approve them.
How I report the results
I report the before and after measurements in two stages:
- When the work is done: Lab measurements taken on the same pages, under the same conditions, with several repeats. The lab score moves from test to test even when nothing on the page changes, so I never rely on a single measurement.
- About a month later: If your site has real visitor data, the change in that data. Real visitor data covers the last 28 days, and fix validation in Search Console also takes 28 days. So the full improvement only shows up at the end of that period.
I share the measurements and the approval steps in writing, and you deal with me from start to finish.
I don’t guarantee you a PageSpeed score of 100 or a load time like “under one second.” Google’s own documentation says a score of 100 isn’t an expected result. What I aim for is a shorter wait for your real visitors and, where it can be measured, Core Web Vitals in the “good” range.
If you want to treat speed as part of your overall search visibility, we can plan it together with SEO and GEO consulting.
Keeping your site fast
A site that’s been sped up can slow down again over time. The most common causes are new plugins, images uploaded without optimization and third-party scripts added later. I add a short note to the report on what to watch out for from now on. If you like, we can also set an upper limit together for page weight and the number of plugins. This is called a performance budget.
If you’d rather leave updates and regular checks to me, the WordPress maintenance service also helps keep your site fast. Theme and plugin updates are tried on a test copy first. If the slowness is a sign of a broken theme, clashing plugins or an unfinished project, it’s better to start with WordPress error fixing. For a hosting change, I plan the move as part of the WordPress site migration process, so your data and search visibility stay protected.