PageSpeed is a useful tool for certain metrics but it lacks some specific details.
Using a tool that shows you a waterfall chart can give you a different angle on performance. GTMetrix, Webpagetest.org and DebugBear are examples of tools that provide a waterfall chart.

What’s a waterfall chart?

The waterfall chart shows a list of every file that your website loads, in the order that those requests are made.

So it pulls back the curtain and gives you a peek at what’s going on behind the scenes when someone visits your site in their browser. It helps you find bottlenecks, errors and other performance issues.

Note, you can get a lot of this info in your browser’s developer tools as well, but using a speed testing service can be more user-friendly and also give you even more details. For example, when using a speed tool, you’ll be able to check from different locations and devices.

Here’s 10 useful things you can learn when running a speed test using a waterfall chart.

1. What’s the Time To First Byte (TTFB)?
2. Is the visit cached?
3. How many files are loading?
4. Are critical files loaded early?
5. Are files served from your CDN?
6. Is browser caching applied?
7. Is compression applied?
8. Are there any loading errors on files?
9. The impact of 3rd party content
10. Are there any unnecessary redirects?

What’s the Time To First Byte (TTFB)?

The very first request in the chart represents the server response time. If this is slow, it will affect everything that comes after it, so this metric is critical.

The very first line shows which URL is being tested. / means I’m testing the homepage. Under 500ms is ideal. In this case the request takes 373ms which is good.

Compare that to the uncached version of the page, and you can see what a difference page caching makes in TTFB. It takes 1.1s in this result – 3 times longer.

So sometimes you can see at a glance whether the page is cached or not, but in the next tip we can check more specifically.

Is the visit cached?

There’s a couple of ways to check this.

The first is similar to the above step: Run the URL twice, once normally and once with ?nocache appended to the URL (which in most cases will bypass any server or plugin cache). If the page is cached, the TTFB will be much faster on the normal URL compared to the ?nocache URL.

The second way to check is by looking at the headers on the request to see if any server cache indicators are present. Some cache plugins may also add headers but others (like WP Rocket ) don’t, so this is not a reliable way to see if your caching plugin is working, but can be used to check if a server cache is applied.

In GT Metrix, to check the headers, click on the request to expand it and reveal the Headers tab.
Here we can see that this site is cached by Cloudflare:

This site’s server has a server cache, but it wasn’t used on this response, as we can see by the MISS on the x-proxy-cache header.

Almost all CDN/server caches have some sort of custom header to show this information – you can check their documentation for the specific details.

If it’s not cached you’ll typically see MISS or BYPASSED.

How many files are loading?

A lot of people think “I have a simple site, it shouldn’t be slow” but they don’t realize how bloated or chunky their page is.

While file count is not the be all and end all of performance, having a realistic look at what’s actually loading on the page can be eye-opening. Perhaps your “simple” page isn’t that simple after all.

In GTMetrix, the overall size is at the bottom of the waterfall:

Generally speaking, fewer files are better. Of course there are exceptions – one massive JavaScript file that runs complicated functions might tank your site more than 10 tiny images. But outside of exceptions, fewer files are better.

Are critical files loaded early enough?

Requests related to your Largest Contentful Paint element, such as the main image, or the font if your LCP is text, should show up in the waterfall at or near the top.

Here you can see the difference between a preloaded image and a non-preloaded image:

In the first screenshot, the LCP image is preloaded and is therefore the second request in the list. In the second screenshot, the LCP image is not preloaded and is found near the bottom of the waterfall.

If the LCP element isn’t loaded until late in the waterfall, this is likely to adversely affect the LCP metric.

DebugBear’s free website test tool is very useful for checking this because it labels the LCP element, preloaded elements and requests with fetchpriority=high:

Is a file served from your CDN?

There’s a couple of ways to check this depending on what kind of CDN you use.

If you use a pull CDN like Bunny CDN, the file will be loaded from their domain, or a custom domain you set up. In that case, it’s easy to check the domain column for that. In the below screenshot, keyloop.b-cdn.net is the CDN domain serving the assets:

However, if you are using a CDN like Cloudflare or similar where you’ve pointed your DNS to it and all the files use your own domain name, you can check by looking at the headers on a specific file. In this case, the CSS file is served from Cloudflare:

The headers will also help you to see if the file has been cached at a specific CDN PoP (Point of Presence, the location of the server it was served from) as well.

Click on the file you’re interested in and check for a cache header and HIT. The server header shows exactly which PoP it came from.

Is browser caching applied?

Click on a specific file and check the headers. Browser caching can be applied in a couple of different ways. Generally you should see a cache-control or expires header. You may see etag although that tends to be a bit less common.

