Slow for whom? How to troubleshoot website performance without guessing
A practical method for finding out whether the slowness is caused by images, JavaScript, caching, the database or the user experience itself.
Category: Website performance
A website can be fast on the homepage and slow in the online store. It may work well on the office network but poorly on mobile. It can also achieve an acceptable overall score while the contact form responds slowly or content shifts as the customer tries to click.
That is why work on website performance should begin with a more precise question than whether the website is fast: Which pages are slow, for which users and during which part of the visit?
Systematic troubleshooting makes it easier to choose the right solution. It also prevents developers from spending time compressing images when the real problem is heavy scripts, poor caching or slow database queries.
Do not measure the entire website as one page
Business websites usually consist of several page types with different technical characteristics. An article page may be simple and well cached, while product search, login or checkout requires more database operations and more JavaScript.
Therefore, start by dividing the website into representative page types:
- Homepage and landing pages
- Articles and expert content
- Product and category pages
- Search and filtering
- Forms and checkout flows
- Logged-in or personalized pages
Then select one or two important pages from each group. This makes it possible to identify patterns. If all product pages are slow, the problem is probably related to the template, data or a component. If only one product page is slow, the cause may be a particular image, video, integration or unusually large amount of content.
Use Core Web Vitals as symptoms, not the final answer
Core Web Vitals describe key aspects of the user experience. The measurements are useful, but they primarily tell you what the user experiences. They do not always point directly to the technical cause.
Slow main content points to LCP
LCP concerns how quickly the largest visible content element is displayed. This is often a hero image, a large heading or a prominent content block.
Poor LCP may be caused by an oversized image, but also by slow server response, render-blocking CSS, fonts loading late or the browser discovering the main element too late. Therefore, check which element is actually being measured before you start optimizing.
Slow clicks and keystrokes point to INP
INP indicates how quickly the page responds when the user clicks, taps or types. A page may appear fully loaded and still respond slowly because the browser is busy with JavaScript.
This is often noticeable in menus, filters, date pickers, forms and shopping carts. Typical causes include large script bundles, many concurrent tracking scripts or components that perform unnecessary work for every action.
Content that shifts points to CLS
CLS measures visual instability. The problem occurs when elements change position after the page has been displayed. The user may end up clicking the wrong button because an image, notification or form suddenly pushes the content downward.
Missing reserved space for images and ads is a common cause. The same applies to fonts that change the size of the text, information fields inserted at the top of the page and components that only get their correct height after JavaScript has run.
Distinguish between lab tests and real-world use
A controlled test is useful for reproducing errors and comparing performance before and after a change. Data from actual visits shows how the website performs on users' phones, networks and browsers.
Both are necessary. A lab test can show exactly which script is blocking the browser, but it does not by itself indicate how many customers are affected. Usage data can show that a page type has a problem, but it does not always provide a clear technical explanation.
Also be aware of the difference between first and subsequent visits. On the first visit, the browser cache is empty. On subsequent visits, images, fonts, CSS and JavaScript may already be stored locally. If you test only with a warm cache, the first visit may appear better than it really is.
A troubleshooting sequence that reduces guesswork
- Identify the affected page type. Determine whether the problem affects the entire website, specific templates or a single page.
- Describe the symptom. Is there a delay before anything appears, a late-loading main image, a slow response after clicking or content that shifts?
- Test under the right conditions. Compare mobile and desktop, an empty and warm cache, and logged-in and logged-out users where relevant.
- Isolate the technical layer. Examine the server response, database, images, CSS and JavaScript separately.
- Change one major thing at a time. Otherwise, it will be difficult to know which measure made a difference.
- Check the entire customer journey. A fast landing page helps little if the form or payment process is still slow.
How to identify the most common causes
Images that are larger than their display size
Image optimization is not just about compression. The browser should receive an image with dimensions suited to the available space and a file type appropriate for the subject. A large original image should not be sent to a small card view on mobile.
Prioritize the image that is visible first. Images farther down the page can normally be loaded later. However, avoid deferring the loading of the main image if it is central to the first viewport. Also specify width and height so the browser can reserve the correct space before the file has finished loading.
JavaScript that keeps the browser busy
A lot of JavaScript is not automatically a problem. What matters is how much must be loaded, parsed and executed before the page can be used.
Pay particular attention to features that load on every page, even if they are only used in certain places. An advanced map does not need to burden article pages without maps. The same applies to calculators, carousels, chat, analytics tools and online store features.
Break large tasks into smaller parts, load features when they are needed, and remove scripts that no longer have a documented purpose. Always test important interactions afterward. Aggressive deferral can make the page faster on paper but break menus, forms or tracking.
CSS that delays or hides content
Large stylesheets may contain rules from old templates and components that are no longer used. The browser still has to retrieve and process the files.
Cleanup should be carried out in a controlled manner. It is easy to remove a rule that is only used on a rare page type or error message. Distinguish between styles needed for the first view and styles belonging to features farther down the page. At the same time, keep the number of small files at a reasonable level so the solution does not become unnecessarily complex.
Caching that is missing or masking the problem
Good caching reduces repeated work. Completed pages, database queries and static files can often be reused instead of being built or retrieved again for every visit.
Check what is actually cached, how long it is stored and what clears the cache. If the entire cache is cleared every time an editor updates a small piece of text, many users may encounter a slow, cold page at the same time.
Remember that page caching does not solve everything. Search, shopping carts, checkout and logged-in areas often contain dynamic data. If these parts are slow, you need to investigate the application and database rather than adding yet another cache layer over the problem.
The database making dynamic pages slow
Database problems often appear as a long delay before the browser receives any content. Common signs are that search, filtering, administration or product pages gradually become slower as the amount of data increases.
Investigate which queries take time, how often they run and whether the same information is retrieved multiple times in a single page view. Old data, unnecessary fields and inefficient lookups can cause noticeable delays. Cleanup must be planned with backups and testing, not performed directly in production as an emergency measure.
Perceived speed must be assessed separately
Users do not evaluate a website with a measurement tool. A short wait can feel acceptable if the page provides clear feedback. The same wait feels longer when nothing happens.
Therefore, provide immediate feedback after important actions. A button can indicate that submission is in progress. A search can display a simple status. The content area can reserve space while data loads so the rest of the page does not jump.
This does not replace technical optimization. A loading indicator does not make a slow database faster. However, it reduces uncertainty and prevents users from clicking multiple times because it appears that their action was not registered.
Conclude with a documented diagnosis
A useful performance report should be concise and ready for decision-making. Note which page type is affected, what symptom the user encounters, the probable cause, the proposed measure and how the improvement will be verified.
Example: On mobile, product pages display the main image late on the first visit. The image is larger than the display requires and is prioritized too late. The measure is to deliver appropriately sized images and prioritize the first product image. The effect is verified using the same test setup and then against data from actual visits.
This approach makes website performance manageable. You move from a general message that the website is slow to a specific issue on a particular page type, with a measure that can be tested. This leads to better prioritization and reduces the risk of costly changes that do not solve the user's problem.
