13 Steps to Troubleshoot a Slow Website

A slow website can have several causes at once: a delayed server response, an oversized image, a busy database or JavaScript that blocks interaction. Troubleshooting means collecting evidence, changing a likely cause and checking whether the customer’s experience improved. Installing another optimisation plugin is not a diagnosis.

Choose one affected page and a task a visitor needs to complete. Record the URL, device, time and symptoms. Then work through the following thirteen checks in order of the evidence, keeping a recoverable copy before changes. You do not need to apply every possible optimisation to every website.

1. Establish a repeatable baseline

Run PageSpeed Insights and inspect both real-user data, where available, and the laboratory result. They describe different things. Laboratory testing helps investigate a controlled page load; real-user information reflects actual visits over a reporting period. A single score cannot represent every visitor or prove a business outcome.

Record the test settings and repeat under comparable conditions. Check a mobile journey as well as a desktop homepage. Core Web Vitals cover loading, responsiveness and visual stability; also observe whether the enquiry form or checkout actually works. Preserve screenshots and measurements so later changes have a meaningful comparison.

2. Locate the delay in the loading sequence

Use the browser’s Network and Performance tools. Is the browser waiting for the first document, downloading a large file or spending time executing code? A network waterfall shows request timing and dependencies, which helps avoid treating every delay as a hosting issue.

Identify the element representing the main visible content and what delays it. A large hero image may be discovered late, transferred slowly or hidden until a script runs. Each problem needs a different fix. Check errors and redirect chains too, especially after a migration or URL change.

3. Investigate hosting resources and application work

Compare slow times with account resource information, error logs and scheduled jobs. A saturated limit, expensive query or long external request can delay the initial response. Give support the page, time and reproducible steps rather than only a speed score.

An upgrade is useful when evidence shows the current resources are insufficient for a legitimate workload. It will not repair an infinite loop or a faulty integration. Check what the proposed package changes: storage size alone does not establish faster application processing. Test the result after any move.

4. Resize and optimise images and media

Inspect the dimensions and transferred size of images. A small card rarely needs the same source as a full-screen photograph. Supply appropriate responsive sizes and use formats supported by the target browsers. Compare visual quality after compression rather than selecting the smallest file regardless of the result.

Give images dimensions to reserve space. Defer genuinely off-screen media where appropriate, but avoid lazy-loading the main image that a visitor needs immediately. Replace decorative autoplay video with a lighter treatment when it adds little value, and keep text and instructions available outside pictures.

5. Reduce unnecessary code and main-thread work

Look for unused styles, duplicated libraries and scripts loaded on pages that do not need them. Minification can reduce transfer size, but a smaller file can still perform expensive work. Profile slow interactions and long tasks before deciding what to change.

Test script deferral carefully because some components depend on one another. Combining every file is not automatically beneficial on modern delivery protocols. Keep source files maintainable and use a repeatable build or platform configuration rather than repeatedly editing compressed output by hand.

6. Set appropriate caching policies

Browser caching can avoid downloading unchanged resources again. Server or application caching can reduce repeated work for public content. Review response headers and verify that the expected cache is actually being used; a dashboard switch alone is insufficient evidence.

Keep personalised pages, baskets and account responses out of inappropriate shared caches. Use a reliable way to invalidate content after a change. Test both a first visit and a repeat visit because they have different costs, and check a signed-in customer journey separately.

7. Evaluate a CDN for the right resources

A content delivery network can serve cacheable resources from distributed locations and reduce repeated traffic to the origin. Its benefit depends on your audience, cache policy and existing delivery path. It cannot eliminate a slow database operation behind an uncached personalised page.

Check DNS, certificate and cache configuration after enabling a CDN. Compare relevant visitor locations under similar conditions. Confirm that error pages, updated content and security rules behave correctly. Adding another service should have an operational purpose and a documented owner.

8. Review plugins, themes and extensions

Count alone does not reveal the problem: one inefficient extension can cost more than several small ones. Identify which components load code, run queries or contact outside services on the affected page. Review duplicated functionality and remove software that is no longer needed.

Use staging or another safe test method before disabling a live shop’s essential components. Change one thing at a time and retest the same task. Preserve configuration and data needed for recovery. Do not replace one unsupported plugin with another merely because its name promises speed.

9. Inspect database queries and scheduled cleanup

Database delays can come from inefficient queries, excessive autoloaded settings or missing indexes in a custom application. Use application profiling and supported diagnostic tools. A large database is not inherently slow, and deleting records without understanding them can damage the site.

Back up before any maintenance. Remove stale temporary data through supported tools and review abandoned plugin tables with care. For custom queries, ask a developer to inspect execution plans and indexes. Test important reports and transactions after the change.

10. Check transfer compression

Text resources such as HTML, CSS and JavaScript often benefit from transfer compression, commonly Brotli or Gzip depending on the server and client. Inspect actual response headers and transferred sizes to see what is already enabled. Avoid stacking conflicting server rules or several plugins for the same job.

Many image and video formats are already compressed, so applying text-oriented compression to them is not a general solution. Keep a copy of server configuration and use the host’s supported method. A syntax error in configuration can make the entire site unavailable.

11. Correlate slow periods with traffic and background work

Compare the timing of slow responses with campaigns, crawlers, imports, backups and scheduled tasks. Separate useful customer traffic from abusive or accidental load. Rate limiting and caching may help particular patterns, but rules should preserve legitimate customers and search access.

Move heavy scheduled work where appropriate or process it in bounded batches. A backup that overlaps an inventory import can create a repeatable daily slowdown. Track the outcome rather than assuming a quiet-looking traffic chart means no background process was active.

12. Measure third-party scripts and requests

Advertising, chat, analytics and embedded media can add requests and processing. Temporarily block a suspected optional service in a controlled browser test and compare the result. This helps estimate its contribution without immediately deleting a business feature.

Load optional components when needed and remove redundant tags. Check their accessibility and applicable privacy requirements as well as speed. A page should still explain its offer if an external widget cannot load. Do not make the main navigation depend on a marketing service.

13. Update supported software and verify the result

Supported application, runtime and extension versions can bring important fixes, but changes need compatibility testing. Back up, review requirements and test a representative journey before deploying to the public site. Keep a route to reverse an unsuccessful update.

Repeat the baseline test and inspect more than the score. Check visual stability, interactions, forms, payment and email. Continue monitoring real-user results after deployment. Record which change helped, what remains uncertain and when to review the site again. That record makes the next investigation much faster.