Site Speed: What Google Measures, What It Says, and What Slows a Page Down

On September 14, 2026, we typed “velocidade do site” (site speed) into Google. The search ran on Google in Brazil, where we are based. The first page was almost all testing tools. PageSpeed Insights, Pingdom, GTmetrix, and others ask for an address and hand back a number. ¹

The same page also showed Fast.com and Speedtest. Both measure the internet connection of whoever runs the test. ^{1 2} So, one boundary before we go on. Here, speed means how fast the page opens for the visitor.

The AI Overview for that search summed up what almost everyone is after. According to it, PageSpeed Insights gives scores from 0 to 100 and points out the failures. ¹

I ran that test on seogenome.com, our company site in Brazil, on September 14, 2026. On mobile, the homepage scored 98 for performance. ³ On the same screen, one block up, the site’s real visitors told another story. In the test, the largest element on the page appeared in 1.4 seconds. In real visits, the figure was 2.4 seconds. ³

Both numbers are right. They measure different things, and this piece shows which. After that, we cover what Google says about speed and ranking, what Search Console groups, and what usually slows a site down. All of it with the documentation open, checked on September 14, 2026.

What the visitor feels

Picture walking into a store. You step inside and stand in the dark until the lights come on. You ask for help at the counter, and the clerk takes a while to look up. When you reach for an item on the shelf, someone moves the shelf.

None of those three waits fits into a single score. All of them wear down the patience of whoever walked in. Google groups these feelings with others, like a secure connection, good display on a phone, and no ads in the way. This is called page experience. ⁴

The three waits in the store each have their own metric, measured with data from real visitors. One looks at loading, another at the response to a tap, the last at how stable the screen stays. Together, they are called Core Web Vitals. ⁵ The names, the thresholds, and the fix for each one are in the piece on Core Web Vitals. Here the subject is speed as a whole.

What Google says about speed and ranking

Google has used speed as a ranking signal since April 2010. The announcement that year already came with caveats. The new signal carried less weight than the relevance of the page. ⁶ It affected fewer than 1% of searches, and only searches in English on Google.com. ⁶

In January 2018, it was mobile’s turn. Google announced speed as a ranking factor for mobile searches, starting that July. ⁷ The change would touch only the slowest pages and a small share of searches. ⁷ And the post repeated the 2010 caveat. A slow page can still rank well if it has great, relevant content. ⁷

Google’s current page on page experience was updated in December 2025. It says there is no single signal. Google’s core ranking systems look at a variety of signals that line up with page experience. ⁴ Core Web Vitals are among them. ⁴

According to the same page, the other parts of page experience do not directly help a site rank higher. They make the site more satisfying to use, and that lines up with what the ranking systems seek to reward. ⁴ The assessment usually happens page by page, with some site-wide assessments on top. ⁴

Picture two drugstores on the same street. If only one has your medicine, you wait in its line. If both have it, you walk into the one that serves you first.

The documentation puts things in the same order. Google Search seeks to show the most relevant content, even when the page experience is sub-par. ⁴ When there is plenty of helpful content for the same search, a great page experience can contribute to success. ⁴

The same page has a warning about scores. A good result in the Search Console report or in a third-party tool does not guarantee the top spot. And chasing a perfect score just for SEO may not be the best use of your time. ⁴

That leaves one question, where the data that counts comes from. The page on the Chrome User Experience Report answers it. Google Search uses that data to inform the page experience ranking factor. ⁸ And the data comes from real Chrome users. ⁸ Keep that detail in mind for the next section.

Lab and field: why the tools disagree

Think of the fuel economy sticker on a new car’s window. That number comes from a standardized test, run the same way for every model. It is there so you can compare one car with another. Your mileage in your own city’s traffic is a different number, and that is the one your wallet feels.

In site speed, the standardized test is called lab data. The city traffic is called field data.

Lab data comes from a page loaded in a controlled environment, with the device and network set in advance. ⁹ The web.dev article sums up the test’s limits in three words: one device, one network, one location. ⁹ The Chrome tools that report lab data generally run Lighthouse. ⁹ Lighthouse is open source and runs right inside Chrome, from the DevTools panel, on any web page. ¹⁰

Field data comes from real visits, with the devices, networks, and locations of the people who visit. ⁹ In Chrome, the source is the Chrome User Experience Report, known as CrUX. ^{8 9} It keeps a distribution over 28 days. Fast visits and slow visits both fit in it. ⁹

When a tool shows a single number for field data, that number is the 75th percentile. ⁹ In plain terms, three out of four visits were as good as that value or better. PageSpeed explains the choice. The goal is a page that works well for most people, even under the hardest device and network conditions. ¹¹

The web.dev article lists the reasons the numbers disagree. ⁹ The test usually starts with an empty browser, with nothing saved from an earlier visit. In real life, returning visitors already have part of the page on their device. The test also never scrolls or taps anything. A real person scrolls, taps, and selects text. ⁹ And the simulated device’s screen may show a different element at the top. ⁹

