The performance conversation usually starts with a score. It should start with a question: on what device, on what connection, and at what point does the user give up? For a vehicle catalogue or a product listing, the honest answer is a mid-range Android phone on a 4G connection that drops to 3G in a lift. Lab scores measured on an M-series laptop over fibre describe a device and network your buyers do not have.
1. You are shipping listing data as JavaScript
This is the most common cause and the most consequential. If the catalogue arrives as a JSON payload that React then renders on the client, the browser must download the framework, download the data, parse both, and only then paint a listing. On a slow connection that sequence is visible.
The fix is to render the listing on the server so the first response already contains the markup and the specification text. Hydration then makes it interactive rather than creating it. The user reads the price before the JavaScript has finished parsing, which is the entire point.
2. Images are sized for a designer's monitor
Catalogue imagery is where pages are quietly lost. A listing that ships desktop-resolution photographs to a phone wastes bandwidth on every card, and if those images lack explicit dimensions the layout reflows as they arrive — which is what actually destroys Core Web Vitals.
- Serve modern formats and let the platform negotiate what the browser supports.
- Generate a size ladder and let the browser pick; do not serve one 2000px asset to everyone.
- Always set explicit width and height so the browser can reserve space before the bytes arrive.
- Lazy-load below the fold; never lazy-load the first card. That is the one the user is waiting for.
3. Third parties are spending your budget
Chat widgets, heatmaps, session recorders, three analytics tools and two advertising pixels will together cost more main-thread time than your entire application. They are also the reason a site can be genuinely well-built and still fail a field audit.
Start by loading them after interaction rather than on arrival, and audit what each one is actually used for. In most businesses two of the five are collecting data nobody has opened in a year.
4. The render strategy is uniform when it should not be
Not every route deserves the same treatment. A homepage, a category listing and an individual product page have completely different traffic patterns and update frequencies.
// The question is not 'SSR or SSG' but 'how stale is this allowed to be?'
// Marketing and category pages → static, revalidated on an interval
// Product detail → static, revalidated on inventory change
// Search results → server-rendered per request
// Account and cart → client-side, behind authChoosing per route is the difference between a site that is fast everywhere and one that is fast on the pages nobody monetises.
What to measure instead of a score
Lighthouse is a diagnostic tool, not a verdict. Field data from real users is the number that matters, and the two are often very far apart because field data includes the device and network mix you actually face.
- Largest Contentful Paint, segmented by device class.
- Interaction to Next Paint — this is where heavy third parties show up.
- Cumulative Layout Shift, which is almost always an image or font sizing problem.
- Enquiry or checkout completion, segmented by device. This is the only metric that is not a proxy.
Capture a baseline before you change anything. Without it, you cannot tell improvement from weather.
The order to do things in
- 01Capture field baselines segmented by device and connection.
- 02Move listing data to the server so content arrives in the first response.
- 03Fix image delivery — formats, size ladders, explicit dimensions.
- 04Defer or remove third-party scripts, then re-measure.
- 05Only then tune the framework: rendering, bundling, prefetching.
Working in that order is what moved a Dubai export catalogue the most. The framework tuning came last, and it was the smallest contributor.