How to diagnose and improve a slow website or application

To improve an application, first identify where the time is being lost. It could be in the network, the server, the database, an external dependency or the browser. Adding caching or ordering more resources without telling them apart can hide the problem without solving it.

Measure a specific operation

Choose a slow URL or action and note the time, device, session and steps to reproduce it. Repeat it several times and compare it with another operation that works well. Check whether imports, tasks or usage peaks were happening at the same time.

In the browser tools, look at which requests are slow, their status codes and the size transferred. A fast HTML response with slow interaction needs a different analysis from a document that takes a long time to arrive.

Production configuration

Check that the application does not force template recompilation or heavy debugging on every visit. Do not assume that every installation has the same default value: review the actual configuration and the deployment procedure for your version.

Keep a recoverable backup and test changes on staging. Once templates are no longer recompiled automatically, you need a way to regenerate them and reflect updates.

Choose a suitable cache

Caching can reuse compatible pages, objects or results. Each layer has a scope and an invalidation policy. Identify which data can be shared and when it must be updated.

Our servers use LiteSpeed and offer integrations for WordPress, PrestaShop and Joomla, among other applications. Check compatibility and do not force public caching for personal content.

After enabling it, check stored responses and content changes, as well as login, forms and purchases. Keep a single solution responsible for each integration to avoid conflicts.

PHP and queries

Use a PHP version with security maintenance and proven compatibility with the application and its components. Test the change before production using the PHP options.

OPcache reduces PHP recompilation. If the delay is in queries or external calls, use PHP X-Ray to find costly work. Compare plans and indexes on a copy before changing a database.

Images, CSS and JavaScript

Serve images with suitable dimensions and formats, keeping the originals. Reserve their space to avoid layout shifts and defer those outside the initial viewport, but not the main image.

Test CSS and JavaScript minification. Combining or deferring files means checking execution order and features; it is not a universal improvement with HTTP/2 and HTTP/3. A static file can also change with a deployment: coordinate versioning and browser caching.

External resources

A third-party image, font, analytics tool or script makes you dependent on its availability and behaviour. Identify what it contributes before removing it. If you decide to host a library locally, check its licence, updates and compatibility; copying it does not remove its execution cost.

A CDN can help deliver resources to distant visitors. Measure from your audience's regions and check DNS, HTTPS and purging before enabling it.

Modules and internal errors

Assess each component by its usefulness, maintenance and observed cost, not just by how many plugins there are. Test removing it on a copy: a barely visible module may hold important data, integrations or tasks.

Check the PHP error logs without showing sensitive messages to visitors. Limit debugging to the time needed and remove its temporary files when you finish.

Check and decide

Apply one change, repeat the same operation and check functionality and resources. If the load comes from sustained genuine demand and is already optimised, consider increasing capacity. If it comes from errors, loops or duplicated work, fix that cause first.

Keep a log of measurements and changes. To go further with WordPress and WooCommerce, follow the step-by-step guide.