We have spent years making ecommerce pages faster. Developers optimize code, improve caching, compress images, and look for ways to cut down the amount of work a browser has to do. Eventually, there is a point where the obvious improvements are gone. The page is already pretty fast. So what comes next?
Fabian Krumbholz, web performance specialist at Speedkit and Google Developer Expert, brought this question to a Shopware Open Stage session. His talk explored what happens when you stop thinking about how fast the page can load and start thinking about what the shopper is likely to do next. Instead of waiting for a click and loading the next page, the browser can already start preparing for that click in advance.
There is a point where faster gets harder
Speed matters in ecommerce but there is no universal performance number that guarantees better results for every shop. The impact depends on what is being sold and how easily shoppers can find the same products elsewhere.
Using real user data from Speed Kit's customer shops, Fabian shows the relationship between the Largest Contentful Pain (LCP) and conversion rates. At the slower end, bringing a 6 second experience down to 4 seconds may not change how a shopper experiences the site at all. Below one second, it becomes very interesting. As Fabian puts it, “For ecommerce, the money is definitely below one second.”
Where does the delay come from
Fabian breaks LCP into 4 parts: time to first byte, resource load delay, resource load time, and element render delay. On a product page, the LCP element is often the main product image. That means performance depends on how quickly the server responds, when the browser discovers the image, and whether scripts delay rendering. Real-user monitoring shows which of these is actually slowing your shoppers down, something a single test or an average score can't.
Getting below one second is the hard part. Every additional improvement on speed requires more effort. Fabian calls this the wall you eventually hit with traditional optimization: “You can never really eliminate any of these things. You can only make them less painful.” Once time to first byte is above around one second, fixing it becomes an infrastructure project rather than a code change.
What if the browser could see the next click coming
Fabian's work with Speed Kit connects traditional optimization with a newer idea. Instead of making a page faster once a shopper asks for it, the browser starts preparing for what comes next. Google's Speculation Rules API has made this possible and you can get started with only a few lines of code.
There are 2 approaches. With prefetching, the browser loads the HTML for a page ahead of time, removing roughly 200 to 400 milliseconds of waiting. Prerendering goes further. The browser prepares the whole page in an invisible tab, loading its resources, and executing its JavaScript, so when the shopper navigates there it appears instantly.
For a Shopware storefront, the most intuitive example is the journey from a listing page to a product detail page. Shopware includes an experimental Speculation Rules API setting in the storefront configuration from Shopware 6.6 onwards for exactly this kind of navigation.
What it takes to make prediction work in production
Speed Kit built its product around speculation rules and has spent 3 years running it on customer shops. Fabian shared what the team learned about issues you're likely to hit if you do it yourself.
The first is accuracy. Browsers cannot know for certain what a shopper will do next. “You cannot just preload one page, you have to preload ten and hope that one of them is the page the user clicks next.” Speed Kit trains AI models on a shop's real-user monitoring data, which lets it predict about 85% of next pages.
There is also a timing problem. Used out of the box, speculation rules often start too late to prerender the whole page. The question is not only what the shopper will do, but when to start preparing for it. Preparing 10 pages instead of one also means 10 times the load on your server. If the infrastructure is not ready, the shop can go down, so this should never be tested on live traffic.
With prerendering, the page is not passive. JavaScript executes before the customer sees the page. Unseen products can show up in product history, analytics can record page views that never happened, and a prerendered logout page will log the shopper out. Fabian highlights these side effects as one of the biggest challenges in production.
Bandwidth matters too since extra pages cost the shopper data. Compression dictionaries can offset this, but they are not straightforward to set up.
Where to start
Prediction cannot help with the first page a customer visits, because there is nothing to predict yet. Fabian recommends optimizing that first experience as much as possible, especially campaign landing pages where most of the ad budget goes, and then using prediction for everything after.
You can verify real-user data to find what is slowing shoppers down and keep entry pages fast. Then try the Speculation Rules setting in your storefront configuration or look at Speed Kit for prediction at scale.
Bring the conversation to Open Stage
Have something you're working through, a new idea you're curious about, or a solution you want to put to the test? Bring it to Open Stage. We meet every third Thursday on the Shopware Discord, where developers, agencies and community members can share what they're building, exchange ideas and learn from each other.
