Website performance

How to Speed Up Your Website. Find the slow part first.

Want us to check your page? Run a free website audit.

Pick one page that feels slow. Find out where the wait happens, make one useful change, then test that same page again. This guide shows you how to do it without guessing from a platform name or one score.

Last reviewed October 8, 2026, including the Core Web Vitals thresholds on web.dev. Sources and testing notes are linked throughout.

Hassan Jamal·Published 30 April 2026·Updated 8 October 2026·14 min read

Start with the page that feels slow

You do not need to work through all twelve checks. Choose one page that matters to your visitors, get a result for that page, and start with the part causing the wait.

Name what feels slow before you test it. A blank first screen, a hero image that arrives late, a menu that ignores a tap and a form that freezes after you submit it are different problems, and each needs different evidence and a different fix. One homepage score can't stand for every visitor, page, device and interaction.

On this page

If you do not have a result yet: run PageSpeed Insights on one specific URL. The top panel shows real Chrome visits when enough data exists; this is called field data. The score below comes from one simulated load, called a lab test. If the two disagree, start with what real visitors experienced, then use the lab details to investigate the cause.

Which of the twelve diagnostics to start with, by current PageSpeed Insights result.
Where you are	What this tells you	Start at
Below 50	There is room to improve, but the score alone will not tell you what caused the delay. Open the details for this page.	Steps 5 to 10
50 to 89	Some changes may help. Start with the issues affecting this page.	Steps 5 to 10
90 or above	This test looks good. Check whether real visitors and important actions have the same experience.	Steps 2 and 9
Not enough visitor data	There were not enough visits for a reliable real visitor view. Repeat the test and use your own monitoring if you have it.	Step 2
Fast for you, slow for visitors	Their phone, connection, location or page may differ from yours. Compare those conditions first.	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. An 81 ms first byte against a 1,952 ms DOMContentLoaded points to work after the server responds. Faster hosting would not address the main delay here. Check the same two timings on your own site before paying for a hosting change.

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, read why a site can seem fast to you and slow to everyone else 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.

Google's threshold article on web.dev, checked October 8, 2026, also sets where poor begins: above 4 seconds for LCP, above 500 milliseconds for INP and above 0.25 for CLS. Every one of those lines is judged at the 75th percentile of visits.

Why it seems fast to you and slow to everyone else

This is usually where an owner starts doubting the report. You open your own site on a good phone, on your own network, with the images already in your browser cache from the last time you looked. Someone arriving for the first time on a mid-range Android over mobile data downloads all of it from scratch. Those are two different page loads, and only one of them is being measured.

The 75th percentile settles the argument. Your site isn't graded on its average visit; it's graded at roughly the slowest quarter of visits, which is why a site can feel fine every time you check it and still be assessed as poor. To see what your visitors see, test on a throttled mobile profile with an empty cache. When your impression and the field data disagree, the field data is the one describing your customers.

Which tool answers which question

These five tools answer different questions. Start with the problem you are trying to locate, then choose the tool that measures it.

✓
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

Check more than how fast a saved page loads. What happens on the first visit, after a price changes, or when a customer signs in? Decide which pages and information can be stored temporarily, and test that visitors still receive the right version.

✓
Define what can be cached and for how long by route and user state.
✓
Test saved pages, first visits and outdated copies. Confirm that changes to content or stock replace the old information.
✓
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

Record a baseline and repeat the same test after each release. These four checks show whether a later release has slowed the site.

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

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.

Why is my website slow but my internet connection is fast?

Your connection is only one layer. Origin response, cache misses, redirects, large media, fonts, JavaScript, third parties and main-thread work can all delay the page. You may also be loading it from your own browser cache. Use a request waterfall and a performance trace under recorded conditions to find the slow layer.

Why are websites so laggy on mobile devices?

Phones can expose slower processors, constrained networks, large responsive images, main-thread JavaScript, layout shifts and touch handlers that are less noticeable on a desktop. Test representative devices and templates on a throttled mobile profile instead of assuming one cause.

Does switching web hosting make a website faster?

It can when server time, worker limits, database latency, storage or region is a measured bottleneck. Hosting will not fix front-end JavaScript, media, third parties or slow application queries. Capture timing and trace evidence before moving, then retest the same pages.

SEO10 min