Is your site slow? 5 website speed checks to do yourself in 15 minutes

A slow website costs you visitors before they read a word. The good news is that you can find out whether your site is slow, and roughly why, in about 15 minutes with free Google tools. Here are five website speed checks, in the order to run them, and what each result means.

Why speed matters for search and for sales

Speed affects both the people on your site and, to a degree, how Google ranks it. Google says its ranking systems use Core Web Vitals, but also that good scores do not guarantee top rankings and do not override relevance. Treat speed as a tie-breaker in search and a direct factor in whether visitors stay.

A failing score is common. The 2025 Web Almanac performance chapter found that 48% of mobile websites had good Core Web Vitals, up from 44% in 2024, with desktop at 56%. Loading speed was the weak point: only 62% of mobile sites had a good Largest Contentful Paint.

The thresholds you are checking against

Core Web Vitals are three measurements of real visits, each with a "good" limit published on web.dev. A page passes when at least 75% of visits meet all three.

If you read older advice about First Input Delay (FID), it is out of date. INP replaced FID as a Core Web Vital on 12 March 2024.

Check 1: read the field data in PageSpeed Insights (3 minutes)

Run your homepage and one key landing page through PageSpeed Insights, and read the top section before the score. That top section is field data: what real Chrome users experienced.

According to Google's PageSpeed Insights documentation, field data comes from the Chrome User Experience Report and covers the previous 28 days. The lab data below it comes from a single Lighthouse test on one simulated device with fixed network conditions. The two often disagree, and when they do, the field data describes your real visitors.

• If the field section says "passed" for Core Web Vitals, your speed is acceptable for most users, whatever the lab score says.
• If it says "failed", note which metric is red or amber.
• If there is no field data, your page has too little Chrome traffic to report. Use the lab data as a rough guide instead.

Check 2: open the Core Web Vitals report in Search Console (3 minutes)

PageSpeed Insights tests one URL; Search Console shows your whole site. The Core Web Vitals report groups similar URLs and labels each group Good, Need improvement or Poor, separately for mobile and desktop.

Two details help you read it. First, a group takes the status of its worst metric, so a group with good LCP but poor CLS shows as Poor. Second, the data comes from real users over the last 28 days, so a fix takes weeks to show. Google suggests fixing Poor groups before those that Need improvement.

Open a Poor group and note the example URLs. They usually share a template, such as product pages or blog posts, which means one fix can improve hundreds of pages.

Check 3: find oversized images (3 minutes)

On most business sites, the largest element on the page is an image, and it is often far bigger than it needs to be. In the Lighthouse section of PageSpeed Insights, look for the "properly size images" and image format suggestions, and note the largest file.

web.dev's image performance guide recommends sizing images to the space they fill multiplied by the screen's pixel density: a 500 by 500 pixel slot on a high-density phone needs about a 1000 pixel image, not a 4000 pixel camera original. It also recommends modern formats such as AVIF and WebP, with JPEG as a fallback, and setting width and height so the layout does not jump.

One warning from web.dev's guide to optimising LCP: do not lazy-load the main image at the top of the page. Put it in the HTML directly and consider fetchpriority="high" on that one image, so the browser fetches it first.

Check 4: count your third-party scripts (3 minutes)

Chat widgets, tracking tags, review badges and embedded videos all load code from other companies' servers, and each one competes with your own content. They are a common cause of poor INP, because scripts keep the browser busy when a visitor taps.

In PageSpeed Insights, look for the diagnostics on third-party code and main-thread work. Then list every tool you have added through your CMS or tag manager, and ask whether each one still earns its place.

web.dev's advice on loading third-party JavaScript efficiently is to load these scripts with async or defer unless they must run first, lazy-load embeds that sit below the fold, and remove scripts that add little value.

Check 5: test your server response time (3 minutes)

If the server is slow to send the first byte, everything else waits. Time to First Byte (TTFB) is shown in the field section of PageSpeed Insights.

web.dev's TTFB article gives 0.8 seconds or less as a rough guide for "good" and above 1.8 seconds as poor. TTFB is not a Core Web Vital itself, but a slow server makes a good LCP very hard to reach. Note that Lighthouse uses a stricter 600 ms limit for its own server response audit, because it measures a narrower slice of time.

If TTFB is consistently high, the usual causes are cheap shared hosting, no page caching, a server far from your visitors, or heavy plugins running on every request. For a site serving India, check where your server and CDN are located. If you put the site behind Cloudflare, review its bot settings too: our guide to blocking AI crawlers safely explains the Cloudflare setting that can block Googlebot by accident.

What we found when we compared Google's speed sources

We set the threshold and method details from web.dev, the Search Console help page, Google Search Central and the PageSpeed Insights documentation side by side, to check whether a site owner gets the same answer from each tool. To repeat this, open each page and note the thresholds, the data source and the time window.

The thresholds agree everywhere. The differences are in scope and data source, which is why the lab score alone can mislead. Our working rule: trust field data for "is it slow?", and use the lab test for "why is it slow?".

Turn your results into a fix list

Match the failing metric to its most likely cause, then fix the template rather than one page at a time.

1. Poor LCP: check the main image size and loading first, then server response time.
2. Poor INP: review third-party scripts and heavy page builders or sliders.
3. Poor CLS: add width and height to images and reserve space for banners, ads and embeds.
4. High TTFB: turn on caching, consider a CDN, or move to better hosting.

Speed is one part of a wider technical review. Our technical SEO audit checklist puts it alongside crawling and indexing, and the on-page SEO checklist covers image alt text and page structure.

When to call in help

If the five checks point to hosting, theme or plugin problems you cannot change yourself, that is the point to involve a developer or specialist. Our technical SEO service covers Core Web Vitals work. If you are budgeting for it, what SEO services cost in India explains the cost drivers, and you can get in touch with your PageSpeed Insights results.