Find the first bottleneck: A practical method for faster websites
A slow website rarely becomes fast through random individual fixes. First find where the wait occurs, then prioritise the measure that actually improves the user journey.
Category: Website performance
When a website feels slow, it is tempting to compress a few images, install a caching solution or remove a plugin. Such measures can help, but they do not necessarily address the problem. If the server takes a long time to generate the page, fine-tuning CSS will do little. If the main image loads too late, a faster database will not fix the overall user experience.
A better approach is to find the first bottleneck in the loading process. This is the point where the delay begins and slows down what the user needs to see or do. Once this point has been identified, it becomes easier to choose between measures involving the server, database, caching, images, JavaScript and CSS.
Start with the user journey, not the homepage
The homepage is often the most tested page on a website, but not necessarily the most important. A potential customer may go directly to a service page from a search, open a product page from an ad or go straight to a form from an email.
Therefore, choose three to five representative pages or actions before you start measuring. For example, a business website might test:
- a key service page opened from an external search
- an article with several images and related posts
- a contact form with validation
- a product page or category page in the online store
- navigation from one internal page to another
Test both the first visit and subsequent navigation. The first visit shows what a new user encounters without cached resources. Subsequent navigation shows whether caching actually reduces waiting time as the user moves around the website.
Divide the waiting time into four phases
It is easier to find the cause when loading is divided into phases. Each phase points to different technical measures.
1. Before the browser receives content
If it takes a long time before the browser receives the first response, the problem is often on the server side. Possible causes include heavy database queries, extensive processing in the content management system, external integrations or missing page caching.
Test the same page several times, both as a logged-out and logged-in user. If logged-out visits are fast but logged-in visits are slow, page caching may be hiding an underlying weakness in the application or database. This is particularly relevant for editors, logged-in customers and online stores, where parts of the content must be generated dynamically.
2. Until the main content becomes visible
When the server responds quickly but the most important content still appears late, you need to examine the resources the browser needs to render the page. The Core Web Vitals metric Largest Contentful Paint, often abbreviated as LCP, concerns when the largest visible content element is displayed.
The LCP element is often a hero image, a large heading or a content block. Find out which element is actually being measured before you optimise. A large hero image may be well compressed and still appear late because the browser does not discover it early enough. It may also be delayed by CSS, fonts or JavaScript that block rendering.
For images, check that the correct image size is delivered to the device, that the format is suitable and that the file is not larger than the dimensions at which it is displayed. Images further down the page can be loaded later. The main image at the top, however, should be prioritised and not treated as if it were below the fold.
3. From visible page to functional page
A page can look complete without being ready for use. The user clicks the menu, opens a filter or starts typing, but the browser responds slowly. In that case, JavaScript is often part of the problem.
Interaction to Next Paint, INP, measures how quickly the page provides visible feedback after user actions. Heavy JavaScript execution can block the browser while tracking tools, animations, calculators, chat, consent solutions and interface features work at the same time.
Create an overview of which scripts load on each page type. A booking tool may not need to load on every article. A product gallery does not need to run on the contact page. Remove unused code where possible, and load features only when the page actually needs them.
CSS should be assessed in the same way. Large stylesheets may contain rules for components that do not exist on the current page. Critical styles for the content at the top should be available early, while the rest can be handled without blocking what the user is waiting for.
4. When content shifts
Cumulative Layout Shift, CLS, reveals unexpected shifts in the layout. A typical example is a button moving because an image, ad, form or notification is inserted after the rest of the page has been displayed.
Reserve space for images, video, embedded elements and dynamic messages. Also be aware of fonts that change the text width and line breaks when they load. The goal is for users to be able to start reading and taking action without the content shifting as they go.
Use caching at the right level
Caching is not a single measure. The browser cache stores static resources on the user’s device. Page caching can deliver pre-generated HTML without the content management system rebuilding the page. Object caching can reduce repeated database operations. An intermediary cache can deliver resources closer to the user.
First clarify what can be cached, how long it can be cached and what should trigger the cache to be cleared. Overly aggressive caching can display outdated content, incorrect prices or data from the wrong context. Overly cautious caching provides little performance benefit.
Also check whether the cache is actually being hit. A solution may be enabled without having any effect because cookies, request parameters or personalised elements make each request unique. Therefore, measure the difference between first and repeat visits instead of assuming that the cache setting is working.
Investigate the database when the server is the bottleneck
The database should not be optimised simply because the website has many posts or products. What matters is which queries are run, how often they are run and how much data is processed per page view.
Signs of database problems may include certain page types being significantly slower than others, the administration interface taking a long time to open lists, or performance dropping sharply with many concurrent visits. Filtering, search, related products and content retrieved using extensive criteria can be more demanding than standard content pages.
Look for repeated queries, unnecessarily large results and data that is loaded even though it will not be displayed. Old revisions, temporary data and remnants of removed extensions can be cleaned up, but cleanup alone does not replace analysis of heavy queries. Back up the database and test changes before modifying the production database.
Combine field data with controlled tests
Core Web Vitals should be evaluated using real-user data once the website has sufficient data. This data captures variations in devices, networks and geographic locations. The drawback is that it reflects a period that has already passed, and that it can take time for improvements to become visible.
Controlled tests provide faster feedback and make it possible to repeat the same scenario. They are useful for identifying specific causes, but do not represent all users. Therefore, use field data to understand the scope and lab tests to diagnose and validate changes.
Always test again after making a change. For example, a smaller JavaScript file may reduce blocking while simultaneously introducing errors in the menu. A new image format may produce smaller files but create unnecessary server-side processing if images are generated with every request.
Perceived speed is more than the measurement result
Users do not judge a website based on a technical report. The experience is also affected by whether the page provides early feedback, whether content appears in a sensible order, and whether it is clear that an action has been registered.
Show the most important content first. Provide immediate visual feedback when users submit a form or add an item to the shopping cart. Avoid empty spaces while entire components wait for data. A simple and stable placeholder can make the wait understandable, but should not be used to conceal that a fundamental process is too slow.
Perceived speed is also about removing unnecessary steps. A technically fast product page can still feel cumbersome if the filter requires multiple confirmations, or if a form loads new fields without clear feedback.
Prioritize one documented bottleneck at a time
Create a short action list in which each item describes the affected page type, observed problem, likely cause and expected improvement for users. Prioritize problems that affect important user journeys and many visits, not just actions that are easy to implement.
- Choose a specific page and action.
- Determine whether the delay occurs on the server, during rendering or in the interaction.
- Identify the element, resource or request causing the delay.
- Make one focused change.
- Retest functionality, measurement results and perceived speed.
- Track progress over time using real-user data.
This approach makes performance work less random. You avoid spending time on general cleanup when the actual problem is a late-loading hero image, a heavy database query or JavaScript running on pages where it is not needed. The result is not just better measurements, but a website that responds faster where users actually notice it.
