The Homepage Is Fast, but the Customer Journey Is Slow: Troubleshoot Performance by Page Type

Category: Website performance

A fast homepage does not mean the website is fast. Customers may encounter entirely different performance problems on the product page, in the article archive, in the contact form or in the shopping cart. Even so, the homepage is often the page that gets measured because it is visible, easy to find and important internally.

A better approach is to investigate the website by page type and user task. This makes it possible to distinguish between problems in templates, images, JavaScript, caching, databases and external services. It also gives you a more precise basis for prioritising measures.

Start with the pages involved in a real user journey

Do not choose test pages at random. Start with the most important tasks the website is meant to support. For a service business, the journey may go from a landing page to a service page and then to a contact form. For an online shop, it may go from a category page to a product page, the shopping cart and checkout.

Create a small test set that covers different technical characteristics:

• An important landing page with a large hero image and a clear call to action.
• A content-rich page with several modules, images or videos.
• An archive, category or search results page with many database queries.
• A page with a form, product selection or other interactive functionality.
• A personalised or dynamic page that cannot be cached in the usual way.

The test set does not need to be large. The point is for it to represent different templates and load patterns. If all test pages use the same page template, you risk overlooking problems that only occur elsewhere.

Distinguish between waiting time, rendering time and response time

“The page is slow” is not a precise description of a problem. Users may wait a long time before anything is displayed, find that the main content appears late, or encounter a page that looks finished but does not respond to clicks.

Core Web Vitals provide a useful language for three central parts of the experience:

• Largest Contentful Paint, LCP: How quickly the largest visible content element is displayed. This is often a hero image, a heading or a larger block of content.
• Interaction to Next Paint, INP: How quickly the page provides visible feedback when the user clicks, taps or types.
• Cumulative Layout Shift, CLS: How much the content shifts unexpectedly while the page loads and is used.

These metrics show that there is a problem, but not necessarily why. A poor LCP may be caused by an oversized image, a slow server response, blocking CSS or main content that is created by JavaScript. Measurements must therefore be linked to the page type and the technical cause.

Use both field data and controlled tests

Field data shows how real visitors experience the website across different devices, networks and times. Controlled tests make it easier to reproduce the same situation and examine loading and execution details.

If field data shows a problem that cannot be reproduced internally, that does not mean the problem has disappeared. Visitors may use less powerful phones, slower networks or browsers with different conditions. At the same time, a single controlled test may give an unnecessarily dramatic or positive impression.

Therefore, compare several runs, both with an empty cache and during repeated visits. Also test the mobile view and the pages that actually receive traffic. Record the time, test conditions and page version examined so that the results can be compared after an intervention.

Read the loading process in the right order

When a page has a poor LCP, you should start early in the delivery chain. If it takes a long time for the server to send the first response, image compression alone will have limited effect. Investigate the causes in a fixed order.

1. Check the server response and database

A slow start may be caused by heavy database queries, numerous calls between systems, complex page templates or missing caching. Archive pages, filtering, search and online shop pages are often more dependent on the database than a simple information page.

Look for patterns. Are all pages slow, or only pages with a particular filter, language or content type? Is the response time worse for logged-in users? Does it increase when a page displays many products or related articles?

Measures may include reducing unnecessary queries, improving query logic, limiting the amount of data retrieved, cleaning up obsolete data or caching results that do not need to be recalculated for every visit. Database work should be guided by measurements, not by general clean-up with no known effect.

2. Check caching at multiple levels

Caching is not a single measure. Entire HTML responses can be cached for pages that are the same for everyone. Images, CSS and JavaScript can be stored in the browser. Computed results can be cached close to the application or database.

Check both whether caching exists and whether it is actually being used. A page may bypass the cache because of cookies, login status, tracking parameters or incorrect rules. For online shops, shopping carts, stock status and personal information must be handled differently from static content pages.

Always test what happens after publishing and clearing the cache. Fast caching is of little help if the first visitors after each change receive a significantly slower page.

3. Find the element that determines LCP

Identify which element is actually the page’s largest visible piece of content. It is not always the hero image. On mobile, the heading or product information may be the most important element.

If the LCP element is an image, the file should have the correct dimensions, an efficient format and a size suited to the viewport. The browser should be able to choose between several image sizes, so that a mobile phone does not download a file intended for a wide desktop screen.

The hero image should normally not be treated as content far down the page. Lazy loading is useful for images outside the viewport, but can make the main content slower if used indiscriminately. Also avoid loading the same image multiple times through HTML, CSS and different mobile variants.

4. Investigate CSS and JavaScript

Large code files are not just a download problem. JavaScript must also be parsed and executed. On less powerful devices, this can block the main thread and result in poor responsiveness even after the page appears finished.

Find out which scripts are used on the relevant page type. A map, chat, carousel or analytics tool may not need to load on every page. Split code by function, remove unused code and defer functions that are not necessary for the initial task.

CSS can delay the initial rendering if the browser has to load and process large stylesheets before drawing the content. Prioritize the styles needed for the first viewport, and avoid sending all component variants to every page.

If INP is weak, investigate long JavaScript tasks and events that do too much work on a single click. For example, a filter should not rebuild the entire results list if only a small part needs updating.

5. Stabilize the layout

Layout shifts often occur because space has not been reserved before an element loads. Set dimensions or aspect ratios for images, videos, and embedded elements. Ensure that consent boxes, notifications, and personalized fields do not push the main content down after the user has started reading.

Font files can also change the width and height of text when they become available. Limit the number of variants, choose good fallback fonts, and test how headings and buttons behave before and after the font has loaded.

Improve perceived speed, not just measured speed

Users judge speed by progress and control. An action feels slower when nothing happens after a click. Therefore, provide immediate visual feedback, such as a clear loading state or a disabled button while the form is being submitted.

Show useful content before features that can wait. On a product page, the name, price, image, and purchase options are more important than recommendations and extensive reviews. On a service page, the main message and next step should come before maps, video, and secondary modules.

At the same time, avoid creating a false sense of progress. A loading indicator does not solve long server wait times or heavy code. It only makes the wait more understandable while the technical cause is addressed.

Create an action list by page type

Collect the findings in a simple prioritization. Each item should describe the page type, symptom, likely cause, proposed action, and how the impact will be verified.

A specific item could be: Product pages have weak LCP on mobile because the main image loads late and is too large. The action is to prioritize the right image variant and verify that smaller files are selected on narrow screens. Measure the impact on the same product pages before and after the change.

Prioritize actions that affect important user journeys and multiple pages at once. An improvement to a central page template often provides greater value than fine-tuning a single campaign page. Repeat the tests after each significant change. This way, you know what actually worked and avoid having multiple simultaneous actions obscure cause and effect.

A fast website requires precise troubleshooting

Performance work becomes more manageable when you stop treating the entire website as a single measurement. Test representative page types, distinguish between server waiting, rendering, and interaction, and follow the delivery chain from database to browser.

This allows the team to focus its efforts on the actual bottleneck: caching when the page is calculated unnecessarily often, image optimization when the main visual is heavy, code work when interactions are blocked, and layout improvements when content shifts. The result is not only better metrics, but a customer journey that feels faster and more predictable.