A common pitfall when reading Core Web Vitals optimization guides is blindly working through a checklist from top to bottom. The causes of latency differ for every site, and in most cases, just one or two bottlenecks drag down the entire score. No matter how much you optimize the other items, the numbers won’t budge.
That is why the process is always the same: Take inventory → Find the bottlenecks → Fix only those.
What Each of the Three Metrics Measures
| Metric | What it measures | Symptoms when poor |
|---|---|---|
| LCP (Largest Contentful Paint) | The point at which the largest element on the initial screen is rendered | The page remains blank for a long time before suddenly appearing |
| CLS (Cumulative Layout Shift) | The degree to which page elements shift unexpectedly | Text shifts downward while reading, or buttons move away just as you try to click them |
| INP (Interaction to Next Paint) | The time it takes for the screen to respond to clicks or inputs | Nothing happens when clicked, followed by a delayed response |
These three metrics stem from different root causes. Categorizing them broadly as LCP for loading, CLS for layout, and INP for JavaScript issues makes diagnosis much faster.
Measure First
There are two types of data, and failing to understand the difference will lead to wasted effort.
Lab Data — Simulated results from PageSpeed Insights or Lighthouse under standardized conditions. They are instantly available and great for root-cause analysis. However, they do not represent real-user environments.
Real-User Data (Field Data) — Values collected from actual visitors’ browsers. This data appears in the Search Console’s Core Web Vitals report and at the top of PageSpeed Insights. This is what actually impacts search rankings.
It is common to have a lab score of 90 but poor field data. This happens because visitors’ devices might be slow, their network connections poor, or the pages they actually visit differ from the ones you tested. As a rule of thumb, you should only optimize metrics where issues have been confirmed in your field data.
In Order of Impact
1. Images — On most sites, the LCP element is an image. This is where you will find the biggest gains.
- Format: Converting JPEG and PNG to WebP or AVIF significantly reduces file size while maintaining the same quality.
- Size: Do not serve a 2000px original image when it is only displayed at 400px on the screen. Use
srcsetto serve appropriate sizes for different devices. - Lazy Loading: Apply
loading="lazy"to images below the fold. However, never apply this to the LCP image—it will actually slow down loading. - Priority: Add
fetchpriority="high"to the main hero image on the initial screen.
2. Fonts — Korean web fonts are much heavier than English ones. This directly impacts perceived performance.
- Use
font-display: swapto display a fallback font first while the web font loads. - Only load the font weights you actually use. In most cases, Regular and Bold are more than enough.
- Use subset fonts. A font containing the entire Korean character set can be several megabytes in size.
- Preload critical fonts early using
<link rel="preload">.
3. Render-Blocking Resources — CSS and JS in the <head> block the browser from rendering the screen.
- Separate CSS that is not needed for the initial screen, and add
deferorasyncto scripts. - Audit external scripts (ads, chat widgets, analytics tools). It is common for a single line of third-party script to delay LCP by a full second.
4. Server Response Time (TTFB) — If this is slow, all subsequent optimizations are meaningless.
- Implement a CDN to serve static files from locations closer to your users.
- Enable server-side caching (page caching, database query caching).
- Identify slow database queries. Usually, a single query lacking an index is the culprit.
CLS: Visual Instability
The cause is almost always failing to reserve space for elements.
- Explicitly define
widthandheighton images and videos. This allows the browser to reserve space in advance. Even if you use CSS for responsive sizing, keep these attributes in place. - Set a minimum height for ad and embed containers. These are classic culprits for pushing down content when they load late.
- Layout shifts from font swapping: Use
size-adjustand other properties to minimize the visual difference between the fallback font and the web font. - Do not insert dynamically injected banners above existing content. If you must, pre-allocate space for them.
INP: Sluggish Responsiveness
If the browser is busy with other tasks when a user clicks, the response will be delayed.
- Break up long tasks. If a JavaScript task runs for hundreds of milliseconds at a time, user inputs will be queued and delayed.
- Keep event handlers lightweight. For heavy computations, render the UI feedback first and process the heavy work in the background.
- Remove unnecessary third-party scripts. They are common culprits for poor INP as well.
- Apply debouncing or throttling to scroll and input events.
Measure and Maintain
Optimization is not a one-time event. Performance can degrade every time new features, images, or scripts are introduced.
- Integrate Lighthouse audits into your deployment pipeline to trigger alerts if scores drop.
- Check the Search Console’s Core Web Vitals report once a month. Field data is aggregated over a 28-day window, so the impact of your optimizations will take that long to fully reflect.
- When optimizing, deploy changes one at a time. If you deploy five changes at once, you won’t know which one actually made a difference.
⚠️ Metric definitions and thresholds are subject to change. This article is current as of August 2026; please refer to web.dev and Search Console documentation for the latest thresholds.
Leave a Reply