Core Web Vitals are the three measurements Google uses to judge how a page feels to load and use: how fast the main content appears, how quickly the page responds to a tap, and how much the layout jumps around. A site full of 3D and animation can pass them, but only if the words on the page never have to wait for the effects.
Our own site is the test case. It runs WebGL scenes on almost every page, and on a slow phone it was failing badly. This is what we measured, what we changed, and the numbers before and after, including the part we haven't solved.
What are the Core Web Vitals, and what counts as passing?
There are three, and Google's definitions set a "good" threshold for each:
- Largest Contentful Paint (LCP) is when the biggest piece of content finishes appearing. Good is 2.5 seconds or less.
- Interaction to Next Paint (INP) is how long the page takes to react when someone taps or types. Good is 200 milliseconds or less.
- Cumulative Layout Shift (CLS) is how much the page moves while it loads. Good is 0.1 or less.
A page passes when 75% of real visits hit those numbers, counted separately for phones and desktops. That last detail matters. A site can be instant on a developer's laptop and still fail, because the phones are judged on their own.
Do they affect rankings? Google's Search documentation says good Core Web Vitals line up with what its ranking systems try to reward, and recommends achieving them. It doesn't say they outrank relevance. We treat them as a floor: they won't make a weak page rank, but a slow one gives visitors a reason to leave before they read anything.
How did we measure it?
On a simulated slow phone, because that's where sites fail. Every number in this article comes from the same setup: a 375-pixel-wide screen, the processor slowed to a quarter of its speed, a 1.6 Mbps connection with 150 milliseconds of delay, and an empty cache, as if it were a first visit.
That is a lab test. It isn't the same as the field data Google collects from real visitors, and our site doesn't have enough traffic yet for field data to exist. Lab numbers are still the right tool for finding out what is slow and whether a change helped. Just don't read them as your Search Console score.
One number we lean on is Total Blocking Time. It adds up the moments when the page is too busy running JavaScript to respond. It isn't a Core Web Vital itself, but it's the best lab stand-in for INP, which can only be measured when a real person interacts.
Why was the text slow to appear?
Because our animation library was hiding it. This was the biggest single problem, and it had nothing to do with 3D.
The headline and intro at the top of each page faded in with a JavaScript animation. To make that fade work, the server sent the text with its opacity set to zero. So the words were in the page from the first moment, but invisible until the animation code had downloaded, started up and run. On the slow phone that took about three seconds after the page first painted.
Google's own guide to improving LCP calls this out: when the main element is hidden until JavaScript finishes loading, speeding up everything else doesn't help. The time just moves into the wait.
The fix was to keep the entrance but change how it's done. The text now slides up using plain CSS, moving but never invisible, so it paints with the very first frame. On a service page, the gap between first paint and the main content appearing went from 3.0 seconds to 0.8. On a blog article it went from 3.0 seconds to 0.85.
If you take one thing from this article, check that your largest text isn't sitting at zero opacity waiting for a script.
Should a phone load the 3D scene at all?
On most pages, no. The 3D engine is about 230 KB of compressed JavaScript before it draws anything, and then the phone has to compile the graphics code. On a small screen the scene sat behind the text anyway, mostly out of sight.
So on inner pages the scene now only starts on screens 768 pixels wide or more. Phones get a static glow in the same colours. Anyone with their browser's data saver switched on gets the static version too, whatever their screen size.
Blocking time on a service page fell from 1,199 milliseconds to 568. On a blog article it fell from 1,000 to 473.
The home page was the harder call, because the 3D hero is the point of it. We kept it on desktop and removed it on phones, where the hero is now one ordinary screen. In our tests on a local build, home page LCP went from 3.3 seconds to 2.5, blocking time from 1,034 milliseconds to 336, and the JavaScript loaded from 647 KB to 409 KB. Desktop didn't change.
When should a scene further down the page start?
When it's about to be seen, and not before. Scenes below the first screen wait until they scroll into view before loading anything.
We got this wrong first. To avoid a flash of empty space, scenes started loading 200 pixels before they reached the screen. On a desktop that's sensible. On a phone, 200 pixels below the first screen was close enough that the next scene started loading immediately, and pulled the whole 3D engine in at page load. The fix was one line: that head start is now zero on phones.
Once a scene is running, it pauses when it scrolls out of view, and it lowers its own resolution if the frame rate drops. Those two don't change the loading scores, but they're why the page stays responsive while you scroll.
What about video and analytics?
Both were costing more than they looked.
The background video on the home page was 3.8 MB. Re-encoded at the same 1280 by 720 size, it's 0.7 MB, and you can't see the difference behind a dark overlay. Videos also don't download until they're near the screen.
Analytics now loads after everything else on the page has finished, not alongside it. A visit is still counted. It just no longer competes with the content for a slow phone's attention.
What is still too slow?
The live site, on the same slow-phone test, measured on 5 October 2026:
- Service page: main content at 2.9 seconds.
- Blog article: 3.2 seconds.
- Home page: 4.2 seconds.
None of those is under 2.5 yet, and we'd rather say so than quote only the flattering numbers.
Two things are left. The first is distance. The server answered in 0.7 to 0.8 seconds from where we tested, which uses up a third of the budget before the page has started. The site runs from one region with no content delivery network in front of it. That's next.
The second is the home page, where there is still a gap of more than a second between the first paint and the main paragraph appearing. We haven't found the cause yet. When we do, we'll update this article with what it was.
A checklist for an animated site
- Test on a throttled phone profile, not on your own laptop.
- Make sure the largest text is visible in the HTML the server sends, with no script needed to show it.
- Animate with CSS transforms where you can, so nothing starts invisible.
- Load 3D only where it will be seen: skip small screens and data saver mode on pages where it's decoration.
- Start below-the-fold scenes when they reach the screen, and check that rule on a phone-sized viewport.
- Pause scenes that are off screen and let them drop resolution under load.
- Compress background video hard and don't download it until it's near the screen.
- Load analytics after the page, not with it.
- Measure again after every change, and write the numbers down.
This is the work behind the "Core Web Vitals tuning" line in our Website Development service. The three sites in our case studies are built the same way, with every visual drawn in code and the heavy parts loaded late. If your site is slow and you're not sure why, tell us about it.
Common questions
Are Core Web Vitals a Google ranking factor?
Google says good Core Web Vitals align with what its ranking systems reward, and recommends achieving them. They are one signal among many, and relevance matters more. In practice a fast page won't outrank a more useful one, but between two similar pages the faster one has the edge, and visitors are less likely to leave.
What is a good LCP score?
2.5 seconds or less, for at least 75% of visits, measured separately on phones and desktops. Between 2.5 and 4 seconds is rated "needs improvement", and above 4 seconds is poor. The score that counts comes from real visitors, so a result from one test on a fast laptop tells you very little.
Does Three.js or WebGL hurt Core Web Vitals?
It can, mainly through the JavaScript it adds and the work the phone does to start it. It doesn't have to. Load it after the text has painted, skip it on small screens where it adds little, and start scenes only when they're about to be seen. Our own pages show text first and 3D second.
Do animations slow down a website?
Not by themselves. The damage comes from animations that hide content until a script runs, because the main content can't count as loaded while it's invisible. An animation that moves or scales visible content with CSS costs almost nothing. One that starts at zero opacity and waits for JavaScript can add seconds.
What is the difference between lab data and field data?
Lab data comes from one controlled test on a simulated device. Field data is collected from real visitors over 28 days and is what Google uses. Use lab tests to find problems and check fixes, and field data to judge whether you pass. A new or low-traffic site may not have field data at all.
Can a site with heavy visuals still pass Core Web Vitals?
Yes, if the content doesn't depend on the visuals. Send the text and layout from the server, let them paint straight away, and bring the heavy parts in afterwards, only on devices that can handle them. The visuals then make a fast page more impressive, where before they were making it slow.
Want something like this built and run in your own accounts? That's what our Website Development service does. You can also see everything we build or look through our case studies.
