Speed up and optimise WordPress and WooCommerce step by step

A performance improvement should make the website load and respond better without breaking its features. This guide suggests an order for reviewing WordPress and WooCommerce: measure, check the technical foundations, configure caching, optimise resources and debug whatever is still slow.

You do not need to apply every setting. An informational website, a shop and a course platform have different needs. Keep a recoverable backup, note the initial state and make major changes on a test copy.

Measure before changing

Choose representative pages and operations: home page, post or category, product, search and an admin task. Test as a visitor and as a logged-in user; in WooCommerce, include the cart and checkout in test mode.

Save several measurements taken under similar conditions. PageSpeed Insights helps you find browser-side problems; PHP X-Ray helps you understand PHP requests. Match the results with resource usage and the tasks running at the same time.

Up-to-date WordPress and plugins

Keep WordPress, the theme and plugins on maintained, compatible versions. Review the developer's changelog and test major updates before production. An update can change files and data: going back to the previous code does not always revert all its effects.

Before updating a shop, confirm how you will recover files and the database without losing new orders. See the available backups and keep a suitable backup from the moment of the change.

Check the PHP version in use

Select a version with security maintenance that is compatible with WordPress, the theme and plugins. Using the latest version without testing guarantees neither compatibility nor an automatic improvement.

The PHP wizard in the client area helps you make the change and check responses. Complement those checks with forms, payments, the admin area and tasks: a page that responds correctly does not prove that every feature works.

Check OPcache for the PHP version in use. It keeps compiled code so that the compilation is not repeated; it does not replace page cache or fix slow queries.

Disable the default WordPress cron system

If you need tasks to be triggered independently of visits, set up a system replacement. Do not disable the usual trigger until you have checked that the new one works. Check the frequency, overdue events and that there are no duplicate tasks.

The WP-Cron guide explains the Softaculous and manual setup options. The interval should match the shop's needs, not just resource usage.

Caching: LiteSpeed to the rescue

Page cache reuses a compatible public response without running WordPress again. LiteSpeed Cache integrates with our server and also offers tools for CSS, JavaScript, images and other tasks.

Install it from WordPress or from LiteSpeed Web Cache Manager. Keep a single page cache solution and follow the setup guide.

Initial setup and presets

Start with basic caching and check a public page in a private session. Check the headers of a subsequent request to confirm that it is served from cache.

Presets apply sets of options. Save or export the configuration before trying one; even a basic preset needs checking. Do not move to the most aggressive preset as a matter of course or assume that every theme is compatible.

To use QUIC.cloud online services, the connection is now started under General > Online Services. This is independent of using the hosting's page cache. You do not need an old domain key to complete this first stage.

Cache options

Setting	How to decide
Logged-in users and commenters	Keep the exclusions unless private caching has been designed and tested
REST API and login pages	Check compatibility and how sensitive the responses are before forcing caching
Mobile cache	Separate it only if the website serves different content, not just a responsive design
TTL	Balance reuse with how long a piece of data can stay out of date
Purge	Invalidate related content when publishing or editing, with real tests
Exclusions	Protect the cart, checkout, private areas and variations specific to your modules
ESI	Use it when there is an integration designed and tested for the dynamic blocks
Browser cache	Long lifetimes for versioned files; take care if content changes without the URL changing

An automatic purge does not necessarily know the dependencies of a custom development. Test that a change to a price, post or template shows up where it should.

Page optimisation

Under Page Optimization, test CSS and JavaScript minification separately. Combining files, deferring scripts and generating critical CSS are different decisions; they do not always improve HTTP/2 or HTTP/3 and they can change behaviour.

Check the menu, search, filters, forms, consent and checkout after each change. CSS and JS exclusions let you isolate a resource that does not tolerate an optimisation. If the problem started after a change, revert it and purge the affected cache before adding another.

Lazy loading is useful for images outside the initial viewport. Exclude the main image and check different screen sizes. Features such as VPI can help, but they depend on the analysis carried out and do not guarantee that every view or state of your website is covered.

Additional tools

Use the narrowest purge that resolves a change that is not showing. If there is a CDN, check its layer separately. Purging everything frequently forces responses to be regenerated and can increase load.

Exporting settings is useful for keeping a reference. Before importing them into another site, review the domains, exclusions, integrations and needs of that project; a configuration is not universal.

Optimise the database

First identify the problem: large autoloaded options, repeated queries, tables growing abnormally or data you no longer need. Do not use every clean-up button at once.

Revisions, the trash and other data can have value. Any deletion needs a chosen retention period and a recoverable backup. Converting an engine or changing indexes are structural operations that must be rehearsed separately.

See autoload and wp_options and cleaning up orphaned data to inspect before deleting.

In-memory object cache, the missing extra

Redis can reduce repeated reads of data that WordPress and its plugins store through compatible APIs. It does not automatically cache every SQL query and may add little to a website already covered by page cache.

Follow the Redis setup, use a single object cache integration and keep the account's websites separate. Measure before keeping it. To remove it, disconnect the plugins first and then the service.

Image optimisation

Distinguish between dimensions, file size and quality. An image displayed at 400 pixels should not always force the download of an original thousands of pixels wide; use suitable responsive variants, also taking higher-density screens into account.

Width and height attributes reserve space and help avoid layout shifts, but they do not reduce the file. Keep the originals before regenerating thumbnails or compressing in bulk.

The image optimiser in the client area processes JPG, JPEG and PNG; check its quality differences by format, especially PNG. LiteSpeed can use QUIC.cloud for optimisation and modern formats, with its own configuration and terms. Do not run two bulk systems at the same time on the same originals.

CDN to distribute static content

A CDN can reduce the delivery distance of resources to distant visitors. Weigh its usefulness against your regions and traffic, cost and cache maintenance.

You can see QUIC.cloud with WordPress or Cloudflare. Before changing DNS, keep a copy of the zone, including the email records, and check HTTPS and the origin. Do not force public caching for every page of a shop.

Debug the wp_options table to find possible bottlenecks

Measure the autoloaded set and identify the large options and the component responsible for each. Do not delete an option just because you do not recognise its name, and do not switch all of them to no-autoload. Use the dedicated guide and check times and memory after each change.

Debug slowness in plugins

The number of plugins does not identify the cost on its own. Review what each one does, whether it holds necessary data or features and how much work it adds to the slow operation. Use short traces to identify queries, external calls and repetitions.

Remove unnecessary components following their own procedure, with a backup of their configuration and data. Do not disable every plugin on a live shop to investigate a hunch.

Increase the WordPress memory limit

Increasing memory is not a mandatory optimisation. If there is an exhaustion error, check the effective limit, the cause and the account's overall resources. The WordPress memory guide explains the difference between those values.

Recommendations on plugins in general, and security plugins in particular

Keep components that are necessary, compatible and maintained. Avoid duplicating costly scans without a measured benefit, but do not remove useful controls such as 2FA or auditing just because they belong to the security category. See how to assess security plugins.

After publishing, repeat the initial operations and watch errors, resources and real user data. Keep a log of changes so that you can tell what helped and revert anything that harms how the website works.