Running WooCommerce on Shared Hosting: Setup and Performance

WooCommerce turns a normal WordPress site into a full online store, and that changes how the site behaves on a server. A brochure site can be cached and mostly forgotten; a store writes to the database on every add-to-cart, keeps a session for every shopper, and serves pages that must never be cached the wrong way. This guide from Ultra Web Hosting covers running WooCommerce well on shared hosting: the PHP settings that matter, the caching rule you cannot get wrong, and the point at which a growing store should move to a VPS or dedicated server.

01. Why WooCommerce Is Heavier Than a Normal WordPress Site

A standard WordPress site is mostly read-only. A visitor requests a page, WordPress builds it once, and a caching plugin can hand every subsequent visitor the same saved copy without touching PHP or the database again. That is why a blog can serve large bursts of traffic on a small plan.

WooCommerce breaks that model in three ways:

• Dynamic, per-user pages. The cart, checkout, and my-account pages are different for every shopper. They cannot be served from a shared full-page cache, so every view runs PHP and queries the database.
• More database writes. Adding to the cart, updating quantities, placing an order, and adjusting stock all write to the database. A read-heavy blog rarely writes; a busy store writes constantly.
• Sessions for every shopper. WooCommerce keeps a session so a cart survives from page to page. Each active shopper holds session data, and those rows accumulate in the wp_options and session tables.

None of this makes shared hosting a bad fit for a small or medium store. It just means the tuning is different. You are optimizing a live application, not caching a static page.

02. Installing WooCommerce and Running the Setup Wizard

WooCommerce is a free plugin. If you do not have WordPress installed yet, set it up first (see article 343), then add the store on top.

1. In the WordPress admin, go to Plugins > Add New.
2. Search for WooCommerce, click Install Now, then Activate.
3. The setup wizard starts automatically. Enter your store address, country, and currency.
4. Choose the type of products you sell (physical, downloadable, or both). This decides whether shipping and tax options appear.
5. Set up payments. You can connect a gateway now or return to it later (Section 07 covers this properly).
6. Pick which optional features to install, such as tax calculation. Skip anything you do not need; every extra add-on is more code running on each request.
7. Finish the wizard. WooCommerce creates the Shop, Cart, Checkout, and My Account pages for you.

03. PHP Settings That Matter for a Store

WooCommerce and its extensions need more PHP headroom than a plain blog, especially during imports, reports, and checkout. On our shared plans you set these per domain in cPanel, no ticket required.

1. In cPanel, open MultiPHP INI Editor (under the Software section).
2. Select your domain from the dropdown.
3. Adjust these values and save:
   • memory_limit → 256M (WooCommerce recommends at least this; some extension-heavy stores want 512M)
   • max_execution_time → 120 or higher, so long imports and reports do not time out
   • post_max_size → 64M, large enough for product CSV imports
   • upload_max_filesize → 64M, so product images and CSVs upload cleanly
   • max_input_vars → 3000, so large settings and variation forms save fully

Confirm the live values under WooCommerce > Status in the WordPress admin. That page flags any setting below the recommended minimum in red, which makes it easy to see what still needs raising.

04. Caching WooCommerce Correctly

Full-page caching is the biggest single speed win for a WordPress site, and it is completely safe for the parts of a store that look the same to everyone: the home page, the shop archive, product pages, and blog posts. It is dangerous for the parts that are unique to each shopper.

You must exclude these dynamic pages from full-page cache:

• /cart/
• /checkout/
• /my-account/

You must also exclude these WooCommerce cookies so a page is never cached for a shopper who has items in the cart or an active session:

woocommerce_items_in_cart
woocommerce_cart_hash
wp_woocommerce_session_

Most quality caching plugins detect WooCommerce and apply these exclusions automatically, but never assume it. After setup, verify:

1. Open your caching plugin's settings and find the page exclusion or never cache list.
2. Confirm cart, checkout, and my-account are listed.
3. Find the cookie exclusion list and confirm the three WooCommerce cookies above are present.
4. Test as a shopper: add an item in a private window, browse to another product, and confirm the cart still shows your item on every page.

05. Object Caching for Dynamic Queries

Full-page caching handles the pages you can save whole. Object caching handles everything you cannot. Because the cart, checkout, and my-account pages always run PHP and query the database, the goal is to make those queries cheaper. An object cache stores the results of repeated database lookups in memory so WooCommerce does not ask the database the same question twice on every request.

Our shared plans support a persistent object cache with Redis. To enable it:

1. Install a Redis object cache plugin (for example the widely used Redis Object Cache plugin) from Plugins > Add New.
2. Open its settings and click Enable Object Cache. The status should switch to Connected.
3. Confirm under WooCommerce > Status that a persistent object cache is now detected.

The payoff is on exactly the pages you cannot full-page cache. Repeat product lookups, option reads, and cart calculations come from memory instead of the database, which keeps the store responsive when several shoppers are active at once.

06. SSL Is Mandatory for Checkout

A store takes personal and payment details, so the entire site must run over HTTPS, not just the checkout page. Modern browsers warn on any form served over plain HTTP, and card brands expect the checkout flow to be encrypted end to end. Every Ultra Web Hosting plan includes free AutoSSL, so there is no extra cost.

