The homepage is fast, but the customer journey is slow: Test performance by page type

Category: Website performance

Many performance checks start and end with the homepage. This produces a neat measurement result, but can hide the problems that actually affect customers. Product pages may fetch more data, landing pages may be filled with images and tracking scripts, and forms may respond slowly when users start typing.

Website performance should therefore be assessed by page type and user task, not as one overall characteristic of the website. The goal is to find out where waiting time occurs in the real customer journey and choose measures suited to that particular page template.

Start with pages that serve a purpose

A technical test of the homepage is useful, but it should be only one part of the review. Select a small sample of pages that represent different templates, features and loads.

• An important landing page from search or advertising
• An article or other content page
• A category, archive or search results page
• A product or service page
• A contact form, ordering process or other conversion page
• Cart and checkout if the website is an online store

Prioritize pages that receive a lot of traffic, support important business goals or contain functionality that differs from the rest of the website. This allows you to examine both what users see most often and what is technically most likely to be slow.

Core Web Vitals must be interpreted in the right context

Core Web Vitals describe three central aspects of the user experience. LCP concerns how quickly the largest visible content element loads. INP measures how responsive the page is when the user clicks, taps or types. CLS indicates how much content shifts while the page loads.

The values should not be treated as a single grade for the entire website. A landing page may have weak LCP because the hero image is too large. An advanced form may have weak INP because JavaScript does too much work with every keystroke. A product page may have weak CLS because the image gallery or stock information does not have space reserved for it.

Also distinguish between laboratory tests and data from real visits. A controlled test is useful for reproducing problems and comparing changes. Field data shows how the website performs on actual devices, networks and browsers. Use both: field data identifies vulnerable page types, while laboratory testing helps the developer understand the cause.

Test cold and warm loads

Caching can make the same page behave very differently from one visit to the next. Therefore, test at least two situations:

1. Cold load: The page is opened without the browser or server cache already having the necessary resources ready.
2. Warm load: The user continues through the website or revisits a page, allowing more resources to be retrieved from the cache.

If warm loading is fast but cold loading is slow, you should investigate images, fonts, external scripts and the server’s response time. If both are slow, the cause may lie in the page’s code, database access or the amount of work performed in the browser.

Also perform the test on a typical mobile phone and a realistic mobile network. A powerful workstation on a fast corporate network can hide both heavy scripts and unnecessarily large files.

Images must be optimized for their placement

Image optimization is not just about file format and compression. The most common practical problem is that the website delivers an image that is far larger than the display requires.

First, check the element that affects LCP. On many pages, this is a hero image, product image or large content image. The browser should receive a file that fits the screen size, and the most important image must not be delayed by unnecessary lazy loading.

• Create multiple image sizes and let the browser choose the right variant.
• Compress originals before uploading them to the publishing system.
• Use modern formats when the solution and workflow support them.
• Specify width and height so that space is reserved before the image has finished loading.
• Use lazy loading for images further down the page, not indiscriminately for content near the top.
• Avoid large background images when a regular responsive image solves the task better.

An article template and a product template may need different rules. Product images may need to support zoom, while an illustration in an article can be delivered at a significantly smaller size. Shared upload routines are useful, but they must take usage into account.

Caching must reflect the lifespan of the content

Good caching reduces both server work and downloads, but it must be configured according to the type of page and data involved. Static resources such as images, fonts, CSS and JavaScript can often be stored in the browser for a long time when the filename changes upon updates.

Fully generated pages can also be cached, but not all pages should be treated alike. A public article is easy to cache. A cart, user account or page with personalized content requires clear exceptions. Otherwise, incorrect configuration may show users outdated or incorrect content.

For WordPress and other data-driven solutions, object caching can reduce repeated database queries. This is particularly helpful for page types that build many menus, filters, product data or relationships. The effect should be measured on the relevant templates, not merely assumed.

JavaScript and CSS should be loaded as needed

A common cause of slow performance is that every page loads code for every feature. A simple article may receive JavaScript and CSS for forms, carousels, online stores, chat and analytics tools even though only a small part is used.

Map which files each page type actually needs. Remove unused code, and avoid loading feature-specific resources globally. Not all JavaScript needs to run before the page can be displayed. Scripts that are not critical for the initial view can often be deferred until the content is available or the user needs the functionality.

Pay particular attention to third-party scripts. Chat, video embeds, maps, ad measurement and consent solutions can affect both loading and responsiveness. This does not mean everything should be removed, but each script should have a clear business purpose and only be loaded where necessary.

For CSS, the goal is to give the browser enough style information to display the initial viewport quickly, without sending large amounts of unused code. At the same time, the optimization must be tested visually. Aggressive splitting or delaying of stylesheets can cause brief flashes of unstyled content and more layout shifts.

When the database makes certain templates slow

If the server takes a long time before it starts sending the page, larger images or more compression are not necessarily the right remedy. You should investigate what the publishing solution is doing before the HTML is delivered.

Product searches, advanced filters, related posts and large archive pages can trigger many or resource-intensive database queries. In WordPress, bloated settings that are loaded automatically, old temporary data, unnecessary revisions and poorly maintained extensions can also contribute to the delay.

Log which database calls take time on the page type in question. Then consider whether the data can be retrieved more simply, cached or limited. It is often better to improve one costly query than to add more computing power to an unclear problem.

Perceived speed begins before everything is finished

A page can feel fast even if some resources are still loading, as long as important content becomes visible early and the page responds when the user takes action. Show the heading, main message and next action before less important elements. Reserve space for images, form elements and messages so the page does not jump.

Also provide immediate feedback on actions. When the user submits a form, adds a product to the cart or opens a filter, the interface should show that the action has been registered. The feedback must be real and understandable, not an animation that hides the fact that the process has stopped.

Avoid making the initial viewport dependent on decorative videos, large carousels or external components. If an external service is slow, the most important content should still be available.

Create a simple performance map

Bring the overview together in a table or task list with one row per page type. Note which user task the page supports, which element is the LCP, which interactions are important, which external services are loaded, and whether the page can be fully cached.

Then record the most important problem and who owns the action. An image-related issue may be the joint responsibility of the content manager and developer. A slow database query requires development work. An unnecessary marketing script must be clarified with whoever requested the tool.

Test the same page type again after the change, under the same conditions. At the same time, verify that forms, tracking, login and the purchase journey still work. Performance work is only successful when the improvement can both be measured and used without introducing new errors.

The most important lesson is simple: A website is not fast because the homepage is fast. It is fast when the customer can find, understand and take action without unnecessary waiting throughout the entire journey.