{"id":1001,"date":"2026-10-10T10:00:00","date_gmt":"2026-10-10T10:00:00","guid":{"rendered":"https:\/\/kryloweb.com\/blog\/?p=1001"},"modified":"2026-10-29T06:58:32","modified_gmt":"2026-10-29T06:58:32","slug":"how-to-improve-core-web-vitals","status":"publish","type":"post","link":"https:\/\/kryloweb.com\/blog\/how-to-improve-core-web-vitals\/","title":{"rendered":"How to Improve Core Web Vitals: What Worked on Our Own Site"},"content":{"rendered":"\n

Core Web Vitals are three measurements Google uses to judge how a page feels to use: how fast the main content appears (Largest Contentful Paint, good under 2.5 seconds), how fast the page responds to a tap or click (Interaction to Next Paint, good under 200 milliseconds), and how much the layout jumps while it loads (Cumulative Layout Shift, good under 0.1). How to improve Core Web Vitals comes down to one method: find out which of the three is failing, find the file or script that causes it, and fix that, one change at a time, measuring after each.<\/p>\n\n\n\n

That is the whole method. The rest of this post is what it looked like on a real site: ours. The homepage of kryloweb.com runs a 3D particle scene, which is about as heavy as a business website gets. When we first ran it through Google’s PageSpeed Insights, the desktop performance score was 64 and Total Blocking Time was over 20 seconds. After the work below, a Lighthouse test with the same desktop settings scores 99, with 40 milliseconds of blocking time, and the scene looks the same.<\/p>\n\n\n\n

\"How<\/figure>\n\n\n\n

What the three Core Web Vitals measure<\/h2>\n\n\n\n

Each metric answers a different question, and each has its own usual causes.<\/p>\n\n\n\n

Metric<\/th>Question it answers<\/th>Good<\/th>Poor<\/th>Usual causes when it fails<\/th><\/tr><\/thead>
Largest Contentful Paint (LCP)<\/td>How long until the main content is visible?<\/td>Under 2.5 s<\/td>Over 4 s<\/td>Large images, slow server, render-blocking styles and fonts<\/td><\/tr>
Interaction to Next Paint (INP)<\/td>How quickly does the page react when you tap or click?<\/td>Under 200 ms<\/td>Over 500 ms<\/td>Long JavaScript tasks, heavy third-party scripts<\/td><\/tr>
Cumulative Layout Shift (CLS)<\/td>Does the page jump around while loading?<\/td>Under 0.1<\/td>Over 0.25<\/td>Images without set sizes, late banners, font swaps<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Google judges each one at the 75th percentile of real visits, so three quarters of your visitors need a good experience for the page to pass.<\/p>\n\n\n\n

\"Core<\/figure>\n\n\n\n

Field data and lab data are not the same thing<\/h2>\n\n\n\n

This tripped us up at first, and it trips up most site owners. PageSpeed Insights shows two kinds of numbers on the same screen.<\/p>\n\n\n\n

Field data comes from real Chrome users over the last 28 days. It is what Google uses for search, and it appears only once a page has enough traffic. A new site often has none.<\/p>\n\n\n\n

Lab data is a single test run on one of Google’s machines, with a simulated phone and network. It gives the performance score out of 100 and lists what slowed the page down. It is useful for finding causes, but it is one machine on one day.<\/p>\n\n\n\n

Our 64 was a lab score. That matters for what follows.<\/p>\n\n\n\n

The problem: a test machine without a graphics card<\/h2>\n\n\n\n

Our blocking time was more than 20 seconds, which made no sense on a computer with a normal graphics chip, where the 3D scene ran smoothly. The answer was in the test machine. PageSpeed runs on servers without a graphics card, so the browser draws 3D graphics in software on the main processor. Our scene, which takes a graphics chip a few milliseconds, took the processor seconds, and every second counted as blocking time.<\/p>\n\n\n\n

Real visitors with a graphics chip never saw that cost. A visitor on a weak phone could have seen some of it.<\/p>\n\n\n\n

How we improved Core Web Vitals, one fix at a time<\/h2>\n\n\n\n

1. Skip the 3D scene when there is no real graphics chip<\/h3>\n\n\n\n

Before loading the 3D code at all, the page now asks the browser whether it would draw in software. If it would, the page shows a painted version of the sky instead and never downloads the 3D files.<\/p>\n\n\n\n

In a local Lighthouse test that imitates the PageSpeed machine, Total Blocking Time fell from 540 milliseconds to 0, and main thread work from 8.9 seconds to 1.7 seconds.<\/p>\n\n\n\n

2. Load the heavy code after the page is usable<\/h3>\n\n\n\n

The 3D files now load when the browser is idle, after the text and buttons are already on screen. The visitor can read and scroll first; the scene arrives a moment later.<\/p>\n\n\n\n

3. Remove the styles that block the first paint<\/h3>\n\n\n\n

The page used to load its stylesheet as a separate file, and the browser waits for that file before it draws anything. The styles are now written into each page, so there is nothing to wait for. The site’s CSS is small enough for this to be the faster choice. On a site with a large stylesheet it might not be.<\/p>\n\n\n\n

4. Stop redrawing things nobody can see<\/h3>\n\n\n\n

Some fixes came from Safari, which was slower than Chrome on the same machine. We found a full-page grain texture that the browser blended over everything on every frame, a gradient that was regenerated as a new image every frame, and hidden sections that were still being composited. Removing the grain, moving the gradient instead of redrawing it, and fully hiding inactive sections made scrolling noticeably smoother in Safari’s engine.<\/p>\n\n\n\n

5. Lower quality only when the device really needs it<\/h3>\n\n\n\n

The scene can reduce its own detail on slow devices. Our first version lowered quality whenever the frame rate dropped below 45 a second. That backfired on Macs and iPhones in Low Power Mode, which cap every page at 30 frames a second however light it is, and the scene dropped to its lowest quality for no reason. It now times how long a frame takes to draw before deciding, so a capped browser keeps full quality and a genuinely slow device still steps down.<\/p>\n\n\n\n

What didn’t work<\/h2>\n\n\n\n

Four things we tried first and had to change.<\/p>\n\n\n\n