WordPress Planet

Image for: WordPress Planet

June 08, 2025

Do The Woo Community: Rebrand: Expanding the Open Web Conversations Show

Image for: Do The Woo Community: Rebrand: Expanding the Open Web Conversations Show
The episode introduces the show Open Web Conversatioins during the Open Channel FM's rebranding series, featuring insights from builders and innovators on digital identity, emerging technologies, and online creativity, inviting listeners to engage.

by Bob Dunn at June 08, 2025 09:20 AM

June 07, 2025

WordPress.org blog: WCEU 2025: A Community Celebration in the Swiss Sun

Image for: WordPress.org blog: WCEU 2025: A Community Celebration in the Swiss Sun
Photo by Nilo Velez

Over 1,723 attendees from 84 countries gathered at the Messe and Congress Center Basel in Switzerland, and 20,353 more joined online for WordCamp Europe 2025.

I’m personally very excited… There’s so much I want to do. I think there’s a clear pathway to 7.0 and beyond…

Matt Mullenweg, WordPress Cofounder

The flagship WordPress event kicked off in Basel, Switzerland, with a dedicated Contributor Day. It was followed by two days of engaging talks, panels, hands-on workshops, and vibrant community connections. WordPress Cofounder Matt Mullenweg and Executive Director Mary Hubbard joined a diverse lineup of speakers and panelists, sharing insights in the heart of one of Europe’s most charming cities.

Set against the backdrop of Basel’s historic streets and Rhine-side views, the sponsor hall buzzed with activity as companies from across the WordPress ecosystem showcased their latest innovations, offered live demos, and connected with attendees. Each day, participants refueled with a range of local and international cuisine — from Swiss specialties to global favorites — making mealtime a lively space for networking, collaboration, and sparking new ideas.

A Global Gathering in Basel

Image for: A Global Gathering in Basel

WordCamp Europe has long been one of the most anticipated WordPress events of the year — a space where community, creativity, and collaboration thrive. This year in Basel, the conference delivered an exciting and diverse program that reached every corner of the WordPress ecosystem.

Here’s what attendees experienced:

  • Engaging Sessions Across Tracks – Across two full days, the conference featured informative talks, captivating keynotes, and dynamic discussions exploring WordPress and the broader web.
  • A Global Speaker Lineup – The stage welcomed 52 speakers from 23 countries across five continents, each bringing unique insights and global perspectives.
  • Wide-Ranging Topics – The schedule included 45 sessions and four hands-on workshops across three tracks, covering:
    • Accessibility and key policy updates like the European Accessibility Act and the Cyber Resilience Act
    • The evolving role of Artificial Intelligence in the open web
    • Cutting-edge web design, development best practices, SEO, and content strategy
    • Real-world case studies and showcases from across the community
  • Hands-On Learning Opportunities – Interactive workshops allowed attendees to roll up their sleeves and develop practical skills in a collaborative setting.
  • A Community Built on Collaboration – Whether developer, designer, content creator, or entrepreneur, every attendee found space to connect, learn, and grow within a vibrant and welcoming community.

Contributor Day

Image for: Contributor Day

WordCamp Europe began with a vibrant Contributor Day that brought together 640 contributors—including many first-timers—to collaborate, share knowledge, and support the WordPress project. Guided by 33 dedicated table leads, with 21 teams, attendees of all experience levels came together to exchange ideas, solve real challenges, and make meaningful contributions to open source. From accessibility improvements to theme development and translation efforts, every table played a part in moving WordPress forward.

Contributor Day at WordCamp Europe 2025 brought together a mix of first-time and returning contributors across a wide range of teams, from Core and Accessibility to Polyglots, Training, and Community. Attendees tackled everything from onboarding and ticket triage to translating strings, improving documentation, and enhancing tools and workflows. Development-focused teams explored performance and testing improvements and worked through live coding exercises. Meanwhile, accessibility testers, support volunteers, and photo moderators contributed to efforts that directly impact users around the world.

In parallel, teams like Marketing, Meta, Hosting, and Sustainability focused on future-facing initiatives—from promoting WordPress through the Showcase and social media campaigns to refining infrastructure, increasing accessibility, and preparing for long-term project growth. Whether contributing to plugins, themes, documentation, or new contributor experiences, participants reinforced the values that power the WordPress project: collaboration, inclusivity, and openness. The day served as a reminder that WordPress is not just software—it’s a community built by and for everyone.

Tomorrow Starts with WordPress

Image for: Tomorrow Starts with WordPress

The first full day of WordCamp Europe 2025 brought the community together to celebrate the power of open source collaboration and innovation. Opening remarks from both global and local event leads reflected on the journey of WordCamp Europe—from its beginnings in 2013 in Leiden, Netherlands, to the vibrant event in Basel today. This full-circle moment underscored the growth of the WordPress community, united by a shared commitment to an open web.

The day launched into an inspiring program with the keynote session, WordPress Without Borders – The Fight for Digital Freedom, delivered by Noel Tock. Drawing from his experiences—including time on the frontlines in Ukraine—Tock illustrated how open source supports global resilience and serves as a digital human right. His message called on contributors to see their work as part of something greater, offering a compelling and forward-looking vision to energize and unify the WordPress community.

From there, the program unfolded across multiple tracks—each one sparking new conversations and insights. One standout session highlighted social entrepreneurship in Bulgaria, where WordPress is helping grassroots organizations drive change in education, journalism, and social justice. Petya Raykovska shared how nonprofits like Teenovator and the Bulgarian Fund for Women are using WordPress to amplify their work and strengthen their communities.

Designers and developers explored ways to improve workflows and collaboration. In Bridging Design and Development, attendees learned how Figma Design Systems can connect design and development through shared structures mapped to block themes. Real-world examples, like the Novus Media Newspaper Design System, demonstrated how scalable, consistent design can power multi-brand platforms.

Workshops played a key role throughout the day, including the interactive Block Developer Cookbook: WCEU 2025 Edition, where attendees worked through community-voted code recipes featuring the latest WordPress APIs. Sessions also dove into emerging technologies, such as Automating WordPress Setup with Modern AI Tools, which showcased how WP-CLI, scripting, and AI can accelerate project setup and reduce repetitive tasks.

Photo by Marc Wieland

Day Two of WordCamp Europe 2025 opened with a focus on the evolving role of the WordPress community in a rapidly changing digital world. Sessions explored how contributors—from local meetup organizers to global advocates—play a vital part in shaping WordPress’s future. Talks on inclusivity, such as Over the Rainbow, encouraged attendees to consider how individual actions can help build a more welcoming, representative open source ecosystem. Throughout the morning, the spirit of collaboration and shared purpose remained front and center.

As the day progressed, attention turned to the tools and technologies pushing WordPress forward. From sessions on scaling multilingual sites and managing observability to hands-on workshops, developers explored new ways to streamline workflows and enhance performance. Highlights included WordPress Gems for Devs, which introduced the Interactivity API through live coding, and Client-side Web AI Agents, a look at cutting-edge browser-based AI that unlocks new possibilities for web experiences. These talks reflected the platform’s growing capacity to adapt to emerging trends while staying true to its open foundations.

The afternoon brought a blend of practical guidance and inspiring stories across tracks. A case study on accessibility from Switzerland showed how thoughtful design can benefit all users, while a session on brand-building for women entrepreneurs highlighted the creative and economic opportunities WordPress enables. With topics spanning content strategy, business growth, regulatory readiness, and more, the second day of WCEU 2025 affirmed the strength of the WordPress ecosystem—not only as a technology platform, but as a global movement fueled by people, purpose, and possibility.

Fireside Chat

Image for: Fireside Chat

As the final day drew to a close, Matt and Mary shared some thoughts on EU regulation (Open Web Alliance), AI, and the introduction of the WordPress AI team, and then answered questions from the audience.

Closing

Image for: Closing

A heartfelt thank you to the dedicated organizers who brought WordCamp Europe 2025 to life in Basel, the speakers who shared their insights, the attendees who joined us in person, and those who followed along from afar. We hope you leave with fresh ideas, meaningful connections, and renewed energy to help shape the future of the open web.

Be sure to mark your calendars for the final major WordPress events in 2025: WordCamp US (Portland, Oregon, USA). Then join us in Kraków, Poland for WordCamp Europe 2026! Also, if you want to get involved with WCEU, the call for organisers is already open for 2026.

by Brett McSherry at June 07, 2025 07:19 PM

WordCamp Central: WordCamp Jinja 2025 Recap: An impactful 2 days of learning, diverse speakers, hands-on workshops, contributions, charity website hackathon, and celebration of WordPress on the Nile

Image for: WordCamp Central: WordCamp Jinja 2025 Recap: An impactful 2 days of learning, diverse speakers, hand

From May 24th to 25th, 2025, we had the fourth annual WordCamp Jinja at the largest educational institution in the region Jinja Senior Secondary School. This year’s event was our biggest and most impactful yet both in numbers and key demographics, having over 250 attendees and participants that primarily included students as well as developers, designers, bloggers, educators, and entrepreneurs from across Uganda and East Africa.

With the theme “Create, Impact, and Explore with WordPress!”, the event was a celebration of open-source innovation, practical skills, and community spirit, all set against the stunning backdrop of the Nile.

A WordCamp Designed for Student WordPressers, Developers and Creatives Alike

Students were at the heart of WordCamp Jinja 2025, reflecting their role as a key and growing demographic in both the WordPress Jinja community and the wider Ugandan community. This year’s venue Jinja Senior Secondary School—was purposefully chosen to bring the WordPress experience closer to students, ensuring greater accessibility, relevance, and impact.

We welcomed enthusiastic participation from students of Jinja SS, Makerere University, Macedonian Vocational School, Ezone School of Computing, and others. For most, it was their first exposure to open-source tools, and the excitement was palpable. At Jinja SS, the event left a lasting impression—inspiring students to launch their very own ICT Club to continue learning and collaborating long after the event, thus we left a standing souvenir at the school.

As a community, we are intentional about balancing engagement between our student and creative/developer communities. We do this by alternating venues each year to better suit both these key groups and demographics, whether it’s schools, colleges or innovation hubs. We are excited to continue our outreach programs and student-focused initiatives at both Jinja Senior Secondary School and Macedonian Vocational School among other schools, nurturing future WordPress contributors, creators, and tech leaders as well as having creative and developer oriented meetups and next-gen events.

Diverse Speaker Sessions

Attendees enjoyed powerful sessions across two tracks led by speakers from Uganda, Kenya, Rwanda, USA, and beyond. Talks covered everything from advanced contributions, development and accessibility to blogging, diversity, SEO, and AI tools for content creators—sparking learning, inspiration, and engagement throughout the event.

Contributor Day sessions and Website Hackathon Track

Teams collaborated in a WordPress Website Hackathon, that we have been holding each year, building websites for NGOs, community initiatives, and personal projects—all powered by WordPress. It was an energetic, purpose-driven space where learning met real-world impact.

Throughout the event during the hackathon track and culminating on May 25th, participants joined the global open-source movement through the Contributor Day and sessions. From learning how to translate and reviewing content to contributing to the WordPress Photos and Polyglots teams, attendees learned how to give back and make an impact in the WordPress ecosystem.

After-Party on the Nile

The event concluded with an unforgettable after-party at the Source of the Nile, where participants networked, shared stories, and reflected on two days of community connection and creative exploration. The boat ride to the source of the Nile closed off such an eventful experience.

Thank You!

Image for: Thank You!

We are deeply grateful to:

  • Our over 250+ attendees and participants especially all the students for bringing their energy and enthusiasm for learning
  • Our amazing speakers and workshop facilitators
  • Our sponsors and partners for their generous support
  • Our volunteers who made everything run smoothly

Your commitment and passion made this year’s WordCamp Jinja the biggest and most impactful yet!

What Next

Image for: What Next

Don’t forget to follow @WordPressJinja for continued updates.

Uganda is one of the places with the highest turnover of WordPress events and a vibrant, supportive, and passionate WordPress community with over 8 WordPress events a year. Including Next Gens and Do Actions. Next inline is the Uganda Websites Projects Competition on 20th June 2025 and WordCamp Masaka on 18th and 19th July 2025 with more to follow in the coming months.

Remember to join our WordPress Jinja Meetup community for timely updates as well. We can’t wait to welcome you to all WordPress Jinja meetups, creative and developer centric next-gen events and WordCamp Jinja 2026 — which shall be even bigger and more impactful, let’s continue to create, impact, and explore together with WordPress!

by Mohammed Kateregga at June 07, 2025 01:18 PM

Do The Woo Community: Version 6.0 OpenChannels.fm Changelog

Image for: Do The Woo Community: Version 6.0 OpenChannels.fm Changelog
An update to our changelog for OpenChannels.fm 6.0

by Bob Dunn at June 07, 2025 10:19 AM

Jonathan Desrosiers: The Impact of Open Source Work

Image for: Jonathan Desrosiers: The Impact of Open Source Work

There’s been growing debate recently about whether WordCamps have lost their value and relevance. Some argue that attendees rarely share meaningful takeaways afterward, and question whether the talks are impactful enough to provide real learning. They suggest that many people attend only for the travel, social events, and parties. While there may be some truth to these points for certain individuals, I don’t believe this is a fair or accurate generalization.

There are certainly areas where WordCamps could improve. But there are also aspects that stand out as exceptional. They bring together people from around the world and across all walks of life. They celebrate the four freedoms of the GPL and the core ideals that make open source meaningful. And they use the opportunity of being together in person to rally around the shared mission of democratizing publishing.

But like anything in life, these events are only as good the mindset you approach them with.

Meaningful Impact of Open Source Software

Image for: Meaningful Impact of Open Source Software

Yesterday’s keynote at WordCamp Europe struck a deep chord with me. In WordPress without Borders — The Fight for Digital Freedom, Noel Tock spoke about his personal experiences in war-torn Ukraine. Through his non-profit, Dog Help Kharkiv, he works to evacuate dogs from the frontlines before finding them safe, loving homes.

He witnessed how the open web enables life-changing work first-hand. Ukranian organizations are reuniting families or literally changing and saving lives. These initiatives were made possible thanks in part to the work we all do building and maintaining the WordPress software powering tens of millions of websites.

What a powerful reality made possible by the ideals of Open Source.

Sharing Our Stories

Image for: Sharing Our Stories

While stories at the severe end of the spectrum like these are (hopefully) rare, there’s no shortage of instances where the impact of the software we maintain is life changing. But why is it so hard to find them? It’s not because they don’t exist. The people living these stories are just busy doing the actual work: fundraising, helping others, managing the demands of everyday life, and running their businesses.

WordCamps are more than just conferences. They are moments of connection, reflection, and renewal for a global community working toward something bigger than ourselves. The value is not always in the slides or the swag, but in the relationships formed, the perspectives expanded, and the stories shared. But they’re also an opportunity to share our own stories.

If we want WordCamps to improve, we have to show up with purpose. Attend the talks, ask thoughtful questions, introduce yourself to someone new, and share what you learn. Most importantly, we need to be more intentional about sharing the stories that matter.

When we tell stories about a simple blog that helps reunite a family, or a one-page fundraising site that powers a grassroots rescue effort, we remind ourselves why this work is meaningful. These are not outliers. WordPress is designed to be stable, extensible, and accessible so that anyone can build with confidence. And what they build can change lives.