1. Confirm your certificate is active in cPanel > SSL/TLS Status. AutoSSL issues one automatically; see article 68 for the full walkthrough.
2. In WordPress, set both the WordPress Address and Site Address under Settings > General to the https:// versions.
3. Force HTTPS site-wide so no page ever loads over plain HTTP.
4. Fix any mixed content: images, scripts, or stylesheets still linked with http:// will make the padlock disappear even when the certificate is valid. Update those URLs to https:// or protocol-relative links.

07. Choosing and Configuring a Payment Gateway

A payment gateway is what actually charges the card. The right architecture keeps card data off your server entirely, which is both safer and dramatically less work for compliance.

• Stripe and PayPal are the two most common choices for WooCommerce and both have official, well-maintained plugins.
• With their hosted or tokenized fields, the shopper's card details go straight to Stripe or PayPal. Your store receives a token, never the card number.
• That means you do not store, transmit, or process raw card data, which keeps you in the simplest PCI category.

1. Install the official gateway plugin (for example WooCommerce Stripe or WooCommerce PayPal Payments) from Plugins > Add New.
2. Under WooCommerce > Settings > Payments, enable the gateway and connect it with your processor account.
3. Enter the API keys the processor gives you. Start in test or sandbox mode and place a test order end to end.
4. Confirm the order appears in both WooCommerce and the processor dashboard, then switch to live mode.

08. Product Image and Database Optimization

Two things quietly bloat a WooCommerce store over time: oversized product images and accumulated database cruft from sessions and transients. Both are easy to keep in check.

Images

• Upload product photos at a sensible size. A 4000px camera original scaled down in the browser wastes bandwidth on every view. Resize to what the theme actually displays, usually 1000 to 1500px on the long edge.
• Compress images before or on upload. An optimization plugin that generates WebP versions cuts image weight substantially with no visible quality loss.
• Set correct WooCommerce image sizes under Appearance > Customize > WooCommerce > Product Images so thumbnails are not scaled-down giants.

Database

• Clear expired transients. WooCommerce and its extensions cache data in transients that can pile up. A maintenance plugin or the WooCommerce tools can purge expired ones.
• Clean up old sessions. Abandoned carts leave session rows behind. WooCommerce has a scheduled task to clear these; make sure WP-Cron is running so it fires.
• Trim what you do not need. Old order drafts, spam, and post revisions add rows. Periodic cleanup keeps queries fast, which matters most on the uncacheable pages from Section 04.

09. Traffic Spikes, Resource Limits, and Cloudflare

Because a store runs PHP on its dynamic pages, a sales spike or a bot crawl can push CPU and memory into your plan's limits. When that happens you may see a 508 Resource Limit Reached or 503 error while the account is throttled. Article 297 explains those errors and how to read the resource usage graphs in cPanel.

The best defense is to keep as much traffic as possible from ever reaching PHP:

• Full-page cache the cacheable pages (Section 04) so the home page, shop, and product pages are served from cache, not PHP.
• Object cache the dynamic pages (Section 05) so the cart and checkout do less database work per request.
• Put Cloudflare in front of the site so its edge network absorbs static assets and repeat requests before they hit our server. See article 295 for setup.

10. Store Security

A store holds customer details and moves money, so it is a bigger target than a blog. The good news is that the basics cover most of the risk. The full hardening checklist is in article 309; the store essentials are:

1. Strong, unique admin passwords. No shared logins, no reused passwords. Give each staff member their own account with only the role they need.
2. Two-factor authentication on every admin and shop-manager account. This is the single highest-value control for a store login.
3. Keep WordPress, WooCommerce, the theme, and every plugin updated. Most store compromises come in through an outdated plugin, not a server flaw. Update promptly and remove anything you do not use.
4. Limit login attempts and use the security tooling covered in article 309 to blunt brute-force attempts against wp-login.

11. When Your Store Has Outgrown Shared Hosting

Shared hosting runs a small to medium WooCommerce store well. There is a point, though, where a store's own success means it needs dedicated resources. The signal is not catalog size alone; it is sustained concurrent shoppers hitting the uncacheable pages at the same time.

If you are weighing the jump, article 481 compares shared, VPS, and dedicated hosting so you can match the plan to where the store actually is. The move is a migration, not a rebuild, and we handle it for you.

Quick Recap: WooCommerce on Shared Hosting

If you only do six things from this guide, do these:

1. Raise PHP limits in MultiPHP INI Editor so WooCommerce has room: 256M memory, 120s execution, 64M uploads.
2. Exclude cart, checkout, and my-account from full-page cache, along with the WooCommerce session cookies. This is the one you cannot get wrong.
3. Enable object caching with Redis so the dynamic pages do less database work per request.
4. Run the whole site on SSL and use a gateway like Stripe or PayPal so card data never touches your server.
5. Keep images and the database lean and put Cloudflare in front to absorb spikes and avoid resource-limit errors.
6. Lock down admin with strong passwords, 2FA, and prompt updates, and move to VPS or dedicated when concurrent checkouts outgrow shared limits.

Last updated July 2026 · Browse all WordPress articles