A slow e-shop is not just a technical problem — it is a business problem. Google's 2023 research found that every 100 ms of load time delay reduces the conversion rate by 0.3 to 1%. A Deloitte study showed that improving speed by 0.1 seconds led to an 8.4% increase in conversions and a 9.2% increase in average order value for retail e-commerce. Yet most store owners only start investigating slow loading when revenue starts dropping — and even then they look in the wrong places.
Measure first, then fix
Before any optimisation, you need to know exactly where the problem lies. The most common mistake is to upgrade hosting or compress a few images and then wonder why nothing improved.
The core tools you should know:
Google PageSpeed Insights (pagespeed.web.dev) — enter your store's URL and get a score from 0 to 100 for both mobile and desktop. The important numbers come from real-user data (CrUX data), not just the lab test. A score below 50 on mobile is a critical state.
Core Web Vitals are three metrics Google uses as a ranking signal:
| Metric | What it measures | Good value |
|---|---|---|
| LCP (Largest Contentful Paint) | How fast the main content loads | under 2.5 s |
| INP (Interaction to Next Paint) | How fast the page responds to clicks | under 200 ms |
| CLS (Cumulative Layout Shift) | How much the page jumps during load | under 0.1 |
Google Search Console → "Web Experience" section shows your real-visitor data, not a simulated test.
Real-world example: Autodíly Procházka, a car parts retailer based in Pardubice, had a PageSpeed score of 38 on mobile. The audit revealed the main issue was an LCP of 6.8 s caused by the first hero product image — a 2.1 MB file that wasn't preloaded. Fixing that single problem moved the LCP to 2.9 s and the overall score to 61.
Image optimisation: the biggest speed gain for the least effort
Images account for 50–70% of the total page weight on a typical e-shop. Product photos, banners, icons, logos — the vast majority of stores serve them incorrectly.
Format: Switch to WebP. It is supported by all modern browsers and is on average 25–35% smaller than JPEG at equivalent visual quality. If you are on Shopify or WooCommerce, there are plugins that handle conversion automatically. Custom builds should convert images at upload time.
Dimensions: Serve images at the size they are actually displayed. A product photo shown at 400×400 px does not need to be 2000×2000 px. Use the srcset attribute to serve different sizes for different screen widths.
Lazy loading: Images below the fold do not need to load immediately. The loading="lazy" attribute on <img> tags tells the browser to wait until the user scrolls closer. Exception: the first image on a page (hero or first product) should never be lazy-loaded — preload it instead using <link rel="preload">.
Compression: Tools like Squoosh, ImageOptim, or automated pipelines (Sharp for Node.js) can reduce file sizes by 40–80% without visible quality loss.
Practical tip: Run a quick audit — open Chrome DevTools (F12), go to the Network tab, filter by Img, and reload the page. Sort by file size. The top five images likely account for 80% of image weight. Start there.
JavaScript bloat: what is dragging your store down
The average e-shop page today contains 400–600 kB of JavaScript. Ten years ago it was 50–80 kB. Most of this growth brings no value to the customer — it is analytics scripts, chatbots, A/B testing tools, review widgets, and tracking pixels.
Each of these scripts:
- blocks or slows down page rendering
- consumes device CPU (critical on older phones)
- adds network requests
What to audit and who the usual suspects are:
| Script type | Typical weight | Do you really need it? |
|---|---|---|
| Google Tag Manager (with 15 tags) | 80–150 kB | Audit what you have in GTM |
| Facebook Pixel | 50 kB | Only if you are actively running ads |
| Hotjar / Microsoft Clarity | 60–120 kB | Only if you actively read the data |
| Live chat widget | 80–200 kB | Consider how many conversions it generates |
| Page builder (Elementor, etc.) | 200–400 kB | The biggest offender |
| Third-party review widgets | 30–80 kB | Consider a native implementation |
Page builders deserve a special mention. Tools like Elementor or Divi generate enormous amounts of redundant CSS and JavaScript. If your store runs on WordPress with Elementor, the page builder alone can account for 30–50% of total page weight.
Real-world example: Fashion boutique Elegance Praha migrated from WooCommerce with Elementor to a hand-coded custom theme. Without any other changes, JavaScript weight dropped from 890 kB to 180 kB. The mobile PageSpeed score went from 41 to 79. Conversion rate improved by 14% in the first month.
Server-side rendering vs. client-side for product pages
This is an architectural decision that significantly affects performance — and many e-shops get it wrong.
Client-side rendering (CSR): The browser downloads an empty HTML file, downloads JavaScript, executes it, and only then does the JavaScript fetch product data and render the page. The result: slow first load, poor LCP, and indexing issues.
Server-side rendering (SSR): The server returns complete HTML with product data already embedded in the response. The browser renders immediately. JavaScript is added afterwards for interactivity.
For e-shop product pages, SSR is almost always the right choice. Data changes infrequently (stock, price), pages are indexed by Google, and customers arrive for the first time with nothing cached.
Practical tip: If you are using Next.js, use getStaticProps for product pages with revalidation every 60–300 seconds (ISR). For products with highly dynamic prices or stock levels, use getServerSideProps. Avoid useEffect for loading basic product data — that is the classic CSR mistake that tanks your LCP.
Checkout optimisation: where customers actually leave
Average cart abandonment sits at 70%. Some of this is inevitable — people comparison shop, close tabs, get interrupted. But a large portion is caused by a poor checkout experience.
Factors that drive customers away:
Mandatory registration is a conversion killer. The Baymard Institute found that 26% of customers abandon checkout when forced to create an account. Always offer guest checkout — you can offer registration after the order is confirmed.
Number of checkout steps: the ideal is 2–3 steps (cart → shipping and payment → confirmation). Every extra step causes drop-offs. Shipping, payment, contact details, and billing address can often fit on a single page.
Cost transparency: customers hate surprises. Show shipping fees and any payment surcharges as early as possible — ideally in the cart itself. If a customer discovers a card processing fee in the final step, they will leave.
Payment methods: What customers in Central Europe expect:
- Credit and debit cards (Visa, Mastercard)
- Bank transfer / QR payment
- Cash on delivery (still 15–25% of orders in many segments)
- Apple Pay / Google Pay (growing fast, especially on mobile)
- Buy now, pay later (useful for higher average order values)
Real-world example: Sports retailer RunCzech added Apple Pay and Google Pay buttons. On mobile devices, checkout conversion increased by 22% — customers no longer had to type their card number on a small keyboard.
Mobile performance: priority number one
On average, 60–70% of e-shop traffic comes from mobile devices. Yet most stores are optimised primarily for desktop.
Mobile testing must happen on real devices, not just Chrome DevTools simulation. A mid-range phone on an average 4G connection is a realistic model of your customer. The PageSpeed Mobile test simulates exactly these conditions.
Common mobile-specific problems:
Tap targets too small: buttons and links need at least a 44×44 px tap area. A tiny "add to cart" button means customers have to tap multiple times, which is frustrating enough to cause abandonment.
Font loading: system fonts load instantly; custom web fonts add 50–300 ms of latency. Limit yourself to 1–2 custom fonts and use font-display: swap.
Unnecessary redirects: every redirect from http:// to https://, from www. to non-www., or from a mobile subdomain to the main domain adds 100–300 ms. Servers should respond directly without redirect chains.
Quick wins vs. long-term fixes
Not every optimisation requires the same investment. Here is a realistic breakdown of what can be done quickly and what requires deeper work:
| Problem | Fix effort | Potential performance impact |
|---|---|---|
| Compress and convert images to WebP | Low (plugin or script) | High |
| Add lazy loading to images | Low (one attribute) | Medium |
| Remove unused tracking scripts | Low (GTM audit) | Medium to high |
| Add guest checkout | Low (configuration) | High (conversions) |
| Add Apple Pay / Google Pay | Low (payment gateway integration) | High (mobile conversions) |
| Move static files to a CDN | Medium | Medium |
| Preload critical fonts and images | Medium | Medium |
| Migrate from CSR to SSR for product pages | High | Very high |
| Rebuild theme without a page builder | High | Very high |
| Optimise database queries | High | Very high (large catalogues) |
Always start with low effort and high impact — that quadrant gives you the best return for the least money. Architectural changes make sense only after you have exhausted the simpler options.
Practical tip: Set up automated monthly Core Web Vitals monitoring through Google Search Console or tools like Sentry Performance. Performance degrades over time — every new plugin, every new tracking script adds a little more weight. Without monitoring you will not notice until the problem is serious.
At BASAD Studios, we build e-shops with performance as a first-class requirement from day one — no unnecessary page builders, properly optimised images, SSR where it makes sense. If you feel your store could be earning more, get in touch or check out our e-commerce service.