How to Increase Site Speed: A Core Web Vitals Guide
Improve site speed with a Core Web Vitals playbook covering LCP, INP, and CLS thresholds, image and JavaScript fixes, caching layers, and measurement.
Site speed is the common denominator of user experience and search visibility: a slow-loading page costs you both the visitor and the ranking. Google has standardized this area with the Core Web Vitals metrics, and the thresholds are clear.
Which metrics are measured?
| Metric | What it measures | Good threshold |
|---|---|---|
| LCP (Largest Contentful Paint) | Time until the main content appears | Under 2.5 seconds |
| INP (Interaction to Next Paint) | Delay in responding to interactions | Under 200 milliseconds |
| CLS (Cumulative Layout Shift) | Layout shift | Under 0.1 |
An important update: in March 2024, INP replaced the old FID metric. FID only measured the delay of the first interaction; INP evaluates every interaction on the page and sets a far tougher bar. Speed guides written for the 2021 era are incomplete for exactly this reason.
Why does speed determine conversion?
The impact is not abstract, it is measurable. In Webtures's work for Acibadem, reducing the INP of the form interaction from 480 ms to 165 ms lifted the mobile form start rate by 9.3 percent; pulling layout shift from 0.31 down to 0.04 brought mistaken taps close to zero, as detailed in the Acibadem success story.
How do you increase site speed?
- Optimize images. On most sites the heaviest load is imagery: WebP/AVIF formats, correct sizing, and lazy loading for offscreen images. The main image serving as the LCP element, however, should not be lazy loaded; it should be prioritized.
- Reduce and defer JavaScript. INP's chief enemy is scripts that lock the main thread; unused plugins and tracking codes get removed, non-critical scripts get deferred.
- Build caching in layers. Browser cache, server cache, and a CDN must work together; on a repeat visit the page should return without ever touching the server.
- Speed up the server response. If TTFB exceeds 600 ms, the problem is not the page but the infrastructure: review hosting quality, database queries, and edge distribution.
- Stabilize the layout. Define dimensions for image and ad slots, and load fonts without causing shifts; CLS mostly comes from these two sources.
How do you measure speed?
Two types of data must be kept separate. Lab data (PageSpeed Insights, Lighthouse) is a controlled test; good for diagnosis. Field data (CrUX, the Core Web Vitals report in Search Console) is real-user measurement; this is what Google uses for ranking. A site that looks fast in the lab but is slow in the field must be tested under real-user conditions: a mid-range phone on a mobile network.
The new stakeholder in speed: AI agents
Speed is no longer only a human visitor's concern. AI agents and agentic browsers load pages the way real users do and time out on slow ones; a slow site simply cannot exist in this new traffic layer. You can measure your site's agent-side readiness for free with the AI Agent Readiness tool.
Common mistakes
The most common mistake is turning the score into the goal: instead of chasing a 100, keeping the three metrics under their thresholds is enough. The second is one-off optimization; every new plugin and campaign code eats speed back, so measurement must be continuous. The third is measuring only the homepage: users mostly land on inner pages, and that is where conversion happens; the experience as a whole is covered in our user experience glossary entry.
Let us make your brand visible in AI search.
Share your goals, we'll come back with a custom growth plan within one business day. A strategy lead will reach out personally.
Get in touch