There are two blocks listed in the block inserter for dates: Date and Modified Date. (Previously these block names started with “Post” but these were removed in WordPress 6.4.) In reality, these two blocks are just variations of the one Date block. You could turn a Date block into a Modified Date block by enabling this block setting:

With block bindings in WordPress 6.9, the Date block became further abstracted to be able to represent any date, not just a post’s publish date or modified date. When a Date block is inserted, you can now decide to bind the block to either of these dates:

The key word there is “either”. The setting I was looking for was missing: the ability to display the publish date and the modified date (if it differs).

I did find Gutenberg issue #53099 opened by Carolina Nymark where she was reporting that it was confusing that the old “display modified date” toggle actually causes the modified date to be displayed instead of the publish date:

The info I was looking for was whether, when toggled on, it would display both the published and modified dates, or display the modified date instead of the published date, as from the settings alone it’s not immediately clear

Commenting on that issue, Ronnie Burt said:

Feedback after using this block on multiple sites in templates for both posts and pages. The ‘modified date’ block doesn’t show anything if the post has never been updated. This makes it really challenging to use, as there will be a blank spot on the front end for new posts or pages without any edits.

It would be more useful to show the date published if the post has no edits.

Carolina responded:

The problem is that there is no one scenario that will work for all use cases. Some users and designs wants to display both the original publishing date and the modified date. So no matter how this block is updated, it will break for someone.

Your best option may be to register a block binding with a callback function that displays the post date, to get the exact conditions that you need, and then insert a paragraph with this block binding, instead of using the post date block.

A few months later, when I discovered the issue, I commented:

To me it seems like the block should facilitate showing the published date and then also show the modified date if it is different, with a prefix like “Updated: ” or some other parenthetical treatment. I don’t think the modified date should ever take over the published date. I’m not sure the best way to achieve that other than by adding a plugin which filters the Date block to append the desired content. I’m not sure how that could be handled in the UI, given we’re dealing with inline content and there is no ability to hide blocks (cf. #50756), and there’d have to be a condition like “Only show this block if the rendered date/time of the published date is not the same as the rendered date/time of the modified date.”

So this is what I wanted, but the Date block didn’t support it. So I started exploring something that would implement my desired use case.

Accounting for all the different scenarios adds complexity to the block. Rendering a single publish date or modified date is simple enough. But if the modified date needs to be displayed conditionally then how is this configured in the editor? Namely, if both dates are displayed, then one or both of the dates would need to have some prefix indicating what the date refers to. The two configurations I had in mind were prefixing the modified date only:

December 25, 2025 (Modified: January 1, 2026)

Or else putting each on a separate line and having prefixes for each:

Published: December 25, 2025
Modified: January 1, 2026

There is an existing Gutenberg issue #61920 which is about adding prefixes and suffixes to the block similarly to the Categories block. But these prefixes are unconditional for only a single date. I wanted these prefixes added conditionally for when the modified date is displayed in addition to the published date.

A New Plugin

Ultimately, I put together a plugin to implement what I wanted: Post Date Block: Published & Modified. It’s currently on GitHub but I’ve also submitted it to the WordPress.org directory.

Update: It’s now live on plugin directory!

Once active, when you are editing the settings for the Date block for the Post Date variation, a new “With Modified Date” panel appears. Inside that panel there is a new toggle:

Show modified date when different from published date

The two dates are rendered in the supplied date format, and only if they then differ will the modified date be displayed after the published date. This prevents the modified date from appearing as a duplicate when the post is updated on the same day it was published.

When that toggle is enabled, two new sets of fields are presented for adding a prefix and suffix to both the published date and the modified date. There is also a toggle for whether the modified date should be displayed on a separate line. Here are the settings for the two configurations I mentioned previously, one where the modified date is displayed on a separate line and another where it is displayed on the same line:

In terms of the frontend rendering, here’s what the Date markup looks like right after publishing on Christmas:

<div class="wp-block-post-date">
	<time datetime="2025-12-25T18:14:21-08:00">
		December 25, 2025
	</time>
</div>

And here is how the block is rendered after having been modified on New Year’s Day, in the two-line configuration:

<div class="wp-block-post-date post-date-modified">
	Published:
	<time class="entry-date published" datetime="2025-12-25T18:14:21-08:00">
		December 25, 2025
	</time>
	<br>
	<span class="modified">
		Modified:
		<time class="updated" datetime="2026-01-01T21:20:05-08:00">
			January 1, 2026
		</time>
	</span>
</div>

Note the added microformat classes to disambiguate the published date from the modified date. I was really happy to be able to leverage the HTML Tag Processor to handle insertion of the prefixes, suffixes, newline, and class names!

This plugin solves my use case, but it’s primarily a prototype/stopgap until something lands in core. The user experience for this doesn’t feel ideal, but I can’t think of a better option at the moment. Note also that there is currently no preview in the editor, so you have to save the changes and go to the frontend to see the results. (My Customizer self weeps.) I didn’t want to fork the Date block’s edit function to implement full preview in the editor, and it would be of little value anyway since when editing a block template the Date block now just shows ”Invalid date” anyway due to there being no post context for the block binding.

The Future

The ideal solution perhaps would involve Bits (now Shortblocks). Maybe the default view for a Post Date block when editing a block template would be to show the view when the modified date is the same as the published date. But then there could potentially be a popover that could allow configuring how the block should render when the modified date is different. With Shortblocks, these tokens could be inserted inline with the content and moved around inside of a paragraph block. This would avoid the need to supply a suffix/prefix in the detached block settings sidebar.

In the meantime, I hope my plugin is helpful for keeping your readers updated!

Where I’ve posted about this:

• LinkedIn
• Bluesky
• Threads
• Mastodon
• Twitter

The post Post Date Block: Published & Modified appeared first on Weston Ruter.

An angel of the Lord appeared to Joseph in a dream and said, “Rise, take the child and his mother, and flee to Egypt, and remain there until I tell you, for Herod is about to search for the child, to destroy him.” And he rose and took the child and his mother by night and departed to Egypt and remained there until the death of Herod.

Matthew 2:13b-15a (ESV)

What if Jesus had been born today instead? Would his family have found refuge in America? (I’m no immigration lawyer, so I’ve relied on Gemini to help navigate the complicated system.) Given their dire and urgent situation, they wouldn’t have been able to apply for an immigrant visa through the Green Card Lottery, which is a years-long process. They also wouldn’t have been able to enter under a refugee program, since that also involves a long process with an extensive vetting pipeline before they would have been possibly admitted as refugees. They also wouldn’t have been able to use Humanitarian Parole, since that is also a slow process. So for legal entry, a tourist visa seems like the only viable pathway.

If they were modern Israeli citizens, there is the Electronic System for Travel Authorization (ESTA) which allows for approval within 72 hours.

On the other hand, if they were Palestinians (as Bethlehem is in Palestine), there is no such 72-hour approval for flight. They’d have to get a visa interview. But, because of Presidential Proclamation 10998 (Restricting and Limiting the Entry of Foreign Nationals) which takes effect on January 1st, 2026:

the United States is suspending or limiting entry and visa issuance to nationals of 39 countries as well as individuals applying using travel documents issued or endorsed by the Palestinian Authority.

So in this case of being Palestinian Authority passport holders, they’d effectively be banned.

Let’s say they were fortunate to have the freedom of travel as Israeli citizens; this still wouldn’t necessarily help them. If they came as tourists due to the urgency, but then claimed asylum upon entering, they would be arrested and detained. One of the few groups currently being admitted into the USA as refugees is the white Afrikaners from South Africa. Recently, one such Afrikaner flew to the US and then requested asylum. Since he didn’t go through the refugee program, he was put into handcuffs and sent to a federal detention facility where he has been for months now.

So the only viable option I see for Mary and Joseph is to fly to the US and enter with an ESTA tourist visa under false pretenses. Since their stay in America under a tourist visa would be for an indeterminate length, this is technically visa fraud. Even if they intend to return to Judea once the threat has passed, they wouldn’t have known how long that would be. Under ESTA, there is a strict 90-day limit on the length of time that the visitor can remain in the USA. We don’t know how long Herod the Great lived specifically after they escaped, but it was probably at least 90 days or maybe even up to a couple of years. If they fled to America under ESTA, they would have overstayed their tourist visa. They would have become undocumented immigrants. They would be illegal aliens. (Jesus would be a Dreamer.)

The current administration is aggressively pursuing the deportation of undocumented immigrants, but it is also cutting the legal pathways for immigrants (e.g. Temporary Protected Status), making them also at risk for deportation. When the Refugee Act of 1980 was passed, there was an initial baseline of 50,000 refugees allowed into the country per year (with the actual number admitted being much higher). Under the current administration, the yearly cap has been reduced to an all-time low of 7,500 refugees. Furthermore, by executive order, most of these are to “primarily be allocated among Afrikaners from South Africa” (as also noted above). So even if Mary and Joseph had fled to a third country and applied with the U.S. Refugee Admissions Program, they would have no feasible chance of being accepted since they are not Afrikaners. These Jews would not be accepted as refugees.

What is particularly striking to me about the dismantling of the refugee program is that it exists today in part because of a modern persecution of Jews by Nazi Germany. In 1939, a German ocean liner named the MS St. Louis sailed to the Americas with nearly a thousand Jewish refugees on board. It attempted to dock in America but was denied (after first being denied in Cuba and later denied by Canada). The ship was forced to return to Europe where tragically over a quarter of the passengers were killed in the Holocaust. After the war, moral outrage over the Holocaust led to the US passing the Displaced Persons Act of 1948 (with its key amendment in 1950) to allow refugees to enter the country. Three decades later, the more comprehensive Refugee Act of 1980 was passed:

The Act created a uniform and comprehensive policy to proactively address refugee admissions by:

• Removing the geographic and ideological limits on the definition of “refugee” that had been introduced by the 1965 Amendments to the INA. The new law formally adopted the United Nations’ definition.
• Providing the first statutory basis for asylum.
• Increasing the number of refugees who could be admitted annually.
• Creating the Office of Refugee Resettlement to oversee resettlement programs.

Under the Act, the president, in consultation with Congress, sets the annual number of refugee admissions and the allocation of these admissions to refugees coming from various parts of [the] world.

According to former Deputy Secretary of State William J. Burns, tragedies like that of the MS St. Louis prompted the international community to take action to protect refugees. Additionally:

A photo of the M.S. Saint Louis hangs in the front office of the State Department’s refugee bureau as a powerful reminder and source of motivation. Our actions since the Saint Louis, we hope, speak more eloquently than any words could to our dedication and commitment to shelter and to protect.

However, it seems our dedication and commitment in the United States is dwindling. I asked Gemini to create a graph of the actual number of refugees admitted per year since 1948:

import pandas as pd
import matplotlib.pyplot as plt

# Data Construction based on search results and historical summaries
data = {
    # Early Acts and Ad-hoc (estimates and rounded historical totals)
    1948: 813, 1949: 100000, 1950: 100000, 1951: 100000, 1952: 93000,
    1953: 53000, 1954: 53000, 1955: 53000, 1956: 55000, # Hungarian Revolution surge
    1957: 56000, 1958: 15000, 1959: 20000, 1960: 25000, # Start of Cuban wave
    1961: 50000, 1962: 55000, 1963: 50000, 1964: 45000, 1965: 40000, # Freedom Flights / Cuban program
    1966: 30000, 1967: 35000, 1968: 40000, 1969: 45000, 1970: 48000,
    1971: 45000, 1972: 40000, 1973: 35000, 1974: 30000,
    # Standardized Reporting era starts with 1975 data from RPC
    1975: 146304, 1976: 27206, 1977: 19946, 1978: 36507, 1979: 111363,
    # Official DHS Yearbook Table 13 (Refugee Act of 1980 era)
    1980: 207120, 1981: 159250, 1982: 98100, 1983: 61220, 1984: 70390, 1985: 67700,
    1986: 62150, 1987: 64530, 1988: 76480, 1989: 107070, 1990: 122070, 1991: 113390,
    1992: 115550, 1993: 114180, 1994: 111680, 1995: 98970, 1996: 75420, 1997: 69650,
    1998: 76710, 1999: 85290, 2000: 72170, 2001: 68920, 2002: 26790, 2003: 28290,
    2004: 52840, 2005: 53740, 2006: 41090, 2007: 48220, 2008: 60110, 2009: 74600,
    2010: 73290, 2011: 56380, 2012: 58180, 2013: 69910, 2014: 69980, 2015: 69920,
    2016: 84990, 2017: 53690, 2018: 22410, 2019: 29920, 2020: 11840, 2021: 11450,
    2022: 25520, 2023: 60050, 2024: 100060,
    # 2025 estimate based on Q1 data and suspension in Jan 2025
    2025: 27500,
    # The current refugee cap (allocated primarily to Afrikaners).
    2026: 7500
}

df = pd.DataFrame(list(data.items()), columns=['Year', 'Admissions'])
df.to_csv('actual_refugee_admissions_1948_2025.csv', index=False)

# Plotting
plt.figure(figsize=(14, 7))
plt.plot(df['Year'], df['Admissions'], marker='s', linestyle='-', color='teal', markersize=3, label='Actual Admissions')
plt.fill_between(df['Year'], df['Admissions'], color='teal', alpha=0.2)

# Specific Event Vertical Lines
plt.axvline(x=1980, color='red', linestyle='--', alpha=0.5, label='Refugee Act of 1980')
plt.axvline(x=1975, color='orange', linestyle=':', alpha=0.6, label='Fall of Saigon (1975)')
plt.axvline(x=2001, color='gray', linestyle=':', alpha=0.6, label='9/11 (2001)')
plt.axvline(x=2020, color='purple', linestyle=':', alpha=0.6, label='COVID-19 (2020)')

# Text Annotations
plt.text(1948, -5500, 'DP Act Begins', horizontalalignment='center')
plt.text(1980.3, 210000, 'Historical Peak', horizontalalignment='left', color='darkred', fontweight='bold')
plt.text(2024, 103000, '2024 Recovery', horizontalalignment='center')
plt.text(2026, 2000, 'Current Cap', horizontalalignment='center', color='red')

plt.title('Actual U.S. Refugee Admissions (1948-2025)', fontsize=16)
plt.xlabel('Fiscal Year', fontsize=12)
plt.ylabel('Actual Admissions', fontsize=12)
plt.grid(True, linestyle='--', alpha=0.3)
plt.legend()

plt.tight_layout()
plt.savefig('actual-us-refugee-admissions-graph.png')
plt.savefig('actual-us-refugee-admissions-graph.svg', format='svg')
print(df.tail(15))

This next year, 2026, is poised to have the lowest number of refugees welcomed into the United States since World War II.

When reflecting on the possibility that Jesus was at one time a refugee or an asylum seeker, I can sense personal experience when he depicts a coming reckoning:

Jesus: “I was a stranger and you did not invite me in, I needed clothes and you did not clothe me, I was sick and in prison and you did not look after me.”

The condemned: “Lord, when did we see you hungry or thirsty or a stranger or needing clothes or sick or in prison, and did not help you?”

Jesus: “Truly I tell you, whatever you did not do for one of the least of these, you did not do for me.”

Matthew 25:43-45 (ESV), with my reformatting

Instead of taking in the stranger and looking after those in prison, the United States has been seeking out the stranger (foreigner) to put into detention or even prison, as in the case of CECOT. Even immigrants who had come here legally have had their legal status revoked so they can be detained and deported: 1.6 million people lost legal right to stay in the U.S. in 2025.

The Hebrew Bible (aka the Old Testament) has many admonitions for the Israelites to care for foreigners, for example:

When a foreigner resides among you in your land, do not mistreat them. The foreigner residing among you must be treated as your native-born. Love them as yourself, for you were foreigners in Egypt.

Leviticus 19:33-34a (NIV)

This sounds an awful lot like due process; it also sounds like an admonition to treat foreigners with dignity as human beings, not to denigrate them as animals. The scriptural commands for how to treat foreigners justly because they were foreigners in Egypt also circle back to Jesus. An Old Testament prophecy from Hosea 11:1 is attributed to him in Matthew 2:15: “Out of Egypt I called my son.” I find it interesting to think about the prior scriptural commands to care for the foreigner when thinking about Jesus’s future experience as a refugee in Egypt; it makes me think about God perhaps establishing a regional norm so that his Son would be protected when he was a refugee. Jesus also identifies with the foreigner and he takes it personally the way they are treated (or mistreated).

When thinking about undocumented immigrants who live in our communities, I also think about whom Jesus identifies as our neighbors, those we are to love as ourselves. They’re not just fellow citizens (neighbors) of our own country, people who are just like us. In Luke 10:25-37, he tells a story of how a man was robbed and left for dead. The man’s fellow countrymen passed him by and didn’t offer any help. But when a foreigner (even a despised Samaritan) came by, the foreigner had compassion on the beaten man and cared for him. Jesus said we are to be a good neighbor like that foreigner.

In the current struggle against antisemitism, I find it inconsistent that refugee laws passed in part to rectify how the United States failed to protect Jewish refugees during the Holocaust are now being suppressed, even as many espouse America as being a “Christian nation”. And this Christmas season, this is brought all the more into focus when thinking about how Jesus was once a refugee and that he likely would not have found refuge in America today.

The post Would Jesus have found refuge in the United States? appeared first on Weston Ruter.

There were many contributors from the Core Performance Team involved in making this possible. Personally, this is a culmination of a year of work, including a bunch of research and development I wrote about previously and spoke about at WordCamp US:

I’ve been working nights and weekends (and days) to help make sure all of this lands in time for the December 2nd release. This is evident from looking at the “A Month in Core” post for October! It has been fun—feeling like the good ol’ contribution days when I was deep in the Customizer up through WordPress 4.9 (2013–2017). But I’m really looking forward to being able to unwind for the holidays.

I hope your sites get a great speed boost for Christmas!

Where I’ve shared the field guide:

• LinkedIn
• Bluesky
• Threads
• Twitter
• Mastodon

The post WordPress 6.9 Performance Landings appeared first on Weston Ruter.

In what may be surprising to many, I’ve found this role at WP Engine. I’ve joined WPE as a principal software engineer to work full time on contributing to WordPress core. I’ll be continuing the performance work I had been doing and which I have continued to work on while I was between roles, with thanks to my sponsors! I’ll be working from home, as I was well accustomed to during my 8 years at X-Team/XWP, and like most of us during COVID. I’m looking forward to resuming frequent visits to my Montavilla neighborhood businesses and regular runs up Mount Tabor.

As far as I know, my being hired is not related in any way to the current WP drama. I’ve tried to stay out of the drama. But WP Engine reached out to me, and after many conversations, I was encouraged with the role they were looking to fill: exactly what I had been looking for when I was let go by Google. There are also a couple former fellow XWPeople who are now at WPE who I’m looking forward to working with again!

I attribute WP Engine’s bringing me on board as a testament to their core value to be committed to give back:

We advance the WordPress Community through original contribution, sharing expertise, and active participation.

I’m looking forward to continuing my WordPress core contribution journey now at a company fully immersed and invested in WordPress!

Where I’ve posted this:

• LinkedIn
• Bluesky
• Twitter
• Mastodon
• Threads

The post Joining WP Engine appeared first on Weston Ruter.

At WordCamp US 2025 this year, I’m presenting a talk called “The Site Speed Frontier with Performance Lab and Beyond” with the following description:

The Core Performance team has been incubating enhancements for WordPress through the Performance Lab plugin. These have been available for a few years now; some have been merged into core (e.g. Speculative Loading) while others are more experimental and remain in testing (e.g. Optimization Detective). This talk will look at how these performance plugins impact the speed of a stock WordPress site running the Twenty Twenty-Five default theme, using Core Web Vitals benchmarks and Lighthouse scores. It will also look at how the theme’s performance can be further tuned, including the use of core patches proposed for the next major release (also available in plugin form to leverage today) to further accelerate the loading of pages to improve the user experience of site visitors.

Here’s my talk from the WordPress YouTube channel (also available on WordPress.tv):

And here are my slides as well:

And what follows is my talk in blog post form, greatly expanded with a lot more details than I had time to share during my talk.

Table of contents:

Performance Lab

I’ve been a WordPress core committer for over 10 years, and since Spring 2023 I’ve been heavily involved on the Core Performance Team. In addition to contributing patches directly to the WordPress core codebase, we also develop new performance optimizations in the form of feature plugins. We use our Performance Lab plugin as a way to collect the feature plugins we’re currently working on to facilitate discovery:

Most of these performance feature plugins are developed in the WordPress/performance monorepo on GitHub. In the same way as the Gutenberg plugin serves as a way to develop new editor features, the Performance Lab plugin is a way we incubate new performance features. It allows us to get feedback from users and test the impact prior to being proposed for merging into a new release of WordPress core when it gets rolled out to ~43% of the web.

Case Study: Twenty Twenty-Five

The default theme for the current version of WordPress is Twenty Twenty- Five. Default themes in core basically encapsulate the latest and greatest in what WordPress has to offer in terms of features and performance. Indeed, block themes are generally faster than classic themes (especially with page caching) for a few reasons, including:

• Scripts and styles are selectively loaded based on whether their blocks actually used on the page.
• Blocks are more likely to use the Interactivity API which involves deferred script modules (which don’t block rendering) and server-side rendering.

So the Twenty Twenty-Five theme should be very fast, and indeed it is. But with Performance Lab features (and beyond), it can be made even faster.

Your mileage will vary with other themes, either having an even greater impact or a lesser one. Every site is unique (hopefully!) and so the impact of optimizations depends on a page’s contents, how a theme is built, and which plugins are active. But in this post, I’ll show the impact of the optimizations in various page layouts of the Twenty Twenty-Five Theme.

Performance Testing Methodology

Perhaps the most popular way to analyze the performance of a webpage is to use Lighthouse, either in Chrome DevTools or via the bottom half of PageSpeed Insights. Lighthouse allows you to test pages either as a desktop or mobile device, emulating the viewport, CPU, and connection speed. Lighthouse is an important tool to get a sense of a page’s performance, but it has limitations. It captures data from a single page load on a simulated device. There is often variability in the results, and it also doesn’t reflect the experience of real users which is what you’d get from Real User Monitoring (RUM), such as in the Chrome User Experience Report (CrUX)—shown in the first section of PageSpeed Insights. Lighthouse provides simulated lab data whereas CrUX provides real field data, which is more accurate. Nevertheless, field data can take a long time to collect and it can be difficult to do A/B tests at scale to capture the before/after performance impacts. That said, CrUX is definitely used to track the performance of new WordPress releases overall, as Felix Arntz shared the WordPress performance impact on Core Web Vitals in 2023. Felix also wrote up how to conduct WordPress performance research in the field.

For the purposes of measuring the impact of performance optimizations here, lab data will be more practical because the results are available in real time, without having to wait for real users to provide field data. And I’m interested in relative performance impacts, not necessarily absolute ones.

Running a Lighthouse audit before and after a Performance Lab feature plugin is active is a way to measure the impact of the optimization. However, given variability in the results, it can be difficult to be certain of the improvement. A Lighthouse audit may no longer flag an area for improvement, but the overall Lighthouse score may be unchanged. Indeed, even a Lighthouse score of 100 doesn’t mean the page performance is “perfect”. As found by Brendan Kenny:

Of the pages that got a 90+ in Lighthouse in September [2021], 43% didn’t meet one or more CWV threshold.

A great score—even 100—doesn’t mean there still isn’t a lot of room for improvement!

Largest Contentful Paint

One of the main components in calculating Lighthouse’s Performance score is the Largest Contentful Paint (LCP) metric of Core Web Vitals (CWV). LCP metric is weighted at 25% of the total Lighthouse score. As noted in how how Lighthouse scores are determined:

The metric value for LCP represents the time duration between the user initiating the page load and the page rendering its primary content. Based on real website data, top-performing sites render LCP in about 1,220ms, so that metric value is mapped to a score of 99.

A 1.2 second LCP is 12 times slower than a 100 ms LCP, where 100 ms is a proposed threshold for the user to perceive a reaction as being instantaneous. Nevertheless, a “good” LCP value is 2.5 seconds and below:

The LCP metric can be further subdivided, with the first part represented by the Time To First Byte (TTFB) metric. The longer it takes the server to respond with the generated HTML document, the more this will hurt the LCP metric. A slow TTFB means you are less likely to have a good LCP. If a site has a 1.5-second TTFB which needs improvement, then this leaves only 1 second for the LCP element to be rendered to get a good LCP metric. A good TTFB is considered to be about half that, at 800 ms and below:

Unfortunately, in looking at HTTP Archive’s Tech Report, as of July 2025, only 31% of desktop clients visiting WordPress sites experience a good TTFB, whereas it’s just 24% for mobile clients. This means it is all too likely that a 1.5-second TTFB is the norm for WordPress sites. This is in part what contributes to WordPress lagging behind most other CMSes for the LCP metric on mobile and on desktop, even about 10% below the average on all measured sites.

In comparison with the other CWV metrics—Cumulative Layout Shift (CLS) and Interaction to Next Paint (INP)—WordPress is doing worse in terms of LCP, as evident in the metric passing rates from the following reports on HTTP Archive:

Therefore, improving LCP remains the most important focus for performance optimizations in WordPress. So in this post I’ll focus on the LCP impact for the plugins featured in Performance Lab and some other changes proposed for WordPress 6.9.

Benchmarking

Because the Lighthouse score is variable and a 100 score merely reflects a “good” LCP, evaluating the performance benefit of an optimization requires measuring the LCP metric itself. Due to the variability in the metric, it’s important to obtain the median value of the LCP over many measurements. By capturing the median LCP value before and after an optimization is applied, the relative impact on performance can be measured.

The tool I use for benchmarking LCP is in the GoogleChromeLabs/​wpp-research repo, which my team developed when I was at Google. Specifically, I use the benchmark-web-vitals command which includes the ability to emulate mobile and desktop devices, network connections, and CPU speeds.

Here’s an example command I use to benchmark two URLs emulating a mobile device on a Fast 4G connection, and compare their results:

npm run research -- benchmark-web-vitals \
	--url="http://localhost/?enable_plugins=none" \
	--url="http://localhost/?enable_plugins=foo" \
	--number=50 \
	--network-conditions="Fast 4G" \
	--emulate-device="Moto G4" \
	--diff \
	--output=md

<?php
/**
 * Plugin Name: Active Plugins Override
 */

namespace ActivePluginsOverride;

function get_always_active_plugins(): array {
	return array(
		'user-switching/user-switching.php'
	);
}

add_filter(
	'option_active_plugins',
	static function ( $plugins ) {
		return array_unique( array_merge( $plugins, get_always_active_plugins() ) );
	},
	100
);

if ( isset( $_GET['disable_all_plugins'] ) || ( isset( $_GET['enable_plugins'] ) && $_GET['enable_plugins'] === 'none' ) ) {
	add_filter( 'option_active_plugins', '__return_empty_array' );
}

if ( isset( $_GET['disable_plugins'] ) ) {
	if ( is_array( $_GET['disable_plugins'] ) ) {
		$disable_plugins = $_GET['disable_plugins'];
	} else {
		$disable_plugins = explode( ',', $_GET['disable_plugins'] );
	}

	add_filter(
		'option_active_plugins',
		function ( $active_plugins ) use ( $disable_plugins ) {
			return array_merge(
				array_filter(
					$active_plugins,
					function ( $active_plugin ) use ( $disable_plugins ) {
						$slug = strtok( $active_plugin, '/' );
						return ! in_array( $slug, $disable_plugins );
					}
				),
				get_always_active_plugins()
			);
		}
	);
}

if ( isset( $_GET['enable_plugins'] ) ) {
	if ( is_array( $_GET['enable_plugins'] ) ) {
		$enable_plugins = $_GET['enable_plugins'];
	} else {
		$enable_plugins = explode( ',', $_GET['enable_plugins'] );
	}

	if ( count( array_intersect( $enable_plugins, array( 'embed-optimizer', 'image-prioritizer' ) ) ) > 0 ) {
		$enable_plugins[] = 'optimization-detective';
		$enable_plugins[] = 'od-admin-ui';
	}

	add_filter(
		'option_active_plugins',
		function ( $active_plugins ) use ( $enable_plugins ) {
			return array_filter(
				$active_plugins,
				function ( $active_plugin ) use ( $enable_plugins ) {
					$slug = strtok( $active_plugin, '/' );
					return in_array( $slug, $enable_plugins );
				}
			);
		}
	);
}

This results in a table like the following, showing the median metrics for the number of requests to both URLs:

In this example, the LCP improved by ~25% by enabling the “foo” plugin, which is exactly the kind of performance improvement we’re looking for on the Core Performance Team. Note this “LCP-TTFB” metric is simply the LCP metric minus the TTFB metric; this allows for measuring the client-side contributions to LCP by discounting any server-side variability in generating the response. The LCP-TTFB metric is important considering the lack of page caching on a local environment, and that certain optimizations may increase TTFB when page caching is not involved. For WordPress to scale, it’s important to have some page caching layer in place.

Analyzing Optimization Impact on LCP

I’m going to analyze the impact of the following feature plugins featured in Performance Lab:

• Image Placeholders
• Modern Image Formats
• Enhanced Responsive Images
• Image Prioritizer
• Speculative Loading
• View Transitions

I’m not covering Performant Translations since it was mostly merged into core as of 6.5. I’m also not covering Embed Optimizer since it primarily helps with INP by lazy-loading and CLS by reserving space for resizing embeds; the LCP improvement is difficult to measure for embeds that appear in the initial viewport given their cross-origin nature. Lastly, I’m not covering Web Worker Offloading since it is quite experimental and it is only related to INP. However, I am going to cover enhancements beyond Performance Lab being targeted for WordPress 6.9:

• Instant Back/Forward (actually, brand new to Performance Lab)
• Script Module Deprioritization
• Minified CSS Inlining

The first four Performance Lab feature plugins are all related to images. In focusing on improving the LCP metric, this makes sense because images are the LCP element 73.3% of the time on mobile and 83.3% of the time on desktop, according to Web Almanac 2024:

Image Placeholders

The Image Placeholders plugin, originally called “Dominant Color Images”, adds a non-transparent image’s dominant color as the background color. This improves the perceived page loading experience by showing something sooner, rather than just a blank spot on the page.

Instead of this:

With the plugin active (and the media regenerated), the following is the result:

The visual impact that this plugin has on the loading of the page is that there is a brown rectangle serving as a placeholder for where the user can expect an image to load.

However, when benchmarking the web vitals, there is no improvement in LCP. In fact, there even appears to be a slight regression:

npm run research -- benchmark-web-vitals \
	--url="https://wcus-perf-talk-demo.local/2025/07/30/bison-featured-image/?enable_plugins=none" \
	--url="https://wcus-perf-talk-demo.local/2025/07/30/bison-featured-image/?enable_plugins=dominant-color-images" \
	--number=250 \
	--network-conditions="Fast 4G" \
	--emulate-device="Moto G4" \
	--diff \
	--output=md

Moreover, there is no difference in the Lighthouse performance score which is already maxed out at 100 (but again, this doesn’t mean perfection). Nevertheless, just because there is no improvement on the raw performance metric, this doesn’t mean there isn’t value in doing it. User-perceived performance is also important, as long as it doesn’t negatively impact LCP (which should hopefully not conflict). We’ll revisit this later with View Transitions.

Modern Image Formats

Modern image formats, like WebP and AVIF, are able to compress much higher compared to older formats like JPEG and PNG. For example, an image compressed with AVIF could be 50% smaller than a JPEG with similar visual quality. It stands to reason that if an image is smaller, then it will take less time to download, and the LCP metric will be improved since the image can render sooner. This also addresses a common audit you encounter in Lighthouse to serve images in next-gen formats:

Note that the audit here estimates that the image in a modern image format would be 54% smaller for this image. (Note also the shameless plug for Performance Lab thanks to the Stack Pack for WordPress.)

The Modern Image Formats plugin (originally called “WebP Uploads”) addresses this audit’s complaint by converting uploaded images into AVIF or WebP, depending on which is available on your server. With the plugin active, the original Bison image uploaded as a JPEG is compressed from 356 KB down to 292 KB in AVIF format. This is ~18% smaller, not the hoped-for ~50% reduction in file size. Nevertheless, will this yield a 18% improvement in LCP? Here are the results of testing the same page as when testing Image Placeholders above, a post where the featured image is the LCP element:

npm run research -- benchmark-web-vitals \
	--url="https://wcus-perf-talk-demo.local/2025/07/30/bison-featured-image/?enable_plugins=none" \
	--url="https://wcus-perf-talk-demo.local/2025/07/30/bison-featured-image/?enable_plugins=webp-uploads" \
	--number=50 \
	--network-conditions="Fast 4G" \
	--emulate-device="Moto G4" \
	--diff \
	--output=md

So while the image file size was reduced ~20%, the LCP improvement here was only ~2%.

Brendan Kenny’s article on Common Misconceptions About How to Optimize LCP shows that among the LCP sub-parts, the TTFB and “image load delay” contribute much more to the overall time compared with actually downloading the image resource. (Also described in Web Almanac.) Remkus de Vries has likewise emphasized that we should Stop Obsessing Over Image Optimization. We absolutely shouldn’t be serving 10 MB images to visitors, but there are diminishing returns for optimizing LCP with each percentage reduction in an image’s file size. There are far more impactful ways to improve LCP than to use the most optimal image compression.

Thanks to Adam Silverstein for championing support for modern image formats both in this plugin and in core!

Enhanced Responsive Images

The Enhanced Responsive Images plugin was originally developed as a way to automatically add sizes=auto for images with loading=lazy. This new part of the HTML spec lets the browser compute the responsive sizes because lazy-loaded images are loaded after the page has been laid out. This enhancement landed in WordPress 6.7. Since then, the scope of the plugin has changed to improve the calculation of the responsive sizes attribute for images which are not lazy-loaded.

By default, WordPress uses the same formula for constructing the default sizes attribute for all images. For example, if an image is 1024 pixels wide, then the sizes attribute is set to:

(max-width: 1024px) 100vw, 1024px

This is problematic, however, because if the image takes up half the width of the screen, then the browser will select the image URL from the srcset attribute for the size corresponding to the width of the viewport, not the width of the actual IMG element. This is often fine on mobile when images are more often taking up the full page width, but on desktop viewports it means a much larger image will be downloaded than is appropriate for the container size. For example, consider these images in a Columns block (sourced from Wikipedia, as linked):

These images were all resized to be 1024 pixels wide, and so using the default WordPress scheme, they all have the same sizes attribute (as shown above), in spite of the fact that the first IMG element is twice the width of the second and third, and 1024px itself is about double the entire 645px width of the root Columns block on desktop.

In Lighthouse, the properly size images audit correctly identifies these images as having inaccurate sizes:

On my test page, this Columns block is at the beginning of the content, so none of the IMG tags are lazy-loaded and likewise none are eligible for auto-sizes. This is where the enhanced Enhanced Responsive Sizes plugin comes in. Now that auto-sizes was merged into core, the plugin’s scope has changed to improve the accuracy of the sizes attribute by using the structured layout information available in block themes (which is not available in classic themes). With this plugin active, the width in the sizes attribute for the IMG in the first column reduces from 1024px down to 429px:

(max-width: 429px) 100vw, 429px

And the two smaller IMG tags in the second narrower column get reduced from 1024px down to 134px:

(max-width: 134px) 100vw, 134px

Here is the performance impact when benchmarking the change:

npm run research -- benchmark-web-vitals \
	--url="https://wcus-perf-talk-demo.local/2025/07/31/bison-two-columns/?enable_plugins=none" \
	--url="https://wcus-perf-talk-demo.local/2025/07/31/bison-two-columns/?enable_plugins=auto-sizes" \
	--number=50 \
	--network-conditions="Fast 4G" \
	--emulate-device="Moto G4" \
	--diff \
	--output=md

This has a dramatic ~25% reduction in LCP!

This also has an improvement in the Lighthouse score for this example page, whereas I did not find an improvement when testing the previous plugins.

The optimization also greatly improved the properly size images audit, before and after:

Note that this audit is unlikely to ever pass completely unless you generate many more intermediate image sizes to better fit all possible dimensions for your responsive images. This is something that an image CDN could do for you, however.

The effect of the more accurate sizes can be is evident in which intermediate image size files get downloaded:

	Before	After	Reduction
	2048×1336	1024×668	-75%
	2048×1483	300×217	-98%
	2048×1413	300×207	-98%
Total:	8,667,136px	811,232px	-91%

In this test of images in a Columns block, what follows is the impact of Modern Image Formats with AVIF versus Enhanced Responsive Images with more accurate sizes, and then with them both active together:

As is evident, the use of a more accurate sizes attribute has three times the reduction in bytes compared with using the AVIF image format (87% vs 29%)! Adding AVIF on top of the better sizes only yields an additional 2% reduction in transferred bytes in this example. It’s no wonder why Enhanced Responsive Images has a greater impact on LCP compared with Modern Image Formats!

Props to Mukesh Panchal and Joe McGill for their work on this! Joe also first proposed the original sizes attribute.

Image Prioritizer

The last Performance Lab feature plugin which focuses on images is Image Prioritizer. As indicated by the name, the plugin optimizes image loading prioritization. For example, it boosts the priority of the detected LCP image with fetchpriority=​high while also deprioritizing the loading of images outside the viewport with lazy-loading. This plugin depends on the Optimization Detective plugin as its framework for the optimizations it applies. I gave a talk at WordCamp Asia 2025 all about this plugin:

In that talk, I cover Image Prioritizer in depth; the plugin description also has the full list of optimizations. But I’ll highlight here a couple of the most impactful optimizations which improve the LCP metric for images.

Responsive Image Prioritization

Take for example this gallery of three images (again, from Wikipedia as linked):

This gallery is configured without the “Crop images to fit” setting enabled. On desktop, the second image is the largest image of the three, and so it is the LCP element. However, on mobile it’s actually the third image which is the largest (and the LCP element) since it appears on a row by itself:

Nevertheless, WordPress core adds fetchpriority=​high to the first IMG, of the bison and calf, even though it is never the LCP element. WordPress adds the fetchpriority attribute to the first sufficiently-large image it finds on the page, making a best guess as to which is the LCP element. But even when core does add the attribute to the right image on a desktop viewport, it could be wrong for mobile, and vice versa. In my research, when WordPress core correctly adds the fetchpriority attribute to the LCP IMG element on desktop or mobile, I found that 37% of those pages have a different IMG which is the LCP element for the other viewport. This means it’s only safe to use the fetchpriority attribute on IMG tags when they are the LCP element on both desktop and mobile (and tablet too). But WordPress doesn’t know how the page is laid out (although this is starting to change in the case of block themes, as with Enhanced Responsive Images above). This is where Optimization Detective comes in.

The Optimization Detective plugin provides a framework to capture measurements from site visitors about what elements are displayed on a page across a variety of device form factors and responsive breakpoints (e.g. desktop, tablet, and mobile). These measurements are stored in “URL Metrics” (a custom post type) which can then be used by extensions, like Image Prioritizer, to apply more accurate optimizations. In this case, Image Prioritizer:

1. Removes fetchpriority=​high from the first IMG in the Gallery.
2. Adds responsive preload LINK tags for the actual LCP element based on media queries.

For example, the following LINK tags are added to the page:

<link
 rel="preload" as="image" fetchpriority="high"
 href=".../bison-2.jpg"
 imagesrcset="..." imagesizes="..."
 media="screen and (width <= 480px)"
>
<link
 rel="preload" as="image" fetchpriority="high"
 href=".../bison-3.jpg"
 imagesrcset="..." imagesizes="..."
 media="screen and (782px < width)"
>

Note how the first LINK preloads the second bison image on mobile, but the second LINK preloads the third bison image on desktop. Here is the performance impact for these changes on mobile:

npm run research -- benchmark-web-vitals \
	--url="https://wcus-perf-talk-demo.local/2025/08/04/bison-gallery/?disable_all_plugins" \
	--url="https://wcus-perf-talk-demo.local/2025/08/04/bison-gallery/?enable_plugins=image-prioritizer" \
	--number=50 \
	--network-conditions="Fast 4G" \
	--emulate-device="Moto G4" \
	--diff \
	--output=md

This is the biggest LCP improvement I’ve yet shown, with a 27.5% reduction compared with the 24.5% improvement in Enhanced Responsive Images. This shows up as an improvement in the Lighthouse performance score, increasing from 95 to 99:

But what becomes truly impressive are the results on desktop:

The LCP improvement here on desktop is almost double the improvement on mobile, at an over 50% reduction in LCP! In other words, the LCP metric is cut in half! This shows impressively in the Lighthouse performance score increasing from 93 to 100:

Background Image Prioritization

Related to there being different LCP IMG elements on desktop versus mobile is that the LCP element’s image may not be an IMG at all, but rather a DIV (or some other element) with a CSS background-image. This is a very common way that imagery is added in page builders. Background images are also present in WordPress core, such as in some classic themes’ header images; background images are also on any WordPress site using the Cover block when using a fixed background or when adding a background image to a Group block. The prevalence of non-IMG LCP images is captured in this data presented in Web Almanac 2022, showing that the DIV (presumably with a background image) is the LCP element ~26% of the time compared with an IMG at 42% of the time:

The problem with the background-image style is that it is CSS: there is no way for core to attach a fetchpriority=​high HTML attribute as can be done for LCP IMG candidates. Take the following page for example, where there is a parallax Cover block at the beginning of the content, followed by some paragraphs of text, and finally a Gallery block with five images in it. The black rectangle denotes the desktop viewport:

Cover image courtesy Gintare K. on Pexels. Other previously-unused images courtesy Wikipedia: 1, 2, 3.

The DIV in the Cover block with the CSS background-image is the LCP element. Nevertheless, WordPress core is adding fetchpriority=​high to the first IMG in the Gallery block because it is the first sufficiently large image, just in terms of its width and height attributes. Additionally, WordPress core omits loading=lazy from the first three content images (the first three images in the Gallery), but they are not even visible on either the desktop or mobile viewports. The effect here is that the first three images of the Gallery are all loaded first before the all-important background image for the Cover block. Image Prioritizer fixes this by:

1. Removing fetchpriority=​high from the first IMG in the Gallery, since it is not the LCP element.
2. Adding loading=lazy to the first three IMG tags in the Gallery, since none of them are visible in any initial viewport.
3. Adding a preload LINK for the CSS background-image so that it is properly prioritized.

The preload LINK looks like the following:

<link
 rel="preload"
 as="image"
 fetchpriority="high"
 href=".../bison.jpg"
 media="screen"
>

Unlike with the responsive image prioritization, the Cover block here is the LCP element for both desktop and mobile, so here there is only one LINK and the media attribute doesn’t need to add any viewport constraints.

Here is the performance impact:

npm run research -- benchmark-web-vitals \
	--url=https://wcus-perf-talk-demo.local/2025/08/04/cover-block/?disable_all_plugins \
	--url=https://wcus-perf-talk-demo.local/2025/08/04/cover-block/?enable_plugins=image-prioritizer \
	--number=50 \
	--network-conditions="Fast 4G" \
	--emulate-device="Moto G4" \
	--diff \
	--output=md

This is the second-best improvement to LCP I’ve shown here in analyzing these plugins. The Lighthouse performance score is also improved from 92 to 99:

Surely nothing can improve LCP more than what was achieved here with the Image Prioritizer plugin, right? Read on.

Speculative Loading

The Speculative Loading plugin is the first discussed here not specifically focused on improving LCP for images, although they do benefit. This was a feature plugin actually to bring the Speculation Rules API to WordPress core, which was merged in 6.8. This API allows pages to either:

• Prefetch a link, reducing TTFB to zero.
• Prerender a link, potentially reducing LCP to zero.

As such, Speculative Loading is somewhat cheating at performance because you can’t get any faster at loading something than to have it already loaded.

The degree by which TTFB and LCP are improved is largely dependent on the “eagerness” of the speculation. There are three main eagerness values for when speculation starts:

• Conservative: when you pointer-down on a link.
• Moderate: when you hover over a link (or soon on mobile when a link is in the viewport).
• Eager: right away without any user interaction.

For the initial core merge, the default cautious configuration was to use prefetch with conservative eagerness. Conservative eagerness was to avoid unused speculations which can overly tax under-powered servers, and prefetching was to avoid potential compatibility issues with prerendering, such as with analytics or ads.

Here’s the impact that the various configurations of Speculative Loading have on LCP:

Navigation with prerendering results in a practically instantaneous page load with a near zero LCP! In all these cases the LCP is still considered “good” at being less than 2.5 seconds, but just because something is good doesn’t mean it can’t be better!

Note that the test page here adds a 1 second TTFB via sleep(1). This reflects a fairly typical server response time considering that only a quarter of WordPress sites have a good TTFB passing rate, which is 800 ms and faster.

Props to Felix Arntz for spearheading this feature and landing it in core.

View Transitions

As described in the previous example, page navigations with Speculative Loading can be nearly instant with prerendering. This is great, but it’s almost too good. The navigation can feel so instant as to be abrupt. There can also be a white flicker between the page loads. To help in part with having too much of a good thing, the newest plugin to be featured in Performance Lab is View Transitions. There is a new web platform feature for cross-document view transitions for multi-page applications, and this plugin brings these smooth page navigation animations to WordPress. With Speculative Loading and View Transitions, navigating around a regular multi-page WordPress site can feel as fluid as a single-page app (and without all the implementation complexity).

Take a look at the impact on the user experience when navigating between the homepage and a blog post:

Note that these view transitions apply not only when navigating via links, but they also apply when navigating with the back/forward buttons in the browser:

Nevertheless, as nice as these cross-document view transitions are, do note that there is no LCP improvement to using them. As referenced previously with Image Placeholders, the View Transitions plugin provides a non-performance user experience improvement. So don’t expect to find any difference in your Lighthouse scores or LCP passing rates with this plugin.

Props again to Felix Arntz for spearheading this feature plugin.

Instant Back/Forward

Originally, the Instant Back/Forward plugin (née “No-cache BFCache”) was part of the “beyond” part of my talk because it wasn’t among the plugins featured by Performance Lab. However, this is no longer the case since v4.0.0. In the previous section about Speculative Loading, I showed how prerendering enabled near instant page loads with practically zero LCP. But there is a much older browser technology for instantaneous page navigations: the back-forward cache (bfcache). This was also depicted above in the back/forward navigation videos with view transitions.

I wrote up a blog post already all about bfcache and this plugin:

To recap, webpages are generally not eligible for bfcache when they are served with Cache-Control: no-store. This header is sent when a user is logged-in and often on e-commerce sites for the shopping cart, checkout, and account pages. While it importantly prevents such pages from being cached by proxies, it also prevents the browser from storing pages in bfcache. This plugin removes the no-store directive. In its place, it ensures that the private directive is sent to prevent proxies from caching the response; also, to ensure preserve privacy after logging out, it includes logic to invalidate pages from the bfcache so they cannot be re-accessed.

What follows is an example of a site running Twenty Twenty-Five with the BuddyPress plugin and Slow 4G network emulation. After entering an activity status update, I navigate from the Personal tab to the Mentions and Favorites tabs. Then I use the back button to go back to the Personal tab. Without bfcache, navigating back from the Favorites tab to the Personal tab is very slow since (1) the browser has to re-fetch the HTML from the server, and (2) the DOM has to be completely reconstructed. Without bfcache, there is also the unfortunate result that the drafted status update is lost, since the form field was re-constructed with JavaScript. In contrast, when bfcache is enabled, navigating to the previous tabs is instant, and the DOM is preserved with each navigation, resulting in the drafted status update being kept intact:

Without bfcache, the back navigation has an LCP of 1.41 seconds whereas with bfcache the LCP is 0.02 seconds: nearly instantaneous.

There are other reasons why pages may be ineligible for bfcache than the no-store directive, but it is one of the most common causes. It’s very important to try to preserve bfcache eligibility because back/forward navigations are very common on the web:

Chrome usage data shows that 1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward.

Script Module Deprioritization

Moving on from instant page loads with Speculative Loading and bfcache, another way to shave off milliseconds on the LCP metric is to reduce network contention for loading the LCP element resource (e.g. an image). Consider a template with an Image block and a Navigation block, where the Image block has a lightbox and the Navigation block expands on mobile. These blocks use the Interactivity API which involves adding script modules to the page with the necessary logic. As noted previously, one of the key design principles of the Interactivity API is server-side rendering. This means that by design the Navigation block and the Image block do not need their script modules in the critical rendering path.

It turns out that these script modules are currently loaded with high priority because the browser doesn’t know they aren’t critical. So they compete with the loading of critical resources, like the LCP image, even though script modules aren’t render blocking.

I’ve written a separate post all about this problem and the solution:

To summarize, there are two ways to prevent script modules from delaying the loading of critical resources:

1. Add fetchpriority=​low to the SCRIPT module tags and the modulepreload LINK.
2. Move the SCRIPT tags to the end of the BODY (the footer).

Here are the results of these optimizations on an emulated broadband connection with an IMG as the LCP element:

This is a healthy LCP improvement, more impactful than using the Modern Image Formats with the AVIF format in my testing above. There are two plugins available on GitHub which implement these optimizations while waiting for them to be available in core:

• Script Fetch Priority Low (cf. #61734)
• Script Modules in Footer (cf. #63486)

Minified CSS Inlining

The final optimization I’m analyzing is the impact of eliminating render-blocking external stylesheets. With JavaScript, adding defer to a SCRIPT is an easy way to prevent them from blocking rendering (assuming they can be deferred). However, this is not so easy to do with external stylesheets. CSS is always render-blocking because otherwise there is a flash of unstyled content (FOUC). The web platform does not (currently) provide an official way to opt in to async CSS. Instead, the best way to handle this is to inline the CSS in STYLE tags (at least for the critical CSS).

On a vanilla WordPress install when loading the Sample Page, where the LCP element is text, there are two render-blocking stylesheets:

• The Navigation block’s style.min.css
• The Twenty Twenty-Five theme’s style.css

Despite these render-blocking stylesheets, Lighthouse is giving the page a 100 performance score. But as I’ve said before, just because you have a 100 score in Lighthouse, this doesn’t mean you can do more. Even with a perfect Lighthouse score, there is actually an audit that is pointing out the performance problem: Eliminate render-blocking resources.

It’s strange that this audit has an overall estimated savings of zero milliseconds, but for the theme’s stylesheet it shows an estimated savings of 150 milliseconds.

To inline these two stylesheets to prevent them from being render-blocking, what is needed is to:

1. Opt in to inline the (minified) theme’s style.css.
2. Increase the styles_inline_size_limit.

To inline Twenty Twenty-Five’s stylesheet, all that is required is to add the path data for where the registered style is located on the filesystem. This can be done as simply as follows:

add_action(
	'wp_enqueue_scripts',
	function (): void {
		wp_style_add_data(
			'twentytwentyfive-style',
			'path',
			get_parent_theme_file_path( 'style.css' )
		);
	},
	20
);

However, since the stylesheet is not yet minified (cf. #63012), you can hack in runtime minification using a plugin like Twenty Twenty-Five Stylesheet Inlining. This plugin is currently just in a Gist since I hope this will land soon in core for 6.9 via #63007.

To increase the limit for inline CSS, all that is needed is a simple filter. The default limit is 20 KB which seems low considering the inline CSS limit for an AMP page is 75 KB. To increase the limit to 30 KB which allows enough room for the Navigation block’s relatively stylesheet to be inlined, you can use this PHP code:

add_filter(
	'styles_inline_size_limit',
	function (): int {
		return 30000;
	}
);

<?php
/**
 * Plugin Name: Increase Styles Inline Size Limit (styles_inline_size_limit)
 * Author: Weston Ruter
 * Update URI: false
 */
add_filter(
	'styles_inline_size_limit',
	static function (): int {
		$limit = -1;
		if ( isset( $_GET['styles_inline_size_limit'] ) ) {
			$limit = (int) $_GET['styles_inline_size_limit'];
		}
		if ( $limit < 0 ) {
			$limit = 75000;
		}
		return $limit;
	}
);

Increasing this limit in core is being tracked in #63018. We still need to determine the optimal threshold for inlining, weighing against the benefits of serving stylesheets from the browser cache for subsequent page navigations.

As for the performance impact of inlining these stylesheets, here are the results for the loading Sample Page on an emulated Fast 4G connection:

npm run research -- benchmark-web-vitals \
	--url="https://wcus-perf-talk-demo.local/sample-page/?enable_plugins=twentytwentyfive-stylesheet-inlining" \
	--url="https://wcus-perf-talk-demo.local/sample-page/?enable_plugins=twentytwentyfive-stylesheet-inlining,increase-styles-inline-size-limit.php&styles_inline_size_limit=30000" \
	--number=50 \
	--network-conditions="Fast 4G" \
	--emulate-device="Moto G4" \
	--diff \
	--output=md

This decreases the LCP by over a third!

And here are the results when emulating a Slow 3G connection:

npm run research -- benchmark-web-vitals \
	--url="https://wcus-perf-talk-demo.local/sample-page/?enable_plugins=twentytwentyfive-stylesheet-inlining" \
	--url="https://wcus-perf-talk-demo.local/sample-page/?enable_plugins=twentytwentyfive-stylesheet-inlining,increase-styles-inline-size-limit.php&styles_inline_size_limit=30000" \
	--number=50 \
	--network-conditions="Slow 3G" \
	--emulate-device="Moto G4" \
	--diff \
	--output=md

A 44.4% reduction in LCP is on par with the largest improvements achieved by the Image Prioritizer plugin in my evaluations here. This means that on a Slow 3G connection, the LCP goes from poor at 4.31 seconds to good at 2.38 seconds.

What’s Next

My hope is that several of these improvements will land later this year in WordPress core. Some of them are tracked in the Roadmap to 6.9:

Planned performance improvements include improving Data Views performance by supporting partial entity fetching and smart field resolution, adding the ability to handle “fetchpriority” to ES Modules and Import Maps, standardizing output buffering so developers can hook into a unified filter and manipulate the entire rendered HTML after it’s generated but before it’s sent to the browser (e.g. for page caches and performance optimizations), implementing instant page navigations from browser history via bfcache even when pages are flagged with “nocache” such as when users are logged in, and stylesheet improvements around minification and inlining.

You can get involved with the Core Performance Team to help make this happen!

Where I’ve shared this, if you want to discuss or boost:

• LinkedIn
• Bluesky
• Twitter
• Mastodon
• Threads

The post The Site Speed Frontier with Performance Lab and Beyond appeared first on Weston Ruter.

For the first time ever, I’ve just seen my blog appear in field metrics from CrUX (Chrome UX Report), albeit in desktop only and for the origin not an individual URL. Baby steps. In any case, Core Web Vitals Assessment: Passed

Yesterday, I checked PageSpeed Insights again, and I was excited to discover that my blog is now also appearing in field metrics for mobile as well! And like desktop, the CWV assessment is also passing for mobile. The eligibility criteria for the CrUX dataset includes that “there must be a large enough number of visitors in order to create a statistically significant dataset.” Granted, my site is still only getting enough traffic for origin-level metrics, and I can’t see field metrics for the homepage URL specifically, but it’s another baby step! (Or maybe a toddler step?)

I’ve really been trying to double down this summer on tuning every bit of performance possible out of WordPress (on the frontend), using my site as a case study, and I’ve been sharing my findings in posts here. I hope the site traffic is an indication that the community has found my posts helpful. The learnings are also making their way into Performance Lab feature plugins as well as in performance improvements on the roadmap for WordPress 6.9. I have some more posts that I’m working on. You can subscribe to get them in your inbox.

On August 27th (next Wednesday) at WordCamp US 2025 here in Portland, Oregon, I’m giving a talk called “The Site Speed Frontier with Performance Lab and Beyond” at 11:30am PDT. I hope to see you there, but it will also be livestreamed and recorded. I’ll be blogging an elaborated version of what I have time to share in my talk. (By the way, if you are attending in person, check out My Portland Picks post for what I recommend visitors check out!)

One takeaway I’ll be emphasizing in my talk is that we needn’t settle with sites merely passing the Core Web Vitals assessment or achieving a “perfect” 100 performance score in Lighthouse. Why be content with a good 2-second LCP when it could be half that or even practically zero? Web performance is a journey, and there’s always room for improvement. I can see from my blog’s field metrics, for example, that the TTFB is hovering around the threshold between “needs improvement” and “poor”. In spite of this, the frontend is so tuned that on mobile the LCP-TTFB in CrUX is 400ms and on desktop it’s only 100ms.

I personally love optimizing the performance of WordPress sites, but I get it that this isn’t for everyone (nor should it be). By landing our improvements from the Core Performance Team, my hope is that WordPress core (and the ecosystem) will have best practices implemented by default so that site owners needn’t worry about performance.

I had to take some PSI screenshots to memorialize the milestone:

Field Data via CrUX

Lab Data via Lighthouse

Where I’ve shared this on social media if you want to discuss there:

• LinkedIn
• Bluesky
• Twitter
• Threads
• Mastodon

The post Web Performance Milestone appeared first on Weston Ruter.

The speed of page navigations in WordPress has seen a big boost in 6.8 with the introduction of Speculative Loading. When paired with the original feature plugin, site visitors can experience instant page navigations thanks to its opt-ins for prerendering and “moderate eagerness”. However, WordPress does not enable such instant navigations by default. WordPress core must take a conservative approach since prerendering may cause compatibility problems, like with analytics or ads. There is also a sustainability concern with moderate prerendering since a user may momentarily hover over a link but not intend to follow it at all; this results in an unused prerender, which can waste a user’s bandwidth (and CPU to a limited extent) as well as increase the load on the web server (which can be problematic on shared hosts without page caching). Furthermore, even when prerendering is enabled, not all visitors may be able to experience instant page loads because: 

1. Moderate eagerness is limited on mobile devices (where there is no hover heuristic on touch screens).
2. Speculative Loading is not enabled when a user is logged in. (Updates: See PR which introduces a frontend opt-in, and the Speculative Loading Admin plugin for a backend opt-in.)
3. The Speculation Rules API is currently only supported in Chromium, leaving Safari and Firefox users out.

Nevertheless, there is a much older web platform technology that enables “prerendering” and which is supported in all browsers: the back/forward cache (bfcache). This instant page navigation involves no network traffic and no CPU load. Previously visited pages are stored in memory as a snapshot with their entire state so that they can be restored instantly. Navigating to pages stored in bfcache is as fast as switching open browser tabs.

Back/forward history navigations are very common, as according to the web.dev article on bfcache:

Chrome usage data shows that 1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward. With bfcache enabled, browsers could eliminate the data transfer and time spent loading for billions of web pages every single day!

Also learn more via the following video:

While Speculative Loading enables prerendering, bfcache involves “previous-rendering”.

The good news is that 84% of WordPress origins in HTTP Archive are already bfcache-eligible (based on this query from Gilberto Cocchi). However, the most frequent user of your site may still not be able to experience instant page navigations via bfcache: you! While browsing around the WP Admin and navigating the frontend of your site, the pages most likely aren’t eligible for bfcache due to various blocking reasons. This sluggish experience extends not only to administrators but also to users of sites which require authentication, including e-commerce (e.g. WooCommerce), social (e.g. BuddyPress), and any membership sites. The 84% metric above doesn’t take into account these types of WordPress sites since HTTP Archive exclusively crawls public URLs without authentication. Users browsing WordPress sites on shared hosts or when on a slow connection will be especially frustrated by slow back/forward navigations. Enabling instant back/forward navigations will not only make your users happier (especially you), but it can also improve your CWV passing rate in CrUX.

I’ve been on a mission to bring back bfcache (or rather to bring it forward).

Stale Content in Page Caches

Before going further, I wanted to call out a potentially negative consequence of navigating cached pages. While instant back/forward navigations can provide a big performance boost to the user experience, they can also be a source of confusion when navigating to a cached page with stale content.

Consider the case of an e-commerce site, where a user is on the shopping cart page. From there, they click a link to a related product, and from that product page they add it to the cart dynamically (e.g. via Ajax). At this point, if they hit the back button to return to the cart page and the cart is restored from a page cache, they may not see the newly added product in the cart. A user can simply reload the page to fix this, but this can also be handled automatically.

As described in the “Update stale or sensitive data after bfcache restore” section of the web.dev post, the pageshow event with the persisted property (further discussed below) indicates when a page was restored from bfcache. This event can be used to update the DOM with the latest shopping cart details. In fact, WooCommerce already implements this for its cart:

const refreshCachedCartData = ( event: PageTransitionEvent ): void => {
	if ( event?.persisted || getNavigationType() === 'back_forward' ) {
		dispatch( cartStore ).invalidateResolutionForStore();
	}
};
/* ... */
window.addEventListener( 'pageshow', refreshCachedCartData );

Simply searching a plugin’s codebase for “pageshow” (e.g. in Woo) should indicate whether bfcache navigations are accounted for.

Note also that stale content is also an issue we’ve faced with Speculative Loading, especially when using non-conservative eagerness.

Breaking Caching to Preserve Privacy

My bfcache work began two years ago when I started collaborating on #55491 to eliminate the use of the deprecated unload event handler in WordPress core. Not only does this event fire unreliably, but it also has the side effect of making a page ineligible for bfcache via the “unload-listener” blocking reason. I had queried HTTP Archive myself at the time, and I found it to be the second most common blocking reason. So in r56809 we eliminated all uses of unload, including from:

• Heartbeat API
• Post locking in the classic editor
• Post previews

However, even with the use of unload eliminated, I was confused why I wasn’t finding pages to be eligible for bfcache in my testing. (The removal of unload in core likely didn’t make a dent in bfcache eligibility in HTTP Archive since only 0.25% of unauthenticated pages had the Heartbeat API present.) It turns out that several weeks before I started working on this, a commit had landed which intentionally broke browser page caching (both bfcache and HTTP cache): the no-store directive was added to the Cache-Control response header for logged-in users. (Specifically, this was added to the wp_get_nocache_headers() function.) This introduced the “response-cache-control-no-store” bfcache blocking reason, which was actually the most common reason for ineligibility, just above unload in my HTTP Archive query. The reason for adding this is found in #21938 which proposed adding the no-store directive in order to explicitly disable caching so that authenticated pages do not get stored in the browser cache. This was followed up with #61942 to also send no-store on the frontend while a user is logged in. The rationale for this is rooted in privacy, per the commit message:

The intention behind this change is to prevent sensitive data in responses for logged in users being cached and available to others, for example via the browser history after the user logs out.

Consider an administrator who is logged in to WordPress on a shared computer and is working on something sensitive, like managing API keys on an admin screen. A malicious person could navigate back to that admin screen via the back button after the user had logged out. Nevertheless, the “bad guy” will need to act fast because a browser won’t store cached pages indefinitely; Chrome, for example, holds onto pages in bfcache for 10 minutes. (Tip: When using a shared computer, always exit the browser after logging out of all sites when ending work.) So while no-store here does improve privacy, it does so at the expense of the user experience by degrading the performance of back/forward navigations. Even when pages aren’t eligible for bfcache, removing no-store still improves back/forward navigation performance since pages can be served from the browser’s HTTP cache (although the DOM has to be re-built and scripts have to be re-executed).

Surely there must be a way to preserve privacy and promote performance together.

It’s important to note that the no-store directive not only prevents pages from being cached by the browser, but it also preserves privacy by preventing proxies from caching pages, per MDN:

The no-store response directive indicates that any caches of any kind (private or shared) should not store this response.  

Keeping authenticated pages out of page caches prevents embarrassing scenarios like serving a user the shopping cart page for another user. Nevertheless, there is a more tailored Cache-Control mechanism for this purpose: the private directive. Again, per MDN:

The private response directive indicates that the response can be stored only in a private cache (e.g., local caches in browsers). ¶ You should add the private directive for user-personalized content, especially for responses received after login and for sessions managed via cookies. ¶ If you forget to add private to a response with personalized content, then that response can be stored in a shared cache and end up being reused for multiple users, which can cause personal information to leak.

This is what was originally requested in #57627, but both private and no-store were added together, with the commit message reasoning:

The private directive complements the no-store directive by specifying that the response contains private information that should not be stored in a public cache. Some proxy caches may ignore the no-store directive but respect the private directive, thus it is included.

So how can the private directive be retained for proxies, while removing the no-store directive so that a user can benefit from browser caching but not at the expense of privacy?

Preserving Privacy while Caching

In order to omit the no-store directive and enable instant back/forward navigations while preserving privacy, a way is needed to evict pages from the browser cache when a user logs out. In my research, there are three mechanisms to do this, with various degrees of browser support.

The Clear-Site-Data Header

The most straightforward mechanism to invalidate pages from bfcache would at first seem to be the Clear-Site-Data HTTP response header. This is supposedly Baseline 2023 Newly Available, but there is an asterisk: “Some parts of this feature may have varying levels of support.” Per MDN, this header “sends a signal to the client that it should remove all browsing data of certain types (cookies, storage, cache) associated with the requesting website.” In fact, the cache directive for this header seems to be exactly what is needed, as it even explicitly calls out bfcache:

The server signals that the client should remove locally cached data (the browser cache, see HTTP caching) for the origin of the response URL. Depending on the browser, this might also clear out things like pre-rendered pages, backwards-forwards cache, script caches, WebGL shader caches, or address bar suggestions.

However, note the word “might”. In my testing, sending this header does currently evict pages from bfcache in Chrome. But, there is an open spec question for whether Clear-Site-Data should clear bfcache; it mentions dropping the cache directive entirely, and it suggests that a different executionContexts directive may be more appropriate (but its browser support is even worse and it may be dropped from the spec). Firefox dropped support for the cache directive but then restored it, although in testing it seems Firefox only evicts pages from the HTTP cache and not from bfcache. Finally, Safari doesn’t seem to evict pages from either the HTTP cache or bfcache when this header is sent. 

When/if browser support for this is improved, implementing eviction of pages from browser caches could be as simple as:

add_action(
	'clear_auth_cookie',
	function () {
		header( 'Clear-Site-Data: "cache"' );
	}
);

Ultimately, while this header seems to be tailor-made for evicting pages from browser caches, it cannot be relied on since it is clearly not widely available in Baseline, and not even “newly available” either. There is also a Chromium bug (40233601) where sending this header can greatly delay page response times, possibly causing a logout link to take half a minute to respond. The final mark against Clear-Site-Data is that the header requires a secure context (HTTPS), so the WordPress sites still on HTTP could not evict pages from browser caches using this header (although privacy could be the last of their concerns at this point).

So to preserve privacy, another browser page cache invalidation method is currently needed.

Broadcast Channel

Going back to the aforementioned bfcache blocking reasons, one of them is “broadcastchannel-message”:

While the page was stored in back/forward cache, a BroadcastChannel connection on the page received a message to trigger a message event.

I went down a rabbit hole with this one, thinking I could leverage this blocking reason as a bfcache eviction mechanism. In my discarded implementation, all authenticated pages include a script which listens to a broadcast channel such as “auth_change”. Then, to evict authenticated pages from bfcache upon a successful logout (or logging in as another user), a script can be included on the page which simply broadcasts an arbitrary message to this same “auth_change” broadcast channel. This causes the eviction of any authenticated pages in bfcache which are listening to messages from this broadcast channel.

I was seeing very promising results with this approach, where pages were being successfully evicted from bfcache in Chromium (Chrome/Edge) and Firefox. Nevertheless, eviction was not happening in Safari, which apparently has not yet implemented this blocking reason. However, this approach fell apart once I closed DevTools.

Normally when DevTools is open I have “Disable cache” checked in the Network panel. This disables the HTTP cache, but not the bfcache. What I would see then is if I navigated around the WP Admin and then logged out in a second tab, hitting the back button in the first tab would immediately take me to the login screen. This is exactly what I wanted. However, once I closed DevTools, I started seeing pages served from the browser’s HTTP cache when navigating back/forward. Because the no-store directive is removed, this means the browser may actually serve pages from HTTP cache when navigating back/forward, even when the Cache-Control header has no-cache, must-revalidate, and max-age=0. And here, when the user logged out, they shouldn’t be served from either HTTP cache or bfcache to preserve privacy. So this was not a viable approach in the end.

Just-in-time Page Cache Invalidation

Ultimately, the most reliable solution I’ve found to invalidate pages from both bfcache and the HTTP cache is to do so just-in-time with JavaScript: When a page is restored from a browser cache and it is determined to be stale, the page contents are wiped and the page is reloaded. This approach is also referenced in the aforementioned “Update stale or sensitive data after bfcache restore” section on web.dev, although I’m accounting for pages not only restored from bfcache but also the HTTP cache.

My implementation involves the creation of a new session token when the user authenticates. This session token is served in the HTML with each authenticated page, and it is also set as a wordpress_​bfcache_​session_​{COOKIEHASH} cookie which can be read by JavaScript. When a user logs out, this session token cookie is cleared. Whenever a page is loaded, the session token in the HTML is compared with the current session token in the cookie. When they don’t match, then the page is invalidated. If a page is served from bfcache, then the pageshow event (with persisted true) is used to do this check; if a page is served from the HTTP cache, then the check is done when the script module is executed. If the user had logged out, then reloading the page will take them to the login screen which, after authenticating, will redirect them back to the page they had been on.

As this page cache invalidation mechanism depends on JavaScript, scripting must be enabled to be eligible to omit the no-store directive from the Cache-Control header. This JavaScript detection can be done when the user submits the login form.

This implementation has been made available in a new plugin: Instant Back/Forward. It is available on WordPress.org and on GitHub. This is a feature plugin to implement #63636 in WordPress core.

Demos

In the following demos, I have Slow 4G network emulation enabled along with CPU throttling. This is in order to better simulate what an average user may experience when navigating, such as on a mid-range device potentially with a WordPress site on a shared host.

Demo: Navigating the WordPress Admin

After navigating from the Dashboard to the posts list table and then opening a post to edit, you can see the difference in speed navigating back and forth through the browser history:

Demo: Navigating the WordPress Frontend

Here you can see me draft a message in a BuddyPress activity update. Then I navigate to another URL, and then I go back and forward:

Appendix

WooCommerce has been serving pages with no-store even for unauthenticated users on its Cart, Checkout, and Account pages. This slowed down navigating a store, even though Woo already implements support for ensuring a cart is up-to-date via the pageshow event, as mentioned above. The lack of bfcache means not only that navigating back to the cart is much slower than it needs to be, but there can also be data loss, for example an entered coupon but accidentally not applied. In PR #58445 the sending of no-store was removed. This is slated to be part of v10.1. See before/after demo videos.

Similarly, in Jetpack certain admin screens are sending no-store which slow down back/forward navigations. In Jetpack 14.9, PR #44322 removes this and greatly speeds up navigating to/from Jetpack admin screens, as seen in the demo videos.

Sometimes the instantaneous navigations enabled by bfcache (and prerendering in Speculative Loading) can be a bit jarring, since pages load faster than expected. So the Instant Back/Forward plugin pairs well with the View Transitions plugin which now features an Admin View Transitions opt-in. This helps smooth the overall experience.

Special thanks to Kinsta for sponsoring part of my time contributing to WordPress while I’ve been between full time roles. I also discussed this bfcache project in my “From Cassette Tapes to Core Commits: Weston Ruter’s WordPress Journey” interview with Roger Williams last week.

Where I’ve shared this, if you want to boost:

• LinkedIn
• Bluesky
• Mastodon
• Twitter
• Threads

The post Instant Back/Forward Navigations in WordPress appeared first on Weston Ruter.

There’s a 2-year old Gutenberg issue (#52185) which reported the underlying problem here that the Video block should have width and height attributes added to prevent layout shifts. Such jank causes a poor user experience and negatively impacts the Cumulative Layout Shift (CLS) metric of Core Web Vitals (CWV).

A dimensionless video element gets a 2:1 aspect ratio placeholder (a 300×150 default object size) until the video’s metadata is loaded, at which time a layout shift happens due to the new dimensions being applied. When there’s a poster attribute, the placeholder dimensions get replaced with the dimensions of the poster image once it loads, also resulting in a layout shift; lastly, if the poster image doesn’t have the exact same dimensions as the video, then a second layout shift occurs once the video starts playing.

Take a look at these screen recordings of a Video block without a poster and then with a poster provided (and there’s a script on this test page that starts video playback after 4 seconds):

The layout shifts are somewhat exaggerated here because:

1. A vertical/portrait video is used.
2. A network delay is added to slow down the loading of the poster and video (which is not unexpected on a mobile connection).
3. The poster image doesn’t have the same dimensions as the video.

In any case, such layout shifts seem to occur anywhere the Video block is used to some degree.

CLS Passing Rates

Layout shifts from the Video block contribute to WordPress overall having a relatively poor passing rate for CLS. On desktop, 71% of WordPress origins have a good CLS passing rate, while on mobile the passing rate is 82%. (CLS is worse on desktop presumably because more content is on the screen at a time, meaning there are more opportunities for layout shifts to appear in the viewport.) When evaluating these CLS passing rates in terms of academic letter grades, WordPress is getting a B− on mobile and a C− on desktop. When comparing WordPress to other popular CMS platforms, it ranks near the bottom with only Joomla performing worse, as seen in this table sorted by desktop:

Graphs of origins with good CLS over time

Desktop

Mobile

The passing rates for WordPress are unsurprisingly very close to the passing rates for the web overall (any technology) since WordPress has the largest market share by far. Whenever WordPress performs badly, the web as a whole suffers. Whenever WordPress performs well, the web as a whole improves. This was the drive behind my “scaled activation” Chrome team at Google when I was sponsored there to work on WordPress performance full time.

Now, CLS in WordPress is not nearly as problematic as Largest Contentful Paint (LCP), which is getting an F grade for its passing rates of 54% on mobile and 65% on desktop. Because of this, improving LCP has been the primary focus for us on the WordPress Core Performance Team, and the metric has improved thanks in part to adding fetchpriority=high to LCP-probable img tags, adjusting image lazy-loading heuristics, optimizing the emoji loader, and most recently landing Speculative Loading. And work continues on improving LCP, for example, by deprioritizing non-critical scripts and by leveraging client-side metrics to more accurately prioritize images via the Optimization Detective project (see also my talk).

The other CWV metric, Interaction to Next Paint (INP), is in relatively great shape with a passing rate of 85% on mobile (B) and 98% on desktop (A+).

So, in parallel with the continued work to improve LCP, it’s important to not neglect WordPress’s sub-optimal CLS passing rate. Prior work to improve CLS included adding width and height attributes to img tags for the sake of lazy-loading. There’s also a ticket (#59119) to measure CLS in performance tests. Additionally, a key feature of the Embed Optimizer extension to the aforementioned Optimization Detective plugin is the reduction of layout shifts caused by embeds that resize when they load. This is commonly seen in embeds for Twitter, Bluesky, and WordPress itself. Embed Optimizer keeps track of these embeds’ resized heights. Then, with these resized heights stored, Embed Optimizer sets the appropriate height on the container figure element as the viewport-specific min-height so that when the embed loads any layout shift is minimized.

Lastly, coming back to the impetus of this post, there’s the issue of layout shifts in the Video block.

Fixing the Video Block

Preventing layout shifts in the Video block is straightforward. As described in the Gutenberg issue, the width and height attributes need to be supplied on the video tag, although a bit more is needed than just that. When a video is uploaded to the Media Library, the metadata is obtained via the wp_read_video_metadata() function, including its width and height. Assuming that reading the metadata was successful, these dimensions can then be injected into the video tag in the same way as dimensions are being added to the img tag. (For external videos added by URL not uploaded into the Media Library, the dimensions could be read client-side in the block editor or they could be gathered via Optimization Detective on the frontend.)

This goes full circle for me because we did something similar in 2018 (7 years ago!) to add dimensions to videos in the AMP plugin when converting from the video tag to the amp-video component. The AMP HTML spec mandates (generally) that all elements must have dimensions supplied to prevent layout shifts, as the first of AMP’s design principles is to prioritize the user experience. As I mentioned in my recent contribution retrospective, AMP predates CWV; as part of contributing back lessons learned from AMP to the whole web, it “invested in defining additional metrics that would paint a more holistic image of user perceived performance.” This included a “Layout Stability” metric which came to be known as CLS.

In addition to providing the width and height attributes, for the video to scale to fit its container and to have the correct aspect ratio, the element needs to be styled with height:auto since it has width:100%. Finally, because of an issue in the CSS spec (as highlighted by Jake Archibald), the width and height need to be replicated in an aspect-ratio style. This currently has to be added as an inline style since the following desired use of the attr() function in a style rule is currently only supported in Chromium:

.wp-block-video video[width][height] {
	aspect-ratio:
		attr(width  type(<number>)) /
		attr(height type(<number>));
}

I’ve submitted the fix in Gutenberg pull request #70293: Fix layout shift caused by video tag in Video block lacking width and height.

And since I didn’t want to wait for that fix to be merged and available in a new Gutenberg release, I also adapted it into a standalone Layout-stabilized Video Block plugin which is active here on my blog (since I wanted to share those AI-generated bison videos!). Please install the plugin on your site and test how it works with your Video blocks.

Compare the above screen recordings of layout-shifting Video blocks with the following screen recordings where the fix is applied:

for video in *.mov; do
  ffmpeg \
    -i "$video" \
    -vf "scale=-2:1080" \
    -c:v libx264 \
    -preset medium \
    -crf 30 \
    -an \
    -b:a 128k \
    -movflags \
    +faststart \
    "${video/.mov/.mp4}"
done

You can try loading this post without the fix by adding a special query var to the URL (and then keep hard reloading to see more layout instability).

And now, with the layout shift fixed, let’s get to the bison videos.

AI Bison Videos

The following Veo-generated videos were downloaded from Gemini and uploaded without any transcoding, although they are encoded quite well for the web at ~3MB each for 8 seconds of high quality 720p video with audio. I manually selected a representative frame of each video to create the poster images.

This first video leans a little too hard into the “mustache” of the Mustache Farmer:

I like how this guy seemingly pretends he didn’t know where the bison was in the open field, “Oh, there you are buddy!”:

Awkward running:

A somewhat less awkward run:

There’s an invisible stirrup in this one:

Apparently Tom Cruise with maniacal laughter and a magically-appearing saddle:

Just heartwarming:

The guy’s smile is a little intense in this one, but it’s also heartwarming:

This guy seems a little fake (almost like he’s AI):

Nice purring sound effect, followed by flapping bird wings?

Cozy, but the cat glitches a bit at the end:

Now I’m going to go pet my real cat.

Where I’ve shared this:

• LinkedIn
• Bluesky
• Mastodon
• Twitter
• Threads

The post Eliminating Layout Shifts in the Video Block appeared first on Weston Ruter.

Update 2025-09-03: In commit r60704, scripts and script modules support registration with fetchpriority, and the Interactivity API script modules and comment-reply script both use low by default. This is milestoned for WP 6.9 (scheduled for December 2025), but you can use a plugin in the meantime.

The past week I’ve been doing a deep dive into the performance impact of how WordPress loads script modules for the Interactivity API. When the Interactivity API was first introduced, it used classic non-module scripts which were printed at the end of the body (i.e. in the footer, at wp_footer) so that they would not block the critical rendering path. With support for script loading strategies in core, I added defer to these scripts and moved them to the head (i.e. at wp_head) in block themes, reasoning:

Leaving them in the head is advantageous because it means the browser will discover these scripts earlier and start loading them with other page resources, but the presence of defer means that they will no longer block page rendering.

Ultimately, when the Interactivity API was fully launched in WordPress 6.5, it had switched to using script modules. One great thing about script modules is that they don’t block rendering: they have the defer behavior by default. This means that they are safe to place in the head, and they continue to be printed there in block themes. (In classic themes, the block scripts are printed in the footer since blocks aren’t parsed before wp_head runs.) However, as I’ve been researching the past week, there can still be negative implications to the LCP metric when these script modules are discovered early, even though they don’t block rendering.

I set up a vanilla test site with Local WP and the Twenty Twenty-Five default theme active. I configured the theme template and post content so that all block configurations which depend on the Interactivity API are present:

• The theme template has a Navigation block with the mobile overlay menu enabled (which is the default).
• A Search block is added to the header with the “Button only” configuration which depends on the Interactivity API.
• The post content starts with an Image block whose IMG is the LCP element. It is configured to “Enlarge on click”.¹ This uses a photo of a Bison of course.
• After a few paragraphs of Lorem Ipsum, I added a File block for a PDF with “Show inline embed” enabled.
• The “More Posts” section of the template has a Query Loop which has its “Reload full page” advanced setting turned off.

In the end, this results in the following markup being printed in the head (from the full page source with some prettying):

<script type="importmap" id="wp-importmap">
{
	"imports":{
		"@wordpress/interactivity": "/wp-includes/js/dist/script-modules/interactivity/index.min.js?ver=55aebb6e0a16726baffb",
		"@wordpress/interactivity-router": "/wp-includes/js/dist/script-modules/interactivity-router/index.min.js?ver=dc4a227f142d2e68ef83",
		"@wordpress/a11y": "/wp-includes/js/dist/script-modules/a11y/index.min.js?ver=b7d06936b8bc23cff2ad"
	}
}
</script>
<script type="module" src="/wp-includes/js/dist/script-modules/block-library/file/view.min.js?ver=fdc2f6842e015af83140" id="@wordpress/block-library/file/view-js-module"></script>
<script type="module" src="/wp-includes/js/dist/script-modules/block-library/image/view.min.js?ver=e38a2f910342023b9d19" id="@wordpress/block-library/image/view-js-module"></script>
<script type="module" src="/wp-includes/js/dist/script-modules/block-library/navigation/view.min.js?ver=61572d447d60c0aa5240" id="@wordpress/block-library/navigation/view-js-module"></script>
<script type="module" src="/wp-includes/js/dist/script-modules/block-library/query/view.min.js?ver=f55e93a1ad4806e91785" id="@wordpress/block-library/query/view-js-module"></script>
<script type="module" src="/wp-includes/js/dist/script-modules/block-library/search/view.min.js?ver=208bf143e4074549fa89" id="@wordpress/block-library/search/view-js-module"></script>
<link rel="modulepreload" href="/wp-includes/js/dist/script-modules/interactivity/index.min.js?ver=55aebb6e0a16726baffb" id="@wordpress/interactivity-js-modulepreload">

When loading the page in Chrome, here’s the network panel in DevTools:

Notice how the script modules are being loaded with a high priority and before the all-important Bison image resource is loaded for the LCP element. This is bad. Here’s a view of the waterfall in the Performance panel, where you can see the script modules indeed start loading before the Bison image:

In my tests, both Chrome and Safari set a default fetch priority of high for module scripts and modulepreload links. In Firefox, the default fetch priority for a modulepreload link is highest, while the script modules are loaded with normal fetch priority. In all these cases, the priorities are incorrect. They should all have a fetch priority of low because they are not in the critical rendering path. This is because the very first requirement/goal defined for the Interactivity API was for server-side rendering:

It must support server-side rendering. Server-rendered HTML and client-hydrated HTML must be exactly the same. This is important for SEO and the user experience.

Since blocks using the Interactivity API are intended to leverage server-side rendering, the script modules for these blocks² by definition should not be prioritized over loading other resources which are in the critical rendering path, especially any image resource for the LCP element.

I wanted to find out what the LCP performance impact would be if these script modules had their priorities changed to low from the default of high. The link and script tags both support the fetchpriority attribute, same as the img tag does. While WordPress now facilitates adding fetchpriority to img tags, it doesn’t do the same for registered scripts or script modules. This is what #61734 is about, and it is why I’m analyzing the performance impact. In the same way that WordPress facilitates adding async and defer to scripts, and does so by default for some scripts, there should perhaps be a way to declare the fetchpriority for a script or script module.

Performance of Low Priority Script Modules

In order to benchmark the performance impact, I developed the Script Fetch Priority Low plugin which automatically adds fetchpriority=low to the module scripts used by the Interactivity API, as well as any modulepreload links which are printed for static import dependencies. If a page is loaded with a specific query parameter, then the plugin short-circuits; this allows for doing before/after benchmarks.

With this plugin active, this is the change to the network panel in Chrome DevTools:

Notice how the script modules are now being loaded with a low priority and after the Bison image. This can also be seen in the Performance panel waterfall:

This looks much better. But what is the performance impact in terms of LCP? To analyze that I used the benchmark-web-vitals tool to obtain the median web vitals metrics for 100 requests with and without the reduction in fetch priority:

npm run research -- benchmark-web-vitals --number=100 --output="md" --network-conditions="broadband" --diff \
  --url "http://localhost:10008/bison/?disable_print_script_modules_in_footer&disable_script_fetchpriority_low" \
  --url "http://localhost:10008/bison/?disable_print_script_modules_in_footer"

This is a big improvement! (Each subsequent benchmark test shows the median metrics of 100 iterations, unless otherwise noted.)

The above results were testing while emulating a broadband network connection. Here are the results testing a “Fast 3G” connection:

npm run research -- benchmark-web-vitals --number=100 --output="md" --network-conditions="Fast 3G" --diff \
  --url "http://localhost:10008/bison/?disable_print_script_modules_in_footer&disable_script_fetchpriority_low" \
  --url "http://localhost:10008/bison/?disable_print_script_modules_in_footer"

So there is roughly the same improvement regardless of the network conditions.

I was also curious what the results would be when there was just a single block on the page using the Interactivity API, instead of attempting to add every single interactive block. This is the normal case for all block themes since the Navigation block is almost always present with the mobile overlay menu enabled. So I tested on a template with the Navigation block and a featured image as the LCP element, this time again emulating a broadband network connection:

npm run research -- benchmark-web-vitals --number=100 --output="md" --network-conditions="broadband" --diff \
  --url "http://localhost:10008/bison-no-file-block/?disable_print_script_modules_in_footer&disable_script_fetchpriority_low" \
  --url "http://localhost:10008/bison-no-file-block/?disable_print_script_modules_in_footer"

So even when there is just a single script module along with the modulepreload link, the performance improvement to LCP is consistent.

Printing Script Modules in the Footer

As referred to above, the classic method WordPress has employed to deprioritize scripts is to load them in the footer by supplying in_footer as true when registering a script. What if instead of adding a fetchpriority of low to script modules, they were instead just printed in the footer for block themes in the same way they are already printed in the footer for classic themes? I created the Script Modules in Footer plugin to implement this and to facilitate benchmarking. Here are the results:

npm run research -- benchmark-web-vitals --number=100 --output="md" --network-conditions="broadband" --diff \
  --url "http://localhost:10008/bison/?disable_print_script_modules_in_footer&disable_script_fetchpriority_low" \
  --url "http://localhost:10008/bison/?disable_script_fetchpriority_low"

This shows almost the same improvement as adding fetchpriority of low. However, even when they are located at the end of the body, they are still loaded with a high fetch priority. When script modules are printed in the footer, adding fetchpriority as well yields an additional ~1% improvement to LCP on my test page:

npm run research -- benchmark-web-vitals --number=100 --output="md" --network-conditions="broadband" --diff \
  --url "http://localhost:10008/bison/?disable_script_fetchpriority_low" \
  --url "http://localhost:10008/bison/"

If script modules are all printed with fetchpriority=low, here’s the difference when moving them from wp_head to wp_footer:

npm run research -- benchmark-web-vitals --number=100 --output="md" --network-conditions="broadband" --diff \
  --url "http://localhost:10008/bison/?disable_print_script_modules_in_footer" \
  --url "http://localhost:10008/bison/"

So again, there’s an improvement but not as large as before/after adding fetchpriority=low or printing in the head versus the footer.

Bonus: Deprioritizing Classic Scripts

While classic scripts registered in WordPress already have the ability to be printed in the footer, they can’t be registered with a specific fetchpriority value. It doesn’t make a lot of sense to set a fetch priority for blocking classic scripts since they should always be loaded with the highest priority since they block rendering. However, what about a script that is using the defer or async loading strategies? Chrome automatically assigns such scripts as having a low priority, regardless of whether they are printed at the head or the footer. However, this is not the case for other browsers:

• An async script in the head gets a medium/normal priority in Safari/Firefox.
• A defer script in the head gets a high priority in Safari and a normal priority in Firefox.
• An async script in the footer gets a medium/normal priority in Safari/Firefox.
• A defer script in the footer gets a high priority in Safari and a normal priority in Firefox.

So for the sake of non-Chromium browsers, it absolutely makes sense to be able to register classic scripts with a fetch priority. For example, the comment-reply script is registered as async and is printed in the footer. Explicitly marking this script as having a low fetch priority ensures that loading it will not compete with more critical resources in Firefox and Safari. My Script Fetch Priority Low plugin also implements this.

As an extra bonus, check out my Site Kit GTag Script Deprioritization and Jetpack Stats Script Deprioritization plugins which optimize the loading of analytics trackers by adding fetchpriority=low to the script tags, removing the dns-prefetch, and ensuring the external script tags are printed in the footer.

Conclusion

There are essentially for different configurations for printing script modules on the page:

1. In head with default fetch priority. (This is the current behavior in WordPress core.)
2. In head with fetchpriority=low.
3. At end of body with default fetch priority.
4. At end of body with fetchpriority=low.

Here are the median metrics for benchmarking 1,000 iterations for each of the four configurations:

npm run research -- benchmark-web-vitals --number=1000 --output="md" --network-conditions="broadband" \
  --url "http://localhost:10008/bison/?disable_print_script_modules_in_footer&disable_script_fetchpriority_low" \
  --url "http://localhost:10008/bison/?disable_print_script_modules_in_footer" \
  --url "http://localhost:10008/bison/?disable_script_fetchpriority_low" \
  --url "http://localhost:10008/bison/"

When script modules are printed in the footer and they have fetchpriority=low, the result is a >9% improvement to LCP on my test page:

npm run research -- benchmark-web-vitals --number=100 --output="md" --network-conditions="broadband" --diff \
  --url "http://localhost:10008/bison/?disable_print_script_modules_in_footer&disable_script_fetchpriority_low" \
  --url "http://localhost:10008/bison/"

Of course your mileage will vary. This will primarily benefit block themes. A vanilla WordPress install with the stock theme is very lightweight and a typical site will have a lot more going on which will lessen the impact of these optimizations. But still, with these findings I’ve been working on a pull request for #61734 to implement fetchpriority support for scripts and script modules in WordPress core; it defaults the fetch priority to low for script modules related to the Interactivity API as well as the comment-reply classic script. This feature is a natural progression to follow script loading strategies (async & defer); in fact, we could consider defaulting scripts to add fetchpriority=low if they use the a delayed loading strategy.

I’ve filed #63486 to implement support for printing script modules in the footer. This work can follow the fetchpriority support as it will be more involved due to the need to account for module dependencies.

While waiting for these performance enhancements to land in core, you can install the Script Fetch Priority Low and Script Modules in Footer plugins. Let me know if you measure any LCP improvements!

Where I’ve shared this:

• LinkedIn
• Bluesky
• Twitter
• Mastodon

Shameless plug: I found out last month that my 6½-year position at Google was eliminated. I was hired to work on WordPress full time, and I’ve been contributing to WordPress as a core committer for over 10 years. Most recently I’ve worked heavily on the Core Performance team. I’m currently #opentowork, hoping to find a full time position as a sponsored contributor at another company that also cares about the health of the open web. Alternatively, I’m exploring the feasibility of being sponsored as an independent contributor. If you find my open source work valuable, maybe you can help sustain my contributions?

Update: I’m no longer seeking additional sponsorship. (It’s good!)

1. I used an Image block as opposed to setting the featured image so that I could use the “Enlarge on click” setting which involves the interactivity, but see also my post about how the Featured Image block can also be extended with a lightbox. ↩︎
2. The one exception here is the File block when a PDF is selected and the “Show inline embed” setting is enabled. In this case, JavaScript runs when the block initializes to populate the hasPdfPreview state, and this then changes the element’s hidden state from true to false if the browser supports rendering PDFs. This is an exceptional case, however, and it would be rare for a File block to appear in the initial viewport and be the LCP element. The script module for the File block should only have a high fetch priority if (1) a PDF is selected, (2) the “Show inline embed” setting is enabled, and (3) the block appears in the initial viewport (on desktop or mobile). This is something that Optimization Detective could facilitate. ↩︎

The post Improve LCP by Deprioritizing Script Modules from the Interactivity API appeared first on Weston Ruter.

I was expecting the Featured Image block to have an “Add caption”/“Remove caption” button in the block toolbar. This is available in the regular Image block, but it is absent in the Featured Image block:

It turns out there is a 3-year old Gutenberg issue (#40946) about this missing capability in the Featured Image block. But this isn’t the only missing feature from the block. In addition to the caption, something else I was missing is the ability to open the featured image in a lightbox, something which the Image block exposes by selecting the link option to “Enlarge on click”. The Featured Image block does not have this Link button in the block toolbar but instead just has a “Link to Post” setting toggle in the block sidebar:

There is also an open Gutenberg issue to add this lightbox capability to the Featured Image block (#57849).

Because I want these features now before they get implemented in Gutenberg, I’ve put together a couple plugins (on GitHub) that extend the Featured Image block with these missing capabilities:

• Featured Image Block with Caption
• Featured Image Block with Lightbox

These are active on this site, so you can see above how the featured image is enhanced with a caption and lightbox.

While the Gutenberg issue for adding a caption has a workaround involving the registration of a new block variation, I wanted there to be the same “Add caption” block toolbar button which is available on the Image block, and I wanted to be able to see a placeholder for how the caption would look in the Site Editor. So this is what I implemented:

Selecting “Add caption” sets a new showCaption block attribute to true, without making any changes to the block markup. This means there won’t be any block validation errors when the plugin is deactivated. When the block attribute is present, a render_block filter in PHP injects the caption into the block’s markup on the frontend. On my site, I edited the Single template to show the caption in the Featured Image block, but I left the caption off for the block on the Home template in order to keep the blog index clean. Editing the text of a Featured Image block’s caption is not done inline in the block editor as is done with the Image block; instead, editing the featured image caption requires either selecting the image in the Media Library in the post editor, opening the image in the Media Library screen, or opening it in the seldom-accessed Edit Media screen.

The plugin to implement a lightbox for the Featured Image block is much simpler, and there is no UI. There’s simply another render_block filter which checks to see if the “Link to Post” setting is enabled, and if not, then it enables the “enlarge on click” functionality. Normally the “Link to Post” setting is not enabled on the Single template, allowing the featured image to open in a lightbox the same as any other Image block which have lightbox enabled. The implementation was trivial because all it needed to do is enqueue the same script module and stylesheet as the Image block does, and then it passes the block content into the same function used by the Image block. In the end, the Featured Image block’s markup looks very similar to the Image block’s markup:

--- image-block.html
+++ featured-image-block.html
@@ -1,11 +1,12 @@
 <figure
 	data-wp-context='{"imageId":"68293cf73baf0"}'
 	data-wp-interactive="core/image"
-	class="wp-block-image size-full wp-lightbox-container"
+	style="aspect-ratio: auto"
+	class="wp-block-post-featured-image wp-lightbox-container"
 >
 	<img
 		alt=""
-		class="wp-image-8"
+		class="attachment-post-thumbnail size-post-thumbnail wp-post-image"
 		data-wp-class--hide="state.isContentHidden"
 		data-wp-class--show="state.isContentVisible"
 		data-wp-init="callbacks.setButtonStyles"
@@ -25,6 +26,7 @@
 			http://localhost:10013/wp-content/uploads/2025/05/American_bison_k5680-1-1536x1002.jpg 1536w,
 			http://localhost:10013/wp-content/uploads/2025/05/American_bison_k5680-1-2048x1336.jpg 2048w
 		"
+		style="width: 100%; height: 100%; object-fit: cover"
 		width="2560"
 	/><button
 		class="lightbox-trigger"

Ultimately, I think the Featured Image block could be deprecated in favor of adding a “Use featured image” source to the Image block. This would allow all of its features to be re-used in a featured image context. I suppose “Link to Post” would have to be added as one of the Link options when the featured image is used as the source.

I hope this is helpful for you with building sites with block themes while waiting for these features to land in the core Featured Image block!

Where I’ve shared this:

• Bluesky
• LinkedIn
• Twitter
• Mastodon

The post Adding Caption & Lightbox to the Featured Image Block appeared first on Weston Ruter.