WordPress website loading slowly: causes, diagnostic sequence, and solutions

Heavy themes, page builders, and plugin load

A common situation in projects investigated for slow WordPress loading is a theme trying to do everything, with many plugins added on top. WordPress.org’s documentation states that a lightweight, fast theme runs much more efficiently than an inefficient theme with heavy graphics. Page builders make editing easier but can generate additional CSS, JavaScript, and nested HTML layers for each section.

With plugins, the problem is behavior more than number; a single poorly written plugin can create more load than many well-written plugins. Two plugins doing the same job, scripts loaded unnecessarily on every page, and plugins constantly connecting to external services in the background are the most common examples. WordPress.org’s documentation recommends deactivating and deleting unnecessary plugins and measuring server performance by selectively disabling plugins.

Must you stop using the page builder?

No; on most websites, disabling unused components and simplifying font and icon libraries can provide meaningful gains instead of removing the page builder. Because changing themes means rebuilding the design, it is considered a last resort.

How do images and external scripts slow a page down?

Uploading a photo of several megabytes taken on a phone without modification directly increases LCP time, especially on mobile connections. WordPress.org’s documentation recommends choosing the correct format and compression for each image and considering modern formats such as WebP. Placing a full-resolution camera image in an area displayed as a small box downloads unnecessary data.

External scripts can slow a page even when the server is fast; these files load from other companies’ servers and are outside the website owner’s control. Common sources are as follows:

• Advertising and remarketing tags, particularly multiple pixels running at the same time
• Analytics and heatmap tools
• Live chat and messaging bubble plugins
• External fonts, embedded videos, and social media feeds

Because these scripts occupy the browser’s main processing thread, they can also affect INP. Review whether each one is actually being used; remove unused tags and, where possible, manage necessary ones through a single tag management tool.

Database bloat, autoloaded options, and WP-Cron

On a website used for years, post revisions, trashed content, expired transient data, and tables left by deleted plugins accumulate. The main area requiring attention is autoloaded options in the wp_options table; these data are loaded into memory on every page request. According to the WordPress core team’s announcement explaining the WordPress 6.6 change, Site Health displays a critical issue if the total size of autoloaded options exceeds 800 KB.

With the same release, options larger than 150,000 bytes added without an explicitly specified autoload preference are no longer autoloaded by default. On older websites, large options left by deleted plugins may still remain autoloaded, requiring controlled cleanup after a backup.

Why does WP-Cron create load?

WordPress’s plugin developer documentation states that WP-Cron does not run continuously like a system scheduler but checks the scheduled task list on every page load. When heavy tasks such as backups, newsletter sending, or imports are triggered by a visitor’s request, the current page may be delayed. If server access permits, triggering can be moved to the server’s own scheduler; this access is unavailable on many shared hosting plans.

Step-by-step diagnostic sequence: where is the slowdown?

The biggest time waster when addressing slow WordPress loading is changing several settings at once. The sequence below is the approach we use to isolate the cause layer by layer:

1. Take a full backup; where possible, perform the work on a staging copy.
2. Measure the homepage and the most visited internal page in PageSpeed Insights, separately for mobile and desktop.
3. Examine server response time; if even a simple page loads slowly, first inspect hosting, the PHP version, and caching.
4. Use Query Monitor to identify slow and duplicate database queries, plugins producing errors, and external HTTP requests.
5. Disable plugins individually on the staging copy and measure the change in timing.
6. Compile a list of image sizes and external scripts.
7. Check the autoload warning and other recommendations on the Site Health screen.

Query Monitor is a free developer tool in the WordPress.org plugin directory. It shows slow, duplicate, or erroneous database queries, PHP errors, triggered hooks, HTTP API calls, and script and stylesheet files added to the page. The plugin page states that its impact on page generation time is very small; nevertheless, disabling it on the live website after diagnosis is tidier practice.

Speeding up WordPress: caching, image formats, and lazy loading

The largest and safest gain in WordPress speed optimization often comes from caching. Page caching performs PHP and database work once, stores the result as a ready-made page, and serves that page to the next visitor. If the hosting company offers server-side caching such as LiteSpeed or Varnish, use that first; otherwise, install a single caching plugin. Running two separate page caches at the same time can cause conflicts.

For images, the first step is resizing: do not upload an image much larger than the area in which it is displayed. For formats, WebP is widely supported; with WordPress 6.5, AVIF images can also be uploaded and used like JPEG and PNG. Check whether the server can process AVIF under Tools > Site Health > Info > Media Handling.

