Website performance

How to Speed Up Your Website With 12 Route-Level Diagnostics

Want measurements for your own page? Run a free technical website audit before choosing a fix.

Platform labels do not diagnose performance. Follow the request from DNS and document delivery through rendering and interaction, fix the measured constraint, and compare the same page state after each change.

Reviewed September 19, 2026 against current Google, Chrome and CrUX guidance.

Hassan Jamal·April 30, 2026·14 min read

Before the 12 diagnostics

✓
Name the page, what the visitor was doing, the device, the region, what they consented to, and what it is costing you.
✓
Separate Chrome field data from a Lighthouse lab result.
✓
Keep at least three comparable runs per agreed profile and preserve raw reports.
✓
Do not use a universal three-second rule, platform ceiling or sub-second promise.
✓
After speed work, retest that it still works, is still accessible, still tracks, and still respects consent.

Delivery

Everything between the click and the first byte.

Rendering

Everything between the first byte and a usable page.

Experience

Field LCP, INP and CLS plus the actual visitor journey.

On this page

Where to start, based on your current score

Twelve diagnostics is the full sweep. You rarely need all twelve, and which ones matter depends on where you are starting from. Get a number first, then jump to the step that fits it.

If you do not have a score yet: run PageSpeed Insights on one specific URL, not your homepage by habit. Read the top panel first, not the score. That panel is Chrome field data: real visits, the slowest quarter of them, over the last 28 days. The coloured score underneath is a lab simulation of a single load on a throttled mid-range phone. When the two disagree, the field data is the one describing your visitors.

Which of the twelve diagnostics to start with, by current PageSpeed Insights result.
Where you are	What the result establishes	Start at
Below 50	This lab run has substantial improvement opportunities. The score does not identify the cause; inspect the audit details and trace.	Steps 5 to 10
50 to 89	This lab run still found measurable work. Rank the named opportunities by route impact instead of assuming one category.	Steps 5 to 10
90 or above	This lab run met Lighthouse's good band. It does not prove good field experience or that important interactions work.	Steps 2 and 9
Field data says “insufficient data”	CrUX does not have enough eligible samples for this URL or origin. Use repeatable lab tests and your own real-user monitoring if available.	Step 2
Fast for you, slow for visitors	Your local visit and the reported user population differ. Compare device, network, geography, cache, consent and page state.	Steps 1 and 2

The standard advice list, the one you have already read a dozen times, is not wrong. Compress images to WebP or AVIF. Minify CSS and JavaScript. Put a CDN in front of static assets. Enable caching. Defer non-critical scripts. Cut redirect chains. Every item on it is real work that helps some sites.

The problem is the order. That list is sorted by how easy each item is to write down, not by how much time it will give you back. Minification saves kilobytes on a site whose actual problem is a 2MB hero image. A CDN does nothing for a page that is slow because it runs 400ms of JavaScript before it renders. Running the list top to bottom means doing five things that change nothing before reaching the one that mattered.

Watch Out

Two items on that list get blamed by name before anyone measures them. Shared hosting and plugins are both real causes of slow sites and neither is a diagnosis on its own. Measure TTFB by template and by region before you conclude hosting is the constraint, and measure what each plugin actually adds to the critical path before you remove it. Moving host or deleting plugins on suspicion is how sites get slower and lose functionality in the same afternoon.

A worked example, measured on this page

Rather than describe the method, here is a run of it against this article, so you can see what the numbers look like and what they do and do not settle. Measured August 2, 2026, headless Chromium 150.0.0.0 on Windows 11, one run, unthrottled connection, no CPU throttling, cold cache, from a single location. Those conditions are the whole point: change any of them and the numbers change, which is why one lab run is a diagnostic and never a verdict.

Measurement	Value	What it tells you
Time to first byte (TTFB)	81 ms	The server responded quickly. Whatever is slow here, it is not the origin
DOMContentLoaded	1,952 ms	Nearly two seconds after an 81 ms first byte. The delay is entirely in what happens after the response arrives
HTML over the wire	58.8 KB	Compressed. Uncompressed it is 644 KB, so compression is doing an 11x reduction
Total requests	33	Count alone means little; what they weigh is the useful number
Total transferred	427 KB	Everything the browser fetched to render an article
JavaScript	235 KB across 13 files	55% of everything transferred, on a page that is mostly text
CSS	93 KB across 3 files	The second largest category

Read the first two rows together, because that pairing is the most useful thing on this page. An 81 ms first byte against a 1,952 ms DOMContentLoaded says the server did its job and the cost is downstream, so anyone selling us faster hosting would be selling a fix for a problem we do not have. That is the single most common misdiagnosis in this whole subject, and you can rule it in or out in about a minute on your own site.

