Editorial illustration; it does not depict a specific website or performance test.
Published on 17 October 2026.
A slow website creates a frustrating guessing game. Someone says the homepage takes too long to open, a developer clears a cache, and the page seems better for a few minutes. Then the complaint returns. The temptation is to redesign everything, change hosts or install another optimisation plugin before anyone has identified the actual bottleneck.
That is backwards. A slow page is usually a collection of smaller costs: a large image, a script that waits too long, a slow server response, a font that blocks the first view, or a mobile layout that asks the browser to do unnecessary work. You can learn a great deal by checking those costs in a sensible order.
Quick Answer
Before rebuilding, test the exact slow page on a clean mobile connection and a desktop connection. Record the page URL, time of day, device and test result. Then inspect these ten areas:
- The page and device you are actually testing
- The server’s initial response
- Images and other media
- Render-blocking styles and scripts
- Third-party services
- Caching and content delivery
- Fonts and layout shifts
- JavaScript errors and unnecessary work
- Mobile-specific problems
- The change that made performance worse
The aim is not to chase a perfect score. It is to find the largest avoidable delay for real visitors, make one controlled change, and test again.
1. Test the real page, not only the homepage
Start with the URL visitors complain about. A product page, article, search page or checkout may use a different template and different assets from the homepage. Test both a fresh visit and a repeat visit, because a cached visit can hide a problem that a new visitor experiences.
Write down whether the page is slow before anything appears, while content is appearing, or after the page looks usable. A long wait before the first response suggests a server or database issue. A page that remains busy may have expensive scripts, while a page that jumps may have missing image dimensions or late-loading fonts.
Tools such as PageSpeed Insights can provide useful lab and field context, but one report is not a diagnosis. Repeat the test on the network your audience uses.
2. Check the initial server response
The browser cannot render the page until it receives enough HTML to begin. If the initial response is slow, inspect hosting resources, database queries, application code and cache misses before spending time on front-end polish.
Use your browser’s Network panel and look at the document request. A high waiting time before the first bytes arrive points towards the origin or an intermediary. It can be caused by an overloaded server, a slow query, a cold application process or work being repeated for every request.
Do not assume a faster plan is the first answer. Ask which request is slow, under what traffic pattern, and whether the same page is fast when served from cache. A small site may need a query fix or page cache rather than more CPU.
3. Find the largest images
Images are often the easiest performance win because they can be large without looking large on screen. A photograph uploaded directly from a phone may contain far more pixels and bytes than a card or article needs.
For each prominent image, ask:
- Is the displayed size close to the source size?
- Is the format appropriate for the image and browser support?
- Does the visitor need this image before the page becomes useful?
Create responsive variants where the content system supports them. Compress an image after deciding its maximum useful dimensions, and keep the original separately if you need it for future editing. The web.dev guidance on responsive images explains why sending an appropriately sized image matters across different screens.
Avoid blindly lazy-loading the main image at the top of the page. A browser should not have to wait for a lazy-loading decision before displaying the content a visitor came to see. Images further down the page are usually better candidates.
4. Identify render-blocking CSS and JavaScript
The browser builds a view from HTML, CSS and scripts. A stylesheet or script that must finish before the first useful view can delay the experience even when the file itself is not very large.
Open the Network and Performance panels to see which files load early and which tasks occupy the main thread. Remove unused CSS where practical, split large bundles, and defer code that belongs to interactions below the first view. Do not make every script asynchronous as a ritual: ordering and dependencies still matter.
If a site uses a theme or page builder, check what it adds to every page. A feature used on one landing page should not necessarily load its assets on every article. Small improvements repeated across all pages are often more valuable than a dramatic change to one template.
5. Audit third-party services
Analytics, advertising, chat widgets, heatmaps, social embeds and video players can add requests to services outside your control. They can also run JavaScript, open connections and delay interaction.
Make a list of every external script and record its purpose. If nobody can explain why a service is installed, remove it from a staging copy and test the difference. If a tool is useful but not needed immediately, load it later or only on pages where it has a clear job.
Consent and privacy requirements still apply. Do not replace a slow third-party tool with another tool that creates a different compliance problem. Performance is part of the decision, not the only criterion.
6. Verify caching at each layer
Caching can exist in the browser, a content delivery network, the web server and the application. A page may be cached for one visitor but rebuilt for another because of cookies, query parameters or an incorrect cache rule.
Check response headers and confirm what you intended to cache. Do not cache private account pages as public content. For public pages, understand how content updates invalidate the cache and whether a deployment is serving the new files. MDN’s HTTP caching guide is a useful reference for the browser-facing part of this work.
Do not use a cache purge as the whole troubleshooting method. A purge can make a page appear slower temporarily because the next visit has to rebuild the cache. Measure both states when the distinction matters.
7. Check fonts and layout stability
Custom fonts can improve a brand’s appearance, but they are additional resources. Large font files, too many weights and late font swaps can make text appear late or move the page after a visitor starts reading.
Keep only the weights you use. Set appropriate fallback behaviour and reserve space for media so the page does not jump when an image arrives. The web.dev explanation of Cumulative Layout Shift shows why visual movement is an experience problem.
Test headings, buttons and navigation on a narrow screen. A single line wrapping unexpectedly can move everything below it and make a page feel unstable.
8. Look for JavaScript errors and repeated work
An error in one script can stop a feature, trigger retries or leave a loading indicator running. Repeated event handlers can also make a page progressively slower as a visitor navigates without a full reload.
Open the Console, reproduce the problem and inspect errors from the same page. In the Performance panel, look for long tasks and repeated layout calculations. A page that does too much work after it has become visible needs a different fix from a page waiting for its first document response.
Remove polling that has no clear purpose. Replace repeated full-page work with smaller updates when the application really needs live data. Keep the behaviour understandable so the next developer can maintain it.
9. Test the mobile path separately
Desktop broadband can hide problems that are obvious on a phone. Mobile users may have a slower connection, less memory and a smaller screen that activates a different layout. Test the actual navigation, form fields, menus and images rather than only shrinking the desktop window.
Pay attention to touch targets, sticky elements and keyboard behaviour. A page can receive a reasonable performance score while still feeling slow because a menu animation blocks a tap or a form waits for a large library to load.
Record what changed between desktop and mobile. That helps you decide whether to fix a shared resource or a mobile-only component.
10. Find the change that made the page worse
If the site was fast last month, search the deployment history, plugin list and content changes before rewriting the site. A new banner, tracking tag, editor block or database query may explain the regression.
Keep a short performance log with the date, test URL, change and result. Change one important variable at a time. If three optimisations are released together and the page improves, you will not know which one helped or which one introduced a future problem.
Common mistakes to avoid
Do not optimise only for a score, test only on your own fast connection, or delete accessibility features because they add a small amount of code. Do not install several optimisation systems that rewrite the same CSS, scripts and cache headers without understanding their order.
Also avoid treating every delay as a hosting problem. A server upgrade cannot make a 20 MB image small, and a compressed image cannot fix a slow database query.
My Take
The most useful performance habit is keeping a short evidence trail. Record the page, the symptom, the largest delay and the one change you made. This turns “the website is slow” into a manageable engineering question.
For a small site, start with images, third-party scripts and caching because they are visible and often reversible. For an application, measure the initial response and browser main-thread work as well. The right order depends on the evidence, not on whichever optimisation trend is popular this week.
Bottom Line
A rebuild can be worthwhile when the current architecture prevents safe improvements, but it should be a conclusion rather than a reflex. Test the real page, identify the biggest cost, make one change and verify it on the devices your visitors use. Ten careful checks can save weeks of rebuilding a problem that was really one oversized image or one forgotten script.