To make WordCamps better, we must make space for stories like these. Seek them out, listen to them, and share them. When we do, we not only rediscover purpose in our work, we also learn from the people who use what we build. But we don’t have to wait for a WordCamp to do this. Reach out. Tell someone how their work has impacted your community, your family, or your life.

As I highlighted in the talk I gave yesterday, every line matters.

Watch the Replay

Image for: Watch the Replay

Featured image credit: CC0 licensed photo by annezazu from the WordPress Photo Directory.

The post The Impact of Open Source Work appeared first on Jonathan Desrosiers.

by Jonathan Desrosiers at June 07, 2025 08:45 AM

Do The Woo Community: Rebrand: Do the Woo Podcast Is Still Here

Image for: Do The Woo Community: Rebrand: Do the Woo Podcast Is Still Here
BobWP updates listeners on the evolution of "Do the Woo," a podcast focused on WooCommerce. It features diverse hosts and segments, catering to all experience levels.

by Bob Dunn at June 07, 2025 06:30 AM

June 06, 2025

Jonathan Desrosiers: How a Core Committer Thinks: Making Decisions for Millions

Image for: Jonathan Desrosiers: How a Core Committer Thinks: Making Decisions for Millions

I just left the stage in Basel after giving my talk at WordCamp Europe. I am really happy with how it turned out, and I hope others found it insightful. There are some points that have stuck with me that I plan to dive into a bit deeper here on my blog in the coming weeks.

Further Reading

Image for: Further Reading

In my session, I covered how the WordPress philosophies and other Open Source decision making frameworks apply to evaluating suggested changes as a Core Committer. If you found yourself wanting to learn more, the philosophies of the WordPress project are largely adapted from some essays by Havoc Pennington.

These concepts are also detailed in Producing Open Source Software: How to Run a Successful Free Software Project by Karl Fogel. My talk submissions are sometimes a way to promote exploring a subject that I am interested in more deeply. While I use the concepts in this talk at depth every time I work on WordPress, this was definitely one of those cases (I’ve had the paperback version of Fogel’s book on my desk for longer than I’d like to admit).

WordPress Lead Developer Andrew Nacin also expanded on the topic a bit in his The qualities of a great WordPress contributor post on his blog.

Watch the Replay

Image for: Watch the Replay

If you missed my talk live, you can watch the replay of the live stream. I’ve included it below and set the video to start when I took the stage.

Slide Deck

Image for: Slide Deck

And here’s my slide deck if you wish to follow along.

The post How a Core Committer Thinks: Making Decisions for Millions appeared first on Jonathan Desrosiers.

by Jonathan Desrosiers at June 06, 2025 04:21 PM

Do The Woo Community: Press Release: Do the Woo Rebrands to OpenChannels.fm

Image for: Do The Woo Community: Press Release: Do the Woo Rebrands to OpenChannels.fm
Do the Woo has rebranded as OpenChannels.fm, expanding its podcast community to cover various aspects of the open web, while still celebrating WooCommerce as a core focus. It's all about diverse voices.

by Bob Dunn at June 06, 2025 08:55 AM

Do The Woo Community: The Rebrand: Do the Woo is now OpenChannels.fm

Image for: Do The Woo Community: The Rebrand: Do the Woo is now OpenChannels.fm
So, the podcast "Do the Woo" is now "OpenChannels.fm"! It’s a cool rebrand to reflect their broader focus on WordPress and open web topics, while still keeping the WooCommerce content. Exciting changes ahead.

by Bob Dunn at June 06, 2025 06:00 AM

June 05, 2025

Weston Ruter: Eliminating Layout Shifts in the Video Block

Image for: Weston Ruter: Eliminating Layout Shifts in the Video Block

Like the rest of the internet, I’ve been awestruck by the quality of Google’s Veo 3 AI video generator (even with audio). As you’ve seen from my posts, the American bison is my favorite animal (aside from my cat of course). Also, perhaps I’ve watched too many videos from the Mustache Farmer, but I realized I could use Veo 3 to realize a fantasy of being able to pal around with what in reality is a wild animal. Generating bison videos brought me a lot of joy so I had to share them. However, I faced a dilemma because I didn’t want to do so via WordPress’s Video block in its current state: it suffers from a bad case of layout shiftitus. Since web performance is an even greater passion of mine than the bison, before I could share the videos I did a deep dive on the problem and came up with a fix. (Skip to the videos below if you don’t care.)

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):

Without a poster, causing a layout shift.
With a poster, causing a layout shift.

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

Image for: 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:

TechnologyDesktopMobile
Wix91% (A−)94% (A)
Shopify82% (B−)90% (A−)
Squarespace77% (C+)88% (B+)
Drupal72% (C−)85% (B)
(Any)72% (C−)79% (C+)
WordPress71% (C−)82% (B−)
Joomla69% (D+)79% (C+)
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

Image for: 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 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:

Without a poster, not causing a layout shift.
With a poster, not causing a layout shift.
Aside: Command used for transcoding screen recordings

I was really impressed with how well FFmpeg compressed the original Quicktime screen recordings from ~32MB down to just ~400KB, and since the args to ffmpeg are always something I have to re-discover, here’s the command for (my) future reference:

for video in $(ls *.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

Image for: 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:

Prompt: A bison falls asleep in the lap of a man in the style 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!”:

Prompt: A bison runs over to a man and affectionately nuzzles him, putting his head next to the man to rub up against him. The man pets the bison’s head and smiles. The bison is the man’s pet.

Awkward running:

Prompt: A bison and a man run toward each other. When they meet, the bison affectionately nuzzles him, putting his head next to the man to rub up against him. The man pets the bison’s head and smiles. The bison is the man’s pet.

A somewhat less awkward run:

Prompt: A bison and a man run toward each other. When they meet, the bison affectionately nuzzles him, putting his head next to the man to rub up against him. The man pets the bison’s head and smiles. The bison is the man’s pet.

There’s an invisible stirrup in this one:

Prompt: A bison kneels down for a man, and the man climbs on the back of the bison and they gallop off into the sunset.

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

Prompt: A bison kneels down for a man to mount on top of the bison. The bison wants to give the man a ride. The man laughs and smiles as he climbs onto the back of the bison and they gallop off into the sunset.

Just heartwarming:

Prompt: A bison walks up to a man. The bison rubs his head against the man, nuzzling him like a cat. The man affectionately rubs the bison’s head. The man smiles. The bison could be the man’s pet.

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

Prompt: A man and a bison having fun together, rolling in the grass and wrestling. The bison is the man’s pet.

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

Prompt: A bison is standing close to a man. The man scratches the bison under its neck and he pets the hair on the bison’s head. The bison is enjoying the affection. The man smiles and tells the bison, “You’re such a good boy.” The bison likes the man. The bison is the man’s pet.

Nice purring sound effect, followed by flapping bird wings?

Prompt: A gray tabby cat with faint stripes jumps on top of a bison and starts to knead its paws into the bison’s thick fur. The bison likes it. The bison and the cat are friends.

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

Prompt: A bison is lying down in the grass. A gray tabby cat nuzzles up to the bison and climbs on its back to lie down for a nap. The bison likes the cat’s company.

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


Where I’ve shared this:

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

by Weston Ruter at June 05, 2025 09:09 PM

Felix Arntz: Introducing the View Transitions Plugin for WordPress

Image for: Felix Arntz: Introducing the View Transitions Plugin for WordPress

I’m thrilled to announce a new plugin from the WordPress Core Performance Team: View Transitions! This experimental plugin brings the power of the cross-document View Transitions browser API to your WordPress site, allowing for smoother, animated transitions between page navigations.

View Transitions?

Image for: View Transitions?

Traditionally, moving from one page (or, technically, URL) to another on the web has always involved an abrupt, “hard” reload. While this might seem completely natural to many of us on the web, user expectations have shifted drastically in the past (almost) two decades.

Native mobile applications, with their seamless in-app navigations and smooth transitions, have set a new bar for user experience. This has led web developers to try to catch up with that experience, often turning to Single Page Applications (SPAs). While SPAs aim to mimic native app navigations by dynamically updating content without full page reloads, this often comes with increased development complexity and a shift in how you structure your entire website, often at the cost of accessibility or performance.

Now, with cross-document view transitions, you can achieve that desired user experience through smooth transitions on the web without any extensive overhaul of your website. And the new View Transitions plugin makes it super simple in WordPress.

How Do View Transitions Work in WordPress?

Image for: How Do View Transitions Work in WordPress?

As soon as you have activated the plugin on your WordPress site and navigate between a few pages of your site, you’ll notice that the plugin implements a gentle fade effect for the transition, creating a more graceful and visually engaging user experience. This is the default behavior not only for the plugin, but also for the View Transitions API in the browser.

If you want to see a live demo – you’re on it! The plugin is active on my site, so for example you could click on the “Blog” link in the header navigation. You should see a smooth transition if your browser supports it (see further below). Just make sure to navigate back here afterwards to continue reading. 😁

(If you want to test it more, you could navigate to the home page by clicking on the site title, scroll down to “Latest posts”, then click on the “View post” button for this post. When using a large enough viewport, that transition should expand/morph the small featured image from the post in the grid to the much larger featured image shown above. If the animation is too fast, try clicking the Back/Forward button in your browser a few times to get a better sense of what I’m referring to.)

Because the nature and style of transitions can be heavily dependent on a theme’s specific layout and design, the long-term vision is for themes to opt in and customize this behavior. This is facilitated through the WordPress theme support API, for instance by calling add_theme_support( 'view-transitions' ).

For now, since this plugin’s explicit purpose is to enable and showcase view transitions, it automatically enables them across your site, regardless of the theme currently in use.

Customizing View Transitions

Image for: Customizing View Transitions

For this initial experimental phase, the plugin offers a user-friendly way to explore different configurations directly within the WordPress admin. You’ll find settings under Settings > Reading that allow you to tweak the view transitions behavior. This UI is primarily for easy exploration and testing at this early stage. Should view transitions make their way into Core, customization would solely be managed through code via the theme support API. That said, even with this early plugin version, themes can already start using the theme support API.

Customizing with add_theme_support()

To quickly enable view transitions with standard settings, add the following to your theme’s functions.php file (typically within the after_setup_theme action hook):

function mytheme_setup() {
	add_theme_support( 'view-transitions' );
}
add_action( 'after_setup_theme', 'mytheme_setup' );

For more control, you can pass an array of arguments to add_theme_support( 'view-transitions', $args ). Here are the available arguments:

  • default-animation: Specifies the default animation style for transitions.
  • post-selector: CSS selector(s) to identify individual post containers, crucial for applying post-specific transitions from archive/listing pages.
  • global-transition-names: A map (associative array) defining CSS selectors for global elements (like headers or sidebars) and their view transition names that should have persistent view-transition-name values across the entire site.
  • post-transition-names: A map (associative array) defining CSS selectors for elements within post containers (like titles or featured images) and their view transition names that should animate during transitions to/from single views.

To provide additional context on what the view transition names are for: Whenever an element has the same view transition name assigned between two URLs that the user navigates between, it will gently morph as part of the transition, maintaining a clear association. For example, a post title in a grid of posts in an archive might scale up in size and move to the top of the page when navigating to its single post URL.

For the default-animation, a few animations are available by default. Additionally, the plugin provides an API to register additional animations, each of which encompasses a unique identifier, some configuration values, a CSS stylesheet, and optional aliases. I’m not going to cover this here for now since it’s a more advanced integration, but ideally in the long term there could be plugins or themes that register their own view transition animations that themes could use. For now, a few basic animations are available out of the box, mostly as an example of what can be done. The initial supported identifiers (and their aliases) are:

  • fade
  • slide
    • slide-from-right
    • slide-from-bottom
    • slide-from-left
    • slide-from-top
  • swipe
    • swipe-from-right
    • swipe-from-bottom
    • swipe-from-left
    • swipe-from-top
  • wipe
    • wipe-from-right
    • wipe-from-bottom
    • wipe-from-left
    • wipe-from-top

You can customize any or all of the supported arguments by passing an array to add_theme_support(). Here’s an example modifying all available options:

function mytheme_custom_view_transitions_setup() {
	add_theme_support( 'view-transitions', array(
		'default-animation'       => 'wipe-from-right',
		'post-selector'           => '.wp-block-post.post, article.post, article.entry',
		'global-transition-names' => array(
			'.site-branding' => 'logo',
			'.site-header'   => 'header',
        	),
        	'post-transition-names'   => array(
			// These are mostly just the defaults, but there's one extra entry.
			'.wp-block-post-title, .entry-title'     => 'post-title',
			'.wp-post-image'                         => 'post-thumbnail',
			'.wp-block-post-content, .entry-content' => 'post-content',
			'.post-meta'                             => 'post-meta', // Additional entry.
		),
	) );
}
add_action( 'after_setup_theme', 'mytheme_custom_view_transitions_setup' );

As you can see in this example, which also indicates some of the default values, they aim to capture common patterns that work across block themes and classic themes alike. That said, block themes are likely a perfect fit for view transitions, given their more predictable nature in markup due to using exclusively blocks.

The default values for all the supported arguments are based partly on WordPress-generated classes that should almost always be included in WordPress sites, and partly on very common conventions. The goal is that the defaults should work well for the majority of WordPress sites. That said, it is impossible to make it look perfect for every possible WordPress theme. That’s precisely why the theme support approach was chosen for making View Transitions available in WordPress.

Customizing via Settings > Reading

A limited subset of what can be customized via add_theme_support is made available via the “View Transitions” settings section under Settings > Reading.

You can customize the default animation, and the selectors for the default view transition names for both global and post-specific elements. While this means the customization options are limited via the UI, it still allows you to play around with different configurations via UI, and likely for the majority of sites these are the most relevant parameters to customize anyways. Keep in mind that this UI is only supplemental, and it only exists for easy exploration in the plugin. The recommended way to customize is via add_theme_support in your site’s WordPress theme.

A Note on Configuration Precedence

It’s important to be mindful that, for now, any configurations you make via the Settings UI will take precedence over what is defined in your theme’s code using add_theme_support(). This is something to keep in mind as you test and explore the plugin.

Browser Support

Image for: Browser Support

Cross-document view transitions are currently supported in a range of modern browsers, including Chrome, Edge, and Safari. For users on browsers that do not yet support this API, there should be no adverse effects; they will simply experience the traditional hard transitions between pages. You can always check the latest browser compatibility at caniuse.com.

Your Feedback is Needed!

Image for: Your Feedback is Needed!

If you’re a WordPress theme developer or maintainer, I strongly encourage you to install the View Transitions plugin and give it a spin. Better yet, consider experimenting with adding support directly into your theme using add_theme_support( 'view-transitions' ).

And if you’re simply curious about the feature and want to enable it on your WordPress site, I similarly encourage you to try out the plugin. The Core Performance Team would love to get your feedback.

While this is a fresh first release and still experimental, like other plugins incubated within the Performance Lab program, it holds the potential to one day become a part of WordPress Core.

Your early feedback and real-world use cases will be absolutely instrumental in refining this feature, addressing potential issues, and shaping its future.

Join Us at WordCamp Europe 2025 Contributor Day!

I’m publishing this post in a very timely manner – today is WordCamp Europe 2025 Contributor Day! I’ll be at the Core Performance Team table, and a key part of our agenda will be testing, discussing, and gathering feedback on this new View Transitions plugin.

If you’re attending and are curious to learn more, want to get involved, or have initial thoughts to share, I would love for you to join us. Your insights will be invaluable!

Feedback and Contributions

As this plugin is in its early stages, your feedback is highly encouraged and deeply appreciated.

And of course, contributions are always welcome! You can learn more about how to get involved by checking out the Core Performance Team Handbook.

I’m really excited to see how the community uses and shapes this new feature!

The post Introducing the View Transitions Plugin for WordPress appeared first on felix-arntz.me.

by Felix at June 05, 2025 04:09 AM

June 04, 2025

Tammie Lister: May in WordPress

Image for: Tammie Lister: May in WordPress

This month was full of backlog management, prioritisation and clearing out queues. I focused on identifying where things were blocking and preparing for WordCamp Europe.

Areas of contribution

Whilst my focus was on backlog management, it split into two distinct areas:

  • Closing tickets: I focused on Trac and the Gutenberg repo for this. Make sure to go oldest first.
  • Focusing design: Ensuring the design queue was clear about what needed design and what required feedback. This was something that arose from contributor input as a point of confusion, and I have made considerable progress through this. I worked on issues, focusing on having only one of those states, and also addressed items in ‘needs design’ that were truly ready for implementation, having an agreement in place. This work does need to continue.

I also began thinking about how to optimise and make reporting easier for backlog management, and I want to bring those discussions to WordCamp Europe. 

Some stats across the backlog management of issues and tickets in Trac and Github.

  • Triaged: around 143
  • Closed: 60
  • Prioritised in design: around 49

In other contributions, I worked on some designs and gave feedback across a range of tickets. I also began exploring how far DataViews can go and have a list of things to now report from this. It reminded me of the value of pushing the boundaries of our learning features.

Upcoming plans for contribution

The big event is WordCamp Europe, which is taking place this week. I will be attending Contribution Day. After that, the following are my objectives:

  • Extensibility: Continue my focus on work there and prioritise how to establish criteria for what gets in and what does not. Hopefully, unblocking a range of issues during WordCamp Europe.
  • Backlog management: My work is constant, but I want to explore how it can evolve smarter, potentially utilising systems to manage and enhance workflow.
  • Papercuts: After WordCamp, I will pick this up again with several issues to focus on.

With WordCamp Europe, I am restricting my plans beyond what I have mentioned above, as things will likely emerge from it and change.

Sponsors this month

I now have three company sponsors: BigScootsGreyd and Kinsta. I also have five sponsors through GitHub: Aaron JorbinTim NashJeffrey PaulFelipe Santos and Scot Rumery. To everyone who sponsored me and helped me secure a sponsorship, thank you.

Want to sponsor me? You can go through GitHub or also get in touch.

There is always sponsorship, of course, that is volunteered, and I’ll do as much as possible whilst still keeping things flowing – let’s get contributing!

by binatethoughts.com at June 04, 2025 08:48 AM

June 03, 2025

Jonathan Desrosiers: WordPress Grab Bag: WCEU, WordPress turns 22, new AI team

Image for: Jonathan Desrosiers: WordPress Grab Bag: WCEU, WordPress turns 22, new AI team

I haven’t been doing a great job blogging regularly so far this year. We’ve now passed the 40% mark of the calendar year, and I’m hoping to make up for that during the remaining 60% of the time. To get started, here are some thoughts on a few topics that have been on my mind over the course of the last week.

Attending and presenting at WordCamp Europe

Image for: Attending and presenting at WordCamp Europe

I’m currently sitting in Terminal A of Boston Logan International Airport waiting for the first leg of my journey to attend WordCamp Europe in Basel, Switzerland. In addition to the obvious reasons to be excited (seeing friends, meeting new people, checking out what everyone in the community has been building), I’m also really happy with what my presentation has grown into and can’t wait to present it. It’s not just about the decision making frameworks Core Committers use, but also a reflection on the project’s foundational philosophies and how they’ve helped the project thrive.

There are several points in my speaker notes that have stuck with me. I plan to write some additional posts to explore deeper in the coming weeks!

If you’re unable to join in person, I’m including the live stream below.

WordPress reaches 22 years old

Image for: WordPress reaches 22 years old

Last week was the 22nd birthday for the WordPress project. The first version of the software was released on May 27, 2003. While 22 is not as exciting as 21, I always enjoy reading the reflections from the community and seeing how the software we all help maintain has changed lives.

I first used WordPress around 2007, and received my first credit for contributing in 2013. This means I’ve now been a user of WordPress for over 80%, and a contributor for over 55% of the project’s lifespan.

Happy Birthday WordPress!

New WordPress AI team

Image for: New WordPress AI team

Also last week, a post was published to announce the formation of a new AI team for the project. I’m really looking forward to this team getting started. Initially, the stance of the Core team was to observe and wait for the needs to become more clear. But the time has come to explore taking action in some important areas. Specifically extensibility of the block editor, documentation, and ensuring any necessary internal functionality is available through APIs.

Near term, I think once some of these items have a plan to be addressed, what could make the most sense is several canonical AI plugins that integrate with different models or services similar to how importing site content works (WordPress, Tumblr, Movable Type/TypePad, etc. each have their own plugin).

If you have thoughts about the place AI has in the project, join the conversation in the #core-ai channel of the WordPress.org Slack!

Featured image credit: CC0 licensed photo by Nilo Velez from the WordPress Photo Directory.

The post WordPress Grab Bag: WCEU, WordPress turns 22, new AI team appeared first on Jonathan Desrosiers.

by Jonathan Desrosiers at June 03, 2025 11:32 AM

June 01, 2025

Tammie Lister: Optimising Triage and Review Processes in WordPress Using AI

Image for: Tammie Lister: Optimising Triage and Review Processes in WordPress Using AI

Integrating advancements into open source processes makes sense. The friction often comes in the how and the usefulness. While AI holds immense potential for revolutionising triage and review processes, it’s crucial to acknowledge its current limitations and look to where it can evolve, learn, and grow to its full capacity. This post aims to explore this potential, offering a realistic perspective. It’s not a post that claims to solve everything; instead, it will show how we can get started and regain some hours to focus on other needed areas of the project.

Before we delve into this topic, it’s important to note that while AI can achieve a great deal, it also has its limitations. This post will focus on high-level inferences rather than direct proposals, starting with small steps. I don’t have all the answers, but together, we can find them. My perspective is informed by extensive theme reviews and ongoing triage work, so I won’t cover areas where I lack knowledge.

What can it do today

Image for: What can it do today

In simple terms, the things we likely shouldn’t be doing manually include reviews, first-pass triage, testing and routine checks. Historically, there have been areas where we have been slowly adding more processes over time before the term AI was widely used. That’s one of the key things: often, having a robust process, a path trodden and documented, means the parsing is simple to learn, and therefore you can hand it over more easily.

Triage is already being done incredibly effectively in areas like healthcare. There it is improving accuracy and saving lives, as noted in an article by Reuters:

“Our study provides the first multinational evidence that artificial intelligence can help enhance accuracy” in determining HER2 clinical categories, “potentially closing critical diagnostic gaps and enabling more patients to have access to new therapies, said Dr. Marina De Brot of the A.C. Camargo Cancer Center in Sao Paulo, Brazil, who led the study.
“Until recently, most of these patients would have not been offered these options,” she said.”
Link: Reuters

A triage first-pass

Image for: A triage first-pass

The first area is improving first-pass triages. What do I mean by this? In simple terms, doing a lot of the manual work like duplicate label removal, closing after a specific time, checking for details and even duplicate issue detection. Pattern-matching tasks are where these systems excel, and a lot of this is simply a matter of pointing to our learnings during triage and matching them accordingly.

This is basic; it’s not AI as much as it’s processing. It’s one step above issue templates. The following piece is where it gets interesting: the model for triage needs to learn comprehension of the issue contents. We need to add features like dashboards to the flow because the first stage could be a catch-all that, over time, allows it to triage more to a buffer dashboard, recommending specific states.

All of these approaches are an excellent way of training, as it provides the model with some freedom to make mistakes, be corrected, learn from them, and refine its patterns. We also collectively don’t have to worry about labels being added and things closed. Whilst those of us doing triage, get to benefit early on and help train.

The impact of triage processing

Image for: The impact of triage processing

As far as triage goes, we will be far from achieving full automation of this for quite some time. My instinct is that this is more of a help in clearing a percentage and making it easier for those working on issues. It can do that in significant numbers, to the extent that over 50% of the time spent in triage could be recovered I’d suggest sooner over later. I do see this going up over time, but how much depends on the quality of the modelling and our trust as a project.

Theme review first-pass

Image for: Theme review first-pass

Just as triage, I suggest adopting a similar model for theme reviews. In this case, too, if we are honest, reviewing what we do and don’t want in reviews would be beneficial. I will be bold here, but nearly 100% of theme reviewing could be done through a process without manual interaction fairly soon.

How do we get there? We achieve this through a balance of reviewing the theme review guidelines and, similarly, triage training. These reviews are very formulaic and matching. This is what models thrive on. Suppose we gain trust in this approach and implement the process. In that case, we can then focus all our effort on manual reviewing in various areas, including raising the quality of the core product, documentation, education, and our theme offerings as a project.

Testing

Image for: Testing

We have, over the years, even before the recent AI tech wave, been leaning into less manual testing. Issues and tickets needed less manual testing. We require testing for regression across all areas in our project. That’s not AI, but we can take it even further, adopting a more updated approach to our testing.

The reality of the world today is that you can share a screenshot with code editors and get an application mocked up that looks like that. We also need to evolve our systems to test for differences and minimise the need for multiple humans to be involved in each ticket.

What will we do if it does this?

Image for: What will we do if it does this?

I share these perspectives as someone who performs triage and frequently engages in this manual work. Some may be sceptical or wonder how their sponsored time will be allocated. The point is that there is a great deal that needs to be done in this project. These systems to implement today’s technology need people. The models require training by experts. Then they need to be nurtured and grown by those same people. There will always be a need for contributors.

At this time, with our capabilities in automation and AI in a world of agentic flows, we can do better than relying solely on manual processes. We must do so in order not to be left behind. It is also not resourceful to use humans this way. We can use our scarce human resources more sensibly. Our time is finite, and this project requires us to accomplish many tasks. There will be a balance between what we automate and utilise as resources and what we provide to a system. That, though, is something we need to start working out, and we do that by realising we need to find a balance in how we do things and measure the costs of our processes today and in the future.

by binatethoughts.com at June 01, 2025 12:42 PM

May 29, 2025

Do The Woo Community: Building Reliable WooCommerce Sites: Insights into Hosting, Scaling, and Workflow

Image for: Do The Woo Community: Building Reliable WooCommerce Sites: Insights into Hosting, Scaling, and Workf
Shared strategies to ensure reliable WooCommerce performance during traffic spikes, emphasizing standardized processes, trusted hosting partnerships, and automated testing to foster client trust and ease agency operations.

by Bob Dunn at May 29, 2025 12:38 PM

Do The Woo Community: Launching Upload Worthy: Video Strategy, Brand Awareness, and Conversions for WordPress Product Creators

Image for: Do The Woo Community: Launching Upload Worthy: Video Strategy, Brand Awareness, and Conversions for
The inaugural episode of "Upload Worthy" explores video marketing strategies with hosts Christian Taylor and Adam Weeks. They discuss timing for video investment, brand awareness versus conversions, and measuring content success.

by Bob Dunn at May 29, 2025 09:57 AM

May 28, 2025

WordPress Foundation: Thank You, Automattic: Announcing the Open Horizons Scholarship

Image for: WordPress Foundation: Thank You, Automattic: Announcing the Open Horizons Scholarship

We’re thrilled to announce the Open Horizons Scholarship, a new initiative to help contributors from underrepresented regions attend flagship WordCamp events, made possible through a generous $30,000 donation from Automattic to the WordPress Foundation.

Thank you, Automattic, for funding this important work. Your support expands opportunities for contributors around the world to participate in person, starting with WordCamp US 2025.

The scholarship will be managed by the WordPress Foundation, which will oversee the application and selection process and ensure that funds are distributed equitably. This new program joins the Kim Parsell Memorial Scholarship and the Diversity Scholarship by WordPress Community Support, reinforcing a shared commitment to a more inclusive and globally representative WordPress community.

If your company believes in a more diverse, open, and accessible web, we invite you to join us. Support a scholarship. Sponsor a contributor. Help build the future of WordPress, together

Interested in applying?
Apply for the Open Horizons Scholarship and take your next step toward joining the flagship WordCamp experience. To learn more, you can read Automattic’s full announcement about the program.

by Isotta Peira at May 28, 2025 07:28 PM

WPTavern: #171 – Felix Arntz on How Speculative Loading Is Speeding Up Your WordPress Website

Image for: WPTavern: #171 – Felix Arntz on How Speculative Loading Is Speeding Up Your WordPress Website
Transcript

[00:00:19] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress, the people, the events, the plugins, the blocks, the themes, and in this case, how speculative loading is speeding up your WordPress website.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you, or your idea, featured. On the show. Head to wptavern.com/contact/jukebox, and use the form there.

So on the podcast today we have Felix Arntz. Felix is a Senior Software Engineer at Google, and a WordPress Core contributor from Germany, currently residing in San Francisco, California. He helped establish the WordPress Core performance team, and has been heavily contributing to its efforts. He has been using WordPress for a decade and contributing back to the project since 2015. More recently, he has stepped into the role of the inaugural performance lead for the WordPress 6.2 release, and subsequently of the 6.3 and 6.8 releases. In the latter release, he spearheaded development, and launch, of the new speculative loading feature, which is the focus of the podcast today.

Speculative loading is one of the most important, and yet, almost invisible performance enhancements of recent times. If you’re on WordPress 6.8, this new feature is already active on your site, working quietly in the background to make page navigation faster, but you might never know from the WordPress UI. There’s no menu, no toggle, and no obvious indicator to show it’s there.

Felix explains exactly what speculative loading is and why it feels almost like browser magic. The Ability for WordPress, using the browser’s new Speculation Rules API to load the next page just as the user is about to visit it. It’s a clever use of browser signals like mouse clicks, and hovers, to anticipate navigation, shaving off precious milliseconds, sometimes even providing what feels like an instant page load.

Felix clarifies the difference between conservative and more aggressive approaches to speculative loading. And why the WordPress core team opted for the safest, least wasteful, option by default, while still giving developers or advanced users the hooks and tools to customize, or even disable it, as needed.

Felix discusses the origins of the feature as a plugin, the testing and data collection undertaking with tens of thousands of sites, and how this real world data gave the team confidence to ship speculative loading to all WordPress users. We talk about what those performance wins mean at scale, how a 2% improvement on 43% of the internet translates into saving users untold hours of waiting collectively.

We also get into the weeds on measurement and methodology, how the team uses data from the Chrome user Experience Report and HTTP Archive to track web performance, prioritize features, and validate real world impact. Felix offers insights into how these global, anonymized data, sets allow the performance team to make truly data-driven decisions.

Beyond the tech, Felix addresses practical considerations such as how to opt out or fine tune speculative loading if you have specific needs. How environmental concerns are balanced by default configurations. And how plugins or agencies might build on this foundation in the future.

If you’ve ever wondered how large scale browser level improvements make their way into WordPress Core, or simply want to know if there’s a way to make your own WordPress site that much faster, this episode is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you Felix Arntz. I am joined on the podcast by Felix Arntz. Hello, Felix.

[00:04:46] Felix Arntz: Hey. Happy to be here.

[00:04:47] Nathan Wrigley: Yeah, thank you. I appreciate you joining us. Felix is joining us all the way from California. I’m in the UK so there’s a big time gap. And I appreciate you getting up early and talking to me. That’s fantastic.

Felix is going to be talking to us today about something which is now in WordPress, and you may not even know that it’s in there because there’s nothing to see here. But the endeavor of what Felix has built is to make all WordPress websites basically immediately better. More performant, so that the end users of your websites will be able to access your content more quickly.

It is something that’s really fascinating. But before we begin digging into all that, I know it’s a dreadfully banal question, Felix, but would you just tell us who you are so that people understand your credentials in the WordPress space?

[00:05:32] Felix Arntz: Sure. Thank you. I have been contributing to WordPress now for 10 years. So I started as a freelancer building websites using WordPress, and eventually got into contributing to WordPress Core after I went to my first WordCamp, which was a great way to get started.

Yeah, ever since then I’ve been contributing to WordPress Core, and eventually became a Core Committer. And now, for over six years, I’ve been working at Google, the team where we focus on CMS projects for the most part. So I’ve been, especially in the last good three years or so, I’ve been sponsored by Google to contribute to WordPress with a specific focus on improving performance.

So our team essentially co-founded the WordPress performance team, which is an official part of the wordpress.org project. And ever since that was founded in late 2021, we’ve been contributing to that effort, and the speculative loading feature is a big part of that.

[00:06:25] Nathan Wrigley: That’s what we’re going to talk about today. Can I just rewind a little bit though, and talk about Google for a minute. So, are you employed by Google to commit to WordPress Core? Do you spend a hundred percent of your time working on WordPressy things, or do you have a proportion of your time which is devoted to more, and I’m doing air quotes, Google things?

[00:06:46] Felix Arntz: Yeah, I mean, I wouldn’t say that I contribute a hundred percent of my time, but a good chunk, probably 70, 80 or something. Our focus is, when it’s not on WordPress, it’s still on other somewhat related open source projects. So we have been contributing, we’ve been also working with other CMSs here and there.

[00:07:02] Nathan Wrigley: Yeah, that’s interesting because I know that Google have a big presence. If you go to the flagship WordPress events, you know, WordCamp Asia, WordCamp US, and so on, then Google very often have a huge advertising booth. You know, they’re a global partner if you like.

But drawing the line between Google and Open Source CMS is a little bit hard to do. It’s almost like a philanthropic thing. Because I guess their job is to just try and make the internet better and part of it, if they can make 43% of the internet better by seconding somebody like you to commit to the project, that’s just good for everybody.

So yeah, bravo to Google. I appreciate the fact that they’re sponsoring you and helping the project in that way.

Also bravo to you and the team, the Performance Team. It is just a relentless good news story coming out of the Performance Team. So, I don’t know, when did you say, 2019 it was founded?

[00:07:54] Felix Arntz: Late 2021, but things really kicked off like mid 2022 I feel.

[00:07:58] Nathan Wrigley: Yeah, and I am habitual about the WordPress news, and it just never stops. The Performance Team do something profound, help everybody out, it just ships into Core. Most people don’t even know that things have happened because, you know, they’re not in the baseball in the same way that you and I probably are.

A profound thanks. Maybe there was just this massive backlog of things that needed to be tackled. Maybe not. But it did seem that the minute the doors opened to the Performance Team, lots of dominoes fell really quickly.

So thank you on behalf of me and everybody who uses WordPress for the work that, I don’t know whether you feel that you get the credit that’s due to you, but I’m giving you some credit now, so thank you.

[00:08:37] Felix Arntz: Thank you. I appreciate it. That’s definitely great to hear.

[00:08:39] Nathan Wrigley: I’m pleased you know, that there’s people as capable as you who are doing this kind of work and that you’re willing to do it in the background. And a big piece of that is what we’re going to talk about today.

Landed in WordPress 6.8, but has a history prior to that as a plugin. It’s called speculative loading. It sounds impressive. But it also, I guess it is impressive and it’s a bit like voodoo. It’s kind of doing things that you wouldn’t imagine were possible. Do you want to just tell us what it is? What is speculative loading?

[00:09:08] Felix Arntz: So essentially, speculative loading, the idea is that when you navigate to a new URL, when you are browsing through a website and you go to a URL, the moment that you land on the URL, it starts loading. And we probably know that the performance aspect of that is very important to the user experience.

So if a page takes, I don’t know, three seconds to load, that’s not great. If it takes eight seconds to load, it’s probably horrible of a user experience. And so one of the performance team’s goals is to make that time that it takes a load shorter. So what then speculative loading does is load the URL, the idea is that it loads the URL before you even get there.

[00:09:47] Nathan Wrigley: Yeah, that’s the bit that’s voodoo. That’s the bit that just sounds like you’ve basically hopped into Back to the Future and you’ve gone back in time a moment or something. It’s very counterintuitive. So you are going to have to explain, how on earth does it do that?

[00:09:59] Felix Arntz: Right, right. Essentially, there are browser, there are heuristics which can be relied upon to hopefully assume correctly that a URL will be visited. So when you are on a page on the website, there is of course links to other pages on the website. So if you hover over the link with your mouse, if you’re on a computer for instance, and you hover over the link with your mouse, maybe you’ll click it. That’s like one level of signal. It’s not the strongest signal.

But then an even stronger signal is when you actually click the link. When you click a link, you want to go to that URL. I think that’s a fair assumption in like 99 plus percent of cases. So when you click on the link, that’s technically still before you’re at the other URL though. We’re talking about milliseconds. You probably think when you click, you are already on the other URL, but that’s not the reality. There is like maybe, I don’t know, 200, 300, 500, however long it takes, there are some milliseconds in between the time you actually click and that the other URL opens.

So by loading, for instance, by loading a URL, when you click on the link, you still gain those, whatever, maybe 500 milliseconds. I’m just going to make that up now, and reduce the actual load time by that.

[00:11:07] Nathan Wrigley: Let me just prize that apart. So we are now going to talk about a tiny fraction of time. For the next few minutes, we’re going to be talking about literal milliseconds. So let me imagine that I’m on my computer, desktop computer, let’s start there. I’m on a webpage and there’s a bunch of links, buttons, what have you.

I’m holding my mouse, my mouse approaches the button and it begins to slow down, you know, because at some point we have to rest on the button. So there’s this deceleration of the mouse and the cursor, and it eventually lands there. And then I click it.

Now my intuition is that the click event is the moment, that’s when everything begins, if you know what I mean. But are you saying that you can go back in time prior to me actually hitting the button with my finger? Is it the mere fact that, okay, the mouse has come to a standstill, you haven’t engaged the finger yet. Maybe the finger is literally on the way down in the real world, in this slow motion universe we’re imagining. Is that kind of it? It’s taking heuristics about, where is the mouse now? How is it decelerating? Or is it literally he clicked? Because if it’s the click bit, then I don’t understand what’s different to how it usually was because it felt like the click was always the moment.

[00:12:19] Felix Arntz: There are different ways to configure speculative loading. And one way, and that’s the way that WordPress Core does now, is to only speculatively load on the click. You say now that that feels like it’s always been like that, but it’s not quite always been like, that because of what I tried to mention with there’s still like 500, maybe 300, whatever, little milliseconds time between the click and the actual URL loading.

So when you hit the other URL, then it starts fetching the HTML document and all the CSS and JavaScript and so on. By doing that already on the click, on the link, on the previous page that you are on, you still gain those, I’m going to say valuable milliseconds. And we’re probably talking about at the very least, a hundred milliseconds, maybe a few hundred milliseconds.

[00:13:04] Nathan Wrigley: It doesn’t sound like a lot, but it’s, you’ve invented time out of nowhere. You’ve completely conjured up time that didn’t, well, actually you’ve removed time. You’ve gone in the opposite direction. But that time was needlessly spent before. Now that time has been saved.

You also mentioned that the WordPress implementation, and we’ll get into how you might be able to configure that in a moment, but the default WordPress installation, so this is in every WordPress website from 6.8 onwards, it is set to, and I’m going to use the word conservative, but it’s set to a fairly dialed back approach to this Speculation Rules API.

I’m curious, and we’ll get into how you do it in WordPress, but just in terms of the Speculation Rules API, what are some of the more aggressive things that you could do if you wanted to? And is things like the mouse slowing down, is that potentially part of it? Those kind of things.

[00:13:55] Felix Arntz: Right. So maybe let me take a step back, first to clarify that there’s a speculative loading feature that is in WordPress Core, it’s built on a browser API that is called Speculation Rules API. We can talk about maybe two things. There’s like, well, how can you use the Speculation Rules API? There’s different ways to configure it, and that’s something that we could apply in WordPress. But then we could go beyond that, and I’m probably not the best person to speak about that, but we could also think, how can you actually, what could the Speculation Rules API possibly do, that it isn’t able to do today?

So in terms of using the Speculation Rules API, it allows different configuration modes in for what is called eagerness. And you actually said it right. It’s called conservative, the mode that WordPress currently uses. And it just means, I think it is conservative in the sense that it is the safest measure if you want to make sure you only load URLs that the user actually goes to.

But it’s also the least performance of all the options. It’s always a trade off because unfortunately we cannot predict the future, so there’s no real wizardry going on here. And because of that, there is always going to be a trade off. You can use signals that are very reliable on the user visiting the other URL, like clicking on the link. There is an scenario where you click a link and then you pull your mouse away before you let go of your finger. We probably all have done this, but we probably do this like 1% of our clicks, if even that. But people do this occasionally, very occasionally.

So that’s the way where a click would not trigger the actual URL to the link to be, that wouldn’t result in the user visiting the other URL. This would be the one example where conservative speculative loading would still load the other URL and the user wouldn’t go to it. But I think that risk, that trade off is very, very little because of how rarely that happens.

[00:15:46] Nathan Wrigley: Right, so the posture of the Performance Team was to go conservative. So although it’s not the most performant, it is the least likely to end up in, you know, needlessly downloading content that is perhaps never going to be looked at.

But again, just moving ourselves away from WordPress for a minute, the Speculation Rules API, if we were to go on the more eager side, what kind of things could be brought to bear? And again, not in the WordPress setup at the moment, but I know that you can modify those things. But what can the Rules API do, if you go like full eager?

[00:16:18] Felix Arntz: Right. So you can also use, the next after conservative is called moderate. That uses signals that are less explicit, like a hover. Again, I have to specify, on desktop it uses hovering, because on the phone you can’t hover, like you don’t have a mouse and it doesn’t know where your finger is if you don’t press the screen.

So, essentially, moderate on desktop, it relies on the hover over a link to preload the URL that is behind that link. So that generally, yeah, of course if you hover over link and then you click it, there may be like a second, easily a second between this, or there may even be five seconds in between those two actions, right? And sometimes you hover and click immediately. Other times you hover and you get back there, and then you click, and in that case, the whole page can technically be already loaded.

So that’s the part where speculative loading, if you configure it more eagerly, you can get to situations where you get instant page load. You go to the other page and it’s already completely loaded. There’s, for instance, there is also Core Web Vitals, metric Largest Contentful Paint, which measures the load time speed. So you can get to an LCP of zero. Like, literally. If you use it, for instance as moderate eagerness, let’s say your page normally takes two seconds to load completely, and you hover over a link, and then you get back there like three seconds later, you click, it’s already there, and your LCP is literally zero because you didn’t need to wait at all.

That’s the performance power that it has. But of course, it does also come with a trade off to consider. Like, how do you configure this in a way that it’s the least wasteful? And wasteful in the sense of loading URLs that the user does not go to, ends up not navigating to. But you have to basically weigh off, what is the performance gain? How do users typically use your website?

There’s also, there’s a lot of individual configurations that websites may want to do on their specific site. So going back to the conservative option that WordPress now uses, it’s just that, it’s simply that we want to give the bare minimum feature and we want to make the feature available in general to WordPress sites. But because WordPress is so massive, you need to go with a literally conservative default.

[00:18:25] Nathan Wrigley: Okay. So that’s all really interesting, but it sounds like all of this is happening in the browser. So all of these events are being triggered by the browser. Again, forgive my ignorance, I’m presuming that Chromium, Chrome, Firefox, all of the other variants that there may be out there, I guess they’re all shipping some variant of this inside the browser because obviously it can’t be WordPress that’s doing this.

If that’s the case, is there kind of like a broad consortium of people who are working on this initiative, maybe other similar related performance initiatives, and trying to make them all browser compatible?

[00:19:03] Felix Arntz: So there is, the Speculation Rules API is currently, it’s available in Chrome, Edge and Opera, so in the Chromium based browsers, but it’s not available yet in Safari and Firefox. That means that people that use Safari or Firefox, they’re basically just not going to get the benefit.

[00:19:18] Nathan Wrigley: So it’s like a progressive enhancement. There’s no downside, it’s just an upside.

[00:19:22] Felix Arntz: Exactly. So because overall the browsers that support it are very widely used, plus the other browsers not having any negative effects of this feature being on a website, that’s why we thought it was a good time to roll it out.

[00:19:36] Nathan Wrigley: Okay, that’s really interesting. It just suddenly, and completely unrelated to the conversation that we’ve had so far, it kind of makes me think that maybe in the future there’ll be a hardware layer to this. You know, imagine if my mouse had built into it some pressure sensation, or even proximity sensor where it could perceive that, you know, my finger is descending and it could fire the signal from the mouse to say, yeah, he’s about to click. Or even in a mobile phone, you know, you were mentioning earlier, we don’t know where your finger is. Maybe at some point in the future we will know where your finger is.

[00:20:09] Felix Arntz: That would be really powerful, yeah.

[00:20:10] Nathan Wrigley: It’d be kind of interesting. Okay, you heard it here first. But it’s not there yet. So, what has been the way that this has been implemented? My understanding is that you launched this as a plugin. I think you got a fairly high user account. I think 30,000, 50,000 or something websites.

[00:20:27] Felix Arntz: I think it’s now at 50,000.

[00:20:28] Nathan Wrigley: 50,000. So tons of data coming back. And presumably that data gave you the confidence to, yeah, let’s push this through. And I have a memory that, broadly speaking, you got fairly close to a 2% productivity gain. And obviously at 43% of the web, if we can do things 2% faster, doesn’t sound like a lot, 2%. But 2% of everything that WordPress gives up, that’s a lot.

[00:20:53] Felix Arntz: Performance is really like, people say sometimes things are numbers games, but performance is a tiny numbers game. Like it’s very hard to make performance wins sound very appealing. It’s like, here is 2% win. We scratched off 80 milliseconds of this, and it’s like, what is this even, like.

[00:21:08] Nathan Wrigley: But it literally is human years. It’s probably decades of time when you think about the internet as a whole. If you think about it in that sense, it’s really quite a lot of time.

[00:21:18] Felix Arntz: Exactly, and I think it’s important to remind ourselves of that sometimes. I feel myself like announcing something where it’s like, oh, here we scratched 80 milliseconds off. It sounds like nothing. It is quite something, but it sounds like so little that, I don’t know, I feel self-consciously saying such a tiny number as a great win.

But yeah, again, like I think it, you exactly mentioned it, the scale of rolling out performance enhancements like this, it really makes the number matter. And also, people browse so many webpages a day, like even for an individual person. If you go on one website, you easily might visit 10 URLs or more, and that’s just one website. So think about , again, I’m just continuing with that number, like if you had 80 milliseconds gain on all the webpages you visit in a day, I don’t know, it might come out at some seconds, maybe a minute, who knows. And if you do that every single day, like you gain time.

[00:22:09] Nathan Wrigley: Yeah, I agree. It’s difficult to parse, isn’t it? The human brain doesn’t kind of work that microscopic level. That really tiny fraction of time is so difficult to become important. But there’s this compound interest effect to it. You know, the more that it adds up, the more time you spend on the internet every day clicking things. And I suppose the curious thing here is, nobody even knows that it’s happened. You would presumably just think, gosh, that is a very quick website. You know, I’m having a fabulous experience here. Everything’s loading amazingly. They must have an amazing server set up or, you know, they’ve got everything configured perfectly. And all the while it’s the Speculation Rules API working in the background.

But I think we’ve got it, you know, it’s adding up to tons of time, probably years, maybe decades of time when you throw that across the whole footprint that WordPress have.

However, most people who don’t follow the WordPress news really, really carefully probably won’t know about this. And there’s nowhere to know about it really, apart from WordPress journalism, and the blog posts that go out from the Performance Team. Because there’s no way in the WordPress UI, there’s no setting, there’s no menu item to go to, there’s no toggle, there’s none of that.

So that then leads me to ask, is there a way to modify this? If you have a need for more eager. Or you just wish to, I don’t know, you’ve got a desire to turn it off for some reason. Can it be modified with code, with hooks, with whatever?

[00:23:31] Felix Arntz: Yeah, certainly. Quick context on the reason that there is no UI in WordPress Core to control it, is that it’s considered a very technical feature, and the philosophy of WordPress Core says, decisions not options. That’s one of the Core philosophies. So try to use defaults that work for the majority, and most people won’t have to change. And then especially when it comes to very technical things, you don’t want to bother an end user that just wants to maintain, create their website with, here you need to learn now about this complex Speculation Rules API.

Like, we already talk about this for like 30 minutes now, and there’s probably so much more to uncover. So you can imagine that certain site owners don’t want to deal with that. So that’s why there’s no UI in WordPress Core. But it can be modified through hooks like you’re saying. There are several filters and actions to modify the behavior programmatically.

And in addition, the Speculative Loading plugin that existed prior to the Core launch, that still exists and it’s now, when you install it on top of 6.8, it still serves a purpose. While it doesn’t ship the whole API anymore, because that’s now part of WordPress Core, it’s still includes a UI where you can configure it via UI in different ways.

And it also changes the default behavior of WordPress, for the speculative loading feature. And that’s essentially because when we started the plugin, we went with a more aggressive default, because we want to know, the plugin only launches at first at small scale, it’s meant to, especially in the case of a feature plugin, it’s meant to inform us about how well it’s working, are there potential issues, and so on.

So we went with a more more performant configuration out of the box with the Speculative Loading plugin. So if you use the plugin, it will use the moderate eagerness that I mentioned before. And then in addition, it uses, and we haven’t covered that at all yet, so it pre-renders the URL. So I can explain that briefly.

The WordPress Core implementation, the Speculation Rules API allows you two alternative modes for speculatively loading a URL. Either you can pre-fetch the URL, or you can pre-render the URL.

Pre-fetching means you essentially just load the, you get the HTML content already, but then you don’t do anything else. Like, it doesn’t load any JavaScript or it doesn’t load any CSS or images, it still waits with all of that until you go to the other page.

With pre-render, it does everything, like literally everything. It loads the HTML, it loads also all the JavaScripts, CSS, images and whatever else is on your page. And it even renders this in the browser, like it basically does everything as if you were already on the page in the browser. Let’s think about it as if you had the page open in another tab and you couldn’t see it.

[00:26:08] Nathan Wrigley: Yeah, you’ve just like pulled back a curtain suddenly and there it is. It’s just, it always there. You just couldn’t see it and suddenly.

[00:26:14] Felix Arntz: And the pre-rendering is the thing that can get you to those immediate page loads. Because when you use pre-fetching, it only loads the HTML, so then when you get to the page, it’ll be faster, but you still have to load all the other things, and render it. But pre-render is where, if you have pre-render and eagerness of moderate, and then we go back to our previous example, you hover over link, go back there, two seconds, three seconds later, then you might get this immediate page load with LCP zero.

[00:26:43] Nathan Wrigley: Okay, that’s really interesting. So you’ve kind of got two options. The first option is just accept WordPress Core. That’s how it is. And then, maybe three options. The second option then might be you can modify things with hooks and what have you. And I’m going to link to the articles that Felix wrote in the blog post that goes with this. So go to wptavern.com and search for the episode and you’ll be able to find all the bits. It’s more easy for me to say that than it is to read out the blog titles and things.

And then the other option, the third option would be to download the plugin, which gives you a UI, but just caveat emptor, beware, it will then automatically make things moderate. It’s going to be doing things in a more, a slightly more aggressive way.

[00:27:21] Felix Arntz: It brings you better performance, but it might also have more trade offs on, it will load, certainly to some capacity, load URLs that may not be navigated to. If you install the plugin, just keep in mind that the UI that it provides also would allow you to go back to the WordPress Core default. If you just want a UI and you install the plugin, just go into the UI of the plugin immediately, change it back to conservative pre-fetch, and you’re back at what Core would do as well.

[00:27:45] Nathan Wrigley: Great. Yeah, thank you. Now you mentioned LCP and things like that. And I think there’s been an obsession for the last, let’s go for four years, with speed and trying to get Lighthouse scores to be impressive for your website. I’m curious, is there a way that Google scraping the internet can perceive any of this?

In other words, if you do this, are you doing it simply to make your visitors happy, because they’re the people who are doing the clicking or what have you? Or is there some like Core Web Vitals metric which can be improved by this? Because it feels like there couldn’t be, because I doubt that Google Bot has the capacity to kind of speculatively load anything, but maybe there’s some flag in the, I don’t know, I have no idea how that would work.

[00:28:31] Felix Arntz: So, that’s a great question. I think you’d, certainly when you apply performance enhancements like this, the goal is that they benefit your website’s end users. Google, of course, would love to know how well these features work, right? And also the people that work on the actual Speculation Rules API would love to see how the features are used in production, on production sites. And we, as a Performance Team, would also like to know that, how it goes with WordPress specifically.

So there is a public data set called Chrome User Experience Report, which is sourced from anonymous data from users that use Chrome and have opted into this anonymous data tracking. So there is essentially a data set that collects the performance data of people visiting websites. And that is made publicly available, you can literally, if you know how to use BigQuery, which is this kind of advanced version of MySQL, where you can query gigantic amounts of data, you can query the Chrome User Experience Report data set, and you could be checking like, I don’t know, as long as sites that appear, it basically aggregates all the page, all the data by origin, so the domain.

Any site that is relatively popular is in there. I don’t know exactly what the threshold is, but something like, maybe like at least 50 monthly users or something like that. So then your site will appear in there and you could query this for your own site to see how your site is doing. And you could do this every single month. And you get like a chart, how the performance of your site is doing over time.

Of course, neither Google nor we as a Performance Team cares about one specific site. We’re doing things like in our team, we were building things for WordPress, for the WordPress ecosystem, try to improve the performance of the ecosystem as a whole. So I have been working a lot in the past years and learning a lot about this stuff. How to query the Crux, that’s a short version of it, Crux, the Crux Report, to gain insights on, how do you possibly measure the impact a certain feature has on these metrics?

There’s another data set called HTTP Archive, which is the domains that are in this are also sourced from the Crux Report. But what HTTP Archive is, it basically scrapes all of these URLs every single month, one time, and gets all sorts of public information from these URLs, like which technologies it uses, does it use WordPress? Does it use, I don’t know, React or whatever, all these things. It also stores, from this one momentary point, it also stores the actual HTML body, and it’s a gigantic data set. And also that is public as well. You can look it up on httparchive.org and how to use it.

So the goal of these efforts is to make these different performance data and to basically assess the health of the web ecosystem, publicly available, and then also these, especially HTTP Archive has a lot of charts on their own website based on their own data that essentially, yeah, makes it easily available without having to query BigQuery data.

But when you actually can query BigQuery data, it becomes really powerful. So we can combine the data from HTTP Archive to see which origins are using WordPress. So then we get like a scaled down version of the whole web that is just the WordPress sites. And then we can combine it with the Crux data that has the performance results for all origins, but scope it down to only the origins that use WordPress.

And that way we can see, for instance, the median LCP for a given month across all WordPress sites is this. Or the median INP and all the other metrics. More importantly, what we have been using as a more important metric though, is what’s called the passing rate. For every Core Web Vitals metric, there is a threshold where it’s, under this threshold is good, above this threshold, it’s not good. So for LCP for instance, that’s 2.5 seconds.

And passing rate is essentially the number of, in this example, is the number of origins that have a median LCP that’s better than 2.5 seconds, the percentage of origins that have an LCP that’s better than 2.5 seconds. And that you can track over time to see how WordPress LCP is improving or decreasing over time. That’s how we essentially monitor performance for WordPress at a high level.

And then we’ve been doing all sorts of experiments to try to get feature specific improvements. That’s really the difficult part because these data sets only gather data, the Archive data set only gathers data once a month, the Crux data set gave this data, it has all the data, but only the performance data. So it does not know, at what point did you activate a certain feature or deactivate another feature? That data doesn’t exist. So we can only make assumptions.

Like, for instance, even when you want to measure the difference, and like an easy example, and that’s already complicated, is to measure the difference from one WordPress version to the next. HTTP Archive has data, whether a site is on, let’s say 6.8 or 6.7, but it’s from one specific moment in time. And we generally broaden these moments in time to the whole month because that’s the generally, like they do it once a month. If you see that a site is on 6.8, I think the HTTP Archive runs, like the actual queries usually run somewhere between 20th and 25th of the month.

So if you see that the site is 6.8, you don’t know, is the site on 6.8 the entire month or did it just update to 6.8 a day before and most of the month data is actually the previous version? This is just unknowns that we have to deal with. And the data set being so huge, because WordPress is so popular, that helps a lot to sort of like make these unknowns maybe less impactful. Because if you’re at scale see that 6.8 has a big improvement, we can’t say that this value precisely is correct, but if it’s a clear improvement, we can assume that there is an actual improvement to a certain degree.

And doing that for feature specific level is even more complex. I don’t think we have time to get into this too much right now, but I just want to say that this 1.9% value that is in the blog post is based on such an effort, where I try to look at all the sites that have speculation rules, and I looked at all the same sites before they activated speculation rules and get this median difference between all of them. And I don’t even know how to explain anymore because I don’t remember, because it was so complicated.

[00:34:42] Nathan Wrigley: I am so glad that you are able to explain it though. I mean, firstly, really interesting, all of that, really interesting. Because you just sort of peeled back a whole curtain that I didn’t even know existed. So there’s just this aggregated, opted-in data coming out of the browser, dropping into this massive data set. I can only imagine what that is like to deal with.

But it does mean that you’ve got anonymised data. You can make reasonable guesses, in the aggregate, about what’s happening. You know, you can refine it to WordPress, you can refine it to 6.7, 6.8, okay? And day by day, maybe it’s not meaningful. But if you spread it over one month, six months, what have you, more and more trends start to pop out.

So you can see over time, you’ve got this 1.9%. And it, terribly complicated though it might be, I’m glad that you did that work for us. That’s amazing. Okay. And I didn’t know that whole thing was going on.

And again, getting back to the point that you made at the beginning, the whole purpose of this is to make it better for your users. The purpose is not for the data that Google’s gathering, but it’s gathering it. And it’s helpful because people like you can then use it and make reasonable assumptions about what the rest of us ought to be doing with our WordPress websites. But the key metric there is, does it perform better for your users? And of course, we know the answer to that.

[00:36:00] Felix Arntz: Just wanted to quickly add like we have been, these two data sets have been important source for us as a Performance Team from the very beginning in terms of even prioritising what we work on. There’s ways to get a high level idea. Like, out of all the 50 things that we could do to improve performance, which have shown to be the most impactful on the web so far outside of WordPress, or maybe even on the few WordPress sites that already use it through some other way. So it has helped a lot on the prioritisation, and personally a big advocate for data driven decision making. And in many parts of the WordPress project, we are not able to do that because we don’t have much data. But I’m really pleased that on the performance side, there is this big data set that can be used to see what is actually impactful.

[00:36:46] Nathan Wrigley: Yeah, you can be really confident that your decisions are based upon fact, which is so nice. A lot of the WordPress project is, you know, intuition and design and things like that, and it’s hard to get agreement about that, and hard to get things right for everybody. But in this case, that’s slightly different.

[00:37:00] Felix Arntz: For anybody that’s interested in this to learn more, I did write a blog post on makewordpress.org/core at some point about it. How to assess performance with HTTP Archive, something like that. That’s something that we can probably, that you can probably look at. There’s a whole collab. I worked out for a while on a collab to teach as a sort of like tutorial, how to get started with this for anybody that’s interested.

[00:37:23] Nathan Wrigley: Okay, I’ve got a couple of pieces that I’ve got open over here, which are probably not the piece that you’ve just mentioned. So when I come back and edit this, I’ll make sure that I get in touch with you and we find that, and we’ll put that into the show notes. So there’ll be at least three things that you, dear listener, can go and check out.

I’m just wondering if there are any situations, because we know what people are like. Performance experts, they love to configure their servers, they love to put things at the edge that, you know, all these clever things that are going on. Are there any scenarios where things like the speculative loading that that can conflict, or overlap or be something that you actually don’t want to do because you’ve already got something in place that might be handling, I don’t know, let’s say for example, you’re in team Cloudflare, and you’ve jumped in on all the different things that they’ve got? Perhaps they do this already. I don’t know. But I’m just wondering if there are any scenarios where, let’s say I’m a hosting company, or I’m just really into my performance. Are there any scenarios where I need to be mindful, maybe I want to switch this off?

[00:38:22] Felix Arntz: I don’t think there’s a lot on the hosting side, but there can be on the whatever client side’s technologies you use. So because this speculative loading happens in the browser, so the, I don’t think there’s anything on the hosting side, or server side, that could do something similar. I think that wouldn’t work.

But there are other ways that some similar things like this have already been done outside of a browser specification, outside of a browser API. Like there are certain JavaScript frameworks, for instance, that have something like speculative loading. Like, if you have a Next.js site, for instance, which I think is not very common to be used together with WordPress, but if you do have a Next.js site for instance, it might load URLs speculatively too, but through its own mechanism, like a completely separate approach. I’m not sure about specific JavaScript libraries right now that do exactly this, but there are definitely things like it that some sites were already using before the browser Speculation Rules API came around.

[00:39:15] Nathan Wrigley: Okay, so broadly speaking, if you’re a WordPress, a typical WordPress user, you’ve got nothing to worry about. And you probably know that you’ve got something interesting and unusual going on with loading things in a different way, so you’re probably okay.

One of the things that I did want to know, I just wondered if there were certain, I don’t know, let’s say I’ve got a WordPress website, maybe there are bits of that website that I don’t wish to be speculatively loading.

I’m not really sure what that might be. An example that I think came out of one of your blog posts was you took the example of a Woo, well, I presume it was WooCommerce, you know, the end of the URL being cart or something like that, you know, so forward slash cart, forward slash whatever.

That’s possible though. I presume, again, with hooks you could say, okay, this predetermined set of URLs, we don’t want to speculatively load anything. That kind of stuff can be done. The URL parameters can be configured into all this.

[00:40:05] Felix Arntz: Yeah, exactly. So you can exclude certain URLs, or URL patterns from being applied to the speculative loading. And you can also configure whether you want to exclude them entirely or whether you want to exclude them only from pre-rendering, but not pre-fetching.

So this is important to consider because the WordPress site, well, probably now 95% of the sites with 6.8 use pre-fetch because that’s a default. There are still sites that change it to pre-render. And then there are different implications for the site, for the URLs that are pre-rendered.

And one of the considerations is, that’s actually another reason why we went with pre-fetch. because also pre-fetch, even though it’s less performant than pre-render, is also a safer option at the scale that we roll this out to all WordPress sites. Because the only risk with pre-fetch occurs if there is a URL that modifies something just by visiting that URL, which is an anti-pattern, like you should not do this, but there are plugins that do this occasionally. For instance, if you have like a URL that’s called empty cart, and just by visiting that URL you empty your shopping cart.

That means, if you speculatively load the URL and you don’t visit it, your cart is emptied. You don’t want that. This is the only risk with pre-fetch. But, for what it’s worth, WordPress, the WordPress Core implementation also includes some default exclusions already. One of them is that it won’t speculatively load any URL with query parameters, like those question marks, something. And that’s because most WordPress sites by far are using pretty permalinks, and on those sites, having a query parameters is extremely unusual. And if there is, it’s usually from a plugin that does something specific.

And so that’s why we exclude URLs because the chance that, like WordPress Core doesn’t have anything in the front end that will change something when you visit a URL, but plugins might. And plugins would usually handle this through query parameters if they do, and that’s why we exclude any query parameter URLs.

[00:42:07] Nathan Wrigley: Yeah, I know that you will not have an answer to the next question, but I’m going to ask it anyway. But I’m just curious on your thoughts about it, because I know that anybody listening to this, there’s going to be a proportion of people thinking, wait, we want less bits traveling across the internet.

And I’m thinking about the environmental impact of things now. You know, we don’t want pre-fetching anything, because that’s then potentially just wasted energy. Just carbon being burnt for stuff which may, or may not, be looked at. And obviously the WordPress approach that you’ve taken is to try and minimise that.

But I just wondered if you had any thoughts, you know, around that and whether you could sort of calm people down about that or whether or not it, was that whole thing disregarded? Where does it fit into the thinking of all of this?

[00:42:52] Felix Arntz: Yeah, like I said in the beginning, it is a trade off that you have to make, but it also depends like, which decision you take probably depends on how your site is being used, like what is the best configuration of speculative loading for your own site?

If you go with a too eager configuration where there’s tons of URLs are eagerly loaded and then they might never be visited, then this definitely has a negative impact, like you’re saying. But obviously the ideal outcome is that the wasteful reloaded URLs are minimised and at the end of the day you, by speculatively loading, you improve the user experience.

I can’t really answer where you draw the line in that. That being said, the adverse effects of URLs being loaded that you don’t navigate to with this conservative eagerness is so little. That’s why we chose that value to be the default. And you can go for more performant solutions, or configurations, but when you do so, please test how that works out.

You can also, don’t want to get too deep into this, but you can also, if you have some kind of analytics provider for your site, you can gather like performance data or you can see which links users typically click on. And then you could configure speculation rules in the way that these links specifically may use like a more eager configuration. But the other ones don’t.

This is where people really get, I’ve not personally done this but when, I’ve heard from other people when they work with enterprise clients, they really go in and look at, oh, when somebody has sent this URL, they usually click one of these four URLs, one of these four links, and then you can configure speculation rules to say, these four links should have moderate eagerness, but all other ones only conservative, for instance.

[00:44:22] Nathan Wrigley: I can see a whole third party ecosystem of plugin developers kind of rubbing their hands together. You know, those that create performance plugins kind of leaning into exactly what you just said. Here’s your entire WordPress website, and here’s what we think, you know, in the same way that SEO plugins might give you a traffic light. Here’s a set of URLs, which we think you are not serving in the way that is going to be beneficial to your users or what have you. So, oh, that’s interesting as well.

[00:44:46] Felix Arntz: The tough thing though is that it’s usually, I think it’s going to be very heavily dependent on the individual site. That’s where my hesitation is with that is that like, I’m not sure how much a plugin, a generally applied plugin, throughout the ecosystem could predict that. I think it’s often depending on the layout of the site. What is even the content of the site, right? What do people mostly click on? I think that makes it challenging from a general plugin perspective. Like to me, that’s mostly something that developers would do for their client’s websites, or agencies would do for a client’s website or at an individual level.

[00:45:18] Nathan Wrigley: Yeah. Well, I mean, it’s just the beginning, isn’t it? It’s dropped in fairly recently. No doubt, the WordPress ecosystem will kind of figure out a posture on this. Maybe third party plugins will come along. Maybe developers will produce more documentation about how to wrangle it. How to surmise whether or not your website is using the Speculation Rules API in a way which is helping you, I don’t know, measuring the cost of your server infrastructure and what have you. But just the beginning.

So there you go. Now, dear listener, you know a whole load of stuff about WordPress 6.8 that you didn’t. Before because probably, it was completely invisible to you. So, is there anything we missed, Felix? Is there any burning issue that you think we did not cover that and that was important?

[00:45:58] Felix Arntz: No. I think we covered pretty much anything, everything. I just wanted to add that the new data from the Crux Report comes out, I think actually it came out yesterday, I believe. So it comes out every second Tuesday of the month. So I’m about to look at that. I want to take a look at that, definitely by the end of this week to see whether we can get any impact data now that speculative loading is out because, so the way that this works is the Crux data is released for the month before. That’s what happened, I think yesterday. So now we should have data on April where WordPress 6.8 came out. So now we can see how much did this feature launching in 6.8, and 6.8 in general, affect performance, hopefully in a good way.

[00:46:39] Nathan Wrigley: Okay. Yeah, yeah. So this is actually for you, quite a big moment. You are suddenly going to get this data dump, which is going to actually cover this 43% of the web. It will be on all, well, most of the sites, and you are suddenly going to see what the impact is. Do you know, if you write that up, I will find it, if it’s out before I produce this post, then I will definitely link to that. And I’ll be fascinated to see if we can calculate how many decades, or weeks, or months, or years of time we have actually saved. That’s absolutely brilliant.

Thank you so much for explaining it, helping to create it in the first place, and basically improving WordPress in a very, very demure way. You know, not shouting it from the rooftops, but doing a lot in the background to make everybody’s experience of the web a whole lot better. Felix Arntz, thank you so much for chatting to me today.

[00:47:29] Felix Arntz: Yeah. Thank you.

On the podcast today we have Felix Arntz.

Felix is a Senior Software Engineer at Google, and a WordPress Core committer from Germany, currently residing in San Francisco, California. He helped establish the WordPress Core Performance Team and has been heavily contributing to its efforts. He has been using WordPress for a decade and contributing back to the project since 2015. More recently, he has stepped into the role of the inaugural Performance Lead for the WordPress 6.2 release and subsequently of the 6.3 and 6.8 releases. In the latter release, he spearheaded development and launch of the new speculative loading feature, which is the focus of the podcast today.

Speculative loading is one of the most important, and yet almost invisible, performance enhancements of recent times. If you’re on WordPress 6.8, this new feature is already active on your site, working quietly in the background to make page navigation faster. But you might never know from the WordPress UI, there’s no menu, no toggle, and no obvious indicator to show it’s there.

Felix explains exactly what speculative loading is, and why it feels almost like browser magic. The ability for WordPress, using the browser’s new Speculation Rules API, to load the next page just as a user is about to visit it. It’s a clever use of browser signals like mouse clicks and hovers to anticipate navigation, shaving off precious milliseconds, sometimes even providing what feels like an instant page load.

Felix clarifies the difference between conservative and more aggressive approaches to speculative loading, and why the WordPress Core team opted for the safest, least wasteful option by default, while still giving developers, or advanced users, the hooks and tools to customise or even disable it as needed.

Felix discusses the origins of the feature as a plugin, the testing and data collection undertaken with tens of thousands of sites, and how this real-world data gave the team confidence to ship speculative loading to all WordPress users. We talk about what those performance wins mean at scale. How a 2% improvement on 43% of the internet translates into saving users untold hours of waiting collectively.

We also get into the weeds on measurement and methodology. How the team uses data from the Chrome User Experience Report and HTTP Archive to track web performance, prioritise features, and validate real-world impact. Felix offers insight into how these global, anonymised data sets allow the Performance Team to make truly data-driven decisions.

Beyond the tech, Felix addresses practical considerations, such as how to opt out, or fine-tune speculative loading if you have specific needs, how environmental concerns are balanced by default configurations, and how plugins or agencies might build on this foundation in the future.

If you’ve ever wondered how large-scale, browser-level improvements make their way into WordPress Core, or simply want to know if there’s a way to make your own WordPress site that much faster, this episode is for you.

Useful links

Image for: Useful links

 WordPress Performance Team

Achieve instant navigations with the Speculation Rules API

Understanding Core Web Vitals and Google search results

Speculative Loading plugin

Speculative Loading, or A Brief History of Landing a Performance Feature in WordPress Core

Overview of CrUX

BigQuery

HTTP Archive

by Nathan Wrigley at May 28, 2025 02:00 PM

Do The Woo Community: Reinventing Careers and Building Resilience in Tech with Mendel Kurland

Image for: Do The Woo Community: Reinventing Careers and Building Resilience in Tech with Mendel Kurland
Zach and Carl chat with Mendel Kurland, sharing stories of resilience, reinvention, and the human side of tech, wrapping it all in laughs and life lessons.

by Bob Dunn at May 28, 2025 09:32 AM

Matt: The Five Layers of Sharing Thoughts and Ideas

Image for: Matt: The Five Layers of Sharing Thoughts and Ideas

I’ve been thinking a lot about mimetic formation, how a thought becomes an idea, and how that idea gestates and evolves as it’s progressively shared in wider and wider circles.

During a recent product review of Day One, I was struck by how central the app is to my perspective on humans, relationships, and what we share. There are several layers to it, ranging from your innermost thoughts to what you share with the world. Each layer has its own context, challenges, and possibilities, and Automattic offers technology and products tailored to each.

1. Layer one is your internal thoughts. Your consciousness, what exists only in your mind, or what I like to call meatspace. This space is yours and yours alone. This generative space is at the core of human creativity and existence.

2. Layer two is triggered as soon as you put something into a medium, like writing it down. It’s everything that leaves your head, but is just reserved for you. In the past, we only had physical journals. Today, we have Day One as our strongest product in this space, but many people also have a private WordPress installation just for themselves. There are so many tools out there that help you create! Colors, brushes, canvases. Harper, for example, helps you write better — think of it as an open-source Grammarly, right now just in a few limited contexts, but in the future everywhere you write. 

3. Layer three is you and someone else. This is everything you share with one other person, which is an incredibly sacred act. Shared journals on Day One, messaging on Beeper, DMs, private blogs with your best friend. A shared Google doc. This is its own special space. It has an intimacy and privacy that is core to the human experience. This is also phase 3 of Gutenberg, which is all about real-time co-editing and collaboration. This layer is the one I’m most excited about expanding in 2025 and 2026.

4. Layer four is sharing within a finite group. N+1. It’s a space of collaboration and brainstorming with families, tribes, and teams. P2, Linear, Github, group chats, and cozy communities. You lose some of the intimacy of layer three but gain more group intelligence.

5. Finally, we have the fifth layer. This is the public layer, where I have spent a lot of my time at Automattic. It is an extremely competitive space of social media and blogs: WordPress, WordPress.com, and Tumblr. Once you publish publicly, you open yourself up to the beauty and chaos of the wider world. The best reason to blog is comments, the people who find you and add to your thoughts, who you never would have imagined. This is a crucible, but makes your own writing and thinking so much better, it’s worth the mishegoss.

This has been kicking around in my head and at layer four for a while. Thanks to Kelly Hoffman for helping me get this to layer five.

P.S. Happy 22nd birthday to WordPress! Very excited about the new AI team on .org.

by Matt at May 28, 2025 12:55 AM

May 27, 2025

Aaron Jorbin: Happy 22nd Birthday WordPress

Image for: Aaron Jorbin: Happy 22nd Birthday WordPress

I don’t know about you, but WordPress is feeling 22.

I am celebrating by helping WordPress do what it has done nearly every day for 22 years: getting a little better (and being ok making mistakes in the process).

The post Happy 22nd Birthday WordPress appeared first on Aaron Jorbin.

by jorbin at May 27, 2025 11:37 PM

WordPress.org blog: Announcing the Formation of the WordPress AI Team

Image for: WordPress.org blog: Announcing the Formation of the WordPress AI Team

Today, I’m pleased to announce the formation of a new WordPress AI Team, a dedicated group focused on accelerating and coordinating artificial intelligence projects across the WordPress ecosystem.

AI is already transforming how people create and manage content online. As this technology evolves, it’s essential that WordPress remains at the forefront, ensuring innovation happens in the open, guided by community values, and built to core standards.

Why This Matters

Image for: Why This Matters
  • Strategic focus: A unified team stewards AI development thoughtfully, avoids fragmentation, and ensures alignment with the long-term goals of WordPress.
  • Shared innovation: Contributors and companies are actively exploring AI across the ecosystem. This team provides a central place to collaborate, share ideas, and build together.
  • Rapid iteration: Like the Performance Team, we’ll take a plugin-first approach. Canonical Plugins will allow us to move quickly, gather feedback, and deliver real value without waiting on the Core release cycle.

What to Expect

Image for: What to Expect

The AI Team will:

  • Coordinate cross-team efforts to explore AI-powered features responsibly and inclusively.
  • Publish and maintain a public roadmap of AI initiatives and Canonical Plugins.
  • Collaborate closely with Core, Design, Accessibility, and other teams to ensure strong integration and shared standards.

Meet the Team

Image for: Meet the Team

The WordPress AI Team brings deep experience in open-source, performance, and product development and a strong commitment to building AI features the WordPress way. The team will launch with the following team contributors:

  • James LePage – Automattic
  • Felix Arntz – Google
  • Pascal Birchler – Google
  • Jeff Paul – 10up

To help get things started, James and Felix will serve as the initial Team Reps in supporting team organization, communication, and coordination with other Make WordPress teams.

This is an exciting and important step in WordPress’s evolution. I look forward to seeing what we’ll create together and in the open.

If you’re interested in contributing or following along, please join the conversations in #core-ai and watch for upcoming meeting announcements on https://make.wordpress.org/ai/.

by Mary Hubbard at May 27, 2025 04:28 PM

Do The Woo Community: How One Solo Agency Owner Manages Hundreds of WordPress Sites (Without Losing His Mind)

Image for: Do The Woo Community: How One Solo Agency Owner Manages Hundreds of WordPress Sites (Without Losing
Running a massive web design business solo, while focusing on one platform, automating wisely, networking locally, and keeping support simple can help with strategies to scale without stress.

by Bob Dunn at May 27, 2025 11:14 AM

Do The Woo Community: Community Engagement Strategies for Successful WooCommerce and WordPress Plugins

Image for: Do The Woo Community: Community Engagement Strategies for Successful WooCommerce and WordPress Plugi
In this episode of Woo Product Chat, co-hosts discuss "community thinking" in WordPress and WooCommerce plugins, highlighting the importance of user feedback and effective engagement strategies.

by Bob Dunn at May 27, 2025 08:44 AM

May 26, 2025

Weston Ruter: Improve LCP by Deprioritizing Script Modules from the Interactivity API

Image for: Weston Ruter: Improve LCP by Deprioritizing Script Modules from the Interactivity API

Adding a fetchpriority of low to script modules and moving them from the head to the footer can improve LCP by >9%! I’ve written plugins you can use to implement this now while waiting for them to land in WordPress core.

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”.1 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 blocks2 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

Image for: 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:

Command
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"
MetricBeforeAfterDiff (ms)Diff (%)
FCP142.6141.7-0.9-0.6%
LCP409.4382.4-27.0-6.6%
TTFB34.735.3+0.7+1.9%
LCP-TTFB374.2347.0-27.2-7.3%

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:

Command
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"
MetricBeforeAfterDiff (ms)Diff (%)
FCP1275.31275.4+0.1+0.0%
LCP3377.13157.1-220.0-6.5%
TTFB35.034.6-0.4-1.0%
LCP-TTFB3341.13123.0-218.1-6.5%

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:

Command
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"
MetricBeforeAfterDiff (ms)Diff (%)
FCP140.7142.6+1.9+1.4%
LCP399.0368.9-30.1-7.5%
TTFB33.433.0-0.4-1.2%
LCP-TTFB365.1335.8-29.3-8.0%

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

Image for: 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:

Command
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"
MetricBeforeAfterDiff (ms)Diff (%)
FCP141.8143.7+1.9+1.3%
LCP410.8383.1-27.8-6.8%
TTFB34.434.4-0.1-0.1%
LCP-TTFB376.7348.4-28.4-7.5%

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:

Command
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/"
MetricBeforeAfterDiff (ms)Diff (%)
FCP142.0144.1+2.1+1.5%
LCP377.5374.7-2.8-0.7%
TTFB34.735.1+0.4+1.2%
LCP-TTFB342.9338.9-4.0-1.2%

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

Command
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/"
MetricBeforeAfterDiff (ms)Diff (%)
FCP142.4143.2+0.8+0.6%
LCP383.9372.7-11.2-2.9%
TTFB35.035.2+0.2+0.6%
LCP-TTFB348.1337.8-10.3-3.0%

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

Image for: 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

Image for: 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:

Command
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/"
Metricheadhead + lowbodybody + low
FCP137.9143.0140.7138.8
LCP405.9383.7376.8370.0
TTFB33.734.533.633.7
LCP-TTFB372.2349.3343.0336.3

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:

Command
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/"
MetricBeforeAfterDiff (ms)Diff (%)
FCP137.0137.2+0.2+0.1%
LCP406.0368.8-37.2-9.2%
TTFB33.733.6-0.1-0.1%
LCP-TTFB371.7336.0-35.7-9.6%

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:

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?

  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.

by Weston Ruter at May 26, 2025 08:36 PM

Do The Woo Community: WordPress Multilingual, Translation and Community with Pascal Birchler and Robert Windisch

Image for: Do The Woo Community: WordPress Multilingual, Translation and Community with Pascal Birchler and Rob
In this episode of The WordPress Way, listen to shared insights on translating WordPress, performance boosts, community involvement, and future multilingual features. They emphasize the ongoing need for translators and collaboration in WordPress.

by Bob Dunn at May 26, 2025 09:01 AM

May 24, 2025

Gutenberg Times: Feature API, Playground, Gutenberg 20.9, Interactivity API, #WCUS and moar — Weekend Edition 331

Image for: Gutenberg Times: Feature API, Playground, Gutenberg 20.9, Interactivity API, #WCUS and moar — Weeken

Howdy,

This week, I continued to learn about more plugins for the block editor. They might be new to the WordPress repository or just new to me, haha. Also, Playground came up in the last couple of weeks, and I share two tutorials and a video about my workshop at WordCamp Europe. And via the Feature API you can prepare your plugins for AI Agents.

As every year, WordCamp Europe will also have a Live stream for the talks and keynotes. Just check out the website on Jun 6th, 2025. The next Weekend Edition will drop in your inbox after WordCamp Europe and I will share some cool talks from the live stream.

Until have a great time!

Yours,
Birgit

WordCamp Europe is just around the corner! If you want to meet up in Basel (June 4–7), grab a slot on my calendar or send me your link. #WCEU

ICYMI: WordCamp US Call for Speaker is now live the deadline is June 20, 2025. WordCamp US will take place from August 26 to 29th, 2025. Similar to last year, there are no lightening talks, only long form talks, workshops, or campfire sessions. August 26 will be Contributor Day. Sessions start on August 27 in three tracks. You need to have a WordPress.org account to enter the form. The Call for Sponsors has also been published.

Developing Gutenberg and WordPress

Image for: Developing Gutenberg and WordPress

George Mamadashvili just dropped the Gutenberg 20.9 RC1 for everyone to test out, and we’re expecting the final version to go live next week! After WordCamp Europe, I’ll catch up with Anne McCarthy to record our next Gutenberg Changelog, where we’ll chat about a bunch of stuff, including those two Gutenberg plugin releases, 20.9 and 21.0.

The latest episode Gutenberg Changelog 117 – WooCommerce Starter Theme and Blocks, WordCamp Europe, and Gutenberg 20.7 and 20.8 I sat down with Ellen Bauer, WooCommerce product lead and discussed what she is working on, WordCamp Europe, Create Block Theme, WP-CLI, Gutenberg 20.7 and Gutenberg 20.8 releases.

Plugins, Themes, and Tools for #nocode site builders and owners

Image for: Plugins, Themes, and Tools for #nocode site builders and owners

Johanne Courtright explains how Gutenberg is a game-changer — and clients actually love it (when done right). When implemented thoughtfully, she found, the Gutenberg editor revolutionizes WordPress by empowering clients with intuitive, flexible content creation. In her experience, clients express genuine satisfaction, as Gutenberg’s block-based approach simplifies editing and design, making website management more accessible and enjoyable for non-technical users.


Kevin Batdorf updated his plugin Pattern CSS . It lets you add CSS scoped to a block, and recently added a floating editor as well as a global CSS editor, making it easy to add custom animations or anything. It’s parsed via Lightening CSS in WebAssembly as you type, and works well with synced patterns.


Thorsten Landsiedel published a plugin called “Hide Block in RSS feed,” which adds a toggle switch to block sidebars for suppressing content in RSS feeds. In his talk at WordCamp Leipzig, he noted that decorative icons/images may display differently in RSS readers. Using this block you can improve readability by suppressing specific blocks in the feeds. The plugin is available on GitHub.


Weston Ruter, a long-time WordPress Core committer, explains step-by step how he added caption and lightbox to the featured image block. When Weston Ruter rebuilt his site with the Twenty Twenty-Five theme, he noticed the Featured Image block lacked caption and lightbox features. Both features are available for the Image block. Ruter shared code examples on how he implemented these features in a plugin. Then he also suggested future improvements for WordPress core.


WM Animations plugin by Widescreen Media, a company from Sweden, helps users to add entrance animations like fade-in and slide-in to core blocks. “You can select animation type and adjust duration/delay per block, directly in the block inspector. Works well with all core blocks and most custom blocks.” Widescreen Media’s website might be the best demo for this plugin.


Andy Fragen, core contributor and trauma surgeon, authored quite a few plugins. The oEmbed for GitHub Gist plugin enables writers to add code from GitHub Gists via the Embed block to their posts. For classic editor users, you just put the URL on a new line.

 “Keeping up with Gutenberg – Index 2025” 
A chronological list of the WordPress Make Blog posts from various teams involved in Gutenberg development: Design, Theme Review Team, Core Editor, Core JS, Core CSS, Test, and Meta team from Jan. 2024 on. Updated by yours truly. The previous years are also available: 2020 | 2021 | 2022 | 2023 | 2024

Building Blocks and Tools for the Block editor

Image for: Building Blocks and Tools for the Block editor

Video recordings from Lisboa’s WordCamp 2025 are already available on WordPressTV


Seth Rubenstein, lead engineer at Pew Research Center, decided to take a break from regularly scheduled work to play around with an Interactivity API (iAPI) Inspector Chrome Extension. This tool offers dev tools to highlight iAPI directives and context associated with a block as well as map connections between iAPI stores on a page.


Jonathan Bossenger has spent some time the last couple of weeks learning more about Feature API, the WordPress MCP plugin and the MCP WordPress remote package. In his latest video, Are your WordPress plugins and themes ready for AI? he puts it all together using one of his plugins and shows the various steps:

  • Registering Features with the Feature API Plugin
  • Converting Features into Tools with MCP Plugin
  • Configuring AI Tools to Use MCP Features

Once you watched the video a couple of times, it might be helpful to also read Jamie Marsland‘s post on LinkedIn again:  WordPress Is Sitting on a Goldmine — And the Feature API Just Dug the First Tunnel


In this week’s live stream, Ryan Welcher also took a A first look at the new WordPress Feature API. He calls the Feature API “a powerful new way of exposing WordPress functionality in a standardized, discoverable way for both server and client-side use.”

What is new in Playground?

Image for: What is new in Playground?

Roger Williams and I spoke about my upcoming WordCamp EU workshop.” “From Zero to Demo: Mastering WordPress Playground Blueprints“. The recording is available on YouTube WordPress Playground Workshop Preview with Birgit Pauli-Haack


Karthick Murugan, from the Multidots team, updated documentation with everything you want to know about the current web instance: WordPress Playground web instance.


Earlier this week, I wrote about the early version of the Playground CLI and how to use it to test your plugin and theme in development or your blueprints locally. Early version Playground CLI testing.


In Automating WordPress Playground Screenshots with Node.js and Playwright I shared the context and code using the JavaScript API to call a with a playwright browser instance to take a screenshot of the Playground site configured with a blueprint.


Need a plugin .zip from Gutenberg’s master branch?
Gutenberg Times provides daily build for testing and review.

Now also available via WordPress Playground. There is no need for a test site locally or on a server. Have you been using it? Email me with your experience

Questions? Suggestions? Ideas?
Don’t hesitate to send them via email or
send me a message on WordPress Slack or Twitter @bph.


For questions to be answered on the Gutenberg Changelog,
send them to changelog@gutenbergtimes.com


Featured Image: Photo by Ivan Bandura on Unsplash


Don’t want to miss the next Weekend Edition?


by Birgit Pauli-Haack at May 24, 2025 09:15 AM

May 23, 2025

Gravatar: Proven Branding Methods for Professional Coaches

Image for: Gravatar: Proven Branding Methods for Professional Coaches

Are you looking for a way to differentiate your coaching services in a competitive online market? You’re not alone. Many coaches struggle to stand out among thousands of others offering similar services.

Here’s the good news: Effective coach branding doesn’t require massive budgets or complex systems. Instead, success comes from focusing on a few foundational pillars: Optimizing your digital presence, promoting your services strategically, and tracking performance consistently.

And no, you don’t need to hire expensive agencies or completely redesign your business. Small, targeted improvements to your branding can yield significant results in attracting your ideal clients.

This guide cuts through the theory and provides practical, proven branding techniques specifically for coaches. Each strategy is designed to help you build a distinctive professional identity that resonates with potential clients and positions you as the obvious choice in your coaching niche.

Essential elements of a professional coaching brand

Image for: Essential elements of a professional coaching brand

The foundation of any successful coaching business isn’t flashy graphics or clever slogans – it’s a consistent multi-platform presence strategy. This means maintaining a unified professional identity across coaching directories, your website, social media profiles, and professional networks. Tools like Gravatar can help automate this consistency, ensuring your professional image remains cohesive wherever potential clients encounter you online.

A big part of that consistency is demonstrating your expertise. Potential clients need clear evidence of your capabilities through certifications, testimonials, and client success stories prominently displayed in your professional bios and website. These serve as social proof that validates your coaching abilities to skeptical prospects.

Video content has become a particularly powerful way to showcase expertise. According to Wistia’s 2025 State of Video Report, short-form video content significantly outperforms other formats in engagement rates, with how-to videos under one minute achieving 82% viewer completion. Instagram reels and TikTok tutorials offer perfect platforms to demonstrate your coaching approach in action.

To truly stand out, develop proprietary frameworks or methodologies that distinguish your services from generic coaching approaches. This gives clients a concrete system to understand and helps position you as an innovative thinker in your field.

On top of that, you need to take whatever time you need to identify what makes your coaching unique – your background, approach, client specialization, or results – and weave these elements into a compelling coaching story that resonates with your target audience.

Now, let’s explore some practical ways to build these brand pillars.

How Gravatar powers your coaching brand identity

Image for: How Gravatar powers your coaching brand identity

Establishing a consistent online presence is one of the biggest challenges for coaches, but thankfully, this is where Gravatar steps in as a powerful brand management tool. As a “Globally Recognized Avatar,” Gravatar can become like a central identity hub that automatically syncs across thousands of platforms, eliminating the frustration of managing multiple profiles.

Think of Gravatar as your digital business card on steroids. It connects your professional image, bio, and credentials across coaching directories, blog comments, professional forums, and social platforms. When potential clients encounter you across different channels, they’ll recognize your consistent presence immediately, crucial for building recognition in a crowded coaching marketplace.

The trust factor gets a significant boost with Gravatar’s verification system. Each link on your profile can display a “verified” tick, signalling authenticity to sceptical prospects. In coaching, where trust is everything, these small trust signals make a substantial difference in conversion rates.

Your Gravatar profile can even live as a QR code in your phone’s digital wallet, making in-person networking seamless

Update your credentials once, and the changes reflect everywhere – saving hours of profile management while maintaining brand consistency.

Ready to strengthen your coaching brand? Get your free Gravatar profile today and bring cohesion to your digital presence.

Building trust through verified profiles and consistent presence

Verification is no longer optional in the coaching industry – it’s essential. When potential clients research your services, they’re looking for trust signals that verify your authenticity and expertise. Social media verification acts as a powerful trust marker in a saturated market.

Instagram deserves special attention in your verification strategy. According to research from Luisa Zhou, this platform is where many coaches successfully find their highest-quality clients, with 54% of Instagram users making purchases after discovering services there. So naturally, verifying your Instagram presence should be a priority.

Similarly, establishing verified presence on X (formerly Twitter) creates additional credibility touchpoints in your professional ecosystem.

For coaches using newer platforms like Bluesky, Gravatar offers a unique advantage – you can get a custom Bluesky domain name and verify it directly through Gravatar, creating an additional layer of professional credibility.

Gravatar’s “update once, sync everywhere” system means your verified professional image automatically appears across hundreds of platforms – from WordPress blogs where you guest post to professional forums where you engage potential clients.

Think of Gravatar as the foundation of your coaching trust architecture. It creates a central verification hub from which all aspects of your digital footprint link back, establishing a cohesive professional identity that builds client confidence at every digital touchpoint.

Practical strategies to promote your coaching brand

Image for: Practical strategies to promote your coaching brand

Establishing credibility through a verified online presence remains the cornerstone of successful coach branding. Creating a verified professional presence using Gravatar across coaching platforms and professional networks provides the essential foundation upon which all other brand-building activities should build. This baseline credibility creates the trust necessary for potential clients to consider your services.

Position yourself as a thought leader

To elevate beyond basic verification, position yourself as a thought leader through specialized content that directly addresses specific pain points in your coaching niche. This approach demonstrates your expertise while providing immediate value to potential clients.

Effective thought leadership channels include:

  • LinkedIn articles that dissect complex coaching challenges.
  • Instagram carousels explaining your methodologies (these have 82% higher engagement for coaching content).
  • Blog posts on your website that showcase your unique perspective.
  • Email newsletters with actionable insights.

The most successful coaches don’t create generic content – they develop material that speaks directly to their audience’s most pressing challenges, demonstrating both understanding and solution expertise.

Develop your signature framework

Creating a distinctive “signature framework” dramatically separates your coaching brand from competitors while simplifying your marketing message. For example, a life coach specializing in work-life balance might develop “The Balance Blueprint” – a structured, step-by-step process clients follow to achieve harmony between career and personal priorities.

Your signature framework accomplishes two critical objectives simultaneously:

  • It clarifies your methodology for potential clients.
  • It creates a memorable brand element that differentiates you from generic coaching approaches.

This combination builds both trust and recognition – the twin pillars of effective coach branding.

Forge strategic partnerships

Explore high-value coaching partnerships with complementary service providers and industry experts. A relationship coach might partner with a financial advisor to address money conflicts in relationships, creating a more comprehensive solution while accessing a new client base.

Additionally, seek opportunities to speak at industry conferences and events. These platforms position you as an authority while creating valuable networking opportunities with potential clients and partners who already recognize your expertise.

Measure your brand’s impact and reach

Without tracking key metrics, you’re essentially operating in the dark, making decisions based on gut feeling rather than data.

Start by monitoring these fundamental metrics that directly reflect your brand’s performance:

  • Track not just visitor numbers but engagement metrics like time-on-page and bounce rates.
  • Measure shares, comments, and saves (not just likes).
  • Monitor conversion rates from brand touchpoints to inquiries.

Tools like Google Analytics provide comprehensive website insights, while platform-specific analytics like Instagram Insights and LinkedIn Analytics reveal how your content performs across different channels.

Still, data without action is useless. Use your metrics to continuously refine your approach:

  • Identify which topics generate the most engagement and double down.
  • Spot underperforming channels and either optimize or reallocate resources.
  • Test different content formats to determine what resonates best with your audience.

When metrics show declining engagement, don’t just produce more content – produce better content that addresses the specific needs revealed in your data.

And, once you do get the results you want, make sure you document your success stories – the most compelling brand assets are documented client transformations. Create systematic before-and-after assessments that quantify client progress:

  • Standardized assessment tools that measure baseline and improvement.
  • Periodic progress check-ins that document incremental gains.
  • Video testimonials that capture emotional and practical outcomes.

Take your coaching brand to the next level

Building a verified, consistent online presence using tools like Gravatar creates the essential foundation for your coaching brand. This strategic approach eliminates the fragmentation that undermines many coaches’ digital presence while establishing the credibility necessary to convert prospects into clients.

With Gravatar handling your consistent visual representation across platforms, you’re free to focus on what truly matters – delivering high-value client interactions through optimized touchpoints. Your social media engagement, website inquiries, and professional forum participation all benefit from the trust architecture you’ve established.

To sum it up, here’s what you need for success: 

  • A proprietary methodology that becomes synonymous with your name.
  • Diverse content formats that appeal to different learning styles.
  • Strategic partnerships that expand your reach into complementary audiences.

The coaches who succeed don’t try to implement everything at once. They start with fundamentals, like creating a free Gravatar profile, and systematically build their brand presence over time.

Remember that brand development is a gradual, ongoing process. Each small improvement compounds, creating a professional presence that stands out in a crowded marketplace. 

Happy branding!

by Ronnie Burt at May 23, 2025 05:44 PM

Gravatar: What Makes a Digital Avatar Effective

Image for: Gravatar: What Makes a Digital Avatar Effective

Fun fact: The global digital avatar market is hurtling toward a whopping $270.61 billion by 2030. That’s up from just $18.19 billion in 2023.

What began as a simple, low-quality profile picture you might put on mIRC or MySpace can now become a full-blown brand asset. The kind that drives clicks, builds trust, and boosts conversions like a charm.

But… not all avatars are created equal. So what separates the forgettable from the phenomenal?

Effective avatars are engagement machines, and brands that get it right are seeing:

  • Higher user engagement across channels.
  • Sharper brand recall (because yep, that tiny image sticks).
  • Better conversion rates on platforms with consistent avatar use.
  • Warmer, more personal user experiences that actually build trust.

This is more than some passing tech phase, it’s a fundamental shift in how digital identity is experienced. As AI-powered avatars and virtual reps get smarter, businesses are tapping into a new kind of connection – fast, human, and scalable.

In this guide, we’ll walk you through how to build and deploy avatars that work, from brand consistency and personalization to next-gen tools like Gravatar that simplify your digital identity across the web.

No more juggling profile pics across platforms. No more brand dissonance. With a smart avatar strategy, you update once and show up everywhere, looking exactly how you want to.

What makes a digital avatar effective: Definition and importance

Image for: What makes a digital avatar effective: Definition and importance

Digital avatars are not just sci-fi playthings anymore. These digital doppelgängers are the new face of brands and professionals online, popping up everywhere from sales decks to marketing assets and customer chats. 

Here’s the kicker: According to research from the National Institutes of Health, our brains respond to avatars a lot like we respond to real humans. Wild, right? But also incredibly useful. Because that means every time a customer sees your avatar, they’re not just spotting a fancy graphic – they’re building a sense of connection, trust, and familiarity, just like they would with a real-life person.

Why does that matter? Well:

  • Avatars act as a consistent visual cue across all your brand’s touchpoints
  • They turn dry, technical info into something surprisingly human
  • They make your brand stick in people’s minds
  • And most importantly, they help you build actual emotional resonance online

And it’s not just big brands getting in on the avatar action. If you’re building a personal brand, a strong digital avatar can become your secret weapon, a visual shorthand people instantly recognize in comment threads, Slack groups, or LinkedIn scroll-athons. 

Of course, different use-cases will call for different strategies. A corporate avatar might need to channel “professional but warm,” while a personal brand might want something that screams “it’s me!” in the best way. Meanwhile, your social avatar? Feel free to let your creativity run wild (meme energy encouraged).

The point is, the avatar you choose should match its mission. A customer support bot? Friendly and dependable. A sales rep avatar? Confident and persuasive. 

Over the rest of this post, we’ll break down how to tailor your avatar’s personality to fit the context, so you’re always putting your best digital face forward.

Types of digital avatars: From simple icons to interactive representations

Let’s start with the basics: The humble headshot avatar. This is your digital calling card. A clean, static image that tells the internet, “Yep, it’s me.” Gravatar is the OG here – a global avatar service that ensures your chosen pic pops up consistently across thousands of sites. 

WordPress blogs, GitHub repos, Slack chats, and plenty more. Set it once, and voilà: Instant recognizability, no matter where you roam online.

In fact, setting up your Gravatar takes less than 5 minutes (likely the best ROI you’ll ever get in under a coffee break).

Set it up in five minutes now, save yourself fifty profile edits later.

Zooming out beyond headshots, the avatar scene gets pretty creative:

2D customizable avatars let you tweak everything from eye shape to shoe style (e.g., Bitmoji). They’re quirky, fun, and surprisingly simple to build.

3D static avatars offer depth, angles, shading, the works. They give your digital self some dimension and make your profile pic feel less…flat.


In 2022 Meta teamed up with the NFL to enable viewers to outfit their Avatars in the colors of the two Superbowl teams

3D animated avatars? Now we’re in Pixar territory. These avatars blink, smile, nod, and generally act like they’re about to ask you how your day’s going. Perfect for adding that human-ish warmth to virtual chats.

At the frontier, we’ve got AI-powered avatars, and this is where things get spicy. Platforms like HeyGen let you build avatars that don’t just look the part – they talk it too. Natural language processing means they can chat, answer questions, and generally hold their own in a conversation without sounding like a 2005 chatbot.

And the tech’s only getting better. Even Gravatar is creating AI-generated avatar tools, so anyone – yes, even the design-challenged – can whip up a slick, professional avatar without breaking a sweat.

The gap between digital you and real you is closing fast. And with these evolving tools, your online presence can be as polished, personable, or playfully weird as you want it to be.

AI-powered avatars: The future of digital identity is already here

Gravatar’s shiny new AI Profile Builder, launched in May 2025, is leading the charge to become the new face (quite literally) of digital identity. And with users saying they feel more emotionally connected to brands using personalized avatar interactions over the usual click-and-type interfaces, this isn’t just for show.

Tools like Gravatar’s AI Profile Builder allow you to build smart, secure avatars that actually do something.

These AI avatars adapt based on where you are and who you’re talking to. Drop into a professional thread? Your avatar turns on the polish. Chiming in on a casual forum? It relaxes the tone. All without you lifting a finger.

For businesses, this opens up a goldmine: Deeper customer engagement, zero need for juggling multiple digital personas, and bulletproof brand consistency, without compromising on privacy.

We’re not just putting an AI face on your profile. We’re building a secure, intelligent bridge between your real self and your digital one – one that works across thousands of platforms.

This means you get to nail that tricky balance between personalization and privacy. 

End result: A smart, responsive avatar that feels genuinely “you”, without handing over your life story to the algorithm gods.

Digital avatars in business: Strategic applications that drive results

Image for: Digital avatars in business: Strategic applications that drive results

When businesses keep their avatars consistent across platforms, they create that magical “ah yes, I know you” moment. It’s instant visual recognition that cements brand identity and reassures your audience they’re in the right place, whether they’re browsing your website, stalking your socials, or firing off a support ticket.

And it’s not just about looking slick. A 2024 University of Reading study showed a significant jump in user interactions when brands used culturally tuned digital avatars in international campaigns. 

Turns out people respond better when your brand feels familiar and relatable, and not like a tourist fumbling through Google Translate.

But avatars aren’t just for marketing. They’re transforming customer service, too. Virtual assistants with avatar interfaces spark more engagement than plain old text bots. Turns out, people prefer chatting with a “someone” rather than a “something.”

Case in point: Lemonade Insurance.

Their claims assistant, Jim (an AI avatar), processes requests in literal seconds. Customers now trust it more than traditional reps, and it’s not just about the speed – being presented with a friendly, familiar face turns a cold system into a warm interaction.

The end result? Happier users who stick around longer and actually enjoy the convo.

Now, for the pros in the room: Enter Gravatar.

Whether you’re replying to a blog comment, debugging on Stack Overflow, or posting in a Slack channel, Gravatar has you covered.

Unlike avatars that change depending on the platform (and leave your brand scattered like confetti), Gravatar keeps everything tidy and cohesive. Set it up once, and your professional avatar just shows up across thousands of platforms without you lifting a finger. It’s recognition on autopilot.

And for businesses building community platforms? The Gravatar API is your new best friend. It lets users show up with their avatars already in tow – no need for endless image uploads or awkward “who’s who” moments. Just seamless, identity-based connection right out of the box.

Implementation guide: Creating the right avatar solution for your needs

Image for: Implementation guide: Creating the right avatar solution for your needs

Before you go charging into avatar creation mode, pause. Breathe. Ask yourself: What do I actually need this avatar to do?

Because the best avatar isn’t just pretty, it’s purpose-built. And the right solution depends entirely on your goals:

  • Brand consistency – Need a single, recognizable face across all your digital turf?
  • Personal branding – Want to show up as a thought leader or expert, loud and clear?
  • Customer interaction – Planning to use avatars in live support or sales scenarios?
  • Immersive engagement – Building an experience that needs personality, emotion, and connection?

Each goal unlocks a different avatar approach, so pick your strategy before picking your style.

Type of avatarPurpose Examples
StaticConsistent visual branding; establish familiarity and recognition.Company logo icon, profile headshot, illustrated character used across web pages and email signatures
InteractiveReal-time, personalized customer interactionAI chatbot with animated face, live avatar-based support agent

No matter what your preferred avatar is, if you’re building a full-blown avatar ecosystem (i.e., membership platforms, technical communities, enterprise apps), then you’ll want to get serious about your tech stack.

Here’s what to factor in:

  • Storage for high-res avatar files
  • Content delivery networks (CDNs) for global speed
  • Sync systems to keep identities aligned everywhere
  • API integrations with your user databases

This is where Gravatar really shines: Its email-based ID system handles identity, and the REST API makes delivery dead simple. Just hash an email, hit the avatar or profile endpoint, and Gravatar returns consistent, customizable visuals – no storage, no syncing, no fuss. 

Developers get fast, cacheable responses, optional profile data, and fallback image controls – all without bloating your backend or reinventing the wheel.

Bottom line: Your perfect avatar setup depends on what you’re building, how techy you’re feeling, and the kind of connection you want with your audience. Choose wisely, and let your digital self do the heavy lifting.

Digital avatar design best practices

When it comes to designing your digital avatar, you want it to be instantly recognizable, reliably familiar, and – above all – consistent wherever it shows up. That visual déjà vu is what builds trust. So, a few pointers:

  • Always, always go for crisp, high-quality visuals. If your avatar looks like it was snapped through a potato or cropped with garden shears, it sends a subtle message that details aren’t your strong suit. Not ideal when you’re aiming to be taken seriously.
  • Make sure your avatar scales like a pro. Whether it’s a teeny-tiny dot in a comment thread or proudly displayed on your profile, it should stay sharp and identifiable. So skip the intricacies – those fine details tend to vanish faster than free Wi-Fi at a cheap café.
  • Test everything. Your avatar might look stunning on your 27-inch monitor, but end up awkwardly cropped on someone’s smartphone. Preview it everywhere before you commit.

One last pro tip: Set up a Gravatar profile. It’s the easy button for keeping your avatar synced across WordPress, Slack, and a ton of other platforms. Update it once, and your whole digital universe stays in step. Clean, consistent, and credible.

Transform your online presence with Gravatar: Start creating your professional digital identity today

Image for: Transform your online presence with Gravatar: Start creating your professional digital identity toda

Tired of uploading your headshot again for the millionth platform? Gravatar is the slick, savvy avatar service that makes you look polished across the internet without breaking a sweat (or opening Photoshop).

Set up your Gravatar once, and that single image becomes your visual passport across the internet, including websites like WordPress, GitHub, Slack, Figma, Mailchimp, Stack Overflow, OpenAI, Atlassian, Coinbase, and more! 

Whether you’re commenting, collaborating, or contributing, your avatar shows up instantly, building recognition and credibility with every interaction.

And if you’re creating a platform where identity matters, Gravatar’s APIs are a goldmine:

  • Avatar API – Automatically pulls user avatars so when they register on your website, they don’t have to upload a new profile pic – instant recognition and zero setup friction.
  • Profiles-as-a-Service API – Pulls bios, links, and other profile data directly from Gravatar, streamlining onboarding and slashing form fatigue.

Faster dev time, smoother UX, and more trust from day one.

Oh, and did we mention? It’s totally free. No fees, no upsells, no “pro” plan with features locked behind a paywall. Gravatar is used by millions of professionals around the world, and you can join them without spending a penny.

Just register and sit back as your avatar quietly does its thing, building trust, recognition, and brand alignment across the web.

by Ronnie Burt at May 23, 2025 05:42 PM

Do The Woo Community: Do the Woo is Sponsoring WordCamp Europe 2025

Image for: Do The Woo Community: Do the Woo is Sponsoring WordCamp Europe 2025
We're exciting to sponsor WordCamp Europe 2025 again. Come by our booth and join the community conversatoin.

by Bob Dunn at May 23, 2025 10:02 AM