How to Improve Website Speed: A Practical Core Web Vitals Guide (LCP, INP, CLS)

People abandon slow websites, and search engines notice. Speed influences conversion rates, ad costs, SEO and how professional your business feels. The challenge is that "make it faster" is vague. This guide turns it into a concrete, ordered plan built around Google's Core Web Vitals.

Key takeaways

• Core Web Vitals: LCP 2.5 s or less, INP 200 ms or less, CLS 0.1 or less, judged at the 75th percentile of real visits.
• Images, server response and render-blocking resources cause most LCP problems; heavy JavaScript causes most INP problems; missing dimensions and late-loading content cause most CLS problems.
• Measure with field data (Search Console, CrUX) and use lab tools to debug.

The three Core Web Vitals

A page passes when it meets all three at the 75th percentile, assessed separately for mobile and desktop. INP replaced the older First Input Delay metric in 2024.

Step 1: measure properly

• Google Search Console, Core Web Vitals report: field data for groups of URLs on your site.
• PageSpeed Insights: shows field data (if available) and lab diagnostics for a single URL. Try our free website speed test tool.
• Chrome DevTools and Lighthouse: lab debugging, performance traces and waterfall charts.
• WebPageTest: detailed waterfalls from different locations and devices.

Remember: a perfect Lighthouse score can still hide poor real-user INP, because INP depends on real interactions. Always check field data.

Step 2: fix LCP (loading speed)

First find your LCP element: usually a hero image, a large heading or a video poster. Then attack the four parts of LCP: server response, resource discovery, resource download and rendering.

Improve server response time

• Use quality hosting close to your audience.
• Cache HTML pages and use a CDN so content is served from a nearby edge location.
• Optimise slow database queries and reduce heavy server-side work.
• Prefer static generation or incremental regeneration for pages that rarely change.

Optimise the hero image

• Use modern formats (WebP or AVIF); they are commonly 30 to 50 percent smaller than JPEG or PNG at similar quality.
• Serve correctly sized images with srcset and sizes; do not send a 3000-pixel photo to a phone.
• Never lazy-load the LCP image; give it high fetch priority and preload it if needed.
• Compress aggressively: most web photos look fine under 100 to 150 KB. Use our free image compressor.

Remove render-blocking resources

• Inline critical CSS; load the rest asynchronously.
• Defer or async non-critical JavaScript.
• Host fonts yourself, use font-display: swap and preload the key font file.
• Remove unused CSS frameworks and plugins.

Step 3: fix INP (responsiveness)

INP is almost always a JavaScript problem: the main thread is busy and cannot respond to taps.

• Ship less JavaScript: audit your bundle; remove unused libraries; replace heavy dependencies with lighter ones.
• Code split: load features only on pages that need them.
• Break up long tasks: anything over 50 ms blocks interaction. Split work into smaller chunks and yield to the main thread.
• Move heavy computation to Web Workers or the server.
• Audit third-party scripts: chat widgets, tag managers, heatmaps and ads are frequent culprits. Load them late or remove them.
• Keep the DOM small: huge pages with thousands of nodes slow every update.
• Give instant feedback: show a pressed state or spinner immediately, even if the full action takes longer.

Step 4: fix CLS (visual stability)

• Set width and height (or aspect-ratio) on every image, video and iframe so the browser reserves space.
• Reserve space for ads, banners and embeds instead of injecting them above existing content.
• Avoid inserting content above what the user is reading, such as late cookie banners that push the page down.
• Handle fonts carefully: use matching fallback metrics to reduce text reflow when web fonts load.
• Animate with transforms rather than properties that cause layout changes.

Step 5: general speed boosters

• Enable compression (Brotli or gzip) on text assets.
• Use HTTP/2 or HTTP/3 and long-lived cache headers for static files.
• Lazy-load below-the-fold images and iframes.
• Preconnect to critical third-party origins.
• Minify CSS and JavaScript; remove unused code.
• Limit fonts to two families and a few weights.
• Replace video backgrounds with optimised images unless truly essential.

Platform-specific advice

WordPress

Choose fast hosting, use a lightweight theme, install one caching plugin, remove plugins you do not need, optimise images on upload and consider a CDN. Page-builder bloat is a common cause of poor INP and LCP.

Shopify and e-commerce

Audit apps (each adds scripts), compress product images, avoid heavy sliders and use lightweight themes.

Next.js and modern frameworks

Use the built-in image and font components, prefer server components and static rendering where possible, and watch client bundle size. See why Next.js suits business websites.

Priority checklist (highest impact first)

1. Compress and properly size your hero image; do not lazy-load it.
2. Add a CDN and caching for HTML and static assets.
3. Remove or defer third-party scripts you do not truly need.
4. Set dimensions on all media.
5. Reduce JavaScript bundle size and long tasks.
6. Optimise fonts.
7. Upgrade hosting if server response (TTFB) is consistently slow.
8. Re-test with field data after changes; allow about 28 days for Search Console to reflect improvements.

How speed connects to the rest of SEO

Speed supports, but does not replace, relevance, helpful content, clear structure and good metadata. Combine this guide with our technical SEO checklist for the full picture.

A worked example: fixing a slow homepage

Imagine a service-business homepage that takes 5.5 seconds to show its main content on a mid-range phone. A typical diagnosis and fix list looks like this:

None of these fixes needs a redesign, and together they commonly cut load times dramatically. Always re-measure after each change so you know what worked.

How to read a waterfall chart

1. Open DevTools, go to the Network tab, disable cache and reload on a throttled mobile profile.
2. Find the request for your largest visible element. When does it start and finish?
3. Look for gaps before it starts: they usually mean waiting on CSS, JavaScript or a slow server response.
4. Sort by size to see the heaviest files, and by time to see the slowest.
5. Check which third-party domains appear. Each one is a cost you can question.

A performance budget for your team

Write limits down so speed does not erode over time:

• Total JavaScript on key pages: under about 200 KB compressed for marketing pages.
• Hero image: under about 150 KB.
• Total page weight: under about 1.5 MB on mobile.
• Third-party scripts: each must justify its existence, with an owner.
• Core Web Vitals: all three in the "good" range at the 75th percentile on mobile.

These are practical targets, not official rules. Adjust them to your site's purpose.

Monitoring: keep it fast after launch

• Check the Core Web Vitals report in Search Console monthly.
• Add real-user monitoring to see actual visitors' experience across devices and countries.
• Run lab tests on every release, and fail the build if budgets are broken.
• Re-audit after adding marketing tags, plugins or new page templates; they are the usual cause of regressions.

Speed myths

• "A 100 Lighthouse score means a fast site." It is a lab simulation; real users on real devices decide.
• "A CDN fixes everything." It helps delivery but cannot fix heavy JavaScript or oversized images.
• "More caching plugins are better." Stacking caches causes conflicts; use one well-configured solution.
• "Speed only matters for SEO." It matters for conversions, ad costs and customer trust first.

Need a faster site?

Our team builds and audits websites for Core Web Vitals as part of our web development service. Request a free performance review and we will show you your biggest bottlenecks.