A common pain point amongst new users of Block Themes is managing homepage content – how and where to edit it and if that should be done in the template itself.

The problem with some block themes is that they put their demo content directly into the template. This can override whatever content you set to show on your homepage. And if you don’t know better, you’ll start editing the template to add your own content.

Template Editing vs. Page Editing

WordPress maintains a separation between content and design.

That means that content like your page-specific text/images etc needs to be placed in the page editor.

The layout and design of your site is managed from the site editor, using templates.

It’s important not to directly edit the template and add your content there. Otherwise it’ll cause you headaches and WordPress won’t act the way you expect.

Here are the 2 biggest problems I’ve encountered when trying to get started with block themes, and how to fix them.

1. Your own homepage content is overridden by theme content.

You have made some posts and pages already in WordPress. Your site currently uses a static page for the homepage with posts displayed on a dedicated blog page.

You decide to try out a block themes. You install one, let’s say Beaumont.

You activate the theme and visit your homepage. You’re expecting to see the content you’ve already carefully crafted.

Instead you find the Beaumont blog layout!

Likewise, if you have your homepage set to show posts, but install a theme like Spectra or Frost, you will find that your posts are nowhere in sight, and you have the theme demo content instead.

2. You don’t realize the demo content is in a template and you edit it directly

You don’t find the usual Edit Page link in the toolbar. So you click Edit Site, which seems logical.

Then you get to work editing, without even realizing that you’re editing the template itself!

These scenarios demonstrate the commons issues you might face getting started with block themes.

How to fix these scenarios

First you have to understand the WordPress template hierarchy to understand why this is happening.

The WordPress template hierarchy

The template hierarchy is the system that determines which template WordPress will choose to display the content, when a page is requested.

Usually it’s quite straightforward – a single post will use the Single template. A standard page will use the Page template etc.

But the homepage is a bit unique and tricky. There’s potentially 3 templates that could be used:

• front-page: this will be used regardless of if you have set your homepage as blog posts or a static page. It has the highest precedence in the hierarchy.
• home: this will be used only if you’ve set your blog posts for the homepage. If you’ve set a static page, you’ll see your page content as expected.
• index: If neither a home nor a front-page template exists, then the index template will be used, so it should show whatever content you already have.

So in the scenarios I outlined, this is what happened:

• Beaumont comes with a front-page.html template, so the content in it always showed up on the home whether it was set to display posts or a page.
• On the other hand, Frost does not come with a front-page.html. Instead it has a home.html template. So the demo content inside that template showed up only when my Reading settings were set to display posts on the homepage. When I set my site to a static homepage, my own content showed up.
• If your theme uses an index template instead of front-page or home, like the Ollie theme does, it will display whatever content you’ve already created.

It’s a lot to expect a new WordPress user, or even someone that’s used WordPress before, to understand intuitively what’s going on here.

How do you know which template your theme is using?

• Go to Appearance → Editor → Templates
• Click on your theme name to filter out other templates
• Now see what you have:
  

So now you know why certain content is showing on your homepage, what do you do if you want to change that?

You’ll either need to edit the template that’s currently being used and/or create a new one.

For example, in the Beaumont scenario, if I want to show my own static page on the homepage and use the Beaumont template for the Blog page, this is what I would do:

Copy the Front Page Template to a Blog Home Template

1. Go to Appearance → Editor → Templates
2. Click on the front page template to open the Site Editor.
3. Click on List view
4. Select all blocks (click the first block, hold down the SHIFT key, then click the last block and it should highlight all of them) in List View, and either right-click or CMD+ C on a Mac (CTRL+C on a PC) to copy them to your clipboard.
5. Click the WordPress logo at the top left to get back to the Templates page.
6. Click Add New Template
7. Select Blog Home. In some cases you’ll see a modal with a pattern or two to choose from. This will vary according to your theme. If one of the patterns presented fits your needs, by all means choose it to get started. But it’s not strictly necessary and you can skip it.
8. After this step you’ll be in the Site Editor.
9. Right-click or CMD+V (CTRL + V on a PC) to paste all the blocks, then click Save at the top right.

Now your blog page has the Beaumont layout for posts, and we can re-purpose the front-page template to show our static page content.

Edit the Front Page Template to Show Page Content

1. Go to the site editor and click on the front page template again.
2. Now you’re going to delete the blocks you don’t want. When you delete a block containing a Query Loop, you will see a warning message. But you can ignore it and proceed with deletion because in the next step we’re going to add a block that displays your content.
3. In the Block Inserter, scroll down until you see the theme section. Choose the Content block which will show your static page content.

If you’re like me, you might be concerned about editing the template directly and not being able to revert back to its former state. But, don’t worry, you can always revert back to the theme’s default content by using the Reset option:

How to use your theme’s demo content, in the right way

In the case of a theme like Frost or Spectra, you might want to use their demo content as a starting point for your homepage, but you need to get that into the page editor instead of editing the template itself.

There are 2 ways to do this:

1. Copy template blocks to your page

The premise of the full site editor is that blocks are usable across pages and templates, anywhere you’d edit your site basically. That means you can copy/paste blocks from a template to a page to duplicate the design.

• Open the Blog home page template in the site editor
• Open the List View. Select and copy all the blocks.
  • Tip: don’t copy header and footer template blocks, just the content sections.
• Exit the site editor and go to Pages → New
• In the editor, paste the blocks

2. Recreate the template using patterns

The template design should be comprised of patterns, which would be available in the pattern inserter when editing a page.

1. Create a new page
2. Click the Block Inserter and click on Patterns
3. Look for the patterns that match the sections you want to add from the demo
   • This works but can be a bit laborious because it’s not always easy to find each specific pattern.
   • Some themes, like Frost, do make it easier by making full page layouts available as patterns. You’ll see them by clicking on Patterns → Page
     

Hopefully WordPress improves the onboarding experience for block themes in the future, providing an easier path forward which doesn’t require so much insider knowledge!

Full site editing is the new direction that WordPress is heading in, to provide a better editing and design experience for site owners.

To get familiar with the new terminology that comes along with Full Site Editing, please read the glossary.

You have likely already used the block editor, formerly known as Gutenberg. It’s been the default editor since WordPress 5.0.

The block editor looks like this:

The previous editing experience, now known as “classic editor” looked like this:

With Full Site Editing, this block concept and interface is expanded beyond the page and post editor, to all parts of your site. This will allow site owners to more easily design and edit their site, using core WordPress features.

The Site Editor extends the block concept to other areas of your site:

• header
• footer
• navigation
• template files

For example, this is how you can now edit your navigation menu:

Why is full site editing a good thing for WordPress site owners?

Previously, site owners were very dependent on the controls provided by the theme they selected.

For example, if you wanted to edit and customize the header section of your site, your theme had to provide options for that, otherwise you would need to get into the code.

One issue with this is that, not only were you dependent on your theme, but the experience of editing would also vary based on your theme. Some themes utilized the customizer, but some still had their own proprietary options panel.

With the Full Site Editing concept, the role of themes will be different, and editing your site will be a much more consistent experience no mater which theme you use.

What’s the difference between full site editing and the block editor or Gutenberg?

The block editor was the first dip of the toe into this concept. But it’s just a replacement for the editing experience of an individual post or page. Full site editing is an expansion of the block editing experience.

How do I start using full site editing?

To make use of full site editing, you must use what’s called a block theme which enables these controls.

A few examples of free block themes are:

• TwentyTwenty Five
• Frost
• Ollie