The max-age number is in seconds. If the value is too small, less than a few months, most testing tools will flag it in the browser caching section of their recommendations.

Is compression applied?

Again check the headers of a specific file and look for content-encoding.

You should see either br (for Brotli), gzip or, zstd. These are different forms of compression. As long as one of them is applied, you’re all set.

Loading errors on files

Check the status column for this. Files that are responding correctly, without an error or redirect will have a 200 response.

Other response codes will likely require further investigation. The most common error you might see in a waterfall is a 404. That means the file does not exist.

In some cases 404 errors might take a long time for the server to resolve, or could block other files coming later.

So addressing any errors will help overall speed as well as prevent a poor user experience due to missing content etc

3rd party content

3rd party content refers to files that are hosted from another domain, that is not your own. Common examples are tracking scripts, Google tag manager, Facebook scripts, etc They are bad for a few reasons:

• Connecting to an external domain adds extra time
• They often result in request chains – that is, the first file brings in another file and so on. This leads to a cascade of files being shoved into your site which take time and processing power to load.
• If anything goes wrong with the external server it’s possible for that failure to load the file to block any file that should come after it and prevent your site from working correctly.
• You don’t control the file so if the 3rd party does not add browser caching, compression etc, it will bring down your scores and you can’t usually fix it.

Scanning the domain list will quickly show you where files are loading from. In the screenshot below you can see that there are numerous files related to klaviyo which are chained from the initial file klaviyo.js at the top of the screenshot:

Redirects

Redirects are bad for performance because they add extra time to get to the final destination. If a browser requests a file and it gets redirected from one URL to another, it will take longer to retrieve and download that file.

Checking the waterfall will reveal such redirects.
Look for a 301 or 302 response in the status column.

In this example, cat1.jpg is redirecting to cat.jpg. The redirect takes one second, which is wasted time. It also pushes the real image to be loaded later on in the list. So, bad news all around. Avoid redirects unless absolutely necessary.

This list does not represent an exhaustive list of all that can be learned from a waterfall, but it covers the most common and useful cases.

The LCP Request Discovery recommendation in PageSpeed helps you to improve the Largest Contentful Paint (LCP) metric on your page.

The LCP element is the biggest piece of content above the fold on your page. It could be an image, a piece of text or a video. In PageSpeed, the request discovery audit is related to images.

When your LCP element is an image, PageSpeed has 3 criteria:

1. The image should not be LazyLoaded
2. fetchpriority=high should be applied to the image tag
3. The request for the image should be found directly in the HTML (not in a separate CSS file).

Let’s examine these in more detail.

The image should not be LazyLoaded

This might feel counter-intuitive at first because we’re always told to use LazyLoading to improve the performance of our images. But LazyLoad essentially holds off on loading images until the user scrolls to that point in the page. Because the LCP image is above-the-fold and should be visible to the user right away, it needs to load immediately. So it should be excluded from LazyLoad.

If you’re using an optimization plugin, this might be done for you as part of a specific feature, like WP Rocket’s Optimize Critical Images.

Otherwise you should manually exclude your LCP image from being LazyLoaded.

“fetchpriority=high” should be used

fetchpriority=high is a message to the browser, telling it that this file is important and should be downloaded ahead of other files that are less important and have a lower priority.

Applying this directive to the LCP image or its preload request will satisfy PageSpeed.

It looks like this when applied:

Image code

Preload code

WordPress already adds this to the relevant images automatically, as of version 6.3, so you likely don’t have to worry about this on your images.

But if you are manually adding preload requests to your code, you should make sure to include fetchpriority="high" .

If you’re using Perfmatters, you can configure that in the Preloading settings:

The image request should be discoverable in initial document

The initial document means the HTML of your page, i.e what you see when you go to View Source in your browser.

The most common case for the image request not being in the HTML is because you’re using a background image on an element, where the background image URL is defined in a CSS file.

It’ll look something like this:

In the above case, the cat image is set as the background image for a specific block, and is specified in the bgcss.css file. This means the browser has to do some hunting to find this important image.

In this case the image must be preloaded to satisfy PageSpeed and ensure that the browser can quickly download the image.

Now, just because your image is found directly in the HTML, that doesn’t mean it’s fully optimized for LCP.

Preloading your LCP image is one of the most impactful changes you can make, even if your image is already directly in the HTML.

The above methods will satisfy PageSpeed’s recommendation to fix the LCP request discovery, but your LCP optimization shouldn’t stop there.

Removing render-blocking CSS and JavaScript, as well as using a CDN and having a fast TTFB will all contribute to a fast LCP.

