Why speed belongs in an SEO plan
Speed is a ranking input in a small way and a buying input in a large way. Google has said that page experience, including speed, is a factor in ranking, but it is one factor among many and a fast page with weak content will not beat a slower page that answers the question better. The stronger reason is the shopper. A product page that takes too long to appear loses people before they read a word of it.
WooCommerce makes this a real concern because it is a plugin on WordPress, and you are responsible for the pieces underneath. Your hosting, the theme, and each plugin you add all affect how fast a page appears. A hosted platform decides much of that for you. Here, you decide it. That is part of the honest trade-off we weigh on the is WooCommerce good for SEO page.
Speed also feeds the signals Google publishes as Core Web Vitals: how fast the main content appears, how quickly the page responds to a tap, and how much the layout jumps around while loading. Our glossary pages on Core Web Vitals for WooCommerce explain what each measures.
This page is about finding what makes your own store slow and fixing the biggest cause first, rather than applying a list of tricks. If you would rather not do it yourself, who can take speed work off your plate is covered on our main guide to the help available.
Measure before you change anything
Do not buy a speed plugin before you have a number. Google's free PageSpeed Insights tool tests any address and reports on mobile and desktop. Test these, not just the home page:
One product page. One category page. The cart page. The home page. Each behaves differently, and a fast home page tells you nothing about the page that sells.
Read two sections of the result. The top shows what real visitors experienced over recent weeks, drawn from Chrome user data, when your site has enough traffic to appear. This is field data and it is the closest to what Google uses. Below it is a lab test run just now under simulated conditions. Lab results move from run to run, so test three times and take the middle result.
Then read the opportunities and diagnostics list. It names the specific items slowing the page, such as large images, render-blocking files, unused code or a slow first response from the server. Write down the top three for each page type.
Test on mobile first. Most store visits come from phones, and phones on ordinary connections are what slow pages punish most. Keep the saved results somewhere, so that in a month you can compare.
Test four page types on mobile, write down the top three problems for each, fix the biggest, then test again.
Where the time usually goes
When a WooCommerce page is slow, the cause is nearly always one of four things. The diagram above sets the slow and fast versions side by side. They are listed here in the order to check them.
Hosting. Everything starts when the server answers. PageSpeed Insights reports server response time, and if that one number is poor, nothing downstream can fix it. Very cheap shared hosting puts your store beside many others on the same machine.
Images. Product photos are the heaviest thing on most store pages. A photo straight from a camera can be several times larger than the space it fills.
Plugins and theme. Every plugin can add code that loads on every page, whether or not that page needs it. A plugin used only on the checkout can still load on a product page unless it is built carefully.
Caching. Without it, WordPress builds each page from scratch for each visitor, by querying the database and running the code. With it, a ready-made copy is served.
The order matters because the fixes cost different amounts. A caching setup and image resizing are cheap and quick. A hosting move is a bigger job. Plugin pruning sits between. Start with whichever your measurements point at, and do not guess.
Hosting
A store is a heavier job than a brochure site. Each product page asks the database for prices, stock and variations, and the cart and checkout cannot be fully cached because they are personal to each visitor.
Signs your hosting is the limit: a slow server response time in PageSpeed Insights, pages that get slower at busy times, and an admin area that drags when you edit products. If the first byte takes long even on a simple cached page, the machine is the problem.
Hosts that specialize in WordPress or WooCommerce usually tune the server for this workload and include server-level caching. Others do not. Ask a host direct questions: which PHP version do you run, is page caching built in, how do you handle the cart and checkout pages, and what is the process if my store grows. Their own documentation will say more than a pricing page.
One useful rule is to keep PHP on a current supported version, because older versions are slower and unsafe. Your hosting dashboard usually lets you change it, and the WordPress and WooCommerce documentation list the versions they recommend. Test on a staging copy first, because an old plugin can break on a newer version.
Moving host is a project with real risk to rankings, since addresses and server behavior can change. Treat it as a migration and plan it. Our WooCommerce SEO migration page has the checks.
Caching
Caching is the single most effective fix on many WooCommerce stores, and it is also the most often set up wrongly.
Page caching saves a finished copy of a page and serves that to the next visitor. It works well for category pages, product pages, the blog and the home page, where every visitor sees the same thing. It must not apply to the cart, the checkout and the account pages, because those show personal data. A good caching plugin or host setup excludes them by default. Check that yours does, and test by adding something to a cart in a private window and confirming a different visitor does not see it.
Beyond page caching there are other layers. Browser caching tells a visitor's browser to keep files like logos and styles for later visits. Object caching keeps the results of common database queries in memory, which helps stores with many products. A content delivery network keeps copies of your files on servers closer to the visitor.
You do not need every layer. Start with page caching, add a content delivery network if your visitors are spread out, and consider object caching only when measurements show the database is the bottleneck.
Use one caching plugin, not two. Two can fight, and the symptoms, such as stale prices or a cart that will not update, are expensive. After any caching change, clear the cache, and check a product's price update and the cart count by hand. Read the plugin's own documentation for its current settings.
Images
Images are usually the cheapest win and the one with the biggest drop in page weight.
Resize to where the image shows. A photo that appears 600 pixels wide does not need to be 4,000 pixels wide. WordPress already creates smaller copies at several sizes, and WooCommerce has its own image size settings for catalog and single product images. Make sure those match what your theme displays. If you changed theme, the stored sizes may be wrong, and regenerating them fixes it.
Compress. A well-compressed photo looks the same and weighs a fraction. Many plugins and hosts do this on upload.
Use a modern format where supported. Newer image formats are smaller at equal quality. Check what your WordPress version and plugins support.
Load below-the-fold images lazily, but not the main one. Lazy loading waits to fetch an image until it is near the screen. It helps long category pages. Applied to the main product photo at the top, it slows the most important visible element, so exclude that one.
Give every image a width and a height. That reserves space so the layout does not jump as pictures arrive, which affects the layout shift score.
Image file names and alt text are a separate job, covered on the product page SEO page. The target here is only weight and size.
Plugin weight
Plugins are the quiet cause. Each is useful, and together they can add dozens of files to every page.
Make a list of every active plugin and ask three questions of each. Do I still use it? Does something else I already run do the same job? Does it load code on pages that do not need it?
Deactivated plugins do not slow the site, but unused ones that are still active do. Remove anything you do not use, then delete rather than just deactivate, because old code is also a security risk.
Watch for overlap: two SEO plugins, two caching plugins, two security plugins, a slider plus a page builder that also has sliders. Page builders and heavy themes add weight of their own, so judge a theme by testing a real product page in PageSpeed Insights, not by its demo.
WooCommerce also loads a script on many pages to keep the cart count current. Some performance tools let you control where that and other scripts load. That is a tuning step to take only after the basics, and with a staging copy to test on. Our page on the WooCommerce SEO plugins covers what an SEO plugin should and should not be doing, so you can judge whether one is earning its weight.
A sensible order of work
Put it all together as a week of work, not a project.
Day one: test four page types in PageSpeed Insights on mobile and record the top three issues for each. Day two: resize and compress images, check the WooCommerce image sizes match the theme. Day three: set up or fix page caching, excluding the cart, checkout and account pages. Day four: audit plugins, remove the unused, and look for overlap. Day five: test again and compare to day one. If the server response time is still poor, the conversation moves to hosting.
Then recheck monthly. Speed drifts as products, plugins and photos pile up. The WooCommerce SEO checklist keeps speed in proportion with everything else, and the page on why a WooCommerce store with no organic traffic usually has bigger problems than speed is worth reading before you spend a month chasing a perfect score.
A fast page does not rescue a page nobody wants. Use speed to remove a handicap, not as the main plan.
Judge speed the way shoppers meet it
A lab score is a stand-in. What counts is how the store feels on a mid-range phone on an ordinary connection. Pick up one and try it. Open a category, tap a product, add it to the cart and begin checkout. Note where you wait.
Waiting at the start usually points at hosting or caching. Waiting while images appear points at image weight. A page that jumps just as you go to tap a button points at missing image dimensions or late-loading banners. A tap that takes a moment to respond points at heavy scripts from plugins, chat widgets or tracking tags.
Third-party scripts deserve their own look. Chat tools, review widgets, tracking pixels and popups each load code from another company. Ask of each one whether it earns its cost in speed, and remove any that you cannot justify.
How RunOctopus handles this
Speed is infrastructure, so it stays with your host and your own settings, and PageSpeed Insights is the honest judge. What a done-for-you service adds is the content that gives fast pages something worth loading.
RunOctopus is a done-for-you service. Its AI, Ollie, researches your business, then writes and publishes pages directly on your own website, and it works with WordPress and WooCommerce. A team plans, writes, reviews and publishes alongside Ollie. There is nothing to install, nothing to approve, nothing to upload and nothing to schedule. Pages go live on their own.
In the first week you get 8 long-form articles, 6 pages and a custom interactive tool built for your niche. After that it is 175+ pieces of content a month, written, published and linked. Reports show where ChatGPT, Perplexity, Claude and Gemini name your business.
The promise is more visibility on Google and in AI answers within 90 days, measured against the 90 days before you joined, or every dollar back. For scale, an agency doing this work charges about $3,209 a month (2026 average, 439 providers) and publishes 4 to 12 pieces.
You can see the plan before you decide anything. Paste your address into the free site read and Ollie reads the site and shows the plan. No account, no call.