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

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

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

• ✓
  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

• ✓
  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 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

• ✓
  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

• ✓
  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

• ✓
  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.

12. Add release and regression controls

• ✓
  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.

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 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 to $10,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.

Primary sources

• PageSpeed Insights documentation
• Google Search Central: Core Web Vitals
• Chrome: Lighthouse performance scoring
• web.dev: optimize LCP
• web.dev: optimize INP
• web.dev: optimize CLS