How do I know if my site has full site editing?

Look for these indications:

1. In the Appearance menu, you will have the option Editor
2. When viewing your site, while logged in, you will have the Edit site option

Can I enable full site editing on a regular theme?

Sort of, but to a limited extent.

If you are a developer you can technically add many components of FSE to a classic theme. But not all components will be available, so what you would end up with would be hybrid between a classic and an FSE, or block, theme.

But this is a highly technical process and may or may not be worth the effort.

Read more about that process at the excellent FullSiteEditing.com

If you are not a developer, it would be better to either keep using your current theme, or switch to a different, already FSE-enabled theme.

There is no requirement to do this, however. Your theme will keep working, so there’s no specific need to start using FSE on your current site.

Keep reading: What’s the difference between a full site editing theme and a classic theme?

The changes to WordPress are not only in the user experience and interface, but in the terminology as well. This glossary should help with the learning curve when navigating the new editor, as well help you to make sense of tutorials and be able to search for help more effectively.

Site Editor

Instead of the Customizer, or a proprietary theme options panel, all your controls will be in the site editor. This is found under Appearance.

Styles AKA Global Styles

This is where you can control typography, fonts, layout widths, block styles and other design elements, which apply across your whole site.

Templates

This is the same concept as in classic themes. Templates are the design layouts for types of pages on your site, such as the homepage, the blog homepage, a single post, a category page etc

Now you can use the block editor to more easily manage these layouts and customize your site.

Template parts

These are smaller, reusable parts within a template, which may be used across the site.

For example, the Header is a template part, as is the footer. It’s not a full page template, but a part of a page that you can now control in the site Editor.

Template Parts are a sub-section of Patterns. They are a bit different from standard patterns because template parts have an area property. That means they are assigned for use within a specific place on the site.

Theme blocks

These are core blocks which are designed for use with full site editing. Some examples are: Navigation, Query Loop, Site Logo

Block Theme

A block theme is one that is designed to take full advantage of full site editing. You’ll use the site editor instead of the customizer to manage your site.

A few examples of block themes are: TwentyTwenty Five, Ollie, Frost.

Block editor

This is the name for the content editing interface in WordPress. It replaces the old “classic editor” for your posts and pages. It was previously known as Gutenberg.

Patterns

Patterns are pre-configured groups of blocks that form a particular layout or feature. You can add them to your page and then edit the content of them. They are an easy and convenient way to make your site look professionally designed.

Patterns can be synced, unsynced or partially synced.

Block grammar / block markup

Block grammar, also known as block markup is a WordPress-specific type of HTML comment which is used in block theme template files and in the block editor.

It looks like this :

<!-- wp:template-part {"slug":"header"} /-->

<!-- wp:group {"tagName":"main","style":{"spacing":{"margin":{"top":"var:preset|spacing|60"}}},"layout":{"type":"constrained"}} -->
<main class="wp-block-group" style="margin-top:var(--wp--preset--spacing--60)">
	<!-- wp:pattern {"slug":"twentytwentyfive/hidden-blog-heading"} /-->
	<!-- wp:pattern {"slug":"twentytwentyfive/template-query-loop"} /-->
</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer"} /-->

List View

This is a feature of the block editor which makes it much easier to view the block structure of your page or template.

The List View panel on the left shows you all the blocks on the page, with a hierarchical structure. You can click on any element in the List and jump to it in the editor, making navigating the page much easier.

When there are grouped and nested elements, it can be hard to select the part you want in the main editing window. using the List View you can be much more precised with your selections.

You can also drag drop elements in the List View to move them around the page.

Theme.json

This file is the engine of block themes. It contains all the settings and configuration information.

A block theme, or block-based theme, is the same as a full site editing (FSE) theme.

A classic theme is one that doesn’t work with full site editing.

Terminology

Whether you are a site owner or a developer, there’s new lingo to learn. Get started with our Full Site Editing glossary.

Differences in User Experience

If you use a classic theme, you will still be using the block-based editor for your posts and pages, but you’ll be dependent on your theme to provide editing capabilities for other parts of your site, like the header, footer etc.

Classic themes utilize either their own custom options panel, or the WordPress customizer to provide design and other controls.

They utilize “widgets” as a way to allow users to add pieces of content to sidebars and other parts of the site the theme has designated as widget-enabled.

Block themes do everything through the new Site Editor. You’ll be able to edit more parts of your site using a native WordPress interface. This will provide a more consistent experience no matter which theme you are using.

You will need to get used to the new user interface, and find where the different options are, but after that initial “culture shock” it should be a better experience.

The Site Editor

This interface allows you access to edit parts of your site using blocks much more easily.

Navigation

Navigation menus now have their own block, and are managed from within the Site Editor:

Templates

Templates control the design of specific types of pages on your site. For example, your category archives have a template, your blog homepage has a template, single posts have a template etc.

You can also create various layouts that you can choose to apply to any page, for example, a layout with a sidebar, one without a sidebar etc.

In classic themes, unless your theme gave you control, you had to use PHP to do custom layouts templates.

Now templates are available for editing in the Site Editor, using block tools and preset patterns.

As a user, block themes will give you a lot more control over your site, without needing to tinker with code.

Global Styles

These are preset color palettes and typography styles provided by your theme, that you can select and edit to style your site. This will allow you to create an aesthetically pleasing site even if you aren’t a designer. In addition to color palettes and typography, you can also set global styles for specific blocks, set layout widths and more.

Patterns

These are pre-styled and pre-configured groups of blocks that you can use to make your pages look professionally designed. Patterns are shortcuts to getting a particular look or feature on your page.

They can save you time and make your site look better than if you did everything yourself (assuming you are not a professional designer).

Patterns can be provided by both plugins and your theme.

For example, the Ollie theme provides many patterns for elements such as Calls to Action, and even full page layouts.

Once added to a page you can then edit the content as normal.

Font library

The font library feature is by default only available in block themes. It allows you to manage fonts from the WordPress site editor, making it easier for users to control the typography of their site. Themes can install fonts as part of their design. And users can upload their own, or install them from Google Fonts, and serve them from your own domain.

With some code, the font library can be added to classic themes.

Consistency

Although some classic themes give you the same amount of control, the methods and interface will vary form theme to theme. So if you change theme you have to re-learn how to control it.

With these controls built into a native WordPress system, the experience will be more unified so you won’t have a learning curve for every theme.

Technical differences

Under the hood a block theme and a classic theme are quite different.

As a developer, the transition might be more difficult because the underlying technology is different and you’ll have to re-learn how to make a theme.

Classic themes mostly utilize PHP, whereas block themes rely more on HTML, and WordPress’ new block markup.

Whereas functions.php was previously the powerhouse of your theme, themes.json is now doing the heavy lifting.

In some ways this could make theme development a bit more accessible.

On the other hand, creating custom blocks is more complicated and requires JavaScript knowledge. You can create a theme without custom blocks, of course, but taking that next step will be a hurdle.

There are some ways in which the classic theme methodologies are still supported in block themes. For example, if the block theme does not have the relevant template html part, it can fallback to a php file. But that PHP file has to be written in a specific way.

Easier theme switching

Some classic themes relied on elaborate shortcodes to create layouts. That meant if you changed themes, you were left with unrendered shortcodes in your pages.

With everything in blocks, even things like patterns which may have come with your theme, will still render to some extent. They may lose some styling, but your content will still be there in a native WordPress way.

What are hybrid themes?