Lazy loading has been part of WordPress core since version 5.5; the loading=”lazy” attribute is automatically added to images with width and height values. Installing a separate lazy loading plugin is often unnecessary and may conflict with the core feature. Do not apply lazy loading to the main image visible in the first screen; otherwise, the most important image, usually the LCP element, arrives late.

Combining and deferring CSS and JavaScript: back up first, then test individually

CSS and JavaScript minification, combining, and deferring options in caching plugins look attractive for reducing PSI warnings; however, these settings also most often break the website’s appearance and functionality. Combined files may change the loading order, and a deferred script can stop the menu, slider, form, or cart button from working. The problem often goes unnoticed at first; weeks may pass before anyone realizes the mobile menu does not open or a form does not submit.

• Take a full backup before changing anything.
• Enable settings individually; clear the cache after each one.
• Test the homepage, contact form, menu, and, if present, cart and checkout on mobile and desktop.
• Exclude the problematic script from the deferral list rather than disabling the entire setting.

The “back up first, then test individually” rule immediately shows which setting broke what. If a problem occurs after enabling five settings at once, finding the culprit can take hours.

CDN and PHP version: two infrastructure improvements

A CDN distributes static files such as images, CSS, and JavaScript from servers close to the visitor. WordPress.org’s documentation states that CDNs are faster and substantially reduce load on the WordPress server. If most visitors are in the same country as the server, the benefit may be more limited; the difference is clearer for websites receiving international traffic.

If a WordPress website loads slowly and an old PHP version is selected in the hosting control panel, upgrading is one step that can improve speed and security without code changes. However, an old theme or an outdated plugin may produce errors with the new version. Before upgrading, take a backup, test on a staging copy, and check the error log.

Enabling a PHP accelerator such as OPcache on the server is also among the improvements listed in WordPress.org’s documentation. This setting is usually controlled by the hosting company and can be requested through a support ticket.

A slow WordPress admin panel: a different problem from the front end

If the WordPress admin panel loads slowly, page caching does not help here; administration screens are not cached and are regenerated on every request. If the front end is fast but the panel is slow, the problem is usually in server resources, the database, or plugins running in the panel. Common causes are as follows:

• Plugins connecting to external services: The panel waits when requests for license checks, news feeds, or statistics receive slow responses; Query Monitor’s HTTP API section shows these calls.
• Heartbeat API: WordPress’s built-in polling mechanism sends requests to the server at intervals ranging from 15 to 120 seconds; having the panel open in multiple tabs may increase resource consumption on shared hosting.
• Large autoload data: Loaded into memory again on every panel request.
• A crowded dashboard: Plugins loading many widgets, notifications, and announcements at startup.
• Low PHP memory limit: May cause heavy plugins to slow down or produce errors in the panel.

The diagnostic method for panel slowness is the same: use Query Monitor to see which plugin generates queries and external requests, then verify by disabling plugins individually on a staging copy. Because list screens can become heavier in stores with growing product and order counts, database checks are performed more frequently on these websites.

Common mistakes and the correct approach

The most costly mistakes with speed problems are interventions made without measurement. The table below places common practices alongside a measurement-based approach:

Another common mistake is installing separate plugins for lazy loading, image compression, and caching and having the same job done twice. Not monitoring updates after speed work is completed also causes gains to erode over time; a newly added plugin or theme update can upset the balance again.

How do you increase WordPress website speed? When is professional support needed?

On most websites, the answer to how to increase WordPress speed is found by following the sequence above, and some steps can be performed by the website owner. Resizing images, deleting unused plugins, and checking the PHP version in the hosting control panel fall into this group. In the following situations, professional support prevents loss of time and data:

• If server response time is high but it is unclear whether hosting or code is responsible
• If the plugin producing slow queries in Query Monitor is indispensable to the business
• If combining or deferring settings have broken the website and cannot be reversed
• If a PHP upgrade produces theme or plugin errors
• If there is no staging environment or regular backup arrangement

At Onur Freelance, this work is carried out as the speed optimization and performance improvement service; scope is clarified in the preliminary discussion and no numerical speed promise is made. If infrastructure is inadequate, hosting opened in the business’s name costs 2,000 TL per year, or 3,000 TL together with a domain; details are on the hosting prices page.

To sustain speed, plugin, theme, and PHP updates must be monitored regularly; this monitoring is carried out within the WordPress maintenance and updates service, ranging from 500–2,000 TL per month. Migration, troubleshooting, and other work are listed on the WordPress services page.