The priority rule is written down too. When you have both kinds of data for the same page, field data decides where to start. It shows what people actually experience. ⁹ Lab data helps you find the cause and test the fix before you publish. ⁹ And there is a reminder almost nobody reads. The field only records the people who managed to load the page. ⁹

PageSpeed Insights puts both on the same screen. At the top, real visitors from CrUX, over the last 28 days. Below that, the Lighthouse diagnosis, from a simulated load. ¹¹ The tool’s help page warns that a good lab score does not guarantee a good experience for real visitors. ¹¹

When the page does not have enough visits, the tool shows the whole site in its place. Sometimes even the site has no data, and the top section stays empty. ¹¹

Our own site: the 98 and the 2.4

Go back to the test from the opening. I ran PageSpeed Insights on the seogenome.com homepage on September 14, 2026, at 5:59 a.m. Brasília time, in mobile mode. ³

The lab simulated a Moto G Power on a slow 4G network, with the browser in North America. ³ The performance score was 98. The first content appeared at 1.0 second, and the largest element at 1.4. The list of third-party resources came back empty. ³

The top section warned that the homepage alone did not have enough visits. So it showed the whole site instead. ³ The period ran from August 15 to September 11. Three out of four visits saw the largest element within 2.4 seconds. One in ten waited more than 4 seconds. ³ The server’s response arrived within 0.8 second for three out of four visits. ³

The gap has three explanations, and all three are documented.

The window. The new site went live on September 2, replacing the old WordPress site at the same address. ¹² Of the 28 days measured, 18 still belonged to the old site. The field data carries the past for almost a month.

The device and the location. The lab simulates a phone on a set network, running far from Brazil. ³ The field is the real phone of each visitor, on whatever network that person had. ⁹

Consent. On the new site, audience measurement only turns on after the visitor accepts cookies. Before that, not a single request goes out to third parties. ¹² The test never taps anything, which is why the third-party list came back empty. ^{3 9} Whoever clicks accept gets more scripts than the test ever saw. ¹²

The internal record from September 2 already carried this caveat. Lighthouse had given a perfect score on all five pages measured, on mobile and on desktop. ¹² The team’s note warned that the measured site had no Google Analytics. So the score did not measure its impact. ¹²

Neither number lies. The 98 shows the page as the test received it. The 2.4 shows what visitors went through, with the old site and the new one added together. To judge only the new site, the window has to fill up with its own visits. By our count of the dates, that happens at the end of September 2026.

The Core Web Vitals report in Search Console

Picture a school that sends home one report card for the whole class. Each student’s grade gets diluted in the group. If the class does badly, everyone gets the same warning.

The Core Web Vitals report in Search Console works this way. It groups pages with a similar experience, which Google assumes share a common framework. And it gives the whole group one status. ¹³ This is called a URL group.

The data comes from CrUX, from real visitors. ¹³ The group’s status is that of its worst metric, and it reflects what 75% of visits got over the last 28 days. ¹³ The labels are Poor, Need improvement, and Good, split between mobile and desktop. ¹³

A few rules change how you read it. Only indexed pages appear, and the list is a sample. ¹³ The data stays tied to the address that was visited. In most other reports, it goes to the canonical URL. ¹³ A group without enough visits becomes an origin group, covering the whole site. With no data even for the origin, you get the “No data available” screen. ¹³

The report also mixes every location together. If a large share of visits comes from a country with slow internet, overall performance drops. ¹³

That brings another disagreement. PageSpeed shows the page, and the report shows the group. One page can be the outlier in its group. ¹³ PageSpeed also strips the parameters from the address before it shows the data. ¹³

A status that changes while you touched nothing also has an explanation in the help page. Many pages were sitting at the edge, and a site-wide event pushed them all over. A traffic spike or a slower image server is enough. ¹³

After you fix things, the validation button starts a 28-day monitoring session. It does not trigger reindexing. It only restarts the measurement clock. ¹³ The order of fixes, with Poor first and then the pages that matter most, is in Exam 3 of the SEO audit.

What usually makes a site slow

The AI Overview for the search lists scattered tips: images, code, and hosting. ¹ The Chrome team’s documentation shows where the time usually goes. Four suspects show up in almost every diagnosis.

The image at the top

The poster in the front window is the first big thing a visitor sees. On 73% of mobile pages, the largest element is an image. The figure comes from the 2024 Web Almanac, cited by web.dev. ¹⁴

Here is the part almost everyone misses. On most sites with poor loading, downloading that image takes less than 10% of the time. ¹⁴ On those pages, the main image waits 1.29 seconds before it starts downloading, at the 75th percentile. ¹⁴ Much of that wait comes from the browser finding the image late. On 35% of pages whose largest element is an image, its address was not even in the initial HTML. ¹⁴