Hybrid themes are classic themes which have some elements of block themes added to them. They provide a bridge between the two kinds of technologies, in theory giving you the best of both worlds if you’re not ready to make the jump to block themes.

Examples of block themes

If you are looking to experiment with full site editing and block theme, I recommend you set up a test site using Local WP or a similar tool, and get started. Here’s a few free themes you can install to play with:

• Twenty Twenty Five
• Ollie
• Spectra One
• Frost

Check out https://fullsiteediting.com/themes/ for a more comprehensive list.

WordPress block patterns are mini-templates. They are pre-configured groups of blocks that give you shortcuts to creating certain features on your site, like a call to action, a nice-looking hero image with text, or even a whole page layout.

They are available to insert on any page, and then the content can be edited.

Below is the Testimonial Card pattern from the Ollie theme. Once added to your page you can see it is composed of a group of blocks, designed and configured for you. You can edit them just like normal blocks.

The confusing part is that there are 3 kinds of Patterns:

• Unsynced
• Synced
• Partially synced

I’ll explain the differences and how to utilize them in your content.

Unsynced patterns

Once an unsynced pattern has been added to a page, it functions like any other block and is independent of other instances of the same pattern.

So if you have added the same pattern on several pages, making a change to one of those changes only the once you edited. The same pattern on other pages will remain unchanged.

You can either add an existing pattern from the pattern library, or create one from scratch.

To add an existing pattern:

• In your post or page click the Block Inserter  button and then click Patterns.
• Choose your pattern

Once it’s in your page, you can make changes to it, and it only changes it on that specific page.

If you want to customize it and save your own version of it, make your changes, then

• Select the pattern in the List View, then click the 3 dots and choose Create Pattern
• Give it a name and choose the category
• At the bottom you have the toggle to choose whether it’s synced or not. The default is set to synced. Click it to toggle off.

You can also get to that from the toolbar:

Now you have a custom pattern you can add to any post/page. It’s specific to each place you insert it and if you make changes to it, it is only changed on that specific place.

Make your own pattern from scratch

• After creating an element or layout you like in your page, select the block or blocks that you want to make into a pattern.
• Click the 3 buttons, then choose create pattern.

Then it will be available to add to any page easily from the Pattern library.

Synced patterns

In previous versions of WordPress, synced patterns were known as reusable blocks.

When a pattern is synced it means that you can make a change to it in one place and that change will update all instances of the pattern across your site.

So this is good for more dynamic content that you may want to update periodically. It allows you to make one update that affects each place you’ve added the pattern across your whole site.

To create a synced pattern:

Make a new pattern as described above, but toggle on the synced option when saving it.

To differentiate unsynced patterns from synced (or partially synced) patterns, synced have a purple icon when viewing them in the pattern library or in the list view:

Edit a Synced Pattern

If you are in a post or page where the synced pattern has been added, you will see the Edit Original option.

When you click this, you are taken into a pattern editing screen:

After making and saving your edits, the pattern will be updated in every place you used it on your site.

When to use Synced vs Unsynced patterns

Is it content that you’re going to have in multiple places on your site?

And will it be the same in all those places and may need to be updated at some point?

Then it should be synced.

Examples:

Business hours
Your business hours may be displayed in multiple places across your site, and the information will be the same in all those cases.

But you might want to update it for holidays, for example. So in that case a synced pattern will be perfect – you make the update once and you’re done.

Team directory

Imagine you show a list of company members in multiple places.

But what if you hire someone new or a team member leaves? You’ll need to update the list and a synced pattern will let you update that once, and have it be updated across your site.

Partially synced patterns / overrides

Partially synced patterns are a hybrid, where only some specific elements within the pattern are synced.

These are also known as Overrides.

This gives you a potentially very flexible pattern.

How to create a partially synced pattern

• When editing your pattern, select a specific block. In the example below, of a Call to Action pattern, I’ve selected the button.
• Make sure you’re in the Block settings in the right panel, and expand the Advanced panel.
• There you will see the Enable overrides button. Clicking that allows syncing for that specific element.
• You will then see a popup where you name that specific synced element

Now when this pattern is added to your content you will notice a couple of things:

• In List view, the partially synced element/block is visible, because it’s editable
• I can change the text of the button for this specific instance
• So now I can have multiple versions of this pattern, where I can have some custom elements specific to each instance and some elements that will be updated in all cases.

The only drawback here is that at the time of writing, only certain blocks are eligible for partial syncing. I expect more and more blocks will be supported over time. But if you don’t see the Enable overrides button on your synced pattern, this is likely why.

The Reset button will remove any edits you made to the partially synced block and reset it to its original state.

How to delete a pattern entirely

Use the site editor

• Click on Patterns
• Find your pattern and click the 3 dots
• Click Delete

From the post/page edit screen

• Click Edit Original
• Click the 3 dots on the right
• Click Delete

Preconnect to required origins is a PageSpeed recommendation that you may see if your site loads files from external domains. It can be satisfied by adding either preconnect or dns-prefetch directives to your page.

preconnect and dns-prefetch are types of “resource hints” which are used to try and speed up the loading of files hosted on 3rd party domains.

Resource hints are small pieces of HTML that are added to the page, to communicate to the browser to start specific tasks as soon as possible.

This is what resource hints look like in the HTML of a page:

<link rel='dns-prefetch' href='//fonts.googleapis.com' />
<link href='https://fonts.gstatic.com' crossorigin rel='preconnect' />

Don’t get this confused with preload, another type of resource hint, which is used for specific files.

In this article I’ll explain the difference between preconnect and prefetch, which you should use, and how to add these to your site.

Benefits of preconnect and prefetch

There is a performance cost when you use content hosted on a domain outside of your main domain.

The browser has to go through a multi-step process to connect to that external domain, which takes time. If you use assets from several other domains, the impact is amplified further.

Per Google’s documentation:

Establishing connections often involves significant time in slow networks, particularly when it comes to secure connections, as it may involve DNS lookups, redirects, and several round trips to the final server that handles the user’s request.

https://developer.chrome.com/docs/lighthouse/performance/uses-rel-preconnect

Using preconnect or prefetch gets that process started earlier, so that downloading the actual file will be quicker when it’s time to do that. It’s like unlocking the door of your house so your visitor can walk right in when they arrive.

Examples of content commonly fetched from 3rd parties include social media widgets, ad scripts from networks like Google Adsense and Mediavine, streaming videos etc

I would classify preconnecting and prefetching as micro-optimizations.

That is, it’s a best practice to use these hints, but you won’t notice a huge difference in performance or loading time. This change alone will not really impact the overall PageSpeed score.

For that reason, resource hints are not the first step to take when optimizing your page (managing your JavaScript and reducing unused CSS are better places to start). But, they are pretty easy to implement, so you may as well utilize them.

What’s the difference between preconnect and prefetch?

DNS prefetch performs the DNS lookup only, whereas preconnect also performs the next couple of steps in the process.

This makes preconnect a bit more expensive to use and should be used sparingly.

DNS prefetch can be used more liberally.

Which domains should you preconnect to?

Running a Lighthouse or PageSpeed report will inform you about domains you could consider preconnecting to.

You could also run a GT Metrix report, go the Waterfall tab, check the Domain column and look for domains listed there which are not yours.

Even if the recommendation is not showing up in PageSpeed, it’s worth scrolling to the “Passed” section to make sure you aren’t using it incorrectly. There it will show warnings for unnecessary preconnects:

There are 2 guidelines to keep in mind, according to PageSpeed:

• Don’t preconnect to more than 2 domains.
• Preconnects should only be for resources definitely used within 10 seconds, otherwise the connection is closed and it was essentially a waste.

So your strategy should be:

Use preconnect for the 2 most important external resources and prefetch for the rest.

• “Most important” is defined as what’s more critical to the display of your webpage. If you have a social widget or externally hosted streaming video above the fold, you’d want to preconnect that.
• If you are unsure, DNS prefetch is the safer choice.

How to add Preconnect and DNS Prefetch on your site

It’s possible some browser hints are being automatically added to your site by WordPress itself, or by themes and plugins:

By default, wp_resource_hints() prints hints for s.w.org (the WordPress.org CDN) and for all scripts and styles which are enqueued from external hosts.

https://make.wordpress.org/core/2016/07/06/resource-hints-in-4-6/

So it would be a good idea to check the HTML of your site to see if that’s the case.

1. Go to View Page Source in your browser
2. Search for preconnect and then dns-prefetch

Besides that, several optimization plugins allow you to add these browser hints, or you can manually add them yourself.

Should you use “crossorigin”?

You will see in some cases the ability to add crossorigin to the preconnect directive. Whether to use it or no can be a bit confusing. If the resource that will be used requires CORS, which webfonts do, then crossorigin should be used.

For more info, please read: “preconnect resource hint and the crossorigin attribute“

WP Rocket

WP Rocket is a premium-only caching and optimization plugin. It automatically added browser hints in some cases:

• If you have enabled the CDN function, a preconnect (with prefetch fallback) is automatically added for your CDN domain.
• Preconnect for Google Fonts is handled automatically

You can manually add dns-prefetch hints:

1. Go to the Preload tab and scroll down to Prefetch DNS Requests
2. Enter the domain without the protocol, like this:
   //example.com
3. Save the settings

Perfmatters

Perfmatters is a premium-only optimization plugin (no caching) which offers options for both prefetch and preconnect.

1. Go to Settings → Perfmatters → Preloading
2. There are fields for both Preconnect and DNS Prefetch
3. For Preconnect enter the domain name including the protocol. For DNS Prefetch enter only the domain preceded by //:

Pre* Party Resource Hints plugin

Pre Party Resource Hints is a free plugin available on WordPress.org. This could be useful if you’re not already using another optimization plugin.

You can use it to add other resource hints like preload and prerender in addition to prefetch and preconnect.

It also has a very useful feature to automatically preconnect external resources it detects:

Due to the slightly more advanced settings, I’d only recommend this plugin for intermediate/advanced site owners.

Add prefetch and preconnect manually

If you want to add the code yourself, you can install a plugin like WP Headers and Footers and use the Scripts in Header field to add it.

Here are the elements you have to include:

1. Open the tag with <link
2. Specify the type of hint with rel= and then either dns-prefetch or preconnect, e,g,: rel='dns-prefetch'
3. Use href= to specify the domain. Use the full domain including http or https for preconnect. For prefetch remove http and use the format: //domain.com
   For example: href='//fonts.googleapis.com'
4. Close the tag with />

Here’s an example of a DNS Prefetch:

<link rel='dns-prefetch' href='//fonts.googleapis.com' />

And an example of a preconnect:

<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

Notes:

• You will see either double quotes or single quotes used in examples across the web. Either way is fine.
• The rel can appear at the start or end of the tag, it doesn’t matter. Both the following are valid:

<link rel='preconnect' href='https://wikipedia.org' >
<link href="https://google.com" rel="preconnect">

How to check if your hints are working

In Safari, the Console outputs messages to let you know if the hints are successful:

You can also use a tool like WebPageTest.org which shows you a Connection view. Here you should be able to see the download of the hinted asset occurring in 2 parts.

1. The preconnect/prefetch phase which should happen early
2. The downloading phase a little later, when the file is actually used.

Look at line 6 below. The first part of the connection and SSL negotiation happens early in the process, then there is a gap until the file is actually needed and downloaded.

If you are just getting started with optimzing your page, I’d recommend handling these higher priority recommendations first: Reduce Unused CSS in WordPress, Reduce unused JavaScript in WordPress, How to avoid enormous network payloads in WordPress.

Implementing browser caching on your WordPress website improves performance for visitors who visit multiple pages or visit your website multiple times.

It allows their computer to store commonly used files in their browser which means pages can be displayed faster on those repeat visits.

Browser caching vs page caching

You may have heard about page caching already. This is related to, but not the same as, browser caching.

Caching is the process of “remembering” information for fast retrieval.

Both page caching and browser caching are methods for remembering information, but they store the information in different places.

Page caching happens on your server, while browser caching happens, yes, in the browser. Specifically, in the browser of each visitor and on each device that they access your site from.

And just to clarify, by browser I mean the program or app you use to look at webpages, e.g. Safari, Chrome, Internet Explorer, Firefox etc

Let’s Cook Up A Webpage!

We can imagine browser caching in terms of making a meal. In this case, the “meal” is the webpage that you want to look at, and all the files used on that page are the “ingredients”.

Before you can make a meal, you have to check that you have all the right ingredients, and that they are fresh. You then combine all those ingredients in a specific way to create the meal.

If this is the first time you’re making this particular meal, you probably don’t have all the ingredients on-hand in your kitchen. So you’ll have to go to the store and buy them – this will of course take some extra time.

Now let’s say you want to have that same meal again tomorrow. This time, because you already have most or all of the ingredients in your kitchen, you can prepare the meal much faster.

Browser caching makes 'cooking up' a webpage faster on repeat visits
Share on X

In our analogy, you use your browser to request a certain webpage – a specific meal.

The browser contacts the server where that webpage lives, it asks for the recipe for that page, and gets sent the list of ingredients. These ingredients are basically, HTML, CSS, JavaScript and image files.

If it’s the first time you’ve gone to this webpage, your browser won’t have any of the ingredients on hand so it has to “go shopping” and retrieve them all fresh from the server.

But when you visit that same webpage again, your browser doesn’t have to reassemble everything from scratch, it can use the ingredients it’s already stored, and only ask the server for the new things it doesn’t have.

So that’s why, the first time you visit a webpage it takes longer than the following visits.

You may have noticed this phenomenon when you do repeated speed tests, or when you use the “repeat view” on webpagetest.org. The repeat view is always faster because many of the components have already been downloaded and don’t have to be fetched fresh.

The  point of browser caching is to make repeat views of a webpage more efficient.

Ingredients in your kitchen go stale though, don’t they?

They sure do, and so do the ingredients of your webpage. In terms of a webpage, “stale” means that you’ve updated something, making the cached version out-of-date.

Just like food, webpage ingredients must also have an expiration date so the browser knows whether to use them, or whether to get a fresh version, when cooking up the webpage.

When the browser gets the list of ingredients from the server, each file has a “header”. This is just some information about that file, including how long it can be considered fresh for.

This can be communicated either by a cache-control header set in seconds, or an expires header using a specific length of time. You can see both, as they appear in the browser, below:

This is like checking the “sell by” or “expiration” date on your ingredients. That expiration will vary according to the type of file. The goal is to keep ingredients fresh as long as possible, to avoid those time-expensive shopping trips.

So the browser checks the expiration for the ingredients list, and then checks it’s kitchen (browser cache) to see if what’s there is stale or not. If the expiration date has not passed, the browser doesn’t need to download that ingredient, it just uses the one it already has, which is much faster.

