To improve Core Web Vitals on WordPress, first find which metric fails on which pages in Search Console, then fix the cause: a page cache and faster hosting for slow LCP, correctly sized and prioritised hero images, fixed dimensions for images, ads and embeds to stop layout shift (CLS), and fewer or delayed third-party scripts for slow interaction (INP). Re-test with real-user data after 28 days.
Most WordPress speed advice starts with plugins. I start with measurement, because the fix for a slow LCP is completely different from the fix for a poor INP. If you would rather have it done for you, see my technical SEO service.
The three metrics and their targets
| Metric | What it measures | Good (75th percentile) | Usual WordPress cause |
|---|---|---|---|
| LCP — Largest Contentful Paint | How fast the main content (often the hero image or heading) appears | ≤ 2.5 s | Slow server response, no page cache, huge hero image |
| INP — Interaction to Next Paint | How fast the page responds to taps, clicks and typing | ≤ 200 ms | Heavy JavaScript from page builders, sliders, chat and tracking scripts |
| CLS — Cumulative Layout Shift | How much content jumps while loading | ≤ 0.1 | Images without dimensions, late-loading ads, banners and web fonts |
INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. Targets are from Google’s web.dev documentation.
Step 1: Measure before changing anything
- Search Console → Core Web Vitals report. Shows which groups of URLs fail on mobile and desktop, based on real visitors. This is your source of truth.
- PageSpeed Insights for a single URL. The top section (“Discover what your real users are experiencing”) is field data; the score below it is a lab test on a simulated device.
- Note the baseline: metric values, the page, the date and the device. Without it you cannot prove a change worked.
New or low-traffic sites may show “not enough data”. Then rely on lab tests in PageSpeed Insights and Chrome DevTools, testing on mobile with throttling — many visitors in Pakistan browse on mid-range Android phones over 4G, where heavy JavaScript hurts most.
Step 2: Fix LCP (slow main content)
- Turn on page caching. On LiteSpeed hosting (including Hostinger), install LiteSpeed Cache; elsewhere use your host’s cache or a plugin such as WP Rocket. Cached pages skip PHP and database work.
- Check server response time (TTFB). If it stays above about 0.8 s with caching on, the hosting plan or server location is the bottleneck. Choose a data centre close to your visitors and add a CDN such as Cloudflare.
- Resize and compress the hero image. Upload it at the size it is displayed (often 1200–1600 px wide), in WebP or AVIF. A 3 MB camera photo as a hero is the most common LCP problem I see.
- Never lazy-load the hero image. Since WordPress 6.3, core adds
fetchpriority="high"to the likely LCP image and skips lazy-loading it — but sliders and page builders often override this. Disable lazy-loading for above-the-fold images in your optimisation plugin. - Avoid sliders in the hero. A single static image or heading loads faster and converts as well.
Step 3: Fix CLS (content jumping)
- Give every image and video width and height (or a CSS
aspect-ratio) so the browser reserves space. - Reserve space for ads, embeds and banners. Cookie bars and promo strips should overlay the page, not push it down.
- Load fonts carefully. Host fonts locally, preload the main one and use
font-display: swapwith a similar fallback font to limit text reflow. - Do not inject content above existing content after load (for example, “Free delivery” bars added by JavaScript).
Step 4: Fix INP (slow response to taps)
- List every script on the page (DevTools → Network → JS). Remove plugins you no longer use; each active plugin may add scripts to every page.
- Delay non-essential JavaScript until the visitor interacts: chat widgets, heatmaps, social embeds and extra tracking pixels. LiteSpeed Cache and WP Rocket both have a “delay JS” option — test forms and menus afterwards.
- Lighten the page builder. Disable unused widgets and animations; replace heavy mega-menus and sliders.
- Find long tasks in DevTools → Performance. Anything blocking the main thread for over 50 ms delays the next tap.
Quick reference: problem → fix
| Symptom | Likely fix | Tool or setting |
|---|---|---|
| LCP over 2.5 s, high TTFB | Page cache, better hosting, CDN | LiteSpeed Cache, Cloudflare |
| LCP slow, TTFB fine | Smaller hero image, no lazy-load on it | WebP/AVIF conversion, plugin exclusions |
| CLS above 0.1 | Image dimensions, reserved ad space, font loading | Theme settings, CSS aspect-ratio |
| INP over 200 ms | Remove or delay third-party and builder scripts | Delay JS, plugin audit, DevTools Performance |
When a rebuild makes more sense
If a site still fails after caching, image and script work — usually because of a heavy theme, a dozen overlapping plugins or a builder that cannot be slimmed — rebuilding can cost less than endless tuning. A server-rendered Next.js site ships far less JavaScript and keeps content editable through a headless CMS. Read custom development vs WordPress to decide, or see my website development service.