In the Site Health section of your WordPress site you might see the warning:
Autoloaded options could affect performance

This is related to the options that themes and plugins request on every page load of your site. If there are too many, it will slow down the load time of the page. The Site Health warning triggers when the options are above 800kb.

What problem does too many autoloaded options cause?

To simplify, the more options that are autoloaded, the bigger the database request becomes. The bigger the request, the slower your page will load.

This problem will primarily affect backend and uncached pages. When a page is cached there won’t be any database calls so this problem won’t be noticeable.

But on important pages that can’t be cached, like cart and checkout pages, if database queries are slow, it can affect the overall load time. If you have a high traffic site, the problem will compound. A slow server response time leads to other metrics like LCP being slower and this will affect your site’s Core Web Vitals.

It can also affect the backend performance and you’ll notice a sluggish experience.

Using object caching, like Redis, can help mitigate such issues, but it’s better to address the problem at the source.

How to fix too many autoloaded options?

To fix this recommendation you’ll need a database clean-up plugin. In this article we’ll look at two tools you can use:

• For beginners: AAA Option Optimizer
• For more advanced/power users: Advanced Database Cleaner

AAA Option Optimizer is a bit more user-friendly compared to Advanced Database Cleaner which has a lot more features and a less intuitive interface.

I’ll show you how to use both.

Guidelines before you get started

It’s important to know that autoloading options isn’t inherently bad, and the goal isn’t to have zero autoloaded options.

The goal here is to restore balance, and have a sensible amount of autoloading, and only for those plugins/themes that are actually in use.

Felix Arntz has a great article about the ins and outs of it. If you want a deeper, more technical understanding of the topic, I recommend reading his guide.

So what should be autoloaded?

Common wisdom is that the following can and should be autoloaded:

• Core WordPress options
• Your active theme’s options
• Active plugins’ options – which are used on most/all page loads

What should not be autoloaded?

As you go through the process, you’ll probably find that a lot of options are being loaded which are associated with deactivated or deleted plugins and themes, and these are low-hanging fruit to clean up.

Since you’ll be working with the database, it’s best practice to make a backup first, just in case.

AAA Option Optimizer

The reason I like this plugin for beginners is that it is focused specifically on fixing autoloaded options, nothing else, and the interface is easier to manage than Advanced Database Cleaner.

After installing the plugin, its author recommends that you click around your site and load some pages, both frontend and backend pages. This allows the plugin to try and detect which options are being used and which aren’t.

After that, go to Tools > Option Optimizer to find the plugin settings.

You’ll mostly be concerned with the Unused, but autoloaded tab.
Click on the size column to sort it with the largest entries first.

Now you have to review the options and try to confirm if they should be autoloaded or not. Since the plugin has determined they are unused, your job is to double-check that.

How to check which theme or plugin an option belongs to

The Source column will let you know where the option is coming from – WordPress core, or from a theme or plugin.

However, you will likely see a lot of “unknown” which makes things a little trickier.

Sometimes the name of the option will obviously indicate its source, e.g. rank-math-options-titles is clearly from the Rank Math plugin.

But others may be less obvious. In that case, there are a few things you can try:

Click show to see the contents of the option

Seeing what’s saved in the option will give you further clues. I checked woo_template which I wasn’t sure if it was related to WooCommerce. In the options I can see it’s coming from an ancient theme that I no longer have installed on the site:

In this case I’d delete the data instead of just preventing the autoload.

Google the option name

A simple Google search will often let you know what the option name is related to.

Use String Locator to search your site

Use a plugin like String Locator to search for the option name – you will likely find it in some plugin files.

In the screenshot below, I searched for an option I found called ssa_settings_json and found it within the Simply Schedule Appointments plugin:

Based on whether or not that plugin is currently active on my site, I would either keep it autoloaded if it’s active, or unload it otherwise.

Advanced DB Cleaner

This plugin does more than let you manage autoloaded options, so the various settings might be overwhelming for a beginner. But it’s a great plugin for cleaning up various parts of your database.

To work on autoloaded options, click on Options from its menu.

You’ll probably see the Autoload size warning here and you can click Filter to see the list sorted by the largest items.

Unfortunately in the free version it won’t detect which theme/plugins options are associated with. You would need the Pro version for that. So you can use the steps provided above to determine which plugins/themes the options are associated with

To either delete the data or turn the autoload off, click the 3 dots at the right and make your selection.

Advanced Database Cleaner will let you know when your autoloaded options are back at a sensible level:

If you don’t change your theme and plugins on your site, you shouldn’t have to go through this process too often.

But it could be useful to review it after installing/removing plugins or switching your theme, to avoid outdated data building up.

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.