Last updated: Rules, fees and platform policies change. This guide is reviewed and kept current.
Speed is not a technical detail in e-commerce; it is a revenue line. A user on the way to the basket will tolerate half a second of delay and close the tab at three seconds. Google’s position is clear too: page experience signals do not determine ranking on their own, but they make the difference between pieces of equivalent content.
This post is a technical checklist to work through, in order, to speed up a store running on WordPress or WooCommerce. The order matters: the first three steps below deliver more than all the rest combined.
WooCommerce speed: which layer comes first?
An ordered plan for passing the Core Web Vitals thresholds.
- Server-side cachingUsually the largest single gain; measure before moving on
- ImagesFormat, sizing and lazy loading; the most direct lever on LCP
- Plugin inventorySee the CSS and JS weight each plugin loads, one by one
- CSS and JavaScriptMinification and delivery order; watch theme compatibility on combine
- Third-party scriptsAnalytics, chat and pixels are the usual suspects behind poor INP
- Database and hostingOnce the plan is at its limit, software changes will not fix it
Measure first: what does each metric tell you?
There are three core metrics, and each corresponds to a different user complaint:
- LCP (Largest Contentful Paint): when the largest piece of content appeared. Target: under 2.5 seconds. When it is bad, the user says “the page will not open”.
- INP (Interaction to Next Paint): the delay in responding to a tap. Target: under 200 ms. When it is bad, the user says “I pressed the button and nothing happened”.
- CLS (Cumulative Layout Shift): how much the layout moves. Target: under 0.1. When it is bad, the user says “I tapped the wrong thing”.
Keep two sources of measurement separate: lab tests (PageSpeed Insights, Lighthouse) show you what is slow; field data (the Core Web Vitals report in Search Console, real-user measurement) shows what is actually being experienced. Decide with field data, diagnose with the lab. Evaluate mobile and desktop separately too; if most of your traffic is mobile, do not let a desktop score reassure you.
1. Server-side caching
The single biggest win is here. Without caching, PHP runs for every visitor, the database is queried, and the page is built from scratch. With full-page caching the same page is served as ready-made HTML.
If your server runs LiteSpeed, LiteSpeed Cache is the right choice; on an Nginx-based setup, FastCGI caching or an equivalent plugin. Once installed, verify two things: (1) are you seeing cache hits in the response headers, and (2) are the basket, checkout, my-account and logged-in user pages excluded from the cache. The second is critical in WooCommerce; if they are not excluded, users can see each other’s baskets.
2. Images
More than half the weight of a typical store page is images. In order:
- Modern format: serve WebP (or AVIF where supported) instead of JPEG/PNG. Conversion plugins pick automatically based on browser support.
- The right size: do not display a 2,400-pixel-wide image in a 600-pixel slot. Resize on upload.
- Lazy loading: let off-screen images load later. But exclude the main product image in the first viewport from lazy loading; that is the classic mistake that directly wrecks LCP.
- Dimension attributes: put a width and height on every image. The most common cause of CLS is images that load without space reserved for them.
3. Plugin inventory
The number of plugins is not bad in itself; what is bad is plugins that load CSS and JavaScript on every page but are used on only one. The usual suspects: form plugins, sliders, social sharing, page builders.
The job is to work out where each plugin loads and disable its assets where they are not needed. Tools with an “asset unloading” feature can do this. And an honest clear-out: inactive plugins are not just a security risk, they are maintenance load. Delete what you do not use.
4. CSS and JavaScript
It is tempting to be aggressive here, but in e-commerce the risk is high. A sensible order:
- Minify — carries almost no risk.
- Defer non-critical CSS — medium risk; always test on mobile.
- Defer or delay JavaScript — the biggest win and the biggest risk. Test add-to-basket, variation selection and the checkout steps by hand, without exception.
- Remove unused CSS — the most fragile step. It can break campaign pages.
After every step, walk through the three most critical flows manually (product → basket → checkout). A rising automated score does not prove the purchase flow still works.
5. Third-party scripts
Analytics, ad pixels, live chat, the cookie banner, a review widget. Every one of these runs on somebody else’s server rather than yours, and as a group they do the most damage to INP. Three rules: keep only what you actually use, load what you can after the first interaction, and delay the live chat widget on mobile. There is no return whatsoever on carrying a pixel you never look at.
6. Database and hosting
In stores that have been running a long time the database bloats: old revisions, transients, leftovers from deleted plugins, spam comments. Regular cleanup and table optimisation noticeably improve the speed of the admin panel.
There is a structural constraint too: on shared hosting the number of PHP workers is limited. If concurrent traffic on a campaign day exceeds that limit, no caching setting will save you. Object caching (Redis or Memcached) also generally requires a service on the server side, which means asking your hosting provider for it.
Implementation order and verification
Do not do all of this in one day. The recommended pace: apply each step separately, wait 48 hours in between, and watch the field data. That is the only way to know which change caused a problem when something breaks.
- Measure and take a screenshot before the change.
- Take a backup, especially before CSS/JS optimisation.
- Clear the cache and test in a browser where you are not logged in.
- Try the product → basket → checkout flow on mobile.
The goal is not a score of 100/100. The goal is a store where real users clear the LCP, INP and CLS thresholds and the add-to-basket button responds on the first tap. The scoreboard is a nice by-product, but the difference at the till is the real measure.
Three common failures and their fixes
“Add to basket stopped working after optimisation”
Almost always caused by a JavaScript defer or combine setting. The fix: exclude the relevant script from deferral. Exempting one script rather than switching the whole setting off preserves the gain.
“The site is fast but the admin panel is very slow”
The front end looks fast because it is served from cache; the admin panel always runs live. Slow admin is usually database bloat, heavy plugin queries or insufficient PHP resources. Object caching makes a visible difference here.
“The mobile score just will not go up”
Mobile tests simulate a slower device and network; every weakness invisible on desktop gets magnified. On mobile the order of priority is: the size of the first-viewport image, the font loading strategy, third-party scripts. Until those three are fixed, other settings have limited effect.
A monthly maintenance routine
- Check the Core Web Vitals report in Search Console: is any URL group getting worse?
- Have you added a new plugin or pixel? If so, measure its impact.
- Review the large images uploaded to the media library.
- Run the database cleanup; clear out accumulated revisions and transients.
Speed optimisation is not a one-off project but a maintenance habit. Every new campaign page, every new pixel and every new plugin upsets the balance a little; without regular checks you are back where you started within six months.
Real examples, and this site’s own measurement
- Vodafone (web.dev, 2021): in an A/B test, a 31% LCP improvement (8.3 s to 5.7 s) lifted sales by 8% and cart-to-visit rate by 11%.
- Rakuten 24 (web.dev, 2022): after Core Web Vitals work, an A/B test showed revenue per visitor up 53% and conversion rate up 33%.
- This site’s own measurement (PageSpeed Insights, 24 September 2026, home page): mobile performance score 57; LCP 9.5 s, CLS 0.07. Desktop: LCP 2.3 s, CLS 0.145. There is not yet enough traffic for real-user (CrUX) data. Mobile LCP is well above the 2.5 s target this article recommends; the biggest items are render-blocking requests and cache lifetimes. We are applying this checklist to this site too.
Sources: web.dev, Vodafone; web.dev, Rakuten 24; PageSpeed Insights report.
Related reading
- To see the commercial value of a speed improvement: calculating real profit margin.
- The content side, once the technical foundation is fixed: getting cited by AI search.
Sources and official links
- web.dev — Web Vitals thresholds — The official LCP, INP and CLS thresholds measured at the 75th percentile
- Google Search Central — Core Web Vitals and Search — How Core Web Vitals relate to Search
- WooCommerce — Troubleshooting a slow site — WooCommerce’s own steps for troubleshooting a slow store
- WordPress — Performance optimization handbook — WordPress’s official performance optimisation handbook
Rules, fee schedules and platform policies change. The figures in this post reflect the position at the time of writing; confirm the current position from the official sources above before you act.
Haftalık bülten
Pazaryeri ve e-ihracatta bu hafta ne değişti?
Komisyon oranları, mevzuat ve algoritma değişikliklerini haftada bir, tek e-postada özetliyorum. Reklam yok, tekrar yok — istediğiniz an tek tıkla çıkabilirsiniz.
