Podcast: Download (Duration: 24:33 — 28.4MB)
Improving Core Web Vitals for an ecommerce store comes down to one technique above all others: lazy loading your JavaScript so functional code only loads after the visitor moves the mouse, scrolls, or touches the screen. My store runs a dozen third-party tools and loads in 1.2 seconds, against 18.7 seconds with no optimization at all.
In this solo episode I walk through every optimization I applied to Bumblebee Linens, ranked by actual impact, plus how to debug the Core Web Vitals metric nobody can figure out.
Below is the complete list: what the three metrics measure, every speed fix rated one to five, the JavaScript lazy loading technique, and how to find layout shift problems Google will not explain.
Get My Free Mini Course On How To Start A Successful Ecommerce Store
If you are interested in starting an ecommerce business, I put together a comprehensive package of resources that will help you launch your own online store from complete scratch. Be sure to grab it before you leave!
Table of Contents
Key takeaways
- 96% of US sites fail Core Web Vitals on desktop, mobile, or both, and ecommerce fails at a higher rate.
- Lazy loading JavaScript is the single highest-impact fix. Everything else is marginal by comparison.
- My store went from 18.7 seconds to 1.2 seconds with the same features installed.
- Browser caching does nothing for your score. Google measures a cold load.
- Live chat alone can take 6 to 10 seconds to load.
- Serve a separate image file for every display size rather than scaling one large file.
- Most layout shift comes from missing dimensions on images and dynamically injected elements.
- Lab scores and field scores frequently disagree, and only field data affects rankings.
What Google Core Web Vitals actually measure
Core Web Vitals are three metrics Google folds into search rankings to score user experience.
Largest Contentful Paint (LCP). How long until the largest piece of content appears on screen. Google requires 2.5 seconds or less.
First Input Delay (FID). The lag between a visitor clicking something interactive and the page responding. Google requires 100 milliseconds or less.
Cumulative Layout Shift (CLS). How much your content jumps around while loading. Google requires 0.1 or less. This is the only one unrelated to speed and the hardest to debug.
The reason to care is rankings. These feed directly into how Google evaluates your pages.
Why ecommerce stores fail Core Web Vitals
Stores fail more often than content sites because every feature required to take a transaction adds loading weight.
The real costs are larger than most people expect:
- Live chat: six to ten seconds by itself.
- Klaviyo email tracking: one to two seconds.
- The Facebook pixel: around 100 milliseconds.
Deferred and asynchronous loading do not exempt you. Every additional element still degrades your scores.
My own store is a deliberate worst case, since I treat it as a lab for testing what I teach. It runs Klaviyo, Postscript, Vizury, ManyChat, Gorgias, a spin-to-win popup, the Facebook pixel, Google Analytics, and a notification slide-up.
With none of the optimizations below, it loaded in 18.7 seconds. With all of them, 1.2 seconds.
The three causes of a slow ecommerce site
Fix these and LCP and FID resolve themselves, since both are fundamentally speed problems.
Render-blocking JavaScript and CSS. By default these load sequentially and block the page from rendering. This accounts for the problem on roughly 99% of stores.
Oversized images and video. Never load an image larger than what displays, and never load an image that is not visible on screen.
A slow server. Rarely the issue on Shopify, BigCommerce, or Shift4Shop. On WooCommerce, moving to a host like WP Engine can help substantially.
Every speed optimization ranked by impact
| Optimization | Impact |
|---|---|
| Lazy load images and JavaScript | 5/5 |
| Shrink and compress images | 4/5 |
| Compress and cache pages | 4/5 |
| Use fewer plugins that load external code | 4/5 |
| Preload large images and scripts | 3/5 |
| Use a faster web host | 3/5 |
| Use a CDN | 3/5 |
| Clean up redirects | 2/5 |
| Combine HTML, CSS, and JS files | 2/5 |
| Enable browser caching | 1/5 |
| Minify CSS and JS | 1/5 |
Focus on the fives and fours. The ones and twos are for squeezing out the last milliseconds.
Why browser caching will not help your score
Browser caching should be on and it will not change your Core Web Vitals or your measured page speed.
Caching tells a visitor’s browser to store images and elements locally so return visits are faster.
Google measures your site from a completely cold state, so none of that benefit is visible to the score.
Why minification and file combining barely matter
Minifying strips whitespace from CSS and JavaScript, saving a handful of bytes with no meaningful speed effect.
Combining files used to matter more. Modern web servers running HTTP/2 fetch multiple files in parallel, which largely eliminates the benefit.
Redirects are worth a quick pass. If you migrated from HTTP to HTTPS and issued 301 redirects on images and pages as a shortcut, each one slows the page. Run GTmetrix to find redirects on page elements and remove them.
When a faster host or CDN is worth it
A faster server rarely solves speed problems, though moving off cheap shared hosting to a VPS or dedicated server can make a real difference.
The instinct on WooCommerce or Magento is to throw money at hardware, which usually is not the bottleneck.
A CDN stores copies of your site and images on servers worldwide so content comes from the nearest location. It matters if you have international customers and an image-heavy site, and has marginal impact on a smaller US-focused store.
How to preload large elements
Preload hints tell the browser which resources matter most, which helps LCP specifically since LCP measures your largest element.
A large splash image is the obvious candidate for preloading.
The caveat is that preloading improves the score without making the site genuinely faster. It reorders priority rather than reducing work.
How to size images correctly
Create a separate image file for every size your site displays, rather than scaling one large file down.
If your theme displays 1000 by 1000 images, never upload anything larger.
My store displays product images at full size, 50%, 33%, and 25% depending on the page, so I keep four separate files and serve the smallest one that looks right in each context.
Compression is the other half. Export JPEGs at a maximum quality setting of 50 in Photoshop or whatever you use, which is visually indistinguishable at web sizes.
How to compress and cache your pages
Fully hosted platforms handle this already. Shopify, BigCommerce, and Shift4Shop compress and cache pages before serving them.
WooCommerce needs a plugin, and WP Rocket is what I use. It prerenders pages so the server delivers static files requiring little CPU, and compresses pages to roughly 90% smaller.
Why plugins are the real problem
Every plugin that loads external code slows your site, and plugins rather than themes cause most speed problems.
The examples that surprise people are small. A Facebook share button or a Pinterest save button can pull an entire JavaScript file from an external server.
The fix is choosing no-code versions. Facebook, Twitter, and Pinterest all have plain hyperlink share options that add zero loading time.
There is a second reason to be careful. I once installed a plugin that was quietly sending my site’s information to several ad networks and selling customer data without my knowledge.
That is why I now read the source code and inspect the network calls of every plugin before installing it.
How to lazy load JavaScript
Load the visual elements of the page first, then load functional JavaScript only after the user moves the mouse, scrolls, or touches the screen.
This is the single most important optimization and the one almost nobody does. Image lazy loading is common and built into many themes. JavaScript lazy loading is not.
On Bumblebee Linens the page loads in under a second with only HTML and CSS. The moment you move the mouse or scroll, live chat and the shopping cart functionality load behind it.
The experience is identical for the shopper, since the functionality arrives before they can possibly need it. Google sees a fast page because Google never triggers those events.
How to decide what is safe to lazy load
Anything that does not affect visual rendering can be deferred. Anything that draws the page must load immediately.
Use GTmetrix and read the waterfall chart, which lists every resource and how long it takes.
My own example: Klaviyo’s script takes nearly half a second and its CSS takes another half second. Klaviyo has no effect on how my site renders, so deferring it removes almost a full second.
The process is mechanical. Build a list of slow-loading code that is not required for visual rendering, then trigger all of it on mouse movement, page scroll, or screen touch.
If you do not write code yourself, this section is specific enough to hand directly to a developer.
How to fix Cumulative Layout Shift
Roughly 90% of CLS problems come from two causes, and both have straightforward fixes.
Elements without dimensions. Size attributes let the browser reserve space before an image loads. Without them the page rearranges when the image arrives. Specify dimensions on every element.
Dynamically injected content. Plugins and ads that load late push the page around. Pre-allocate space for whatever will appear. If a plugin makes this impossible, contact the developer.
Why your CLS score fails when the test passes
Google’s PageSpeed test measures CLS above the fold under ideal conditions, while field data comes from real users scrolling on slower connections.
This is why lab and field scores disagree, and only field data affects your rankings. My blog scored perfectly in the test and failed in the field.
Google does not tell you what is wrong, which is why this took me three weeks to solve.
The method that works: open the Chrome debugger by right-clicking anything and choosing Inspect. On the Network tab, throttle the connection to slow 3G. Enable the layout shift regions overlay, then reload.
Shifting areas flash blue as the page loads. Scroll through the page the way a real visitor would, note where the flashing happens, and hand that to your developer.
The underlying principle
Keep the site as simple as possible and treat every plugin as a cost.
Before installing anything, ask whether you genuinely need the feature. Then look for a version that does not add JavaScript.
Most speed problems are not your theme’s fault. They accumulate from features nobody evaluated before adding.
Frequently asked questions
What are Google Core Web Vitals?
Three metrics Google uses in search rankings: Largest Contentful Paint at 2.5 seconds or less, First Input Delay at 100 milliseconds or less, and Cumulative Layout Shift at 0.1 or less. The first two are speed measures and the third measures visual stability.
What is the most effective way to speed up an ecommerce site?
Lazy loading JavaScript. Load visual HTML and CSS first, then load functional code only when the user moves the mouse, scrolls, or touches the screen. This took my store from 18.7 seconds to 1.2 seconds with the same features installed.
Does browser caching improve Core Web Vitals?
No. Google measures your site from a completely cold state, so caching benefits are invisible to the score. It should still be enabled because it genuinely improves the experience for returning visitors.
How should you size images for an ecommerce store?
Create a separate file for every size your site displays rather than scaling one large image. Never upload larger than your theme displays, and compress JPEGs to around 50 quality, which looks identical at web sizes.
Do plugins slow down your website?
Yes, and they cause most speed problems rather than themes. Even a Facebook share button can pull an external JavaScript file. Use no-code hyperlink versions of share buttons and evaluate every plugin’s network calls before installing.
What causes Cumulative Layout Shift?
About 90% comes from images and elements without specified dimensions, so the browser cannot reserve space, plus dynamically injected content like ads that push the page around when they arrive late.
Why does my site pass the PageSpeed test but fail in the field?
The test measures above-the-fold performance under ideal conditions, while field data comes from real users scrolling on slower connections. Debug it by throttling Chrome to slow 3G, enabling the layout shift overlay, and scrolling the page as a real visitor would.
