Why WordPress speed fixes fail when you start with images

The biggest gains usually come from fixing hosting, PHP and page caching before tackling images, fonts, scripts and adverts.

The fastest way to improve a slow WordPress site is to work in the right order. First measure the problem, then fix the layers that affect every page, and only then move on to the finer details such as images, fonts, scripts and ads. That sequence matters because a poor server, outdated PHP or missing page cache can overwhelm every other optimisation you make. According to the supplied guide, Google’s Core Web Vitals are the end goal, but the real task is to remove the biggest bottlenecks one by one and retest after each change.

Measurement should come before any tuning. PageSpeed Insights is useful because it separates field data, which reflects real user visits over the previous 28 days, from lab data, which is a simulated single-page test used for debugging. The article says that field data is what Google uses for Core Web Vitals, while the lab score helps identify the causes of slowness. It also notes that Search Console’s Core Web Vitals report is the best place to review sitewide URL groups rather than a single page in isolation.

The thresholds themselves are straightforward. Google’s current Core Web Vitals targets are 2.5 seconds or less for Largest Contentful Paint, 200 milliseconds or less for Interaction to Next Paint, and 0.1 or less for Cumulative Layout Shift at the 75th percentile of visits. The guide also points out that INP has replaced First Input Delay as the relevant responsiveness metric, and that Time to First Byte is not a Core Web Vital, even though it is still an important sign of server performance because slow server response tends to drag down LCP.

Hosting and PHP version sit at the top of the fix list because every request begins there. As the article explains, a crowded or underpowered host can limit speed no matter how many plugins are installed. That point is reinforced by industry guides from Apex Weave and Velopress, which both emphasise that modern server stacks, current PHP releases, server-level caching and efficient database co-location can make a substantial difference to TTFB. The practical takeaway is simple: if a cached page is still slow to start loading, the hosting layer is usually the first place to look.

Caching is the next major lever. A page cache stores finished HTML instead of rebuilding each page on every visit, which is why WordPress.org describes it as the quickest immediate fix. The guide warns against stacking multiple cache systems and recommends using only one page cache, whether that comes from the host or a plugin such as LiteSpeed Cache, WP Rocket, WP Super Cache or W3 Total Cache. It also advises checking the site in a private window afterwards so that forms, logged-in areas and other dynamic sections still behave correctly.

Images, fonts and front-end code usually explain the remaining gap. The guide recommends resizing images before upload, compressing them, using WebP or AVIF where possible and letting WordPress handle lazy loading for images that are not part of the main visible content. It also notes that width and height attributes help prevent layout shifts. Fonts should be kept to a minimum, ideally with sensible fallbacks, because heavy web fonts can delay text rendering or shift the page. The same applies to CSS and JavaScript: unused plugins should be removed, non-essential scripts deferred or delayed, and excess CSS trimmed carefully so that the site does not break.

A CDN helps when visitors are geographically far from the origin server, but it is not a substitute for poor hosting or weak caching. Once the foundation is in place, the next gains often come from database clean-up and third-party scripts. The guide says that revisions, transients, spam comments and leftover plugin tables can accumulate over time, while analytics, ad networks, social embeds and chat widgets often create the worst delays because they load from elsewhere and cannot be optimised in the same way as local assets.

Ads deserve special attention because they can damage both speed and visual stability. According to the guide, and in line with web.dev’s own advice, ad slots should reserve space before creative loads, rather than appearing at zero height and pushing the page down afterwards. That means using a defined minimum height or aspect ratio, especially on monetised posts where the ad network may return different sizes on mobile and desktop. The article’s final message is practical rather than theoretical: make one change at a time, test again, and judge success by real-user data after the 28-day field window has refreshed.