“Make the site faster” and “make the site lighter” often end up on the same to-do list, and they often help each other. But they are different measurements. Page speed is about how quickly the page appears, responds and settles for a visitor. Page weight is how many bytes the visitor downloads. A carbon estimate is built on the second, not the first. Knowing where they overlap, and where they don't, saves you from fixing the wrong thing.
What Core Web Vitals measure
Google's Core Web Vitals are three measures of how a page feels to use:
- Largest Contentful Paint (LCP) measures loading. web.dev says it should happen within 2.5 seconds of the page starting to load.
- Interaction to Next Paint (INP) measures responsiveness: how quickly the page reacts to clicks, taps and key presses throughout a visit. The target is 200 milliseconds or less.
- Cumulative Layout Shift (CLS) measures visual stability: how much things jump around unexpectedly. The target is 0.1 or less.
web.dev recommends judging each at the 75th percentile of page loads, across mobile and desktop. None of the three is a measure of bytes.
Where weight and speed meet
They do overlap. Lighthouse's network payload audit says large network payloads are highly correlated with long load times, and that they cost users money on mobile data. It flags pages whose requests exceed 5,000 KiB and suggests aiming below 1,600 KiB.
The clearest link is LCP. web.dev's guide to optimising LCP splits it into four parts that add up to the total: time to first byte, the delay before the main image or text resource starts loading, the time to download it, and the delay before it is drawn. If your largest element is a 3 MB hero photo, its download time is part of your LCP, and shrinking it helps both your speed and your carbon estimate. That's why image weight is usually the first place to look.
A heavy page can feel fast
web.dev defines LCP as the render time of the largest image, text block or video visible in the viewport. Bytes that arrive afterwards, or that belong to content further down the page, don't have to hold it up. Imagine a page whose main heading and a modest photo appear quickly, followed by a gallery of large images further down. It can pass LCP comfortably and still send a lot of data.
Some of that weight may not show up in a carbon test either. A GreenTracer check loads the page once without scrolling, clicking or accepting cookie banners, so images that only load as you scroll, and tags that wait for consent, aren't counted. Visitors who scroll or accept still download them. A good speed score is welcome, but it doesn't tell you the page is light.
A light page can feel slow
The reverse happens too. A page with few bytes can still score badly on speed, for reasons weight doesn't capture:
- Slow server response. web.dev notes that nothing can happen in the browser until the server delivers the first byte, and that a high time to first byte can make a 2.5-second LCP hard or impossible. Multiple redirects are one cause it lists.
- Render-blocking files. Stylesheets or synchronous scripts in the page's head that are still loading can block the whole page from rendering, even after the main image has arrived.
- Busy JavaScript. The INP article says JavaScript is often the main driver of interactivity, and that long tasks on the main thread can delay the response to a click. A small script can still keep the browser busy.
- Layout shifts. The CLS article lists causes such as images or videos without known dimensions, fonts that render larger or smaller than their fallback, and ads or widgets that resize themselves. None of these needs many bytes.
Bytes, speed and the tools that report them
GreenTracer measures bytes, not speed. It uses Google PageSpeed Insights to load your page on mobile and desktop, takes the bytes transferred from the heavier of the two runs, and turns them into an estimate with the Sustainable Web Design Model v4. Your report doesn't give a speed score, and a good carbon grade doesn't mean the page is fast.
PageSpeed Insights itself reports both kinds of information. It shows real-user data from the Chrome UX Report, where a page passes the Core Web Vitals assessment if the 75th percentiles of all three metrics are good, and lab data from Lighthouse, which simulates a mid-tier phone on a mobile network and an emulated desktop. Lighthouse's diagnostics include the “Avoid enormous network payloads” audit, which lists the total size and the largest requests. Real-user data only appears when Google has enough samples for the page or site, which a recently published or quiet page may not have; web.dev says INP is best measured with real users.
A sensible order of work:
- Check your page with GreenTracer to see its weight and grade, and see why desktop and mobile results differ.
- Run the same address through PageSpeed Insights and note which Core Web Vitals need work.
- Fix what helps both first: oversized images, unused scripts and extra font files.
- Then fix speed-only problems, such as server response time, render-blocking files and layout shifts.
- Check again after each change, because both numbers can move.