Browser caching adds 'sell by' dates to website files for efficiency & freshness
Share on X

Sometimes in Google PageSpeed or other tools, you get this recommendation:

“Serve static assets with an efficient cache policy”

What this is saying is that, these ingredients had a short shelf-life, they go stale quickly so you’ll have to shop for them frequently and that’s inefficient.

So generally, it’s a good idea to have a far expiration date so that your browser doesn’t have to do the equivalent of run out to the store all the time for a new version of that file.

Read our guide on how to enable browser caching in WordPress.

What if I change a file and the browser cache rule hasn’t expired yet?

Very valid question! There is a mechanism for this process of letting the browser know “hey, you may have cached this file but I need you to fetch it again.” This is called “busting” the browser cache.

The browser can’t check the contents of the file to see if it’s different than the contents of the file it already has in its cache. But if it detects a different filename, it will assume the file is new and download it again.

On the website side, we can use query strings for this. You have probably seen file URLs like this:

https://example.com/wp-content/themes/astra-child/style.css?ver=4.0.3

The part at the end, after the ?, is called the query string.

By changing the query string, the browser will understand that this style.css file has been changed, and will therefore download the new version of it, even if the value of the browser cache rule hasn’t yet been met.

In this way, you can make sure that all new code changes are pushed out to all visitors and won’t depend upon visitors clearing their own browser cache.

How to disable browser caching in WordPress

Themes and plugins

You shouldn’t need to disable any browser caching in WordPress if the plugins you’re using are following best practices, or if you as a developer are doing so.

The issue people can have is that they make a change to, let’s say a CSS file, but they don’t see it reflected on the site because the old version is cached in their browser.

This will only happen if you haven’t correctly versioned your files. That means appending a query string which changes when you update the file.

For example, you change style.css?ver=1 to style.css?ver=2

It actually doesn’t matter what comes after the ?
The query string can be anything, as long as it’s different than before.

By doing that you are “busting the browser cache.” That means that the browser will recognize this is a new file and download again, letting you see your changes. If you continue to use the exact same file name the browser will not understand that there is new content, so it won’t download it again.

WordPress themes and plugins have this in place and most often the query strings are the version number which updates when the theme/plugin updates.

If you are creating your own custom theme make sure you edit the theme version number in your style.css when you make an update:

This will change the query string on the files, and all your changes will be available.

If for some reason you can’t get that to work, you could try the Cachebuster plugin. This is a very simple plugin that adds the file modification time as a query string to CSS and JS files. When the file is updated the query string will change, updating the cache of all site visitors.

Media files

Other files which could be browser cached are media files like images and pdfs. This can be trickier because they don’t have any query strings to version them, by default, and there isn’t a simple WordPress way to add and change them automatically.

In most cases you don’t update these kinds of files often. But if you need to update a file and don’t change the filename, you will run into a problem.

There is no great way to handle this in WordPress, to be honest.

Some people want to disable browser caching entirely for these file types by adding something like the following to their htaccess file:

<FilesMatch "\.(gif|jpe?g|png|webp)$"> 
<IfModule mod_headers.c> 
Header set Cache-Control "no-cache, no-store, must-revalidate, max-age=0" 
</IfModule> 
</FilesMatch>

However, that’s disabling browser caching for all those filetypes which is overkill in my opinion.

You could use a more specific rule to target a specific file, like this:

<IfModule mod_headers.c>
<FilesMatch "image.jpg">
FileETag None
Header unset ETag
Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires "Wed, 11 Jan 1984 05:00:00 GMT"
</FilesMatch>
</IfModule>

In the second line replace image.jpg with the filename you want to keep updated.

That’s still not ideal because there will be no browser caching for that file.

The best workaround would be to modify the filename.

In that case you would have to make sure you also update any links that point to it, to avoid a broken link. You can use the Enable Media Replace plugin to help with that.

If you are linking to a PDF you can add a query string to the file manually. To do that in the block editor, go to edit visually and manually edit the URL to add the query string:

How to clear your browser cache in WordPress

If you’ve followed along with the article so far, you’ll now realize that this question is a bit incorrect. As we’ve learned, the browser cache is not specific to WordPress.

The browser cache lives on each person’s device, so you can’t clear it from WordPress.

Each person has to clear their own browser cache on their own device. Here’s how to do it in the major browsers.

The Google PageSpeed recommendation to serve static assets with an efficient cache policy is all about browser caching. It’s usually pretty straightforward to fix on WordPress sites.

“Static assets” means the files on your site: CSS, JavaScript, images, fonts, videos (and other media files).

“Efficient cache policy” means that they have a long enough browser caching value so that they do not have to be downloaded by your site visitors frequently. Usually 4 months or longer is enough to satisfy Google and other tools.

This recommendation does not actually affect your overall score! It is a best practice to have a good browser caching policy for your site, but if it’s not “green” on your site, it won’t affect the score or Core Web Vitals.

I’ll let you know how to implement browser caching and how to troubleshoot issues.

How to set up the correct cache policy

You can only control the cache policy for files that are hosted on your own domain, or your CDN. You can’t control files coming from external domains, like Facebook, Google, Pinterest etc.

The rules are either set in the htaccess file of your site, or in the server configuration files. Most commonly they are set using “Expires” or “cache-control” rules. Either is fine.

It’s usually quite easy to apply the correct caching rules with one of the below methods. I’ve also provided a troubleshooting guide for common issues later on.

Your webhost

Most good webhosts apply browser caching automatically in the server configuration. If the values aren’t long enough, according to Google, you should be able to contact your host to have them adjusted.

A caching plugin

The easiest way to set this up is to use a caching or optimization plugin like WP Rocket, Flying Press etc. They add the necessary rules to the htaccess file for you. Of course, you’ll get tons more performance benefits from these plugins besides browser caching!

Manually edit htaccess file

If the two options above aren’t to your liking, you can manually add the caching rules to the htaccess file.

Copy/paste the following into your htaccess file to set the correct Expires rules:

# Expires headers (for better cache control)
<IfModule mod_expires.c>
ExpiresActive on
    ExpiresDefault                              "access plus 1 month"
    # cache.appcache needs re-requests in FF 3.6 (thanks Remy ~Introducing HTML5)
    ExpiresByType text/cache-manifest           "access plus 0 seconds"
    # Your document html
    ExpiresByType text/html                     "access plus 0 seconds"
    # Data
    ExpiresByType text/xml                      "access plus 0 seconds"
    ExpiresByType application/xml               "access plus 0 seconds"
    ExpiresByType application/json              "access plus 0 seconds"
    # Feed
    ExpiresByType application/rss+xml           "access plus 1 hour"
    ExpiresByType application/atom+xml          "access plus 1 hour"
    # Favicon (cannot be renamed)
    ExpiresByType image/x-icon                  "access plus 1 week"
    # Media: images, video, audio
    ExpiresByType image/gif                     "access plus 4 months"
    ExpiresByType image/png                     "access plus 4 months"
    ExpiresByType image/jpeg                    "access plus 4 months"
    ExpiresByType image/webp                    "access plus 4 months"
    ExpiresByType video/ogg                     "access plus 4 months"
    ExpiresByType audio/ogg                     "access plus 4 months"
    ExpiresByType video/mp4                     "access plus 4 months"
    ExpiresByType video/webm                    "access plus 4 months"
    ExpiresByType image/avif                    "access plus 4 months"
    ExpiresByType image/avif-sequence           "access plus 4 months"
    # HTC files  (css3pie)
    ExpiresByType text/x-component              "access plus 1 month"
    # Webfonts
    ExpiresByType font/ttf    "access plus 4 months"
    ExpiresByType font/otf    "access plus 4 months"
    ExpiresByType font/woff   "access plus 4 months"
    ExpiresByType font/woff2  "access plus 4 months"
    ExpiresByType image/svg+xml                 "access plus 4 months"
    ExpiresByType application/vnd.ms-fontobject "access plus 1 month"
    # CSS and JavaScript
    ExpiresByType text/css                      "access plus 1 year"
    ExpiresByType application/javascript        "access plus 1 year"