The web.dev article points to two common causes. One is hiding the image behind a script. The other is telling the top image to wait until it scrolls into view, with the loading="lazy" attribute. ¹⁴ The same page records that 66% of pages have at least one image with no declared width and height. Without those measurements, the space starts at zero height, and the text jumps when the image arrives. ¹⁴

For readers who are not technical, the Search Console help gives two yardsticks. The whole page, with everything it pulls in, under 500 KB. And no more than 50 resources per page on mobile. ¹³

Fonts

Nobody hauls the whole toolbox out to tighten one screw. A site’s fonts do exactly that when they bring every weight and every character, and the page uses a fraction of them.

A font is also a file, and the browser usually holds back the text until it arrives. If it takes up a different amount of space than the backup font, the page jumps when it lands. ¹⁵ web.dev has a warning for anyone who hosts their own fonts. Font providers usually strip out the characters a page does not use. Whoever copies the file to their own server can lose that trimming and serve a bigger file. ¹⁵ This is called font subsetting.

That was the case on our own site. The first diagnosis of the new site pointed to the images on a few pages. The real weight was in the fonts, charged on every page: 50.3 KB of dead weight. ¹² The files carried the full weight axis, from 100 to 900, and the site asked for 400 to 600. ¹²

With subsetting, the main font dropped from 48 to 20.8 KB. ¹² Across that day’s fixes, the homepage went from 150 to 94 KB. In the recorded lab test, the largest element on mobile went from 1.95 to 1.50 seconds. ¹²

Third-party scripts

Imagine a store that lets five vendors set up booths at the entrance. Each one brings its own staff and its own noise. The customer walks past all of them before reaching the counter.

A third-party script is code that another company puts on your site. Social buttons, embedded videos, ads, analytics, and A/B testing all make web.dev’s list. ¹⁶ The article opens without hedging. If you have already optimized your code and the site still loads slowly, third-party scripts are probably to blame. ¹⁶

Many of these scripts come in through a tag manager. The web.dev article on the subject reports a correlation between larger tag managers and a slower response to taps. ¹⁷ A single tag may weigh very little. Dozens or hundreds on the same page weigh a lot. ¹⁷ The same article advises against loading the cookie notice and the main image through the tag manager. ¹⁷

Hosting

In a restaurant, no dish gets started until the kitchen confirms the order. On a page, that confirmation is the server’s first response. This is called Time to First Byte, or TTFB. ¹⁸

It comes before everything the visitor sees, and every delay in it pushes the rest back. ¹⁸ It is not one of the Core Web Vitals, and web.dev treats its thresholds as a rough guide. ¹⁸

The web.dev section on servers has the same word three times in its title: hosting. ¹⁸ Before any other tweak, the advice is to check whether the host can handle the traffic it gets. Shared hosting tends to be slower. For a small site that serves mostly static files, the article says it is probably fine. ¹⁸

On WordPress, the same article points to the number and quality of plugins and to the theme in use. ¹⁸ What WordPress does on its own and what a plugin adds is in the piece on SEO for WordPress. Two other things weigh on the first byte. Every redirect along the way adds waiting time. ¹⁸ So does a server far from the visitor. A content delivery network, or CDN, keeps copies close to the people who visit. ^{14 18}

A slow server also costs you with Google’s crawler. The crawl budget guide says the crawl capacity limit drops when the site slows down or responds with errors. Then Google crawls less. ¹⁹ The guide was written for very large sites. How to read that screen on a real site is in the piece on crawl budget.

The one-morning check

Pick the page on your site that gets the most visits from Google.

1. Open PageSpeed Insights in mobile mode. Read the top section first. Write down whether the data is for the page or for the whole site, and the period. ¹¹
2. Read the lab section as a diagnosis. Use the score to compare the page with itself, before and after a change. ^{9 11}
3. Check what changed inside the window. A platform switch, a new theme, or a migration in the last 28 days mixes two sites into one number. ⁹
4. Open the Core Web Vitals report, mobile version. Write down the groups in Poor and the example URL for each one. ¹³
5. Weigh the page. Compare it with the two yardsticks from the help page: 500 KB and 50 resources. ¹³
6. List the third-party scripts. For each one, ask who at the company uses that button or that data. ¹⁶
7. Look at the top image and the fonts. The image needs to be in the HTML, with no deferred loading. The fonts should carry only the weights and characters in use. ^{14 15}
8. Fixed something? Validate it. The Search Console monitoring takes 28 days. ¹³

The rest of the technical ground, from indexing to structured data, is in the technical SEO section.

From now on, when someone shows you a speed score, you will ask two things. Whether the number comes from the lab or from real visitors. And which period it covers.

The first answer tells you whether you are looking at a diagnosis or an experience. The second tells you which site the number is talking about.

Open PageSpeed Insights today, paste in the address of your most visited page, and read the top section first.