The JavaScript row is the uncomfortable one and it stays in. On an article that is largely text, JavaScript is 55% of what we ship. That is not a disaster and the page still renders its content in the initial HTML, but it is more than a text page needs, and publishing a speed guide does not exempt us from the finding. If you run the same check and see the same shape, the honest next step is the same for you as for us: find out what each of those files is for, and whether the ones that are not needed for first render can be deferred or dropped.

Weight and readability are two different problems, and only one of them decides whether a machine can read you. A page can be heavy with JavaScript and still serve every word of its content in the first response. A page can also be light and serve an empty <div>. The question that matters for search engines and AI assistants is not how much JavaScript you ship, it is whether your actual sentences are in the HTML before any of it runs.

So we measured this page the way a crawler sees it. Requesting it as GPTBot on 13 September 2026 returned 716,835 bytes of HTML uncompressed, of which 64.1% is inline script, 23.3% inline CSS, 9.1% markup and 3.5% readable text— about 4,081 words in 24.8 KB. Before you read that as bloat, here is what it actually is. Most of that script is the React Server Component payload Next.js inlines so the browser can hydrate without a second request, and it contains a serialised copy of the same sentences that are already in the HTML. The content is genuinely in the document twice, by design. Compression collapses the duplication almost entirely: the same page leaves our server at roughly 60 to 80 KB, a reduction of about ten times. The uncompressed ratio is a useful thing to understand and a bad thing to optimise against.

The raw-response check passed: every sentence in this article, including the uncomfortable one above, is present before client-side JavaScript executes. That is one useful crawlability check, and it takes one command. Fetch your page with a named user agent using curl -A "GPTBot" https://yoursite.com/ and search the output for a sentence only a human reader would see. If it is there, that crawler can receive the text in the initial response and the JavaScript weight remains a separate performance question. If it is missing, investigate rendering and crawler access with the tools for the search or assistant you care about; this curl check alone does not prove what every crawler renders. We wrote up what that failure can look like in why AI-built sites are invisible.

What this run does not show

Two things, and they matter more than the numbers above. Largest Contentful Paint was not captured in this run, so nothing here tells you when the main content actually appeared, which is the metric a visitor experiences. And a single unthrottled run from one machine on a fast connection is not what your visitors have. Field data from Search Console at the 75th percentile is the only thing that describes them. Treat everything above as a way to find the constraint, never as a score.

You can reproduce this in your own browser without installing anything. Open the page, open developer tools, and in the console read performance.getEntriesByType('navigation')[0] for the timing rows and performance.getEntriesByType('resource') for the per-file weights. Group the second one by initiatorType and you have the table above for any site you can load, including your competitors'.

"The platform label never diagnoses the problem. Following the request from DNS to render does.

1. Confirm the route and template

Test representative templates and states: home, long content, search, product, collection, form, cart, account and error. A homepage result cannot prove a page with different content, scripts or interaction. Record the release and page state with the baseline. If you are still working out the symptom, start with why a site loads slowly and come back to this list.

2. Separate field and lab data

Google's PageSpeed Insights can show eligible Chrome User Experience Report data and a Lighthouse lab run. Field data describes real-user distributions; the lab result is a simulated diagnostic. Use both for their intended purpose and state when URL data is unavailable and origin data is substituted. Our Core Web Vitals explainer covers what each field metric measures, and our PageSpeed testing method shows how we record lab runs.

Google publishes a good threshold for each Core Web Vital: Largest Contentful Paint at or under 2.5 seconds, Interaction to Next Paint at or under 200 milliseconds, and Cumulative Layout Shift at or under 0.1. Those are the numbers to design an acceptance test around. A Lighthouse performance score is a weighted summary of lab metrics, not a fourth vital and not a ranking cutoff.

Which tool answers which question

No single performance tool answers every question, and reaching for the wrong one is how a morning disappears into a metric that was never the constraint. Five tools cover the ground between them, and each has one question it is genuinely best at. Pick by the question you are holding rather than by the tab you already have open.

✓
PageSpeed Insights: eligible field data and a Lighthouse lab run for one URL in one place. Use it for the headline diagnosis and the shareable record.
✓
Chrome DevTools: the Performance panel for main-thread traces and long tasks, the Network panel for request order and sizes, the Coverage panel for unused CSS and JavaScript, and Lighthouse for local runs before you push.
✓
WebPageTest: repeat runs from chosen locations with chosen connection profiles. Use it when geography or network conditions are part of the complaint.
✓
A waterfall tool such as GTmetrix: request-by-request timing when you need to see exactly which file blocks which.
✓
Search Console Core Web Vitals report: which URL groups fail in the field across the whole property, so you test the right templates rather than the homepage.

Throttle to a mid-range mobile profile when you test. Script that runs in tens of milliseconds on a development laptop can take several times longer on a mid-range Android device, and the mobile result is the one that matches how most visitors arrive.

3. Trace DNS, redirects and connection setup

