A slow website is rarely caused by just one problem; it is almost always several layered issues compounding across the server, network, and browser rendering layers.
Loading Website Speed Test…
Step-by-step diagnosis methodology
Covers all main causes: server, images, JavaScript, CSS
Identifies priority fixes for maximum impact
Run the speed test to start your diagnosis
Drop the Website Speed Test into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.
Embed code
<iframe
src="https://www.fixtools.io/web-tools/website-speed-test?embed=1"
width="100%"
height="780"
frameborder="0"
style="border:0;border-radius:16px;max-width:900px;"
title="Website Speed Test by FixTools"
loading="lazy"
allow="clipboard-write"
></iframe>Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.
Slow website diagnosis is a process of elimination across four distinct layers: the server, the network, the browser rendering pipeline, and the third-party resources loaded into the page. Many site owners apply front-end optimisations such as compressing images and minifying CSS when the actual bottleneck is the server with its high TTFB, which produces visible but small improvements while leaving the highest-impact fix untouched. The correct diagnostic sequence starts at the server and works forward toward the browser: first measure TTFB, then total page weight, then identify render-blocking resources, then quantify third-party script impact, then profile rendering performance during interaction. Each layer only becomes the dominant bottleneck after the preceding layer has been optimised, which is why working in this order avoids wasted effort.
Server-side diagnosis focuses on Time to First Byte as the single most important number. A TTFB above 800ms indicates one of three common issues. The most frequent is absent or misconfigured caching, where a CMS such as WordPress runs a full PHP and database query cycle on every page request instead of serving a cached HTML file directly. The second is slow application code where database queries, external API calls in the request path, or inefficient business logic add measurable time to every request. The third is insufficient server resources such as shared hosting overloaded during peak traffic windows. Use your hosting control panel or server logs to identify which of the three is responsible. Enabling a full-page caching plugin such as WP Rocket for WordPress or Varnish for custom setups typically reduces TTFB from 1 to 3 seconds down to under 200ms in a single configuration change.
Front-end diagnosis uses WebPageTest's waterfall view to identify which specific resources are slow, render-blocking, or loaded inefficiently in ways that delay the critical rendering path. Look for resources that appear early in the waterfall and have long download times, which are usually large uncompressed images or oversized JavaScript bundles that should be split. Look for resources creating a staircase pattern with sequential waits, which indicates HTTP/2 multiplexing problems or render-blocking dependency chains where each script must finish before the next can begin. Look for resources from third-party domains that appear late in the waterfall with long DNS lookup times, and fix those using DNS prefetch or preconnect hints in the document head that warm the connection before the resource is requested.
Browser rendering diagnosis happens last and uses the Chrome DevTools Performance panel rather than a remote testing service. Record a real interaction on the page, such as clicking a button or scrolling through a list, and observe the main thread timeline for long tasks coloured red. Each long task represents a moment when the browser could not respond to user input because JavaScript was monopolising the CPU, and the call tree drilling into each task reveals the specific function calls consuming time. This is where INP failures are diagnosed and where third-party scripts that look benign in the network waterfall reveal themselves as serious blockers during real user interaction. Without this fourth-layer analysis, INP issues remain invisible to the audit and persist in production where they affect real users.
Run the Website Speed Test first to identify which metrics are failing, then use this guide to diagnose the root cause of each issue.
Step-by-step guide to slow website diagnosis: what's slowing your site down?:
Run the speed test and note all failing metrics
Run the Website Speed Test on the affected page and capture every metric in the red or failing range, including LCP, CLS, TTFB, TBT, and any resource-level opportunities flagged in the report. Treat the resulting list as your diagnostic worksheet, because the pattern of failures tells you which layer of the stack to investigate first. A page failing only on LCP points to image or render-path problems; a page failing on TTFB and everything downstream points firmly at the server.
Diagnose server speed (TTFB)
If TTFB is over 600ms, investigate the hosting layer first by checking whether your hosting plan provides sufficient CPU and memory for the traffic level, then check whether full-page caching is correctly configured to bypass application code on cacheable responses. Look at database query performance using the appropriate profiling tool for your stack, and verify CDN configuration is actually serving cached responses from edge nodes rather than passing every request through to the origin server unnecessarily.
Diagnose image issues
Check the resource list in the speed test report for large images, defined as anything over 200KB per file on a typical content page. Compress all images using a tool such as Squoosh or ImageOptim, convert to WebP format which is roughly 30 per cent smaller than JPEG at equivalent visual quality, and implement srcset with multiple resolutions so mobile devices receive appropriately sized variants rather than the desktop-resolution master file that wastes bandwidth and slows the LCP measurement.
Diagnose JavaScript and CSS blocking
Check the audit report for render-blocking resources in the critical path before first paint. Add defer or async attributes to all non-critical scripts so they do not block parsing of the document. Minify and combine CSS files where appropriate, then remove unused CSS using a tool such as PurgeCSS that analyses which selectors are actually applied by the page. The Coverage tab in Chrome DevTools shows the percentage of loaded code that actually runs, which is the fastest way to identify dead code worth removing.
Common situations where this approach makes a real difference:
E-commerce site sudden slowdown
An online store that was previously fast suddenly slows to 8-second mobile load times after the marketing team adds a new server-side personalisation platform that runs on every product page request. The technical team applies the diagnosis sequence and identifies through TTFB measurement that the new platform is adding roughly 4 seconds of server-side processing to every cacheable response, defeating the existing page cache in the process. The team switches to client-side personalisation that runs after the initial page render, restoring previous performance within a single deployment cycle and preserving the marketing functionality the platform was added to provide.
WordPress site audit
A WordPress site with a Lighthouse mobile score of 38 is diagnosed systematically using the layered approach. TTFB measures 1.8 seconds on shared hosting, so the first fix is migration to managed WordPress hosting that brings TTFB to 180ms. Images are uncompressed and add roughly 3MB of avoidable weight, so Imagify is installed to handle WebP conversion automatically across the existing media library. Twelve render-blocking scripts are identified and resolved with a script manager plugin that defers non-critical scripts. Each fix is applied in sequence, re-tested in isolation to verify the impact, and the final mobile score reaches 81 within three weeks.
New developer inheritance
A developer inheriting an old codebase with no documentation uses the speed test and this diagnosis guide to systematically identify and document every performance issue across the four diagnostic layers before presenting an improvement roadmap to the client. The deliverable lists each issue with its measured impact, the proposed fix, the estimated engineering effort, and the priority based on traffic and revenue weighting. The client approves the roadmap because the systematic structure makes the work feel manageable rather than overwhelming, and the developer ships fixes in priority order over the following sprints with measurable progress at every milestone.
Use this guide when your website is noticeably slow, when you have received a failing performance score, or when you want to systematically work through all possible causes of poor speed.
Get better results with these expert suggestions:
Check TTFB before all other optimisations
TTFB is the foundation that every other metric builds on, and ignoring it while optimising the front-end is the most common diagnostic mistake. If your TTFB is above 1 second, front-end optimisations such as image compression will have limited impact because the browser cannot even begin rendering until the server responds with the initial HTML. Fix TTFB first by enabling caching and upgrading hosting if the underlying plan is constrained, then address front-end performance once the server-side ceiling has been raised to a healthy level below 200ms.
Use the Coverage tab in Chrome DevTools
The Chrome DevTools Coverage tab, accessed via the command palette by typing Coverage after pressing Ctrl+Shift+P, shows the percentage of loaded JavaScript and CSS that is actually used on the current page. Unused code above 50 per cent indicates significant JavaScript bloat or CSS that could be split into smaller bundles and deferred until needed. This is the fastest way to identify dead code worth removing, and the resulting size reduction often delivers meaningful FCP and LCP improvements with no behavioural change to the page.
Isolate third-party script impact by blocking them
In the Chrome DevTools Network panel, right-click any third-party domain in the request list and select Block Request Domain from the context menu. Reload the page and note the performance difference compared with the original test. This immediately quantifies the time each third-party script adds to the load. Any third-party script adding more than 100ms should be evaluated for removal, deferral via async or defer, or replacement with a lighter alternative that provides the same business function without the performance cost.
Check for redirect chains in your URLs
Every redirect in a URL chain adds roughly 100 to 200ms of latency to the page load, and chains of three or four redirects compound into seconds. Common redirect chains include http to https, non-www to www, old URL to new URL after a site migration, and trailing slash normalisation. Use a tool such as httpstatus.io to trace all redirect chains across your important URLs. Ideally any URL should redirect zero or one times before reaching its canonical destination, and longer chains should be consolidated into single redirects served by the web server configuration.
Start with TTFB, slow servers explain a lot
Time to First Byte (TTFB) measures how long it takes the server to start sending data. A TTFB over 600ms usually points to slow hosting, uncached database queries, or an inefficient back-end. This is the most impactful single fix for many sites.
Images are the most common culprit
Over 60% of a typical website's payload is images. Uncompressed images, missing next-gen formats (WebP/AVIF), and oversized images (serving desktop images to mobile) are the most common and most fixable speed problems.
JavaScript blocks rendering, defer what you can
Any script in the <head> without async or defer blocks the browser from rendering the page until that script has downloaded and executed. Deferring non-critical scripts can often reduce render blocking time by 1–3 seconds on mobile.
More use-case guides for the same tool:
Other tools you might find useful:
Open the full Website Speed Test — free, no account needed, works on any device.
Open Website Speed Test →Free · No account needed · Works on any device