A shopper holding a phone gives a store a few seconds. If the product photo and price do not appear in that time, they go back to the Google results and tap the next store, and Google takes note, because page speed and stability are among the signals it uses to order results.
A slow store therefore pays twice - for the customer who already arrived and for the ranking that would have brought the next one. Below are the six optimisations that, in our projects, decide whether a store stays within Google's thresholds.
Where a Slow Store Loses Money
To a store owner, a slow page rarely looks like a problem. On an office laptop with fibre, the store opens instantly. The shopper opens it on a four-year-old phone, on a tram, on whatever connection is there. The same store can show a blank screen for several seconds.
Google measures this with three metrics and publishes the thresholds a page has to meet. LCP (Largest Contentful Paint) is the moment the shopper sees what they came for - the product photo, the price, the first items on a listing. The threshold is 2.5 seconds. INP (Interaction to Next Paint) is the delay between a tap and the page's response, after tapping a filter, "add to cart" or a gallery arrow. The threshold is 200 milliseconds. CLS (Cumulative Layout Shift) is layout jumping, where a banner or image loads above a button and pushes it down. The threshold is 0.1. Google grades a page on data from its visitors in Chrome, so one quick test on an office laptop changes nothing.
The cost shows up in two places. In sales - a shopper waiting for a photo still has the Google results tab open and a second store within thumb's reach. Abandoning a listing costs one visit, and abandoning a cart costs an order that almost happened. In rankings - for similar offers, Google places the store that meets the thresholds higher, so a store below them hands traffic to a competitor before anyone compares prices.
In wholesale the same problem is milder. A customer logs in to a B2B panel, like the one we built for iBox, because their price list is there and they have an order to place. A B2C shopper has no such obligation, and the Google results hold other stores with the same product.
Three Routes to a Fast Store - a Comparison
On launch day almost every store is fast. The differences appear a year later, when the store carries a dozen marketing scripts, a few thousand more products and a theme nobody has slimmed down. The comparison is qualitative.
| Criterion | Off-the-shelf template on subscription (SaaS) with apps | Open-source store engine with a ready theme and plugins | Tailored store on open components (Laravel and Lunar) |
|---|---|---|---|
| Return on investment (ROI), i.e. when speed starts earning | Low entry cost. Speed is whatever the vendor provides, and every added app lowers it | Low entry cost, then the cost of slimming down. The theme and plugins load code for features the store does not use | Higher entry cost. The return comes from a page that loads only what sells, and from the rankings that follow |
| Time to start selling (Time-to-Market) | Shortest - configuration and product import | Short, if the theme fits. Work on Google's thresholds usually starts after launch | Longer, because the front end and catalogue are built for one specific store |
| Running costs (OPEX) | Subscription plus app fees. Server performance outside your control | Hosting plus theme and plugin updates, any of which can break the score | Hosting and development. No licence fees, because Laravel and Lunar are MIT-licensed |
| Flexibility | Within the theme editor and the vendor's app catalogue | Large on paper, limited by how many plugins a page can carry on a phone | Every element of the page and catalogue can be arranged around what the shopper should see first |
| Vendor lock-in | Data and front end sit with the vendor. Changing platforms means a migration | Open code, but dependent on a theme and plugins someone else develops | Code and data belong to you. Changing the contractor does not require changing the platform |
If the catalogue holds a few hundred products and the store sells mostly to returning customers, an off-the-shelf template is enough. A tailored store makes sense when the edge comes from a catalogue of thousands of SKUs from several suppliers and the Google traffic it should bring. That is what the industry-tailored B2C stores we build look like, on Laravel and Lunar.
What Happens Between a Google Click and an Order
A shopper's path through a store that stays within the thresholds, with the Google metric measured at each step:
- The shopper types "urban electric bike" into Google and taps a result. From this moment, LCP is running.
- The server returns a finished listing page with the first products, photos and prices. The shopper sees them before anything else loads.
- Photos below the first screen load only on scroll.
- The shopper taps the "wheel size" filter. The list refreshes at once, because filter values and product counts are computed in advance. Here Google measures INP.
- They open a product page. The main photo loads with priority, and space for the gallery, price and button is reserved, so nothing moves when reviews and a banner load. Here Google measures CLS.
- They tap "add to cart". The cart responds immediately, and marketing scripts receive the event afterwards, in the background.
- The checkout form and payment load only what that step needs, with no chat and no recommendations.
Six Optimisations That Decide the Score
The order follows where loading takes longest in a B2C store.
A Page Assembled on the Server Rather Than in the Browser
Many modern storefronts send the browser an empty page and a bundle of scripts, and the shopper's phone assembles the listing on the spot. On a mid-range phone on a mobile network that takes seconds, during which the shopper looks at a blank screen and LCP climbs.
Server-side rendering reverses the order. The server sends a finished listing or product page with the photo and price, the browser shows it at once, and interactivity attaches in the background. The stores we build on Laravel and Lunar PHP work this way, and Google receives ready content to index.
The second half of this optimisation is the time the server needs to prepare the page. Finished listing fragments are kept in the server's memory and refreshed when a price or stock level changes, so the hundredth visit to a category costs a read from memory.
Product Photos That Weigh What They Should
Photos are the heaviest element of a store page. Distributor price lists arrive with print-sized files, and without processing they reach the page in the form the supplier sent. A shopper on a phone then downloads many times more data than the screen can display.
A properly configured store prepares several sizes of every photo, sends the one that fits the screen and stores them in a modern format (WebP or AVIF). The main photo on a product page loads with priority, because it usually decides LCP. The gallery and photos further down the listing load only on scroll.
With a catalogue of thousands of SKUs, this processing has to happen automatically at import. One batch of new products in original size is enough to push LCP for an entire category over the threshold.
A Budget for Third-Party Scripts
Ad tags, a retargeting pixel, chat, a reviews widget, an A/B testing tool, a heatmap, a consent manager. Each is a few lines to paste and each runs on the shopper's phone. Together they mean that after tapping "add to cart" the phone is busy with a dozen other things, and INP crosses the threshold.
The optimisation consists of two decisions. Scripts that are not needed to show the product load after the first interaction, or while the browser is idle. Scripts nobody in the company can tie to a purpose are removed - a tag left over from a campaign two years ago still executes on every visit.
This decision belongs to management, because the script is usually added by marketing and the effect is seen by sales, in mobile conversion. Every new script should pass a check of what it did to response time before it stays.
A Layout That Does Not Jump
Layout jumping has several sources. An image without reserved dimensions, which the page makes room for only after downloading it. A cookie consent bar that slides in from the top and pushes everything down. A brand font that replaces the system one and changes the heading's width. A promo banner injected above the listing by a marketing tool.
For the shopper the effect is the same each time. They aim at "add to cart", the layout shifts, and they hit "compare" or an ad. For Google the effect is a CLS value above 0.1 on the URLs that are supposed to sell.
The fix is that every page element has its space reserved before it loads. Images carry their dimensions, the consent bar overlays content instead of pushing it, the brand font has a fallback of the same width, and banners have a fixed slot of known height.
A Catalogue That Does Not Slow Down the Listing
In a store with a large catalogue, the listing with filters is the most expensive page to prepare. Every filter with a product count next to each value means counting thousands of items by attribute. If each supplier writes wheel size or battery capacity differently, the store counts them on the fly at every filter tap and shows values with no product behind them.
The solution starts in the catalogue. Attributes are brought to one standard at import, filter values come straight from attributes, and product counts are computed in advance. Categories go down to a level where the listing has a sensible length. A filter tap then ends in an immediate response, and listing LCP is independent of how many products the catalogue holds.
We describe the same data work in the article on B2B platform implementation, because in wholesale the catalogue problem looks identical.
Field Measurement and a Threshold in Acceptance Criteria
A speed test in a lab tool measures one visit, on one device, under one set of conditions. Google grades a page on data collected from its visitors in Chrome, and Search Console shows for free which store URLs are good, which need improvement and which are poor. Rankings follow that report.
If nobody reviews that report regularly, a drop in the score after a new theme or plugin comes to light a quarter later, as a drop in traffic. The optimisation here is a process. Google's thresholds are written into the contract with the contractor as an acceptance condition, and into the release process. After every release someone checks the report against the previous week. The Core Web Vitals score goes into the monthly review next to mobile conversion, because those two numbers move together.
The Trippi Bike Store on Lunar PHP
The challenge. Trippi sells bikes, e-bikes and accessories from a catalogue of four distributors, each describing the same equipment differently. Together that is more than 22,000 items in four price lists and four formats. Before the project, categories mirrored the distributors' price lists, and filters were one set for the whole store. The route to a product ran through the search box and the name as written in the price list. Onboarding a new supplier took 2-3 weeks.
The solution. A store built on Lunar PHP and Laravel, with Idosell and Tpay behind it. We brought the four price lists down to a single category tree and a shared set of attributes at import, and out of 22,000 items we selected the 12,000 SKUs Trippi wants to sell. Filters are assigned to categories, their values come straight from attributes, and each value shows a product count. The "Electric" category listing is 1,368 products broken into subcategories that match how a shopper names the bike they want. For speed, that means the listing computes nothing on the fly, and a shopper on a phone gets a subcategory of sensible length instead of the whole category at once.
The results. The 12,000-SKU catalogue became browsable through categories and filters instead of only through search. Onboarding a new supplier shrank from 2-3 weeks to 2-3 days. The store runs on open Lunar PHP on its own server, with no licence cost, so the decision about stronger hosting or caching is Trippi's. The full story is in the Trippi case study.
Board Checklist Before a Conversation About Speed
Each of these questions can be checked in a day without a developer:
- Open your store on a phone, on a mobile network, in a private window. How many seconds pass before you see the first product's photo and price?
- Does the Core Web Vitals report in Search Console show your URLs as good, and who looked at it in the last month?
- How many third-party scripts does a product page load, and who in the company can say what each one is for?
- Who can add a marketing script to the store, and does anyone check afterwards what it did to response time?
- Are photos from supplier price lists resized automatically at import, or do they reach the page in their original size?
- How long does the listing take to refresh after a filter tap in the store's largest category?
- Does the contract with your contractor, or your release process, state a speed threshold as an acceptance condition?
- What share of orders comes from phones, and does anyone compare mobile conversion with desktop conversion?
Let's Talk About Your Store's Speed
If you want to know how these six optimisations would translate to your store, write to us or book a call. We will go through your Core Web Vitals report in Search Console, say what is pulling the score down, and assess whether it can be fixed on the current platform or needs a front end and catalogue built for your industry. If you also sell wholesale, we will look at how the same catalogue could feed a B2B procurement platform without keeping data in two places.
About the author