</IfModule>

For these rules to be correctly applied, your server needs to have the mod_expires module activated. It will already be activated on the vast majority of webhosts .

NGINX

If your site is on an NGINX server and therefore without an htaccess file, you need your webhost or server admin to modify the server configuration and add the necessary rules.

You can ask them to add the following:

location ~* \.(css|js|ico|gif|jpe?g|png|svg|eot|otf|woff|woff2|ttf|ogg|webp)$ {
	expires 1y; 
}

Troubleshooting

If you’ve followed the above steps but PageSpeed is still showing you a warning about the cache policy for your static assets, there are a few common issues you can check.

Check with your CDN

If you are using a CDN like BunnyCDN, Key CDN etc, to serve static assets, you may need to tweak your settings there. They may be using different cache expiration than what’s set at your host.

CDNs may also apply rules which can end up overriding what you set. So you either need to contact the CDN to have them adjust it, or see if they have a settings, something like “respect existing headers” which will take the rules set at your main server.

Cloudflare

If your site is on Cloudflare, you can adjust the Browser Cache TTL setting.

Go to: Caching → Configuration → Browser Cache TTL

Cache TTL is none

If the Cache TTL column lists “none” it means the server is not set up correctly and is likely missing the mod_expires module. You have to contact your webhost about this.

Cache TTL is different than expected

There’s a couple of reasons PageSpeed might detect a different value than the expected one.

If you have both cache-control and expires values defined differently, the cache-control value will take precedence:

cache-control is defined in seconds. So max-age=1333600 gives a value of about 15 days, which is what PageSpeed sees for this asset:

Check your htaccess file, if you have different values defined for the same file type, the rule that is furthest down in the file will take precedence.

If you would like to understand more about browser caching in WordPress, read our guide.

Addressing PageSpeed’s recommendation to Reduce Unused CSS improves your site’s overall score, along with the First Contentful Paint (FCP) and Largest Contentful Paint (LCP) metrics.

Removing unused CSS is closely tied with removing render-blocking resources, and the plugins available will often let you achieve both things at once:

1. Load only the exact CSS needed for any given page
2. Make sure that CSS is not render-blocking

Disclaimer: I do work with WP Rocket, one of the plugins mentioned here, so I know the most about that plugin. But I tested all of them and remain unbiased for the purpose of reviewing potential solutions. I don’t get paid to write these posts and don’t have a vested interest in promoting WP Rocket over others. I am a WordPress site owner first and foremost.

How does removing unused CSS work?

The fundamental function of the plugins is the same – the plugin looks through all the CSS on your site, determines what is actually used, and adds only that used CSS to each page.

There are typically 2 ways to add the used CSS to your page:

• Internal – in a <style> tag on the page, so the CSS is in the HTML. This is also referred to as “inline.”
• In an “external” CSS file, e.g. yourdomain.com/wp-content/themes/style.css
  
• In some cases, the additional unused CSS may be loaded after a user interaction. This will prevent the CSS from showing up as unused in a PageSpeed test, while also correcting any display/layout issues, on interaction.

There are pros and cons to these methods.

External CSS file

• Can be browser cached.
• Requires downloading an asset
• Smaller improvement to PageSpeed score

That means if you use the exact same CSS on multiple pages and your visitor goes to multiple pages, or if they visit the same page multiple times, they won’t have to re-download the file every time. The same CSS file could be stored in their browser and it will be faster for repeat visits.

Internal/inline CSS

• Can’t be browser cached.
• The size of the page’s HTML will be bigger
• Better PageSpeed score

Which method is better?

I have read other articles that tell you the inline method is inferior. I disagree because it gives better PageSpeed results and to the naked eye, there is usually no discernible difference in loading speed.

Inserting the CSS directly inline will increase the size of the HTML. But again, in most cases this makes no difference to performance or user experience.

If the plugin you’re using gives you a choice, make sure to test for yourself because in web performance many things vary from site to site – each one is unique and not all blanket recommendations will hold up.

Additionally, in some plugins you can choose to delay the CSS. This is safer because it means you may miss fewer styles, but in my experience it can cause jumpiness on interaction with the page,so the user experience might be a bit weird.

Factors that can affect how these features work on your site:

Everyone thinks their site is simple but most people don’t really understand what’s under the hood of their site. A few factors are:

• How much CSS there is on your site to begin with
• How much of the CSS depends on classes added by JavaScript. Sliders, animations, popups and other fancy features also rely on JavaScript and this can be harder for automated tools to detect.
• How well the site is coded – code that does not follow best practices and standards may have more conflicts when optimized.

This is a complicated optimization and it wouldn’t be unexpected to run into some issues and have to safelist some CSS selectors to fix the issues.

Plugins to Reduce Unused CSS in WordPress

The best solutions for reducing unused CSS are premium ones – that means plugins you have to pay for. But I have included a free one as well, in case you’re on a strict budget.

Testing process

I tested all the plugins below on the same handful sites, to get an idea of how they perform. This is a small sample size and doesn’t mean you will have the same results.

The sites varied from very lightweight, to heavier and messier ones.

In all cases I used just page caching, plus the CSS feature. So the goal wasn’t to get the maximum score by activating all features, but to see the impact of reducing CSS on the scores.

I considered the following criteria for each:

• Frontend result: Was the layout broken at all? Were there any quirks?
• PageSpeed: Did the score improve? Was the Reduce Unused CSS warning removed? Did the LCP and FCP metrics improve?
• User experience: How easy or difficult is it to work with and set up?

Premium Plugins to Reduce Unused CSS

WP Rocket

WP Rocket is premium-only caching an optimization plugin. It has many optimization features, and was one of the first to manage removing unused CSS in an automated way.

WP Rocket’s Remove Unused CSS feature will handle this for you.

On the File Optimization tab, select Optimize CSS Delivery, then choose Remove Unused CSS.

This feature will:

• Process each page on your site to determine only the used CSS.
• Then it inserts that CSS inline into a <style> tag on your page.
• No other CSS files will be loaded, and the inline CSS is not render-blocking
• Automatically preload fonts

The Load CSS Asynchronously feature will only make sure that the CSS is not render-blocking – it will not remove the unused rules, so it’s not relevant here.

Pros

• It’s the most accurate solution I’ve tested.
• It’s actively improved for compatibility with common themes/plugins
• It’s gives great PageSpeed results
• There is in-depth documentation and a way to fix issues
• Processing is done on an external server which means fixes can be applied immediately and all affected sites will benefit, without a plugin update.
• If you need help, you can contact the Support team.

Cons

• Due to the external processing, the feature isn’t applied instantly. It may take a couple of minutes for the first pages to be processed.
• Depending on your server, processing can take longer compared to other plugins.
• If you have a huge site with thousands of pages, it will take some time to process all of them.

Testing Notes

