Why WordPress is slow: seven causes and how to check them

If WordPress is slow, start by measuring where the time goes. A slow server response, an image that takes too long to download and an unresponsive button are different problems. Installing an optimisation plugin without knowing which problem you have can conceal the symptom and complicate diagnosis.

Compare several pages and repeat the test under similar conditions. On a WooCommerce store, include the cart and checkout: pages with personal or session information cannot be treated like ordinary public pages. Save a recoverable backup before changing code, versions or configuration.

What to measure before changing WordPress

PageSpeed Insights can provide laboratory information and, where enough data exists, information from real users. Do not confuse the two. Core Web Vitals describe loading, responsiveness and visual stability; one score does not explain the cause of a slowdown or predict sales.

• Test a lightweight page and a content-heavy page.
• Compare a first visit with a repeat visit.
• Review the initial server response and the sequence of resources.
• Find scripts that block or keep the browser busy.
• Record the date, device and conditions of each measurement.

1. The server takes too long to generate the page

If the browser spends a long time waiting for the document, review the application, queries and server resources. Insufficient hosting is one possibility, but a particular operation may also be consuming excessive time.

Request metrics for the actual interval: processes, memory, CPU, database activity and external requests. Moving to a more expensive plan without examining these signals may provide temporary headroom without solving the cause. WordPress documentation lists hosting among several performance factors, rather than as the only explanation.

2. A plugin or theme performs expensive work

What the code does matters more than the number of installed plugins. An extension may add queries to every page, call an external service or load scripts the template does not need. A theme may load heavy components even where they are not displayed.

On a test copy, compare behaviour with a minimal configuration and reactivate components in a controlled way. If you identify a cause, review its purpose and options before replacing it. Record the functions you would lose by removing it.

3. Oversized images and video

Check which file the visitor downloads and the size at which it is displayed. A photo several thousand pixels wide may be unnecessary in a small card. Use suitable dimensions, reasonable compression and device-appropriate versions.

Reserve priority loading for the asset that actually appears at the beginning. Offscreen videos and images can load later where that does not affect use. Avoid indiscriminately deferring the main image, because it can delay the perceived loading of the page.

4. Missing or incorrectly applied caching

Caching can reduce repeated work, but you must know what it stores and when it is invalidated. Distinguish page, object, server, CDN and browser caches. Clearing one does not automatically clear the others.

For ecommerce, check exclusions and sessions: the cart, checkout and personal pages must not display another visitor's data. After enabling an optimisation, test a complete order, price changes and availability. A speed improvement does not compensate for an incorrect response.

5. The database and background tasks

Check for slow operations, queued tasks or data loaded unnecessarily. Looking at sizes helps, but a large table is not inherently useless. It may contain orders, necessary logs or integration data.

Before deleting information, identify its owner, purpose and restoration method. If a task runs repeatedly, investigate why it is duplicated. Maintenance should improve operations without compromising commercial history.

6. JavaScript, CSS and external tools

Chat tools, analytics, widgets and advertising can compete for browser resources. Identify which scripts load, on which pages and for what purpose. If a third party responds slowly, check whether it blocks content or an essential action.

Combining, minifying or delaying files may help in some cases, but it can also break dependencies. Introduce one change at a time and verify menus, forms, consent and checkout. Compare the result with the original test.

7. Outdated software or a security incident

Check compatible versions of WordPress, PHP, the theme and extensions. Updates should be tested and have a viable recovery path. Do not publish several major updates at once without understanding what is changing.

If unusual redirects, unknown files or abnormal requests appear, investigate a possible security incident. Slow performance alone does not prove malware is present. In a security incident, containment and correction of the cause are needed alongside restoring resources where appropriate.

A practical order for making improvements

1. Reproduce the slowdown and save measurements.
2. Find whether the server, assets or browser execution dominate.
3. Select the change with the greatest impact and fewest dependencies.
4. Test it on a representative copy.
5. Verify the commercial function and publish with recovery prepared.
6. Measure again and compare real-user data where available.

If your store demands maintenance you can no longer sustain, it may make sense to consider another platform. But a slow WordPress site does not automatically require migration. A Shopify suitability review should also compare fixing the existing installation and the cost of retaining its processes.

Further reading for your store

• Common WooCommerce problems
• WordPress and Shopify for ecommerce
• Planning a migration from WordPress

Sources and review

• WordPress: optimisation and performance factors
• Google web.dev: Core Web Vitals
• WooCommerce: testing for conflicts

Editorial review: the Migraciones.io team · 30 October 2026. Features, plans and availability are checked against the linked sources.