2,942 queries per product page. Now 199.

One product page, built like twenty.

A B2B retailer selling more than €20M a year runs eight storefronts on one Magento install. Its product pages are rich: stock per warehouse, accessories, bundles, documents, videos. They had also become slow. Without cache, one product page took almost 10 seconds of server time, ran 2,942 SQL queries and fully loaded about 20 products to show one.

Real-user data agreed. On desktop, the 75th percentile LCP was 4.1 s and time to first byte was 3.5 s. Google Search Console kept flagging slow URLs. At peak traffic, one heavy query caused database deadlocks.

Fix the server first. Cache comes after.

Cache hides a slow page, but every cache miss, every flush and every new URL still pays for it. We profiled uncached product pages with Blackfire and read the database's own query statistics. Then we fixed each block of the page one at a time.

• Stock lookups, one query instead of hundreds.Stock was read with one SELECT per inventory source, per product. With 20 sources and 30 product tiles on a page, that's 600 queries. One joined query now returns every product's stock and tells own warehouse stock from dropship suppliers.
• A heavy extension query, cached.A product-attachments extension ran a query so slow that it caused deadlocks at peak traffic. We rewrote the query and moved the result into Redis.
• Flat tables for product relations.Four related-product blocks and a bundle block each loaded full product models. Two flat index tables (simple products and bundles) now hold what those blocks show: price, stock, URL, image. A sales-rank table lets them sort and limit in SQL. Reindexing takes under a minute for simples and two for bundles, across 20,000+ products and 8 stores.
• No reloading data the page already has.Structured data (rich snippets) loaded full products again to print values already on the page. It now reads the objects already built, or Redis.

-- before: one query per source, per product, per block (20 × 30 = 600)
SELECT quantity, status FROM inventory_source_item
WHERE sku = ? AND source_code = ?;

-- after: one query per page (simplified)
SELECT si.sku, src.is_dropship, SUM(si.quantity) AS qty
FROM inventory_source_item si
JOIN inventory_source_stock_link l ON l.source_code = si.source_code AND l.stock_id = ?
JOIN inventory_source src ON src.source_code = si.source_code
WHERE si.sku IN (…) AND si.status = 1
GROUP BY si.sku, src.is_dropship;

Every page cached before the first visitor asks for it.

varnishstat showed that at peak traffic Varnish ran out of memory and evicted cached pages to make room for new ones. We gave it enough memory for the whole catalogue. Then we made sure the cache is always full.

A small Magento module exports every CMS, category and product URL for each storefront. A cache warmer written in Rust requests them all with a fixed limit on concurrent requests, so the servers are never overloaded. Magento keys its cache on the X-Magento-Vary cookie, so the warmer crawls each URL once for each customer group. The cache is flushed every night and warmed again straight away. During the day, the warmer keeps running.

// warmer core: bounded concurrency over the exported URL list
stream::iter(urls)
    .map(|url| client.get(url).header(COOKIE, &vary_cookie).send())
    .buffer_unordered(MAX_IN_FLIGHT)  // never more than N requests at once
    .for_each(|res| async { record(res) })
    .await;

From 175 requests to 58.

The page made 175 requests and weighed 4.4 MB. Several blocks loaded by AJAX after the page itself, so the page kept changing for seconds. Speed Index was 7 s and CLS 0.65. Too many fonts, too much RequireJS, and an A/B-testing script that faded the page out after it had already loaded.

• Blocks loaded by AJAX after page load are now in the cached HTML.This fixed most of the Speed Index and layout shift.
• JavaScript bundled with Magepack.We tried Magento's own bundling and another extension first. Magepack gave the best result.
• The main image loads first.The gallery's first image is eager, with fetchpriority="high".
• CRM forms load on demand.The form script loads only when a visitor opens a form.
• Videos show a thumbnail until clicked.Video iframes load only after a click, in descriptions and in the gallery.

Marketing tags (A/B testing, tag manager, consent) belong to another team and are being fixed separately. We measured with and without them so each team could see its own share.

RequireJS was the ceiling. Hyvä removed it.

Magepack took desktop as far as RequireJS and Knockout could go. Mobile was still around 50. The product page has now been rebuilt on Hyvä with Alpine.js, and it is in testing.

• The full menu is cached in Redis. Its deepest level loads on interaction.
• All JavaScript, including the gallery, waits for the first interaction. The LCP image is preloaded in the <head>.
• Modals are rendered on interaction, not on load.
• Images re-encoded, SVG icons trimmed, and repeated icons served from one SVG sprite.
• The web font is subset to Latin: 80 KB down to 30 KB.

Before and Magepack figures are production runs. Hyvä figures come from the pre-production build without third-party tags, and will be replaced with production runs after launch.

Lab numbers are a promise. Field data is the proof.

Google ranks on what real visitors experience, measured by Chrome over 28 days. On desktop, LCP, FCP and INP now pass, and time to first byte is three times faster than before.

CLS is the one metric still above the line. A marketing script added after the optimisation work shifts the layout, and it is being fixed in the Hyvä release. It shows why performance needs monitoring: one new script can undo months of work.

Four phases, each one measured.

1. Phase 1Profiling with Blackfire and RDS query insights. Stock, attachments, flat tables, structured data.
2. Phase 2Varnish memory sized for peak traffic. URL export and cache warmer in production.
3. Phase 3AJAX blocks removed, Magepack, LCP image, third-party scripts loaded on demand.
4. Phase 4Hyvä theme, product page first. In testing now.