What WordPress loads without you needing it

You have cleared out your plugins. The images are smaller. The fonts are on your own server. And the site is still heavier than it needs to be.

Then it is worth looking at a layer almost nobody ever looks at: what WordPress itself ships with. Not your theme, not your plugins — the core. It brings a range of files and header entries that are there for features many websites never use.

That is not a flaw in WordPress. It is a system that does not know what you are planning and therefore provides everything to start with. The decision about what is really needed can only be made by someone who knows the site.

Why this matters at all

Every file a page loads is a request of its own. The browser has to ask for it, wait, receive it, process it. A single small file is not noticeable. Twelve of them are — especially on the phone, where every connection costs more than at a desk.

On top of that comes a second effect that has nothing to do with size: some of it keeps running in the background while the visitor reads. It regularly requests new data from the server without anyone waiting for it.

And third, there are entries in the head of the page that load nothing at all but merely give something away — which interfaces are open, which version is running, which services can be reached. They cost no loading time, but they are still ballast.

Three groups, three different questions

It helps to see the stuff not as one list, but as three groups. A different question applies to each.

First: features you do not use. Here the question is simply — does this occur on my website? If not, it can go.

Second: things only the admin area needs. Here the question is — does a visitor even see this? Much of what WordPress delivers is meant for you in the backend and still ends up with every anonymous reader.

Third: things loaded everywhere although they are needed in only one place. Here the question is — does this have to be on every page? This is the most interesting group, because here you rarely switch something off completely, you only narrow it down.

Group one: features you do not use

Emoji support. WordPress loads a small script and a piece of styling on every page so that emojis look the same in older browsers too. Modern browsers have long been able to do that themselves. If no emojis appear on your site — and on most business sites none do — something is being loaded here that does nothing.

The embed feature. WordPress can embed foreign content automatically when you write an address into the text — a video, a post from elsewhere. For this it brings its own script and writes discovery entries into the head. Whoever uses no such embeds loads it anyway.

References to services nobody uses any more. In the head of a standard WordPress page there are entries for long-discontinued blogging tools — a reference to an editor from the 2000s, a discovery link for services that no longer exist, a shortlink almost nobody opens. They cost no loading time, but they are there for no reason.

The comment feature when you have no comments. If comments are switched off, the page does not need to load anything for them either.

Self-pings when publishing. If you link to one of your own other pages in a post, WordPress by default reports that to itself — a process that creates work on every publish and helps nobody.

Foreign profile pictures. WordPress fetches author pictures from an external service by default. That is a connection to a foreign server on every page view where such a picture appears — with everything that means for data protection. (There is an article of its own on what loads before consent.)

Group two: things only the admin area needs

The backend's icon font. WordPress brings its own font for the icons in the admin area. On many sites it is also delivered when an anonymous visitor opens the page — someone who never gets to see the admin area. A complete font file for icons they do not see.

The background connection. WordPress keeps a regular connection to the server open. It is there so that nothing gets lost while you write a post and so that you are warned when someone else is editing the same text. In the admin area that is useful and should stay there. On a public page that is only read, it creates regular requests without a purpose.

Important here: switching it off completely is the wrong move. Whoever removes the connection everywhere loses the automatic saving while writing. The right way is to leave it out in the public area and keep it in the admin area — or to slow its rhythm instead of ending it.

The password strength meter. This is a comparatively large script that checks how secure an entered password is. It is needed at registration and when resetting. It is often delivered everywhere.

The old compatibility layer for JavaScript. WordPress brings a helper file that keeps outdated code running. If your theme and your plugins are current, nobody needs it.

Group three: loaded everywhere, needed in one place

This group is the most interesting, because here you switch nothing off, you narrow it down.

The blocks' styling. The block editor delivers a stylesheet by default that contains the styling of all block types — including those that do not occur on the current page at all. Since newer WordPress versions this can be switched: then only what is actually used on this page is loaded. On pages with few blocks this is one of the biggest single savings in the whole core.

The theme's central style presets. Block themes generate a set of style variables from their configuration file and deliver it on every page. That can be switched off — but only if another system provides these variables completely. Otherwise the page loses its base values, and the design breaks.

This is the one point in this article where I advise caution: visible design hangs on it here, not only invisible ballast.

The trap: it always looks good for you

A practical point that misleads many.

Whoever is logged in often sees the website in a different state from an anonymous visitor. Some optimisations deliberately do not apply to logged-in users — so that an editor sees what is really in the system and not the trimmed version. That is how it should be, but it means that when you check for yourself you measure the wrong state.