• Frontend result: this gave the most accurate layout of all the solutions I tested.
• PageSpeed: It most cases it produced the best score and LCP/FCP metrics and in all cases passed the reduced unused CSS audit most successfully.
• User experience: it’s easy to activate and you don’t have to choose from various options like the others, so it’s simple. The only confusing part can be that the feature isn’t applied instantly to all pages, so you may think it’s not working correctly, but you just need to wait a few more minutes.

WP Rocket automatically preloads fonts that are found when Remove Unused CSS is active. In a few cases, it might improve FCP/LCP to prevent that from happening. You can do so with a code snippet, found here.

FlyingPress

FlyingPress is another all-around caching and optimization plugin.

Whereas WP Rocket has a “decisions, not options” approach to the user interface and settings, FlyingPress offers more options. This is good for people who want to have more control, but makes things more complex for inexperienced users.

So in FlyingPress, when it comes to managing Remove Unused CSS you have 3 options:

• Asynchronously
• On user interaction
• Remove

You will see the best results from using either the On user interaction or Remove options.

The benefit of On user interaction is that display issues should be corrected on interaction. Whereas if the CSS is removed, you would have to manually fix that by excluding stylesheets or CSS selectors.

But the downside of On user interaction is that you might see some flashing, or jumping in the layout after you interact with the page and other styles kick in.

In most cases, the PageSpeed warning about reduce unused CSS was generally resolved. But in some cases, the Google Font CSS was still listed as render-blocking:

• Frontend result: If you use the Remove option, you may see a few unstyled, or incorrectly styled details. It was not always as accurate as WP Rocket. If you use, On user interaction you may see a little jumpiness when the styles kick in.
• PageSpeed: Scores improved, similar to Perfmatters, sometimes left a little render-blocking CSS and still a little unused CSS. LCP and FCP metrics improved and were competitive with WP Rocket and Perfmatters.
• User experience: Overall the user interface (UI) is pleasing but there’s no context given to which feature you should choose and no links to documentation. So it’s not necessarily the most user-friendly.

Pros

• Nice UI but not much guidance given
• Processes the pages pretty quickly
• Good PageSpeed results
• Overall a good option for managing CSS
• Provides support

Cons

• Options could be confusing to non-expert users
• Some documentation but it’s a bit limited

Perfmatters

Perfmatters is also a Premium-only plugin, heavily influenced by WP Rocket and FlyingPress, but differs from them because it’s not a full optimization plugin. The main difference is that Perfmatters doesn’t offer page caching.

So you can actually use Perfmatters at the same time as other caching plugins like WP Rocket. You just have to make sure not to activate duplicate optimizations in both plugins.

Go to Settings → Assets and scroll down to the CSS section:

Perfmatters offers the most methods for removing unused CSS. In the Used CSS method you have:

• Inline (the same as internal CSS)
• File

Then you also choose a stylesheet behavior:

• Delay (equivalent to FlyingPress’ On user interaction option)
• Async
• Remove

Perfmatters’ documentation states that the File method is:

the best for user and perceived performance as the file can be cached on repeat visits and reduces the size of the HTML doc.

But I did not find that to be the case. On the sites I tested, I got the best results from using Inline and either Remove or Delay.

But one size does not necessarily fit all, so you should see what works for your site.

There are exclusion fields for stylesheets and files in case you need to fix display issues.

• Frontend result – Overall the accuracy of removal was lower than either WP Rocket or Flying Press. To fix display issues you can use the Delay option but you may get jumpiness. The Remove options gives the smoothest user experience as long as you fix issues.
• PageSpeed – Metrics improved, but in some cases there was still some CSS reported as unused.
• User experience– I think there’s too many options which could be confusing for non-technical users.

Pros

• Works well, is effective in improving PageSpeed results
• Pretty good documentation

Cons

• Too many options to choose from – could be overwhelming for a beginner user.
• You’ll still need a caching plugin as well (unless your host provides server caching)

Free plugin to Reduce Unused CSS

I don’t really recommend free plugins for optimization because you may not get the support you need.

Unless you an expert, you are likely going to need help when some optimizations break something on your site.

Debloat

Debloat is a free plugin, available in the WordPress repository that specifically removes and optimizes CSS and JavaScript.

It is recommended to pair it with a caching plugin, but make sure that you don’t activate duplicate features in the caching plugin as well. I tested it in combination with WP Rocket’s page caching..

Testing Notes

• Frontend result: In the cases I tested it on, it was less accurate than the other plugins, except on the most straightforward site.
• PageSpeed: Sometimes the reduce unused CSS message was still there, although it was improved
• User experience: Pretty good – the UI provides decent guidance on the features. I couldn’t find any actual documentation though. Since it’s a free plugin, you shouldn’t expect much in the way of support. Their support page shows a lot of unanswered threads. So I’d only recommend this for more advanced site owners.

In general, you’re going to get improved results from any of the above solutions. If you are not a developer, choose a solution that will provide support should you run into any issues, and one that is proactively developing and improving.

The PageSpeed recommendation to “avoid an excessive DOM size” is a tricky one for WordPress site owners. There isn’t a plugin that can magically fix this for you. You, the site owner, will need to make some changes to your content.

Most of the articles you’ll find on this topic are going to go into the technical things to do which aren’t possible for non-developers. However, this guide is a practical one for WordPress site owners.

In this guide I will show you:

1. How to identify what’s causing DOM size problems on your pages
2. How to fix the problems.

If you’re trying to improve your PageSpeed score, also check out these other guides:

• Google PageSpeed Insights – A Guide for WordPress Users
• Reduce unused JavaScript in WordPress
• How to avoid enormous network payloads in WordPress

We’ll start with a little bit of technical stuff, because you have to have some idea of what PageSpeed is talking about here. But then we’ll get into practical steps you can take to fix it and look at some real world examples.

What’s the DOM and why does it matter?

DOM stands for Document Object Model. This is a tree-like map that represents all of the elements of HTML code on your page. The browser uses this map to build the web page that we actually see.

Every element, like an <img>, <div> or a <p> is a node in this structure.

If you’ve ever used “inspect element” in your browser, you’ve seen the DOM. The top half of the screenshot below shows a basic webpage. The lower half of the screenshot shows the Elements panel of the developer tools in Chrome and here we can see the DOM:

I’ve underlined the visible text in blue, and the 5 DOM elements that create it are indicated with red arrows.

This is a pretty simple structure, but later on we’ll see some complicated examples.

Whenever you add any content to your page, like a paragraph of text, or an image, it’s adding elements to the DOM. If your page was made only of basic text and simple images, DOM size probably wouldn’t be an issue.

Problems usually start to arise when more complicated features, like sliders for example, are added. Because these often require many DOM elements to contain the required code.

The more complicated and large the DOM structure is, the more intensive the processing the browser has to do to read and process it. That means it will take longer to show content to your visitor.

Therefore PageSpeed wants your page’s DOM to be a reasonable size, so that won’t slow down the page.

When does PageSpeed show the DOM size recommendation?

PageSpeed specifically checks the <body> element of your page.
It shows a warning when the <body> has more than 800 nodes/elements
It shows an error when there are more than 1,400 nodes/elements

PageSpeed also gives you the following info:
Maximum DOM depth – this is the longest sequence of nested elements on the page, in other words the distance from a given element to the root element of the page.

Maximum child elements – this is the element that contains the highest number of child elements in the DOM, on the page

But, don’t get too caught up in those 2 numbers, they aren’t necessarily the most helpful in actually troubleshooting your page.

