--- title: "Five Changes That Actually Moved The Number On Client Sites" url: https://hostmy.blog/wordpress-speed-optimization/ date: 2026-09-08 modified: 2026-09-03 lang: en author: "Aditya Sharma" description: "A caching plugin is not the biggest win on most WordPress blogs. Here are five changes that moved LCP on our client sites, and three that did nothing." categories: - "WordPress" image: https://hostmy.blog/wp-content/uploads/2026/09/hmb-card-1847-1024x538.jpg word_count: 1790 --- # Five Changes That Actually Moved The Number On Client Sites The largest speed improvement available on most WordPress blogs is deleting one image and replacing it with a smaller one. A multi megabyte hero at the top of every article template will dominate Largest Contentful Paint, and swapping it out is a ten minute job. Sites in that state usually already have a caching plugin, a CDN, minified CSS, and a PageSpeed score somebody spent a weekend chasing. None of it matters while a 2.8MB PNG sits at the top of every article template. Speed work on WordPress is unglamorous in exactly this way. A small number of changes carry almost all of the improvement, and they are usually not the ones being sold. ## Measure the page people actually land on Before anything else: stop optimising the homepage. On a blog, the homepage is rarely where visitors arrive. Search and social land on article pages, which have a different template, different images, and often a different set of scripts. A homepage PageSpeed score of 96 tells you almost nothing about the experience most visitors get. What we measure, per template: - LCP on the top five landing pages by organic traffic, on a throttled mobile profile. - Time to first byte, separately, because it is a server problem and the rest are front end problems. - Total transferred bytes, split by CSS, JS, images, fonts. Lab tools are directional, and they are also where most people start in the wrong order, which is the argument of [fixing Core Web Vitals in the sequence that moves the number](/core-web-vitals-wordpress/). Where the site has enough traffic, field data from the Chrome UX Report is the number that matters, because it reflects real devices on real connections rather than a data centre in Iowa. ## 1. The hero image, almost every time On article templates, the LCP element is nearly always the featured image. Which means LCP is nearly always an image delivery problem. Four things, in order of how much they returned for us: **Serve the right dimensions.** A 3000px wide original scaled down by CSS to 760px is the most common single waste we find. WordPress generates intermediate sizes. Themes frequently ignore them and output `full`. **Serve modern formats.** WebP or AVIF, with a fallback. WebP comes in roughly 25 to 34 percent smaller than a comparable quality JPEG. AVIF goes further and encodes slowly, which matters if you upload in bulk. **Preload it.** The browser cannot start downloading the hero until it has parsed enough HTML to find it. A preload hint in the head moves that start time forward, sometimes by more than a second. `` **Never lazy load it.** More on that below, because we got this wrong. ## 2. Third party scripts in the head The second biggest category, consistently. A blog we took over last year was loading, on every page: analytics, a heatmap tool, two ad network scripts, a chat widget, a social sharing service, and a font script. Six third party origins, each requiring a DNS lookup, a TCP connection, and a TLS handshake before a single byte of useful content arrived. The audit question is not whether each one is useful. It is whether it needs to run before the page is readable. What we do now: everything non essential moves to `defer`, and anything that renders visible UI after load gets a deliberate decision about whether it is worth the delay. A chat widget producing a few dozen conversations a month against tens of thousands of sessions does not need to block the first paint, and a fair number of those scripts arrive with a plugin nobody has audited since install, which is [a removal decision more than a performance one](/wordpress-plugin-bloat/). Move it to a delayed load after user interaction. Be careful here. Delay scripts on a page with consent requirements or ad revenue and you can break things that pay for the site. Delaying an ad script can genuinely cost money. That is a business decision, not a performance decision, and it belongs to the client. ## 3. Page builder CSS This is the one people do not want to hear. Most page builders load a global stylesheet covering every widget they ship, on every page, regardless of what the page uses. On sites we have measured, that has run between 180KB and 500KB of CSS before the theme's own styles. There is rarely a clean fix that does not involve rebuilding the template. What has worked for us: - Turning on whatever per page asset loading the builder offers. Most have it now. Most have it off by default. - Removing builder widgets from templates that render on every article, especially in headers and footers, where one widget drags in a bundle. - Building the article template in the block editor even when the marketing pages stay in the builder. Article templates are simple and they carry the traffic. That last one is a real project, not an afternoon. Rebuilding an article template in the block editor can take CSS on those pages from several hundred KB down to under a hundred. It also costs days of work and a conversation about why the editors now have two ways to build a page. ## 4. Server response time, which is a hosting problem Time to first byte is the one thing on this list that a plugin cannot fix. On the blogs we run, uncached TTFB sits between 180ms and 400ms on a decent stack. On oversold shared hosting we have measured the same WordPress install at 900ms to 2.4 seconds, varying by hour of day in a pattern that tracks somebody else's traffic. The specific failure modes are in [the uncomfortable economics of cheap shared hosting](/cheap-shared-hosting-economics/). Three server side things that have paid off repeatedly: - **A persistent object cache.** Redis or Memcached. On query heavy sites this has been the single largest TTFB improvement available, because it stops WordPress rebuilding the same option and term queries on every request. Query heavy usually also means the tables underneath deserve [a look at what has been quietly growing](/wordpress-database-maintenance/). - **Full page caching that actually serves the cached copy.** Check that it does. A cookie set by a plugin can bypass the cache for every visitor, and the caching plugin will still report itself as working. - **A current PHP version.** The gap between old and current PHP is real and free, with the caveats in [choosing a PHP and MySQL version](/wordpress-php-version/). Two of those three come configured on most managed platforms, which is part of [what a managed WordPress host is actually selling](/managed-wordpress-hosting/) and part of why the bill is higher. ## 5. Fonts Smaller than the first four, and cheap enough to always do. Self host rather than calling a font CDN, which removes a connection to a third origin. Use `font-display: swap` so text renders in a fallback while the file downloads. Subset to the characters you actually use. Load two weights, not six, and stop letting a theme demo pull in weights nothing renders. On a typical blog this has been worth 200 to 500ms of perceived render time. Worth thirty minutes. ## What did not move the number This is the part worth reading twice, because we spent real time on these. **Aggressive minification and concatenation.** With HTTP/2 and gzip already in place, the measured difference was inside the noise on every site we tried it. It did cause two breakages from mangled inline scripts. **Automatic critical CSS generation.** Produced a small improvement on paper and introduced a whole class of visual bugs, where a page in a state the generator never saw would render unstyled for a moment. We turned it off and did not miss it. **An image CDN on already optimised images.** If the images are already correctly sized and in WebP, adding a transformation CDN mostly adds a DNS lookup. It is a good tool for a site with thousands of unoptimised uploads and a poor tool for a site that already did the work. **Chasing the PageSpeed score.** The score is a weighted composite. On one site we moved it from 71 to 89 with changes that made no difference to a real LCP measurement. Optimise the metric that reflects what a person waits for. ## The mistake: we lazy loaded the LCP image Worth its own section, because it is the most common self inflicted wound in this area and we did it too. Lazy loading is genuinely good for images below the fold. Applied globally by a plugin, it also gets applied to the hero image, which means the browser deliberately waits before downloading the exact element LCP is measuring. On the site where we did this, LCP got worse by about 600ms and we spent two days looking at everything except the change we had made. The `loading="lazy"` attribute was right there in the HTML the whole time. The rule: the LCP element is never lazy loaded. Most decent plugins now have a setting to skip the first N images. Set it, then verify in the rendered HTML rather than trusting the setting. ## What a realistic result looks like Ranges from the sites we have worked on, article templates, throttled mobile. | Change | LCP effect we measured | | ------ | ---------------------- | | Hero image resized, converted, preloaded | 0.8s to 2.5s faster | | Third party scripts deferred | 0.3s to 1.1s faster | | Page builder CSS reduced | 0.2s to 0.9s faster | | Object cache added on a query heavy site | 0.2s to 0.7s faster on TTFB | | Fonts self hosted and subset | 0.2s to 0.5s faster | These are our sites, not a benchmark, and they do not add up cleanly because the changes overlap. A site that is already fast will get less from each of them. Anybody quoting you a guaranteed improvement before looking at your waterfall is guessing. One layer sits outside all of this and gets confused with it. Making a page fast for a person is not the same as making it cheap for an assistant to read, which is a plain text and structure question rather than a byte weight one. [RankReady](https://wordpress.org/plugins/rankready-ai-llm-seo/) is the WordPress AI SEO plugin we install for that job, version 1.3.1, tested to WordPress 7.1, with about 300 active installs on WordPress.org. It sits next to Rank Math, Yoast, AIOSEO or SEOPress rather than replacing any of them, setup runs about five minutes, and what it changes is crawlability, not your LCP. The other honest caveat: speed work decays. A new plugin, a new widget in the footer, an editor uploading a 4MB image, and you are back where you started in six months. That drift is exactly what the monthly checks in [a real WordPress maintenance month](/wordpress-maintenance-service/) are for. So before you buy another optimisation plugin: do you know which element is your LCP on the page most of your visitors actually land on?