WordPress site loading slowly: plugin, theme or server?

If a WordPress site loads slowly, the cause is usually in one of these places: the time the server takes to build the page, the files the theme and plugins add to every page, or images larger than they need to be. Which one is adding the time on your site is found by changing one thing at a time and repeating the same measurement.

WordPress itself is not slow software; slowness comes from the sum of everything built around it. WordPress’s own performance documentation lists the factors that affect speed one by one: the hosting environment and hardware, the versions of PHP and the database software, the choice of theme and plugins, the size and number of images, the efficiency of the database, the load on the server and its distance from the visitor. Two sites built with the same theme can load at completely different speeds because of different combinations of these factors.

That is why this article contains no figures of the kind “this plugin adds this much time to a page.” The same plugin costs different amounts on two sites, and a one-size-fits-all number leads you to the wrong place. Instead, we describe how to work out on your own where the cause lies on your site. If you would rather leave the measuring and fixing to us, the site speed optimization page describes the process; the list of general causes that are not specific to WordPress is in the article why your website is slow to load.

Is the problem on the server or in the browser?

This is the first distinction, and it separates two different worlds. WordPress builds the page for every visit with PHP from the database; this happens on the server, and the time it takes is measured as Time to First Byte (TTFB). Once the page has been built and sent, the browser downloads the style, script, image and font files that the theme and plugins call; that is the browser side. A caching plugin speeds up the first side; it does not reduce the load on the second.

How to spot it: open the developer tools in Chrome with F12, check the “Disable cache” box in the Network tab and reload the page. The first row of the list is the page itself; click it and look at the “Waiting for server response” time in the Timing section. web.dev gives 0.8 seconds or less as the target for most sites. If this time is consistently long across several reloads, look at the server first; if it is short but the page still appears late, the problem is the load sent to the browser. The technical side of the topic: TTFB and server response.

A warning: a measurement taken while logged in to WordPress as an administrator may not show what a visitor sees. Many caching setups rebuild the page every time for logged-in users and load extra files such as the admin bar. Measure in a private window, while logged out.

What do you check if the server is slow?

On the server side, three questions are asked in order. The first is hosting: on a crowded shared server, the processor and memory allotted to your site may not be enough at peak traffic hours. The second is software versions: the WordPress documentation counts keeping PHP, database and web server software up to date as a performance factor. The third is page caching: sending a ready-made copy of the page instead of rebuilding the same page from the database on every visit.

WordPress’s own documentation describes caching as the step that gives the biggest gain for the least effort, and that is true for the server side. But if the page is still slow after a caching plugin has been installed, the problem is most likely no longer on the server; move on to the next section.

How do you find out which plugin is slowing things down?

The WordPress documentation suggests the same route: selectively deactivate plugins and measure performance. The method is only reliable if a few rules are followed:

• Work not on the live site but on a copy of it (a staging environment); deactivating plugins can break forms and checkout flows.
• Take a baseline measurement first: the same page, the same tool, the same device profile; at least five runs and the median value. A single run cannot separate the difference between two plugins from noise.
• Deactivate plugins one at a time and repeat the same measurement after each one.
• On each line, write down the deactivated plugin, the Time to First Byte, the total data transferred and the number of requests.
• Note the ones with a large difference, then reactivate them all. The table makes the decision, not intuition.

On the browser side there is a faster shortcut. In WordPress, plugin files come from the “/wp-content/plugins/plugin-name/” folder and theme files from the “/wp-content/themes/theme-name/” folder. When you type “plugins” into the filter box of the Network tab, only the files downloaded by plugins remain, and the address of each row shows which plugin it belongs to. That way you can see at a glance whether the contact form plugin’s script also loads on pages without a form, or whether a gallery plugin loads a stylesheet across the whole site. The Coverage panel in the developer tools also shows how much of the downloaded code is never used on that page.

Does the number of plugins matter, or what they do?

The WordPress documentation writes that both the number of plugins and the plugins’ own performance have a large effect on speed, and it counts removing unnecessary plugins as an important improvement. In practice, the real question is behavior more than number: a single plugin that does heavy work on the server on every request can be more expensive than several plugins that run only in the admin panel. Ask three questions for each plugin: does it add files to the page the visitor sees, does it do so on every page, and does the theme or the browser itself already do what it does?

Is the theme heavy?

Multipurpose themes and page builders are built to fit every kind of site; they may also send styles and scripts for sliders, animations and components you do not use. The way to isolate the theme’s share is again a single-variable measurement: on a copy of the site, with the plugins held constant, switch the theme to one of WordPress’s default themes and measure the same page under the same conditions. The difference is a rough indication of what the theme costs. The “themes” filter in the Network tab and the share of unused CSS in the Coverage panel answer the same question from a second angle.

How much do images and embedded content account for?

In WordPress, images are often uploaded at the size they came out of the camera or design program. Select the Img filter in the Network tab and sort by the Size column; the heaviest file on the page is usually an image, and often the LCP element counted as the page’s main content. Content from other servers, such as embedded videos and maps, is a separate item; when you turn on the Domain column, you see every row that comes from outside your own domain.

Is installing a speed optimization plugin enough?

Speed optimization plugins combine files, defer scripts and compress images. On some sites they bring a real gain; but they do not remove a load, they often just change its order. A deferred script can speed up the first view of the page while delaying the first click; combined files can cause layout shift or a broken menu. The rule is simple: after every settings change, repeat the same measurement and keep only the settings the measurement shows to be an improvement.

How did we apply this method on our own site?

This site is built not with WordPress but with our own generator, but the method of isolating slowness is the same. After one round of work, the home page’s Total Blocking Time suddenly rose. The first suspect was the JavaScript added in that round; the measurement pointed somewhere else. We tested the style rules in families, removing a single family each time, and read the median blocking time on every attempt. With all :has() selectors removed, the time fell from 369 milliseconds to 104 milliseconds; with only those tied to the root of the page removed, to 115 milliseconds. The load was concentrated in a single family, and those rules painted nothing on the home page. After the fix, the time fell to 97–108 milliseconds. Details in how a :has() selector affected blocking time.

Our experience most similar to plugins, though, was with libraries. Before removing the two libraries that controlled scrolling, we asked ourselves: can the browser itself do this job? It could; once the libraries were gone, compressed JavaScript dropped from 51.1 kilobytes to 33.5 kilobytes. The WordPress equivalent is to ask, before removing a plugin, whether what it does already exists in the theme or the browser.

Change one variable, repeat the same measurement; let the table decide.

Speed it up or rebuild it?

The measurement table answers this question too. If the load is concentrated in a few plugins and a few large images, working on the existing site is enough and usually cheaper. If the theme or page builder adds a heavy base load to every page of the site, and that load does not go away without changing the theme, rebuilding may be cheaper in the long run. How often and by whom the content changes is also part of this decision; we explain the difference between the two approaches in static site or content management system.

Whichever route you choose, speed that is gained but not protected slips back: every new plugin and every new campaign image adds a little to the load. Writing down limits the site may not exceed and measuring after every update is therefore part of the job; how to set them up is in the performance budget guide. If you wonder why the measurement itself gives a different result every time: how to measure site speed.

If you want your own site measured and fixed at the source, our Core Web Vitals optimization starts from real-user data and delivers LCP, INP and CLS against a budget.