Reducing the overall number of elements is the goal.

What adds to the DOM size on WordPress sites?

Anything that adds code to your page can add to the DOM size. In WordPress this means:

1. Your theme
2. Your plugins
3. Your content

Although you may not be writing the code directly, you do still have a lot of control over the DOM size with the choices you make, as we’ll see below.

How to find the biggest contributors to DOM size on your site

I recommend using the DOM Size Analyzer Chrome extension to help you find the sources of excessive DOM size.

1. Add the extension to your browser.
2. Navigate to the page on your site that you want to improve
3. Right click and choose Inspect
4. Find the tab named Analyze DOM Size
5. Click the Play button
   This analyzes the page and gives you the total number of DOM elements. Below that it displays the elements of the DOM tree, each with the number of nodes.
6. Since HTML is nested, you have to click into elements to find the sections that match your content.
   Keep clicking on the element with the largest number until you get into more specific parts of the content
   Find the row with the largest number of descendants:
7. As you click into elements, you will see that the corresponding part of the page becomes highlighted, as you mouse over them (see gif below)
8. This will allow you to see exactly which parts of the page are contributing the most to the DOM bloat.
9. Once you have that info you can either remove that element, or reduce its footprint: reduce the number of images, reduce number of featured items, reduce number of slides etc.

Practical tips and examples for site owners

Avoid page builders

Page builders like Elementor and WP Bakery are notorious for being inefficiently coded. They output messy HTML with tons of nested elements (sometimes referred to as “div soup”), often triggering the PageSpeed warning.

The goal of page builders is to make it easy for you build complicated pages, and maintaining best practices when trying to provide a huge number of easy-to-use features, is challenging.

Here’s an example:

This image looks simple enough. It’s not part of a slider or anything fancy, it’s just a basic image. It shouldn’t generate too many DOM elements normally.

But, when we check the DOM, look at the amount of nesting it takes to get to that image:

Even if you are not familiar with code, you can see the slope of the indentation in the code – the longer the slope, the more nested elements there are. That’s an example of overly complicated and bloated code.

This is because the site owner used an additional plugin and a parallax section to add basic image and text.

Takeaways:

• Always use the simplest method you can to build your pages.
• Switch to simpler themes like GeneratePress, Astra, etc.
• Avoid page builders

But your theme or page builder by itself is not the whole story.

Reduce menu items, avoid mega menus

Huge navigation menus, like mega menus, will add many more DOM elements.

A mega menu, or uber menu, looks like the example below. It generally contains many navigation links, usually organized in columns, and may also contain images and icons:

They may look nice and may seem like a good way to include many links to your content, but they come with a cost.

This UberMenu widget contains 450 DOM elements! That’s more than 50% of the “budget” for the whole page!

Even if you don’t use a mega menu, but you create many items with a lot of drop-downs, you will still be adding quite a lot of DOM elements.

Reduce rows of products and other featured items

Ecommerce sites are often amongst the worst offenders when it comes to DOM size. They tend to use many rows of featured products, which bloat the DOM.

This single product carousel has 353 elements:

If that was the only one on the page, that might be OK.

But on this site there are multiple rows of product carousels:

So those hundreds of elements really add up!

This could apply to any type of row, it doesn’t have to be products specifically. It could be portfolio items, blog posts etc.

Use simple images instead of animated carousels or sliders.

This product row which is just images, has only 48 elements:

Takeaways

• Reduce the number of rows
• Reduce the number of products or items per row
• Use simple images instead of animated carousels

Don’t overuse tabs and accordions

Tabs, accordions, toggles – these are a good way to include more content on your page without the need for a lot of scrolling.

But you should be aware that even if your visitor doesn’t see all of the content at once, it’s still present in the DOM. So if each tab has a ton of content in it, this can still bloat the DOM.

In the example below, there’s 246 DOM elements hiding behind those tabs:

Don’t use CSS to hide content

Some themes and plugins will use CSS to hide content, for example to control which content shows on desktop vs. mobile.

This is a relatively easy and convenient way to handle different content for different devices, but the problem is that the “hidden” elements are still present in the DOM. So if you use this method too much, it could bloat the DOM too much.

For example, take a look at what Elementor does – it uses CSS to hide elements not intended for desktop:

Depending on how many elements each one has and how many hidden sections there are, that could contribute to the unnecessary size.

Streamline your pages

Whether or not your theme and plugins output messy or clean code, you will always make things worse if you load up your pages with tons of unnecessary content.

Some site owners throw a lot of content on the page, especially the homepage because they want to showcase everything they’ve got and they don’t make choices.

The longer your page is, the more content you add to it, the bigger the DOM size will be.

But this will only overwhelm your visitor.

Creating shorter, more focused pages will improve the DOM size and will also help your visitor.

Here are a few examples of content choices you can make, to reduce the DOM:

• Consider using simple, static images instead of sliders.
• If you must use a slider, don’t add a ton of images. 10 slides will add more DOM elements than 3 slides.
• Avoid adding multiple sliders or multiple interactive elements on the same page.
• If you have an image or video gallery, add the minimum number of items that you can.
• If you have a blog grid or list, limit the number of blog posts you’re showing and use pagination to display more.
• Avoid the temptation to use every fancy feature that your page builder or theme provides. Parallax elements, carousels, animations, toggles, galleries etc will increase the DOM more than basic content, so be mindful of what you add to your page.

WordPress Duotone SVGs

This is what I would call a micro-optimization.

WordPress adds some SVGs that are used for the Duotone filter feature:

These amount to about 80 DOM elements. Not huge, and not your starting point if your DOM size is massive. But if you really want to fine tune, you could remove these.

Just be sure your site isn’t actually using these styles :)

These DOM elements can be removed using the “Remove Global Styles” feature in the Perfmatters plugin (affiliate link).

Technical tips for developers

If you are a developer and have access to the HTML of a site, or are building a theme, consider these recommendations.

Make CSS as concise as possible – don’t use inline styles.

Here you can see multiple inline styles – these nodes could be removed and the CSS added to one stylesheet, then also reused throughout the site.

Use modern CSS

• Using layout models like Flexbox or Grid will enable you to create more efficient layouts compared to using older methods like tables or floating divs.
• Use CSS Pseudo-elements**: ::before and ::after can be used to add decorative elements without adding extra DOM elements.

Use content-visibility

Above I showed the example of CSS display:none being used to hide elements for mobile and desktop.

Consider using content-visibility instead. Using a value of hidden is similar to display:none

And using auto will provide a kind of “lazy load” for HTML elements. WordPress plugins like LiteSpeed Cache and FlyingPress offer this so-called lazy rendering of HTML elements by using content-visibility.

When searching for ways to reduce the DOM size, you may come across some articles which claim that lazy rendering HTML does this. It does not.

The DOM elements are still present in the page, so the DOM size is not reduced. But it does improve the render time, thereby offsetting the performance issues of a large DOM.

So you may still see the warning in PageSpeed, but the loading metrics should be better.

Use clean, semantic HTML

When you use the correct HTML tags as they are intended, your code will be leaner and reduce the need for additional elements.

In this example you can see that each line item is its own list.

Instead of making one list with several sub-items, this would have been more efficient and reduced the number of elements.

Minimize the use of JavaScript

There are tons of performance issues with JavaScript.

As far as DOM size goes, JavaScript can be problematic because it can add a lot of DOM elements. So if you can implement a feature in CSS instead of JavaScript, do that!