How Do I Check My Page Speed and Why Does It Matter?

Where to check, all free

You do not need a paid tool to know if your site is slow. Two Google tools and your own phone cover the whole question:

Reading PageSpeed Insights right

Go to pagespeed.web.dev, enter a URL that earns traffic, and run the test. Then read it in this order, which is not the order the page presents:

1. The field data at the top. This is what real visitors experienced over the last 28 days, and it is what Google uses. If it says your LCP is 3.1 seconds, that is the number that matters.
2. The mobile tab. Most visits and almost all slowness are on phones. Desktop passing means little if mobile fails.
3. The score, last and lightly. It is one simulated load, it wobbles between runs, and Google does not rank with it. Use it to debug, never to celebrate.

Reading the Search Console report

PageSpeed Insights checks one page. The Core Web Vitals report in Search Console checks all of them, which is the view you actually fix from. Open it from the left sidebar, under Experience, and give it a moment: the report only exists once your site has enough real traffic to measure.

Three things make this report the better starting point:

• Pages are grouped by template. The report clusters similar pages, so a Poor group almost always means one layout, not scattered URLs.
• One template fix repairs the whole group. Fixing the product-page layout fixes every product page at once, which is why this report beats testing URLs one by one.
• No data is not a failure. Small sites lack the traffic for field data. That is absence of evidence, nothing more.

What counts as fast

Five numbers appear across both tools. Three are the actual Core Web Vitals, two are supporting diagnostics:

If a metric is failing and you want the fix rather than the definition, how to fix your Core Web Vitals works through each one with the exact repairs.

Reading a result: a worked example

Say a product page comes back with mobile field LCP at 2.8 seconds, a lab score of 61, and a desktop tab that passes everything. Here is the whole diagnosis:

• The 2.8 seconds is the finding. Real phone visitors wait almost three seconds for the main content. That is over the 2.0 threshold and worth fixing.
• The 61 is noise. It will read 55 or 68 on the next run. Do not report it, and do not chase it.
• The passing desktop tab changes nothing. Most visits are mobile, and Google weights what visitors actually experience.

One sentence for the ticket: mobile LCP on the product template is 2.8 seconds, likely the hero image, target under 2.0. That is a speed check done well.

Why speed matters, honestly sized

Three real reasons, in order of how much they should move you:

• Visitors leave slow pages. This is the biggest effect and it shows up in revenue, not rankings. People bounce before a slow page finishes, and no ranking survives contact with a page nobody waits for.
• Speed decides close ranking contests. Since the March 2026 core update, Core Web Vitals are scored site-wide, so a few Poor templates drag on the whole domain. The effect is a margin, not a cliff.
• AI search reads fast pages more. Pages with FCP under 0.4 seconds earn 6.7 times more AI citations in our research. Speed is becoming a visibility input twice over.

The honest ceiling: speed will not rescue weak content, and it does not explain a large collapse on its own. If your whole site is struggling, run the 20-minute SEO problem check before blaming milliseconds.

Which pages to check first

Do not test your homepage and stop, which is what almost everyone does. The homepage is usually your most optimized page and your least typical one, so it passes while the templates that earn your traffic quietly fail. Check in this order instead:

1. Your top pages by search clicks. Slowness there has traffic actually at stake.
2. One page per template. A product page, a blog post, a category page. Each result covers its whole family.
3. The pages you are about to promote. A campaign landing on a slow page pays for the slowness in ad spend.

CrawlRaven runs this prioritization automatically: the crawl checks speed on every page and the Search Console join ranks the slow ones by the traffic they carry. With the MCP server connected, the list is a question:

List the pages on [your site] with the most impressions over the last 28 days, grouped by page type, so I know which templates to speed-test first.

What to do with a bad result

Three steps, and the order protects you from the classic mistake:

1. Confirm it in field data. A bad lab score on a page whose field data passes is a debugging note, not an emergency.
2. Identify the failing metric and template. LCP, INP, or CLS, on which layout. That pair defines the actual job.
3. Go fix that one thing. The metric-by-metric fix guide takes it from here, one metric at a time.