Always check logged out. A private browser window is enough.

And what about the database leftovers?

Two settings belong in the same direction, even though they load nothing.

Post revisions. WordPress stores a complete copy of the post on every save. Without a limit, hundreds of them pile up over the years. They do not make the page slower to open, but they bloat the database and lengthen every backup.

Autosave. By default it runs every minute. A somewhat longer interval noticeably reduces the write operations without anyone losing anything.

How to check it yourself

You need no tool and no access to the server for this.

A look at the source. Open your home page in a private window, right-click and choose “View page source”. The head is at the very top. Read through it once. Everything there that means nothing to you is a candidate for the question: what is this for?

The Network tab. Press F12, switch to “Network” and reload the page. You see every single file that is loaded, with name and size. Sort by size. Names containing emoji, dashicons, heartbeat or block-library are exactly the ones from this article.

That is the more reliable of the two checks, because it shows what was actually loaded — not only what is announced in the source.

Just count along. How many requests does your home page make? And how many of them can you assign to a purpose you actually offer?

What to do — ordered by leverage

First: narrow down the block styling. On pages with few blocks this is the biggest single saving, and it is harmless — only what does not occur on the page is left out.

Then: leave out the icon font for logged-out visitors. One whole font file less, without anything changing for anyone.

Then: end the background connection in the public area — but keep it in the admin area.

Then: the features you do not use — emojis, embeds, password strength, the old compatibility layer, self-pings. Each one is small, together they are several requests.

Then: tidy up the head. Costs no loading time, but makes the page more honest about what it offers.

Last: limit revisions and lengthen the save interval. Does not affect loading time, but the database and how long your backups take.

A warning at the end

There are plugins for all of this, and some of them are good. But the temptation to flip all the switches at once is great — and that is exactly where the mistakes come from.

Every component switched off is a promise that nothing needs it. A theme may use the icon font for a menu. A plugin may use the embed feature for its display. You do not notice that at once, but two weeks later in a place nobody connects with the switch any more.

So: flip them one at a time, then look at the page, logged out. And note what you switched off — so that in a year someone still knows why a detail is missing.

That is the unspectacular truth at this point. It is no trick and no secret, but a list that someone works through patiently once and documents.

Sources

• Atlas, wordpress/core/patterns/performance-toggles.md — that emoji support consists of a detection script in the head, an embedded style and several filters for feeds and email; that the embed feature comprises a route, several filters, two head entries and a script of its own; that the old JavaScript compatibility layer is only removed outside the admin area; that the icon font can be deregistered for visitors who are not logged in; that the background connection can be removed completely, slowed in its rhythm or ended outside the editing screens, with the explicit note not to switch it off during an ongoing edit; that the password strength meter is removed through its dependency; that the interface discovery comes from two places, one in the head and one in the response header; that self-pings on publishing are filtered by the address of your own website; that since WordPress 6.9 the blocks' styling can be limited to the blocks actually used and that this gives a clear reduction on pages with few blocks; that switching off the theme's central style presets removes the variables from the configuration file and is only allowed when another system provides them completely; that optimisations are deliberately skipped for logged-in users; and limiting post revisions and lengthening the autosave interval.
• Own checklist page-speed-tune-wp-core — the collection of switches with their defaults, among them removing emoji support, slowing the background connection to 60 seconds as the standard route rather than switching it off completely, removing shortlink, editor discovery, manifest reference, interface reference, embed discovery, previous and next links and feed links from the head, preventing self-pings, replacing the external profile picture service with an empty image, switching off the password strength meter and limiting post revisions — and the finding that this layer is safe on every setup, because it depends neither on a plugin nor on a theme.
• Udemy, WordPress Speed Optimization & Core Web Vitals, section 4 — the basic settings that are flipped first in practice: removing the old JavaScript compatibility layer, hiding the version number, removing shortlink and editor discovery, switching off feeds and self-pings when unused, switching off the interface for logged-out visitors, removing the interface references, switching off the password strength meter, limiting post revisions, lengthening the save interval to five minutes, keeping comments while removing the comment URL fields, and the advice to agree on switching off further features with the site owner beforehand. Likewise the observation from the script manager that scripts of individual sections also run on pages where their feature does not occur.
• Own audit practice — the self-check through source and Network tab, the need to check logged out, the order by leverage, and the experience that switches should be flipped one at a time and documented, because a switched-off component only shows weeks later somewhere else.