Signs your WordPress site is too slow
Speed is the leak you can feel. Visitors on phones leave before the page finishes, and you never see them in your analytics because they bounce before the tag fires.
The usual signs: PageSpeed Insights shows red on mobile whatever plugin you install. Search Console flags pages as “Poor” for LCP or INP. The hero image appears last, after everything else. Buttons feel sticky, so you tap and nothing happens for a moment. Three caching plugins are installed and nobody remembers why. Ad clicks get more expensive while the bounce rate keeps rising.
Core Web Vitals in plain words
Google measures three things from real visitors over 28 days, collected in the Chrome User Experience Report (CrUX). To pass, at least 75% of visits need a good score on all three.
Largest Contentful Paint (LCP), under 2.5 seconds. How long until the main content is visible, usually the hero image or the headline. On WordPress it’s most often an oversized image that loads late.
Interaction to Next Paint (INP), under 200 milliseconds. How quickly the page reacts when someone taps or clicks. INP replaced First Input Delay in 2024 and is the metric most WordPress sites now fail, mostly because of third-party JavaScript, sliders and mega menus.
Cumulative Layout Shift (CLS), under 0.1. How much the layout jumps while it loads: late cookie banners, web fonts swapping in, and images without dimensions.
Why a caching plugin alone won’t fix it
Most slow WordPress sites already run a caching plugin, often two, and adding WP Rocket, LiteSpeed Cache or W3 Total Cache on top rarely moves the score much. Caching helps the server answer faster, which improves Time to First Byte. It can’t shrink a 2 MB hero image, remove 400 KB of unused builder CSS, or stop a chat widget from blocking every tap.
That’s why WordPress speed optimization starts with the page itself: the LCP element, render-blocking CSS and JavaScript, fonts and third-party tags. Caching is configured last, once, and properly.
Elementor, WPBakery and Divi
Page builders are the most common reason a WordPress site stays slow. Each widget ships its own CSS and JavaScript, and the markup is deeply nested, which makes the browser work harder on every page.
A lot can still be fixed: unused CSS removed per template, scripts deferred, heavy widgets replaced, and the builder’s own performance settings switched on. But there is a ceiling. If the builder is most of the page weight, I’ll tell you where that ceiling is for your site, and whether a migration to a lean block theme costs less than fighting it.
WooCommerce and dynamic pages
Shops and membership sites can’t cache every page. Cart fragments, logged-in sessions and search pages hit the server on every visit, so hosting, database queries and object caching matter more. I profile the slow queries, cut unnecessary AJAX calls, and keep the product and category templates as light as the homepage.
Hosting, TTFB and CDN
If the server takes more than about 800 milliseconds to answer, nothing on the page can make up for it. I check Time to First Byte on your host, the PHP version, object caching and whether a CDN such as Cloudflare is serving images and static files. Sometimes the cheapest fix is a better hosting plan. When it is, you’ll hear that before you pay for anything else.
Keeping the site fast after the fix
The usual reason a fixed site gets slow again is a new plugin or tag added without anyone checking. A simple performance budget for each template, plus a weekly check of Core Web Vitals and page weight, stops that. Leak watch does those checks for you, and fixes regressions within two business days.