Everything in this step happens before your own code runs, which is why no amount of front-end work will shorten it. The browser has to resolve the hostname, follow any redirects, negotiate TLS and open a connection before the first byte of your document exists. Three checks cover the whole stage.

✓
Remove accidental redirect chains and verify canonical host and protocol behavior.
✓
Inspect DNS, TLS, connection reuse, compression and geographic delivery.
✓
Do not remove required authentication, locale or campaign behavior merely to shorten a trace.

Every redirect in a chain is a fresh request and response before the browser has any content to work with, and browser caching of static assets does nothing to shorten it. Point internal navigation, campaign URLs and email links at the final destination rather than relying on a hop.

4. Profile document and origin time

Inspect cache status, CDN, origin compute, database, upstream APIs and errors. A host change helps only when the current origin or network path is the constraint. It cannot remove oversized images or main-thread JavaScript, and no list price predicts the page result.

Time to first byte (TTFB) sets the floor for everything after it. Nothing you do in the browser starts until the document response arrives, so measure it directly with a request trace or a timed request from the command line before you rewrite front-end code. Compare a cold cache with a warm one, and a request from near the origin with one from a region your visitors actually use. If the document response is the slow part, the fix is in the server, the cache or the network path, not in image formats.

5. Identify the real LCP element

Use the trace to find the LCP resource and its delay components. Ensure it is discoverable, prioritized appropriately and not accidentally lazy-loaded. If the element is text, inspect fonts and render-blocking styles rather than optimizing an unrelated image.

6. Right-size images and video

Most image weight on a slow page is dimensions nobody sees, because a file sized for a large desktop display costs a phone visitor the full download whatever slot it lands in. Serving dimensions close to the rendered size is the largest saving available in this step, and it changes nothing about how the page looks.

✓
Serve dimensions close to the rendered slot with responsive candidates.
✓
Choose an efficient format and quality that preserves the approved visual requirement.
✓
Lazy-load offscreen media, not the above-the-fold LCP resource.
✓
Use posters, user-triggered loads or lighter delivery for video and heavy embeds where acceptable.
✓
Reserve dimensions to prevent layout shifts.

7. Audit CSS and fonts

Remove unused style sources carefully, reduce render-blocking work, consolidate where it helps, and verify component states. Limit font families and weights, use appropriate subsets and loading behavior, and test fallback-to-final layout. “Minify everything” is not a complete strategy and can make debugging or caching worse if applied blindly.

8. Reduce JavaScript and long tasks

JavaScript charges the visitor twice, once to download it and once to parse and execute it, and on a mid-range phone the second charge is usually the larger. That is why deleting a small file can beat compressing a large image. The work here is finding the code that ships to this route and is not needed by it.

✓
Use coverage and traces to identify unused and expensive code.
✓
Split non-critical work and avoid shipping admin or feature code to routes that do not use it.
✓
Keep event handlers small and yield during long processing.
✓
Test real menus, forms, filters, cart actions and modals for interaction delay.

A render-blocking script is one the browser must fetch, parse and execute before it can paint, which is what produces the blank screen at the start of a slow load. Add defer to scripts whose execution order still matters, since deferred scripts run in document order after parsing. Add async only where a script is genuinely independent of the rest of the page and of other scripts. Non-critical widgets can wait for a real user signal such as a click or a scroll into view rather than loading with the document.

9. Stabilize layout

Reserve media and embed space, keep validation messages predictable, avoid inserting late banners above content, and verify consent, font, ad and personalization states. Exercise loading, success and error paths instead of reading CLS from one clean page load.

10. Govern third parties and consent

Inventory analytics, ads, chat, heatmaps, video, maps, reviews, calendars, experimentation and tag-manager loads. Record purpose, owner, consent category, transfer, load condition, cost and failure behavior. Remove or defer only when product and compliance requirements permit it.

11. Verify cache and CDN behavior

A cache is worth whatever its miss and invalidation behavior is worth, and that is the half nobody tests. A configuration that serves a fast hit and then serves yesterday's price after an inventory change has bought you nothing. Decide what is cacheable by route and user state, then prove each state behaves the way you decided.

✓
Define what can be cached and for how long by route and user state.
✓
Verify hit, miss, stale and invalidation behavior after content or inventory changes.
✓
Keep private, cart, account and personalized data out of shared caches.
✓
Test cold and warm conditions and document which state the acceptance method uses.

The usual working convention is a long cache lifetime on fingerprinted static assets, where the filename changes whenever the contents do, and a short one on HTML, which has to be able to change without waiting for a cache to expire. That split is what lets a returning visitor reuse almost everything while still seeing today's content. It only holds if your build actually fingerprints those filenames, so check that before extending any lifetime.

12. Add release and regression controls

Speed work that is not defended by a repeatable test gets undone by a later release, usually by someone who never knew the constraint existed. What defends it is a recorded baseline rather than a memory of a good afternoon. Four controls make the improvement survive the next deploy.

✓
Repeat the agreed pages and profiles three times and retain reports.
✓
Record release version, tool version, environment, exclusions and known variance.
✓
Test responsive behavior, keyboard use, forms, integrations, analytics and consent.
✓
Monitor real-user distributions and business journeys after release.

No platform score ceiling

WordPress, Shopify, Wix, Squarespace, Webflow and Next.js do not have one universal mobile score. Implementation, content, integrations, visitors and test conditions vary. A custom framework offers different controls, not an automatic 90+ result.

The constraints you actually measure do differ by platform, so we keep route-level diagnostics for slow WordPress sites, Shopify storefronts, WooCommerce stores, Wix sites, Squarespace sites and GoHighLevel pages.

When to optimize and when to rebuild

Optimize unless the platform itself is blocking a requirement you have already accepted, which is a narrower condition than most rebuild conversations assume. The measured constraint decides this, not the age of the site and not a dislike of the current editor. Three positions cover almost every case.

✓
Optimize when measured constraints are controllable and the current editor, commerce and integration model still fits.
✓
Rebuild within the platform when the current theme or template is the primary constraint and platform operations remain valuable.
✓
Migrate when accepted performance, security, ownership, integration or operating requirements remain blocked and a comparable total-cost model supports replacement.

If a rebuild is on the table, put the performance target in the written scope rather than in the sales conversation. Ours is a handover target of 90 or better on mobile and desktop Lighthouse for the representative pages named in that scope, evidenced by three recorded runs per page and profile before handover. It is a lab acceptance target for delivered work. It is not a promise about rankings, traffic or revenue, because nobody controls those. Planning tiers start at $1,500 for Starter, $3,500 for Growth and $5,000 for Scale.

If replacement is the answer, the cost drivers are set out in our website migration cost breakdown, and the scope of the work itself sits on the WordPress migration and storefront engineering pages.

Google uses Core Web Vitals in broader ranking systems but does not publish a Lighthouse ranking cutoff. Do not promise ranking recovery, a conversion multiplier, or payback from speed alone. Measure property-level search and funnel outcomes with a change log and limitations. What the evidence does and does not support is covered in how website speed affects SEO.

Bring us the route that feels slow

We will baseline representative routes, isolate the slow layer and tell you whether a focused fix, a larger rebuild or no development work is justified.

Frequently Asked Questions

What is the 3 second rule in website design?

It is a planning heuristic, not a Google requirement or universal abandonment point. Different routes, devices, networks, audiences and tasks behave differently. Use the property's field performance and funnel evidence rather than applying one cutoff to every visitor.

Does website speed affect Google rankings?

Google uses Core Web Vitals in broader ranking systems but says good scores do not guarantee top rankings and relevance remains fundamental. Lighthouse is a lab diagnostic, not a direct ranking cutoff. Diagnose search changes with Search Console, content, links, indexing and release evidence.

How much does it cost to speed up a website?

Diagnosis costs almost nothing: PageSpeed Insights, your own browser's network panel and an hour will tell you where the constraint is. Paying starts when the fix is structural. Get the diagnosis first, because the most common outcome is that two or three free changes close most of the gap and the quote you were about to accept was for the wrong problem.

What are the best tips to optimize website speed and performance?

The usual list is compress images to WebP or AVIF, minify CSS and JavaScript, use a CDN, enable caching, defer non-critical scripts and cut redirect chains. All of it is real work, but the list is sorted by how easy each item is to describe rather than by how much time it gives back. Get a number first: run PageSpeed Insights on one specific URL and read the Chrome field data panel above the score. Below 50, an oversized LCP image or render-blocking CSS in the head is almost always dominating, so start there. Between 50 and 89, script execution and third-party tags are usually splitting the remaining time. At 90 or above the lab score is no longer the constraint and you should be looking at field INP and CLS instead. Minifying a site whose real problem is a 2MB hero image saves kilobytes and changes nothing.

Can a CDN alone make my website fast?

A CDN can reduce delivery distance and cache eligible responses, but it cannot automatically fix origin compute, database work, cache misses, oversized media, render-blocking resources, JavaScript, layout shifts or third parties. Measure the request path before choosing the fix.

How long does it take to optimize a slow website?

Diagnosis is hours; the fixes are days; confirming they worked takes weeks because field data accumulates over a rolling window. That last part is what people get wrong, treating a same-day lab score as proof. Change one thing at a time, record the conditions, and wait for the field data before concluding anything.

Is AMP required for fast mobile pages or Google rankings?

No. AMP is not required for eligibility in Google's mobile search experiences. Choose an architecture from the site's product, content, performance and maintenance requirements, then verify field and lab results. Server rendering, static generation or edge delivery do not automatically make a page fast.

AEO24 min