If my calendar is correct, one of the OG bloggers Anil Dash is turning 50 today! His blog, which I believe has been active since 1999, inspired me with how he effortlessly transitioned between his top-tier fandom of Prince and his thoughtful commentary on the nuances and second-order effects of what we were doing with blogging, micro-blogging, web standards, interoperability, and much more. His writing is incisive and insightful. I see a core flame of empowering independents throughout his career that very much aligns with the philosophies I aspire to. Please follow him if you don’t already, and happy birthday Anil! It appears that I have linked to him 15 times on my blog before this post, and he has commented 17+ times, the first in 2005, so we have some history! Since I started drafting this he published his Five for Fifty birthday post.

Simon Willison has vibe-coded 124 useful tools.

There are many levels to the excellent Scott Alexander satire of God, Iblis (Islamic word for devil), and Dwarkesh Patel, one of the best new podcasters of this era.

There are people who have gone their whole lives without realizing that Twinkle Twinkle Little Star, Baa Baa Black Sheep, and the ABC Song are all the same tune […]

If they’re used to stories about surgeons getting completed with the string “man”, then that’s the direction their thoughts will always go… Also, how come God can’t make humans speak normally? Everything they say is full of these um dashes!

Which leads to a hat tip to Brian Gardner on the incredible McSweeney’s Em dash responding to the the AI allegations.

So next time you read something and think, “AI wrote this—it has a lot of em dashes,” ask yourself: Is it AI? Or is it just a poet trying to give you vertigo in four lines or fewer?

I wasn’t sure I was going to make it to WordCamp US this year, but at almost the last minute, WordPress.com helped me out with travel and accommodations! More on that below.

Contributor Day

The first day was contributor day and I was a table lead. I think we had more people this year than any other year before. I started the day showing 4 or 5 people how to become contributors, and they each uploaded 20 photos or so. All told we moderated about 160 photos during the day, and pushed the total over 26,000. I also made some great new friends!

Photography

For the first time ever I was on the WordCamp Photography team. I feel like it’s a great honor because don’t really think of myself as a photographer, and I don’t even own a “real” camera, I just use my iPhone. I do have some lenses from Moment.io which are cool, but they’re not a patch on some of the big crazy lenses I saw around. I took several hundred pictures over the week, here are just a few:

The Mural

In addition to the regular photos, I got a series of Jax Ko making a WordCamp mural. They painted for 2 straight days, and I took a photo about every 2 hours. Here’s the progression in slideshow format:

How I Got There

As I mentioned at the top, WordPress.com was my sponsor to get to WordCamp US this year. I really wanted to attend, I’ve never missed one! They very generously offered to help me get there and cover my hotel. More than that though, folks from .com at WordCamp sought me out and told me how glad they were that I was there. It was a very welcoming gesture.

If you haven’t looked at WordPress.com for hosting in a while, you should check it out. There have been some substantial changes in the last few years, there are some great new features.

While many people may have thought of WordPress.com as a “free blog” platform only, WordPress.com has been a full-featured host for years. At the business and commerce plan level the plugin library is available for both free and paid plugins, which is great, and for more advanced users and developers they offer features like staging servers, SSH access, WP-CLI, github deployments, and a local development environment. That local dev environment allows you to copy sites from production to local and then push back to either staging or production. This lets you to work on your site without disrupting your visitors’ experiences.

Even if you don’t have hosting needs at the moment, you can still get involved! They have a great affiliate program, check it out here.

The post HeroPress at WordCamp US 2025! appeared first on HeroPress.

On the podcast today we have Destiny Kanno, Isotta Peira and Anand Upadhyay.

Destiny is the head of Community Education at Automattic. Isotta is the leader of the WordPress credits initiative for students. Anand is the founder of WordPress Campus Connect.

This episode is all about how WordPress is not only powering websites but also empowering the next generation of learners and creators. You’ll hear about the growing movement of education-focused WordPress events happening worldwide, from hands-on workshops on university campuses in India, to student clubs designed to keep the momentum going after introductory events.

Anand shares how WP Campus Connect is bringing WordPress directly to students, reducing barriers to entry and helping bridge the gap between academic learning and real-world tech skills. We also explore the challenges of organising these events, from convincing institutions of the value of open source, to fostering genuine community involvement among both students and educators.

Isotta then introduces us to the WordPress Credits program, an initiative that lets students turn their contributions to the WordPress ecosystem into recognised academic credit at universities like Pisa in Italy. It’s a win-win: students gain practical, resume-worthy experience, while educational institutions get a transferable, skills-focused, program that prepares learners for the jobs of the future.

Whether you’re an educator, a WordPress enthusiast, or just someone who cares about open source and community, this episode is packed with actionable insights. The guests share how flexible and resilient these education initiatives are, how you can get involved, and why engaging the next generation is not just important, but essential for the continued growth and sustainability of the WordPress community.

It’s a truly inspiring episode, and is at the intersection of so many areas of profound importance.

If you’re curious about how to bring WordPress into your local school, university, or community, or if you just want to hear how WordPress is making a difference far beyond the web, this episode is for you.

Useful links

WordPress Credits Program

WordPress Credits: A bridge to open-source technology

WordPress Campus Connect

Learn WordPress

WordPress Student Clubs

Introducing WordPress Credits: A New Contribution Internship Program for University Students

Biographies

Destiny Kanno

Destiny Fox Kanno, sponsored contributor at Automattic with a focus on education within the WordPress community. Currently focusing on growing, enabling and amplifying the WordPress Campus Connect and Student Club initiatives.

Isotta Peira

Isotta joined the WordPress Community in 2022 as a full-time contributor to the Community Team, sponsored by Automattic. With a background in translation, sales, training, and community management, she also ran a culinary events business. She values making informed decisions by integrating data analysis into her work and believes sharing knowledge is key to fighting inequality. Isotta is currently leading the WordPress Credits program, an initiative that connects open-source contributions with academic curricula worldwide.

Anand Upadhyay

Anand Upadhyay is the founder of WPVibes, a WordPress plugin development company. He has been working with WordPress since 2010 and contributes to several Make WordPress teams, including Core, Docs, Polyglots, and Community. He also serves as an organizer for WordCamp Asia, one of the flagship events in the WordPress ecosystem.
In addition to building plugins, Anand is deeply passionate about teaching and education. He co-organizes the Ajmer WordPress Meetup and is currently contributing to the global expansion of WordPress Campus Connect, a program he initiated as a pilot in 2024 to introduce students to WordPress and open source. Through these efforts, he focuses on helping new learners and contributors discover opportunities to learn, grow, and find their place in the WordPress community.

You might be a WordPresser if…

• You like to have freedom and control over all your software.
• You don’t mind taking a bit more time to invest in tools that give you agency.
• You like inserting little opportunities for joy in everyday interfaces.
• You want future generations to grow up with a free and open web.
• You like to tinker, hack, mod, customize, and share what you learn.
• You are impeccable with your word.
• You think software should have a little soul in it.
• You love giving other people superpowers, teaching them not to need you anymore.
• You appreciate a good plan but want to be able to color outside the lines, or completely reimagine the canvas altogether.
• You think technology is best when it brings people together.
• You get excited by updates.
• You want your corner of the web to truly be yours, not generic or commoditized slop.
• Your friends come to you to learn about new stuff.
• You leave things better than you find them.
• You fix things as you find them, it’s never someone else’s problem.
• You know a single comment can light up someone’s day.
• You’ve gotten out of the house to meet other people into WordPress.
• There’s a Wapuu item or sticker somewhere in your life.
• You “view source.”
• You know the difference between owning your content and being a digital sharecropper.
• You’ve drunkenly registered a domain, and have more domains than websites.
• You’ve snuck an easter egg in a slug.
• You have a Gravatar, and it’s also a museum of all your email identities over the years.
• You think code can be poetry.

If you identified with two or more of these statements, I am afraid to inform you might be classified as a WordPresser. What did I miss?

Over the years, I have been an ardent supporter of keeping WordPress lean and letting plugins and themes do all the fun, custom stuff. But the block paradigm shifted everything. And moreso, it shifted everything about building WordPress themes.

Today, my perspective has changed, and I’ve nestled into the camp of those calling for more blocks in WordPress.

Let me explain why.

A journey

Let’s jump back in time for a moment. Three and a half years ago, just before the release of WordPress 5.9, themers were in complete control of the front-end output of WordPress sites. 

Well, that’s a bit of a stretch. They were actually in control of everything but the content. Of that, they mostly had styling control. It was much like the previous 18 years where you would have the freedom and flexibility to build whatever you wanted. 

But in the few years leading up to that point, the landscape had begun changing. Themes had to be compatible with new types of output beyond the basic paragraphs, headings, lists, and media. The Block Editor had been on the scene for a while before WordPress 5.9, but theme authors still exercised almost all the control they had in the past.

Once you started building block themes, suddenly what was possible shrank very, very quickly.

Want to include breadcrumbs? You need to add support for a breadcrumbs block, but which one?

Need an accordion? Maybe you could manipulate the Details block, but that may not be an accessible approach.

How about including SVG icons? You guessed it; you need an icon block for that.

And have you ever experienced what the UI looks like when a user doesn’t have a supported block installed?

Eeeek!

Gone were the days where you could just include anything and everything. It’s like painting on a canvas with a limited color palette and set of brushes when you previously had every tool at your disposal.

Now, truly great artists can make magic happen regardless of the tools. Things like the Block Bindings API can fill in some of the gaps. But some features are just darn hard without a dedicated block.

Before block themes, theme authors enjoyed loads of new features over the years, but how and what you could build mostly remained static, the only limitation being the technology of the day. Block themes created the potential for more people to take that first step into the world of theming without knowing any code whatsoever. And they introduced the standards that so many of the inner community had called on for so long, created better interoperability with plugins, and brought contemporary technologies to WordPress.

But the cost was a limited toolset that required new ways of thinking from us old timers who’d been merrily doing our own thing for so long.

It’s an exciting world, but it could be more exciting in the next stage of this journey.

The case for more Core blocks

I am a developer. I love tinkering with anything and everything. I even dabble in creating custom plugins, but my true passion is creating WordPress themes. I’ve probably written just as much on the subject as anyone over the years. It’s safe to say that I know the technical limitations of block theming as much as anyone can reasonably be expected to (though I’m still learning new things all the time).

So when Matías Ventura, the Project Architect of Gutenberg, opened a ticket calling for more niche blocks in WordPress, it piqued my interest. The list of potential blocks were:

• Icons
• Playlist
• Slider/Carousel
• Stretchy Text
• Tabs
• Accordion
• Mega Menus
• MathML
• Marquee
• Table of Contents
• Time to Read
• Breadcrumbs
• Dialog

Admittedly, I chuckled at the thought of a Stretchy Text block actually being included in Core. But the more I dug into what it takes to actually implement the design, I could see the case for it. I certainly don’t see a good way of using it in a theme design pattern without a dedicated block.

And marquees? Were they not relegated to a long dead era when Geocities ruled the blogosphere? I miss the old days of the wild and wacky web. Could be fun.

It’s easy to get tangled up in the weeds, using the most niche blocks as arguments against components like accordions, tabs, dialogs, and table of contents, which are standard pieces of the web as we know it today.

If you recall, I said earlier that I was a longtime supporter of keeping Core lean. The old WordPress was very much a development framework. But as a theme author in the block theme era, I’ve moved much closer to the thoughts that Ventura espoused:

I think not having these blocks in the core library severely limits the expressiveness that theme builders (and users) can depend upon to build great designs and it can fracture the overall experience.

There have been many moments in the last three years where I’d have 95% of the work done, speeding toward the finish line of a block theme project. Then I’d smash into a brick wall. Quite often that wall was a missing design component. 

I’ve been in the development game long enough to find workarounds, but it’s been at the expense of untold hours of development time that could’ve been better spent elsewhere.

And if I’m at the top of my game, what hope is there for newcomers who have bright ideas and big dreams? Will they be able to build that unique design they have in mind? Or will they switch to another platform?

So…I want more blocks. 

I want more possibilities. 

I want to make ideas come to life without spending a week figuring out how to pigeonhole some feature into a place it doesn’t belong just to make things work.

To include or not include

I hope that you at least agree on one point: For block theming to progress, WordPress needs a mechanism for theme authors to fully express their ideas. 

Everything beyond that is implementation details. Ventura’s proposal for additional blocks has garnered a lot of discussion over the past month both in the ticket and elsewhere around the community. There’s wide agreement and disagreement on some or all points.

Chiefly, whether the more niche blocks should be bundled is of concern. Things like future compatibility, potential legacy baggage, and bundle size are worth discussing. There’s also the potential for Core/Canonical blocks that Ventura proposed in 2024, a set of blocks built and maintained by WordPress contributors but not shipped with the platform itself. I’d even be happy with a method of auto-installing supported blocks when a user activates a theme.

Frankly, I don’t much care how we get there—just that we do. And I hope that god-forsaken “your site doesn’t include support for the [name] block” message never graces the screen of one of my theme’s users.

Let me bundle patterns with icons that users can swap out as needed:

Let me create accessible accordions without manipulating the Details block:

Just let me create something beautiful.

Props to Birgit Pauli-Haack, Anne McCarthy, and Héctor Prieto for feedback on this article before publishing.

The New Yorker is always good, but they’re having a bit of a victory lap as they celebrate their centennial. This article on the vaunted fact-checkers is such a delight, with so many in-jokes and back references it’s hard to keep track.

When I started WordPress, I wrote down five publications that I hoped someday we’d make software so good they’d adopt it. The New Yorker is one of them. If you enjoy words that make your brain tingle, make sure to also follow Automattic’s publications, Longreads and Atavist.

If you signed up on the original post, you will also receive this info in an email.

For week one of a WordPress Book Club, we will be discussing the Preface and Chapter 1. Introduction.

To start the club, we are going to do introductions. I’ll ask everyone to share their name and how long they have been involved in open source. We’ll do this popcorn style.

Next I’ll quickly review some norms for this club:

• Make Space for each other — Be conscious of how much you are speaking and encourage others to speak as well. While cooperative overlapping is a conversation style that is natural to some, it’s one we should avoid in this context.
• Approach this club with enthusiastic collaboration — This is a phrase that I stole from the preface and is one of the ways that the author describes the unique culture of open source. In this context the phrase means to me that everyone is coming with a positive attitude and a desire to share and learn. We will all assume good intent since everyone is approaching this with good intent.
• Camera On by default, no questions asked if camera is off — It’s easier and more engaging if we can see each other, so I want to encourage you to have your camera on, but there are also a multitude of reasons that you may want it off. You don’t need to explain why your camera is off, but if you can, please turn it on.

After that we will get to the meat of the session, and discuss these two sections. I’ll bring a few questions to help get the discussion flowing, but I would also love if folks brought their own as well. Since the majority of participants don’t work in open source day in and day out, I expect some questions to be about ways to apply our learnings outside open source.

Finally, I am going to encourage everyone to spend some time blogging their thoughts after the discussion. This can be a reaction to something you read or something discussed. It can be notes you took while reading, but I would like to encourage blogging.

The post WP Book Club Week 1 appeared first on Aaron Jorbin.

I’m still buzzing from an incredible WordCamp US this week, from contributor day to the closing party the vibes were right and it was amazing to connect with fellow travelers in the journey towards creating a more free and open source internet.

Before our open town hall Q&A I was able to make some fun announcements:

• Traffic to WordPress.org is up, and we’ve brought the plugin queue from months to basically a few days.
• Previewed Block Comments and the upcoming Command Palette feature in 6.9.
• Shared some fun AI experiments, including Felix’s AI chatbot demo, Automattic’s new Telex block creator, and more.
• Got to announce details for the next two flagships:
  • WordCamp Asia 2026: Mumbai, India, from April 9^th to 11^th.
  • WordCamp Europe 2026: Kraków, Poland. June 4^th to 6^th 2026.
  • WordCamp US 2026: Phoenix, Arizona, from August 16^th to 19^th.

Give it a watch!

A full house of attendees gathered in Portland, Oregon, for WordCamp US 2025, with thousands more tuning in online. Over four days, the flagship WordPress event brought together contributors, innovators, and community members for collaboration, inspiration, and discovery.

The WordPress event began with a dedicated Contributor Day and continued with a Showcase Day and two days of sessions filled with talks, panels, workshops, and community celebrations. WordPress Cofounder Matt Mullenweg joined a diverse lineup of speakers, panelists, and workshop leaders who brought fresh perspectives to the open web from across the globe.

Set against the vibrant backdrop of Portland — with its iconic bridges, coffee culture, and creative energy — the Sponsor Hall buzzed as companies across the WordPress ecosystem demoed new products, shared insights, and connected with attendees. Each day offered opportunities to refuel with local flavors and international favorites, turning mealtimes into lively hubs of networking and idea-sharing.

A Global Gathering in Portland

WordCamp US is the annual gathering point for the WordPress community — where collaboration, creativity, and innovation intersect. This year in Portland, the event delivered an expansive program that reached every corner of the ecosystem.

Here’s what attendees experienced:

• Engaging Sessions Across Tracks – Keynotes, presentations, and discussions explored the evolving web and the role of open source in shaping it.
• A Global Speaker Lineup – Voices from across continents brought local stories and global visions to the stage.
• Wide-Ranging Topics – From AI in WordPress development to accessibility, design systems, content strategy, education, and case studies of WordPress at scale.
• Hands-On Learning Opportunities – Workshops provided practical takeaways, empowering attendees to apply new skills immediately.
• A Community Built on Collaboration – Whether contributing code, exploring business strategies, or sharing creative projects, attendees found space to learn, grow, and celebrate open source together.

New contributors took their first steps into open source, seasoned developers explored cutting-edge AI integrations, and agencies and product teams shared strategies for scaling WordPress to meet modern needs. Beyond the technical, conversations around inclusivity, sustainability, and education underscored WordPress’s role as a tool for empowerment and positive change.

In hallways, coffee lines, and evening meetups, attendees found the “hallway track” alive and well, spontaneous moments of connection that often became the most memorable part of the experience. Whether reconnecting with longtime collaborators or meeting someone new, these small interactions reinforced the heart of WordCamp US: a community that thrives on openness, generosity, and shared purpose.

Contributor Day: Collaboration at the Core

The conference opened on Tuesday, August 26, with a vibrant Contributor Day. Nearly 300 contributors filled the space, including more than 120 first-time participants who were onboarded across 19 teams. Developers, designers, translators, marketers, and community organizers worked side by side, representing WordPress expertise.

Throughout the day, contributors tackled everything from improving accessibility and performance to refining documentation to enhancing translation tools. Beyond technical contributions, teams like Marketing and Community focused on outreach, mentoring, and shaping future-facing initiatives. Remote participants joined via dedicated channels, reinforcing the inclusive nature of WordPress’s global community. By day’s end, the collective energy was clear: WordPress continues to be built by and for everyone.

The mix of experience in the room made this year especially notable. First-time contributors were paired with seasoned table leads who guided them through their first steps into open source contribution. Longtime contributors reconnected with their teams and advanced ongoing initiatives, while new voices added fresh perspectives and momentum. The spirit of mentorship was woven throughout, ensuring that Contributor Day was productive and welcoming.

The results spoke for themselves:

• Polyglots translated more than 12,000 strings, expanding WordPress’s accessibility worldwide.
• The Community team celebrated the approval of two brand-new local meetups.
• The Training team achieved its objective of updating outdated course thumbnails.
• The Core team worked through a live bug scrub, with 9 committers and 16 contributors collaborating on improvements.
• The Documentation team completed numerous content updates to keep resources fresh and reliable.

Momentum carried through every table, with participants reporting measurable progress and a renewed sense of shared purpose. Contributor Day once again highlighted the unique power of collaboration in shaping the open web, proving that every contribution matters through code, translations, training, or community building.

Showcase Day: WordPress in Action

Wednesday, August 27, was the popular Showcase Day, spotlighting real-world innovation in WordPress. Initially expected to draw about 250 participants, Showcase Day welcomed more than 800 attendees — a powerful sign of how much energy and curiosity the community brought to Portland. The sessions demonstrated how WordPress powers meaningful work across industries from nonprofits to newsrooms, agencies to global enterprises, while staying true to open source values.

The day opened with a keynote by Amy Sample Ward: The Tech That Comes Next. Drawing from their co-authored book with Afua Bruce, Amy highlighted the inequities embedded in today’s technologies — from dataset bias to accessibility gaps — and challenged attendees to rethink how tools are funded, built, and deployed. Their talk invited technologists, funders, and community leaders to imagine a more equitable digital future, rooted in collaboration and shared responsibility.

From there, Joeleen Kennedy of Human Made shared how Full Site Editing (FSE) shapes the refresh of Wikimedia’s ongoing user experience. Her session Modernizing at Scale detailed how FSE is simplifying workflows, improving accessibility, and making the multilingual platform more sustainable for the long term. Attendees gained a behind-the-scenes look at how one of the world’s largest open knowledge platforms is leveraging WordPress innovation.

Josh Bryant took the stage to explore what happens when Gutenberg leaves the WP-Admin dashboard. His talk, Reimagining WordPress Editing, walked through embedding the block editor into a standalone React application to support Dow Jones’s newsroom workflows. From decoupling Gutenberg to managing custom data stores, the session showcased advanced techniques for scaling editorial tools while maintaining the flexibility of the WordPress ecosystem.

Hands-on learning was a hallmark of Showcase Day, with Jamie Marsland’s workshop leading participants through building and launching their own professional portfolio sites — no coding required. Attendees left with a fully functioning site, demonstrating WordPress’s continued ability to empower anyone, anywhere, to publish online.

In the afternoon, Jeffrey Paul’s session Scalable, Ethical AI addressed one of the most pressing topics in today’s digital world: how to integrate AI without sacrificing ownership, privacy, or open standards. Walking participants through practical use cases with ClassifAI and local LLMs, Paul emphasized how WordPress can help content creators harness AI while maintaining autonomy over their data.

The day closed with a forward-looking community highlight: WordPress Campus Connect. Panelists Destiny Kanno, Andrés Parra, Javier Montes de Blas, Mauricio Barrantes, and Elineth Morera Campos shared how this initiative brings WordPress into classrooms and universities worldwide. Student Andrés Parra received a scholarship to attend WordCamp. During the panel, Elineth also announced that Fidélitas University will begin offering its students a WordPress Credits program starting in October 2025, making it a mandatory addition sometime in 2026, enabling them to contribute directly to WordPress as part of their studies.

By connecting students and educators with the open web, Campus Connect is building the next generation of contributors and innovators, ensuring that WordPress remains both a learning tool and a pathway to opportunity.

Taken together, Showcase Day affirmed that WordPress is more than just a CMS — it is a platform for equitable technology, global collaboration, cutting-edge enterprise solutions, and the future of digital education. WordPress has the power to be both a platform and a community tool for education, equity, and innovation.

Presentation Days: Learning, Inspiration, and Connection

The first full day of sessions at WordCamp US 2025 opened with warm remarks from the organizing team, who reminded attendees: “The most important thanks goes to all of you. The mix of new energy and veteran experience is what makes WordCamp so special, so thank you for being here.” That spirit of gratitude and community carried throughout the event.

The Sponsor Hall became a hub of activity, complete with raffles, the return of Career Corner, and even a Voodoo Donut Truck parked outside. Attendees lined up to test their luck at a claw machine stuffed with plush Wapuus, while others sought guidance at the Happiness Bar — a hands-on help desk for WordPress questions big and small. Between these activities, the steady buzz of conversations made it clear: the “hallway track” remained one of WordCamp’s most valuable experiences.

The program itself set a high bar. Danny Sullivan’s keynote shed light on how search has evolved to meet the needs of new generations, from 24/7 demand and mobile expectations to short-form video and AI. His session gave attendees a deeper understanding of how search intersects with publishing today and sparked conversations about how WordPress can continue adapting in an era where AI shapes discovery and content.

From there, the schedule unfolded across multiple tracks. The Core AI panel — featuring James LePage, Felix Arntz, and Jeffrey Paul — offered a look into how AI tools are woven into WordPress core. Emphasizing ethics, transparency, and user empowerment, the panel painted a roadmap for how WordPress can adopt new technologies without compromising its open-source values.

Hands-on learning played a significant role throughout the conference. Ryan Welcher’s interactive Block Developer Cookbook drew a packed room as participants worked through community-selected code recipes built on the latest WordPress APIs. By the end, attendees left with working examples and practical strategies they could bring back to their projects.

The program also highlighted diverse technical perspectives. Jemima Abu’s session, A PHP Developer’s Guide to ReactJS, bridged the gap between classic and modern web development. At the same time, Adam Gazzaley’s keynote, A New Era of Experiential Medicine – AI and the Brain, invited attendees to consider the human side of technology, exploring how digital tools can advance health and well-being.

The second day of presentations, Friday, August 29, opened with creativity and imagination. John Maeda’s keynote, Cozy AI Cooking: WordCamp Edition, used the metaphor of a kitchen to demystify AI, blending storytelling with technical insight to show how curiosity and care can guide builders in integrating AI into their work.

Later in the day, Tammie Lister’s The System is the Strategy illustrated how design systems provide structure and scalability for growing WordPress projects. At the same time, Adam Silverstein’s Unlock Developer Superpowers with AI showcased new ways developers can use emerging tools to speed up workflows and problem-solving.

Community stories also took center stage. In Creators around a Campfire, Anne McCarthy, Jamie Marsland, Christian Taylor, Mark Szymanski, and Michael Cunningham reflected on how YouTubers and content creators shape the WordPress ecosystem. Their session highlighted the role of storytelling and education in expanding WordPress’s reach to new audiences worldwide.

The Sponsor Hall remained lively between sessions — with attendees meeting companies, testing demos, and swapping ideas that extended far beyond the conference halls. They also shared moments together at the arcade built for the event and added smiles, hugs, and laughter, which underscored the atmosphere: WordCamp US was as much about connection as code.

Together Into the Future

As the event drew to a close, WordPress Cofounder Matt Mullenweg took the stage to share the current state of WordPress and a vision for its future. He highlighted the growth in social media for WordPress with 124,726 new followers since last WCUS — and the WordPress.org website growing over 10% in users along with almost 20% in new users.

Matt also spotlighted community initiatives shaping the future of open source education and diversity: WordPress Campus Connect, which has already reached 570 students across 11 events. Combined with the growth in overall events (77) which is a 32.76% increase over 2024. Each effort reinforced the message that WordPress is more than software; it is a global movement driven by people.

He concluded with a live Q&A, fielding questions from the audience on the direction of WordPress, its role in an AI-driven web, and the importance of keeping the project open, inclusive, and adaptable. The final notes of the keynote carried into a closing party in downtown Portland, where attendees capped off the week with music, conversation, and the unmistakable joy of a community coming together.

Closing

WordCamp US 2025 once again demonstrated what makes the WordPress ecosystem extraordinary: a community committed to building tools, resources, and opportunities that empower people everywhere.

This year also marked the debut of the Open Horizons Scholarship, which funded six recipients — two organizers, three volunteers, and one speaker — from five countries. A total of $14,670 supported their journeys to WCUS. The scholarship, which also supports participation at WordCamp Asia and WordCamp Europe, is designed to make flagship events more accessible to contributors worldwide.

A heartfelt thank you goes to the organizers, volunteers, sponsors, and speakers who brought the Portland edition to life — and to every attendee who joined us in person or followed along online. 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 next global gatherings: WordCamp Asia 2026  in Mumbai, India, WordCamp Europe 2026  in Kraków, Poland, and WordCamp US 2026 in Phoenix, Arizona. We can’t wait to see you at the next chapter of the WordPress story.

Pretty heads down at WordCamp US, which has had amazing energy and talks so far. I wanted to take a moment to note two things, first being a great essay from Dave Winer asking people to Think Different about WordPress.

I’ve done this before — asked people to think differently about things, like public writing, with blogging. In the 90s I was running around the Vallley trying to explain to everyone that blogging was going to change everything, all I got was blank stares from people who said “we don’t do that.” They of course eventually did do it. But at first the ideas seemed foreign, unreasonable.

And in light of the news of Typepad shutting down, note that WordPress has a Typepad importer. A big advantage of putting your content into an open source platform like WordPress with an active community, vs just static pages or something custom, is that you’re getting constant upgrades “for free” as we maintain and iterate on the software, enabling new APIs or things like allowing your AI to talk to your site.

WordPress is built by a community of people deeply passionate about backwards and forward compatibility, radical openness so it’s easy to get things in and out of it, and relentless iteration building for the long term. Despite literally billions of dollars spent trying to kill or crush WordPress, and frequent proclamations of its death, we keep trucking along and doing our darndest to make the web a bit more open and free every day. It’s a life mission of many people, including myself.

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

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

Here’s my talk on WordPress.tv (but it’s also available on the YouTube livestream recording):

And here are my slides as well:

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

Table of contents:

Performance Lab

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

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

Case Study: Twenty Twenty-Five

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

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

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

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

Performance Testing Methodology

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

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

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

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

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

Largest Contentful Paint

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

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

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

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

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

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

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

Benchmarking

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

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

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

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

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

namespace ActivePluginsOverride;

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

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

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

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

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

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

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

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

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

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

Analyzing Optimization Impact on LCP

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

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

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

• No-cache BFCache (actually, brand new to Performance Lab)
• Script Module Deprioritization
• Minified CSS Inlining

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

Image Placeholders

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

Instead of this:

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

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

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

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

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

Modern Image Formats

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

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

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

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

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

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

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

Enhanced Responsive Images

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

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

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

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

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

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

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

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

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

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

Here is the performance impact when benchmarking the change:

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

This has a dramatic ~25% reduction in LCP!

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

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

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

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

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

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

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

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

Image Prioritizer

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

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

Responsive Image Prioritization

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

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

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

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

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

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

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

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

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

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

But what becomes truly impressive are the results on desktop:

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

Background Image Prioritization

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

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

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

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

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

The preload LINK looks like the following:

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

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

Here is the performance impact:

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

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

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

Speculative Loading

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

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

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

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

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

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

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

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

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

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

View Transitions

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

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

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

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

Props again to Felix Arntz for spearheading this feature plugin.

No-cache BFCache

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

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

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

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

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

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

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

Script Module Deprioritization

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

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

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

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

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

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

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

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

Minified CSS Inlining

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This decreases the LCP by over a third!

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

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

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

What’s Next

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

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

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

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

• LinkedIn
• Bluesky
• Twitter
• Mastodon
• Threads

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

এই নিবন্ধটি বাংলায় পাওয়া যায়

Beginnings

My story with WordPress began in a classroom. I was a student working on a simple project, a portfolio website. I wanted to use WordPress because it felt easy to learn and flexible enough to build what I had in mind. I completed the project and proudly showed it to my teacher.

Instead of encouragement, I was told to scrap it. “Do it with raw PHP coding,” my teacher said. WordPress was dismissed as the easy way out. At the time, that felt discouraging. I followed instructions and rewrote everything in PHP, but the memory stayed with me.

What my teacher could not see was what I had already discovered. WordPress had opened a door. It gave me confidence that I could build something meaningful with the skills I had. That moment became a seed. It was the beginning of a path that would later shape my career, my community work, and my life.

Learn

In 2016, I joined weDevs. This was my first real step into the professional WordPress ecosystem. Products like Dokan and WP User Frontend were not just plugins. They were solutions that empowered people. Dokan made it possible for anyone to create a multi-vendor marketplace without needing deep technical knowledge. WP User Frontend gave site owners control from the frontend in a way that felt natural and accessible.

Then came WP ERP. This plugin fascinated me more than anything else at that time. The idea that WordPress could run HR, CRM, and accounting for a business was almost unbelievable. For me, it was proof that WordPress is like water. It can take any form. It can flow into any gap and solve almost any problem.

Later, I worked with newer products, including ElementsKit, MetForm, ShopEngine, GetGenie AI, which now powers more than 2 million websites around the world. Over the years, I built an 8-year career in WordPress product marketing, working with multiple global companies to grow their eCommerce, LMS, SaaS, and WordPress products.

But my learning did not stop there. Coming from a computer science background, I shifted into marketing. At first, I wasn’t sure I belonged in this space. But I discovered that having the knowledge of algorithms, logic, and technical systems helped me become a better marketer. It allowed me to solve business problems more effectively and to connect with product teams in a way that bridged technical and user needs. That blend of skills became my advantage.

As Shakespeare wrote, “To be or not to be, that is the question.” For me, the answer has always been to be—to be curious, to be adaptable, and to be willing to learn. Or in the words of Bruce Lee, “Be water, my friend.” That is what WordPress has taught me. Adapt, flow, and find your form.

Connect

In 2017, I organized my first WordPress meetup. It was a small gathering, but the energy in the room was undeniable. People came together to share, to teach, to learn, and to encourage each other. That was when I saw the true strength of WordPress. It was not just software. It was a community.

From that point on, I made community a core part of my life. Meetups turned into WordCamps. I spoke at events. I volunteered wherever I could. And I attended as many gatherings as possible. To date, I have been part of 25 WordCamps around the world. Each one gave me new lessons, friendships, and a sense of belonging.

The first time I spoke at WordCamp Kathmandu 2019, I was nervous. I had fixed what I would say but my heart was racing. I kept thinking, “What if nobody listens? What if I fail?” When I walked onto the stage and looked at the audience, something changed. I saw faces eager to learn. I realized they were not there to judge me. They were there to grow with me.

It was a panel discussion where I sat together with my mentor, M Asif Rahman, and we discussed marketing WordPress products. That panel discussion gave me confidence I had never felt before. It showed me that sharing what you know, even if it feels small, can inspire others. After that, I participated in two other panel discussions: WordCamp Nagpur in 2022 and WordCamp Sylhet in 2024.

Over the years, I have served as a WordCamp Organizer, Speaker, Volunteer, Global Mentor, and Event Supporter. I mentored teams as they organized their first WordCamps, helping them overcome challenges and celebrate success. These connections showed me that WordPress is not just a platform to build websites. It is a platform to build people. It gives us the tools, but more importantly, it gives us the relationships that carry us forward.

In 2022, I was humbled to receive the Yoast Care Fund award for my community contributions. It reminded me that the efforts we give to the community, often behind the scenes, do not go unnoticed.

Contribute

With learning and connection came responsibility. I knew I had to contribute.

Contribution takes many forms. For me, it has been about building communities, mentoring, and supporting events. I have served as a WordCamp Mentor and Global Event Supporter, helping new organizers take their first steps. I have guided teams, answered their questions, and encouraged them through the challenges of organizing. Seeing them succeed gave me joy that no personal achievement could replace.

WordCamp Asia holds a special place in my heart. I have been part of its organizing team three times so far, including working with the AX and communications teams. It was a chance to tell stories, welcome attendees, and celebrate the diversity of Asia’s WordPress community.

When I joined the organizing team for the first WordCamp Asia in 2022, it felt like stepping into history. This was the first flagship WordCamp in our region, and expectations were sky high. I worked on the AX team, helping to provide an amazing experience to the attendees. There were long nights, endless discussions, and moments of uncertainty. But when the doors opened and thousands of people gathered, it was worth it. That event showed me how powerful Asia’s WordPress community had become. It was proof that our voices, our energy, and our contributions mattered on a global scale.

Since then, I continued serving as part of WordCamp Asia 2023 and 2025, and later joined the organizing team of WordCamp US 2025, one of the biggest WordPress events in the world. Being part of that team was a reminder that no matter where we come from, our contributions connect us on a global scale.

In 2025, I was also honoured to be selected as a recipient of the Automattic Open Horizons Scholarship, which supports contributors from underrepresented communities in continuing their WordPress journey.

At the same time, I am pursuing a PhD in marketing, researching Agile Marketing Methodologies for Promoting Digital Software Products. For me, this connects directly to WordPress. Agile and AI-driven methods are shaping how we market plugins, SaaS platforms, and digital tools. My research helps me give back not only to academia but also to the WordPress ecosystem by exploring new ways to reach people, improve adoption, and create sustainable growth.

Volunteering, speaking, organizing, mentoring, researching — each role has shown me the same truth. Contribution is not about doing everything. It is about showing up, sharing what you can, and making space for others to shine.

A Story for Marketers Who Wonder: “Can I Belong?”

If you are a marketer, a writer, or someone who feels more comfortable with words than code, you may wonder if you truly belong in WordPress. I want to speak directly to you.

You do belong.

WordPress needs your thinking. It needs your storytelling. It needs people who can bridge the gap between product and user. Your technical background, even if it is small, is an asset. Your creativity is essential. Your ability to connect with people is what gives technology meaning.

I moved from computer science into marketing and found my place. You can too. You don’t have to be a developer to be valuable. Contribution comes in many forms. Learning, connecting, mentoring, writing, organizing—all of these matter.

Remember: WordPress is like water. It adapts to the needs of its people. And in the same way, you can adapt your own path in it.

Lessons

Looking back, three words define my WordPress journey.

• Learn. WordPress taught me more than software. It taught me resilience, curiosity, and the courage to explore.
• Connect. The relationships I built through meetups, WordCamps, mentoring, and organizing have been the most valuable part of this journey.
• Contribute. Giving back to the community has been my way of honouring everything I have received.
  

Wrapping Up

I sometimes think about that moment in my classroom when my teacher told me not to use WordPress. At the time, it felt like rejection. Today, I see it as the spark that lit the way forward. Without that moment, perhaps I would not have discovered what WordPress truly means to me.

WordPress has been my teacher, my platform, and my community. It has given me a career, friendships across the world, and a purpose that goes beyond myself.

I am also a loving father of a 3-year-old daughter and a proud husband. My family gives me balance and joy, and they remind me why community and contribution matter so much.

If you are reading this and wondering whether you belong in WordPress, I want you to know that you do. Whether you are a developer, a writer, a designer, or someone still figuring out your path, there is space for you here.

Start by learning. Reach out and connect. Then, when you are ready, contribute in your own way.

That is how WordPress grows. That is how communities grow. And that is how we grow as people.

Learn. Connect. Contribute. That is my story.

শিখুন, যুক্ত হোন, অবদান রাখুন; আমার ওয়ার্ডপ্রেস গল্প

শুরু

আমার ওয়ার্ডপ্রেসের যাত্রা শুরু হয়েছিল ক্লাসে। তখন আমি একজন ছাত্র, একটা পোর্টফোলিও ওয়েবসাইট বানাচ্ছিলাম। কাজটা করার জন্য আমি ওয়ার্ডপ্রেস বেছে নিয়েছিলাম কারণ এটা শেখা সহজ আর ব্যবহার করতেও আরামদায়ক। প্রোজেক্টটা শেষ করে গর্ব করে স্যারকে দেখালাম।

কিন্তু প্রশংসার বদলে স্যার বললেন, “এটা বাদ দাও, একেবারে শুরু থেকে PHP দিয়ে বানাও।” কথাটা শুনে খারাপ লেগেছিল। তবুও তার কথা মেনে PHP তে আবার করলাম। কিন্তু সেই অভিজ্ঞতা মনে গেঁথে রইল।

তখনই আমি বুঝে গিয়েছিলাম ওয়ার্ডপ্রেস আমার জন্য একটা নতুন দরজা খুলে দিয়েছে। সেটাই পরে আমার ক্যারিয়ার আর জীবনের পথ ঠিক করে দিয়েছে।

শিখুন

২০১৬ সালে আমি যোগ দিই weDevs এ। তখন কাজ করেছি Dokan, WP User Frontend, WP ERP এর মতো প্রোডাক্টে। এগুলো আমাকে দেখিয়েছিল ওয়ার্ডপ্রেস কতটা শক্তিশালী হতে পারে।

পরে কাজ করেছি ElementsKit, MetForm, ShopEngine, GetGenie AI এর মতো প্রোডাক্টে, যা এখন লাখ লাখ ওয়েবসাইটে চলছে। গত ৮ বছরে আমি ওয়ার্ডপ্রেস প্রোডাক্ট মার্কেটিং এ ক্যারিয়ার গড়েছি, বিভিন্ন আন্তর্জাতিক কোম্পানির সাথে কাজ করেছি তাদের eCommerce, LMS আর SaaS প্রোডাক্ট বড় করতে।

আমি কম্পিউটার সায়েন্স থেকে মার্কেটিং এ চলে এসেছিলাম। প্রথমে ভয় ছিল আমি পারব কিনা। কিন্তু টেকনিক্যাল ব্যাকগ্রাউন্ডটা আমাকে এগিয়ে দিয়েছে। এতে প্রোডাক্ট টিমের সাথে কাজ করা আর ব্যবসার সমস্যা বোঝা সহজ হয়েছে।

ওয়ার্ডপ্রেস আমাকে শিখিয়েছে কৌতূহলী থাকতে, মানিয়ে নিতে আর শেখা চালিয়ে যেতে।

যুক্ত হোন

২০১৭ সালে আমি প্রথম ওয়ার্ডপ্রেস মিটআপ আয়োজন করি। অনুষ্ঠানটা ছোট ছিল, কিন্তু সেখানে সবাই একে অপরকে শেয়ার করছিল, শেখাচ্ছিল, শিখছিল। তখনই বুঝলাম ওয়ার্ডপ্রেস শুধু সফটওয়্যার না, এটা আসলে একটা কমিউনিটি।

এরপর থেকে আমি মিটআপ, ওয়ার্ডক্যাম্প, নানা ইভেন্টে যুক্ত থেকেছি। এখন পর্যন্ত আমি ২৫টা ওয়ার্ডক্যাম্পে অংশ নিয়েছি, কখনো বক্তা হিসেবে, কখনো স্বেচ্ছাসেবক বা আয়োজক হিসেবে। প্রতিটি অভিজ্ঞতা আমাকে নতুন বন্ধু আর আত্মবিশ্বাস দিয়েছে।

প্রথমবার ওয়ার্ডক্যাম্প কাঠমাণ্ডু ২০১৯ এ বক্তা হই। শুরুতে ভয় লাগছিল, মনে হচ্ছিল যদি কেউ না শোনে? কিন্তু মঞ্চে উঠে দেখলাম সবাই শিখতে এসেছে। তখনই সাহস পেলাম।

২০২২ সালে কমিউনিটিতে অবদানের জন্য আমি Yoast Care Fund Award পেয়েছিলাম।

অবদান রাখুন

শেখা আর সংযোগের পর বুঝলাম ফিরিয়ে দেওয়ার সময় এসেছে।

আমি কাজ করেছি WordCamp Mentor আর Global Event Supporter হিসেবে। নতুন আয়োজকদের পাশে দাঁড়িয়েছি, তাদের সাহায্য করেছি। তাদের সাফল্য আমাকে সবসময় খুশি করেছে।

WordCamp Asia আমার কাছে খুবই বিশেষ। আমি ২০২২, ২০২৩ আর ২০২৫ এ আয়োজক টিমে ছিলাম। পরে যুক্ত হই WordCamp US 2025 এর টিমেও।

২০২৫ সালে আমি পাই Automattic Open Horizons Scholarship। একই সময়ে মার্কেটিং এ পিএইচডি করছি, যেখানে গবেষণা করছি কিভাবে নতুন পদ্ধতিতে সফটওয়্যার প্রোডাক্ট প্রচার করা যায়।

এসব অভিজ্ঞতা আমাকে শিখিয়েছে: অবদান মানে সবকিছু করতে হবে না, বরং যা পারেন সেটুকু নিয়মিত শেয়ার করাটাই আসল।

মার্কেটারদের জন্য কথা

আপনি যদি মার্কেটার হন, লেখক হন বা কোডের চেয়ে লেখালেখি ভালো পারেন, তবে নিশ্চিন্ত থাকুন, ওয়ার্ডপ্রেসে আপনার জায়গা আছে।

ওয়ার্ডপ্রেস শুধু ডেভেলপারদের প্রয়োজন নেই। প্রোডাক্ট আর ব্যবহারকারীর মধ্যে সেতু গড়তে যারা পারে, গল্প বলতে পারে, মানুষের সাথে সংযোগ তৈরি করতে পারে, তাদেরও সমানভাবে দরকার।

আমি কম্পিউটার সায়েন্স থেকে মার্কেটিং এ এসেছি, আপনিও পারবেন নিজের জায়গা খুঁজে নিতে। শেখা, লেখা, আয়োজন, মেন্টরিং সবই অবদান।

শিক্ষা

আমার যাত্রাকে তিনটি শব্দ সবচেয়ে ভালোভাবে বোঝায় –

• শিখুন. কৌতূহলী হোন, শিখুন, এগিয়ে যান।
• যুক্ত হোন. সম্পর্ক আর বন্ধুত্বই আসল শক্তি।
• অবদান রাখুন. যা শিখেছেন, সেটা অন্যদের সাথে ভাগ করুন।

শেষ কথা

শুরুতে শিক্ষক আমাকে ওয়ার্ডপ্রেসে কাজ করতে মানা করেছিলেন। তখন খারাপ লেগেছিল, কিন্তু আজ বুঝি সেটাই আমাকে সামনে এগিয়ে নিয়ে গেছে।

ওয়ার্ডপ্রেস আমার শিক্ষক, আমার প্ল্যাটফর্ম, আমার কমিউনিটি। এখান থেকেই আমি ক্যারিয়ার, বন্ধু আর জীবনের উদ্দেশ্য খুঁজে পেয়েছি।

আমি একজন ৩ বছরের মেয়ের বাবা আর একজন গর্বিত স্বামী। পরিবারই আমাকে সব সময় প্রেরণা আর আনন্দ দেয়।

আপনি ডেভেলপার হোন, লেখক হোন বা এখনও নিজের পথ খুঁজছেন, ওয়ার্ডপ্রেসে আপনার জন্য জায়গা আছে। শুরু করুন শেখা দিয়ে, তারপর সংযোগ তৈরি করুন আর ধীরে ধীরে অবদান রাখুন।

শিখুন. যুক্ত হোন. অবদান রাখুন. এটাই আমার গল্প।

The post Learn. Connect. Contribute. My WordPress Story – শিখুন, যুক্ত হোন, অবদান রাখুন; আমার ওয়ার্ডপ্রেস গল্প appeared first on HeroPress.

The presentations for WordCamp US are just a few days away! We have some really exciting keynotes including Danny Sullivan from Google, John Maeda from Microsoft AI, and Adam Gazzaley (one of the top neuroscientists in the world) from UCSF. I think being in the room and able to meet the speakers and ask questions is even more valuable this year, as things are changing so quickly. If you know anyone in or near Portland, Oregon have them get a ticket! Here are all the other AI-related talks:

• Scalable, Ethical AI: How to Own Your Content and Your AI with WordPress
  • Presenter: Jeffrey Paul, VP of Open Source, Fueled
  • Wednesday, August 27, 1:15 PM PT
• Catch Bugs Faster with AI & Playwright (No Hype, Just Results)
  • Presenter: Wendy Erdheim-Poch, Senior Automation Engineer, Elementor
  • Wednesday, August 27, 3:15 PM PT
• Core AI: What We’re Building
  • Presenter: James LePage, Head of AI, Automattic
  • Thursday, August 28, 10:30 AM PT
• Zero to Plugin in 30 Minutes – Harnessing AI Coding Assistants for WordPress Development
  • Presenter: Maulik Vora, Founder and CEO of Zluck Solutions
  • Thursday, August 28, 1:45 PM PT
• Fixing and Optimizing websites with AI
  • Presenter: Arnas Donauskas, Product Manager at Hostinger
  • Thursday, August 28, 3:45 PM PT
• Turn your local WordPress install into your AI coding assistant
  • Presenter: Jonathan Bossenger, Developer Educator, Automattic
  • Friday, August 29, 10:30 AM PT
• From Storefront to Strategy: What Happens When AI Shops for Your Customers?
  • Presenter: Sonja Ibele, Delivery and Account Manager, Syde
  • Friday, August 29, 1:15 PM PT
• Unlock Developer Superpowers with AI
  • Presenter: Adam Silverstein, Developer Relations Engineer, Google
  • Friday, August 29, 2:15 PM PT

Hi there,

I am thoroughly giddy for WordCamp US. The schedule looks fantastic. A great collection of Keynote speakers with Amy Sample Ward (NTEN), Danny Sullivan (Google), John Maeda (Microsoft), and Adam Gazzaley (Neuroscape at UCSF).

There are in total 44 sessions, covering three overall topics: “Technical WordPress,” “Honing your skills,” and “AI.” Below you’ll find a list of block and block theme-related talks you can follow on the livestream or on demand later on.

And when you read this, I am already on my way to Portland.

Yours,
Birgit

WordCamp US talks and workshops on block development and block themes

Staying within the block editor context, here is the list of talks that tackle the latest blocks buzz.

• Joeleen Kennedy: Modernizing at Scale: How FSE Supports Wikimedia’s Evolving UX
• Josh Bryant: Reimagining WordPress Editing: How We Embedded Gutenberg Into Our Product Ecosystem
• Seth Rubenstein: Block Composability: The Past and The Future
• Stephanie Stelzer: Coding the Magic: A Developer’s Journey Through Aloha
• Mary Ann Aschenbrenner: Moving a Website from Classic to a Block Theme
• Anton Plauche: Building Resilient Interfaces by Embracing Fluid Design
• Jemima Abu: A PHP Developer’s Guide to ReactJS
• Michelle Schlup Hunt: Building Experiences: Design Systems, User Experience, and Full Site Editing
• Tammie Lister: The System is the Strategy
• Jamie Marsland: Launch Your Personal Portfolio—A Hands-On WordPress Workshop
• Ryan Welcher: The Block Developer Cookbook

Developing Gutenberg and WordPress

Jeff Paul posted the members of the Release Squad for WordPress 6.9. It’s a mix of community and sponsored contributors. Five squad members are from Automattic; two of them, Jonathen Bossenger and Ryan Welcher are first-timers, paired with longtime contributors on the Triage team and Test team.

In a personal blog post, Exploring work in progress for WordPress 6.9, Anne McCarthy selected a few features on their way to the WordPress 6.9 release and reported on their status. She followed fairly closely the Roadmap 6.9 post and shared updates and discussions that are happening right now, roughly two months away from Beta 1 on October 21.

Rae Morey, The Repository, reported on both publications in WordPress 6.9 Release Squad Named as Features Take Shape.

The latest episode is Gutenberg Changelog 119—WordPress 6.8.2 and 6.9, Gutenberg 21.1, 21.2, and 21.3 Releases with Tammie Lister.

If you are listening via Spotify, please leave a comment. If you listen via other podcast apps, please leave a review. It’ll help with the distribution.

Release lead Hector Prieto published What’s New in Gutenberg 21.4 and highlighted

• DataViews table layout grouping and multi-selecting
• More on DataViews enhancements
• Style shuffling in write mode

In his August edition of the What’s new for developers roundup post, Justin Tadlock has a vast array of released or upcoming updates for you to review. He also added three discussions you might want to chime in on if they are relevant to your work.

1. Expanding the Core block library? It might be in the cards
2. Proposing more theme.json settings control
3. Discussion on “composite” blocks 

You also learn about Playground updates and Theme related changes and interesting bug fixes. If you only have time to read one post this week, make it this one.

Never ever miss another post from the WordPress Developer Blog! Subscribe!

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

In previous editions of this newsletter, I mentioned the new Events plugin by Lesley Sim and Ahmed Fouad called EventKoi. It works natively with the block editor, supports recurring + multi-day events, and gives you beautiful calendar views out of the box. They are running a Founding Partner Lifetime Deal from Aug. 25–31 only. Learn more and get on the waitlist now.

Ajit Bohra and the team at LubusIN have shared their super cool Slider Block that they originally used for their own projects! Now, you can get it from the WordPress Plugin Directory, complete with a handy setup guide to help you get started.

The new plugin WPMozo Blocks and Addons by Elicus comes with a set of very fancy blocks like FlipBox, Image Card, Tilted Image, and some more. Each of them has also many design choices. If you need some interactive blocks on your site, it’s worth checking out.

Theme Development for Full Site and Blocks

On the Developer Blog, Justin Tadlock wrote a tutorial on how to use a new extensibility feature to add custom social links to the block editor: Registering custom social icons in WordPress 6.9. If you want to test this for yourself before WordPress 6.9 comes out, make sure you install Gutenberg plugin 21.1 or newer.

I used this new feature to add podcast directory icons for my block theme on Gutenberg Times. The plugin will be in the WordPress repository as soon as I figure out this SVN version control thingy. The code is available on GitHub.

In her latest tutorial, Anne Katzeff, ASK Designs, explores the core Gallery block and shows how to arrange multiple images in a grid of rows and columns. She also mentioned the ‘click to enlarge’ feature. Katzeff then continues comparing the default gallery block with the one provided by Kadence Blocks.

Web developer Elliott Richmond delivers a thirty-year veteran’s verdict: “Menus have always had one job… to help people find their way around a website.” His manifesto against mega-menu bloat reveals hidden SEO penalties—link dilution, crawlability nightmares, and semantic confusion plague JavaScript-heavy navigation systems. Richmond advocates for WordPress’s foundational principle: semantic simplicity over marketing spectacle. The prescription? Five to seven top-level items maximum, unified cross-device structure, and letting content—not navigation—handle conversion duties.

Building Blocks and Tools for the Block editor.

Paulo Carvajal shared in his blog post how to build Blocks That Work Seamlessly with Block Themes and the Site Editor. He covers the paradigm shift where everything becomes blocks, emphasizing the importance of integrating with theme.json design systems rather than using hard-coded styles. Key topics include responsive design integration, global styles compatibility, block patterns usage, and performance optimization for the evolving WordPress ecosystem.

Carvajal is also working on the block editor book called WordPress Editor and Blocks—A Comprehensive Guide.

In his livestream, Ryan Welcher let you in on Block Deprecation Secrets Only WordPress Experts Know as one of the Block Development Cookbook series. He cooked up a tasty recipe block and walked through the process of updating it with block deprecations—the secret ingredient to keeping your blocks fresh while maintaining compatibility with older content.

Brendan O’Connell started a video series talking about Remote Data Blocks. the plugin by the WordPress VIP team. Using it helps you connect the block editor to external APIs and sync data in real time to blocks. It also auto-registers custom blocks with a custom schema.

• In Part 1, O’Connell gives you an introduction.
• In Part 2 He covers using the plugin with an Airtable.

WordPressVIP also held a webinar highlighting the Remote Data Block. Rae Morey, The Repository, has the report for you. WordPress VIP Demos Its New Enterprise Suite: Remote Blocks and Parse.ly AI Updates

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 [email protected]

A couple months ago, this blog reached a web performance milestone which I shared on LinkedIn, Bluesky, Mastodon, Twitter:

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

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

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

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

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

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

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

Field Data via CrUX

Lab Data via Lighthouse

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

• LinkedIn
• Bluesky
• Twitter
• Threads
• Mastodon

The post Web Performance Milestone appeared first on Weston Ruter.

My good friend Tim Ferriss has launched a new card game with the Exploding Kittens folks, I just ordered it and you should do so too. It’s a lovely way to share an evening with a few friends.

At a previous job, we had an engineering book club. Once a week we would meet and discuss a chapter of a book. It was a good opportunity to hear multiple perspectives on an author’s work, to see who agreed with the author and where people thought the author was off-base.

I would like to bring this concept to WordPress, especially to fellow Core Contributors. For the first book, we will be reading Producing Open Source Software by Karl Fogel. This is a book that has greatly influenced my perspective on open source and software development in general.

The club will meet on Google Meet on Tuesdays at 16:00 UTC (edit: This was originally 15:00 UTC. Moving to not conflict with recurring meetings of multiple WordPress teams) for one hour with the following schedule:

• 2 September 2025: Preface and Chapter 1. Introduction
• 9 September 2025: Chapter 2. Getting Started
• 16 September 2025: Chapter 3. Technical Infrastructure
• 23 September 2025: Chapter 4. Social and Political Infrastructure and Chapter 5. Organizations and Money: Businesses, Non-Profits, and Governments
• 30 September 2025: Chapter 6. Communications
• 7 October 2025: Chapter 7. Packaging, Releasing, and Daily Development
• 14 October 2025: Chapter 8. Managing Participants
• 21 October 2025: Chapter 9. Legal Matters: Licenses, Copyrights, Trademarks and Patents

While not an official WordPress event, the expectations from the WordPress Community Code of Conduct will apply and at my sole discretion, violations may result in individuals not being invited to continue. Additionally, participants are also encouraged to blog their thoughts on each chapter.

If you are interested, please leave a comment on this post. I will be getting in touch with respondents. If there is an overwhelming interest, I may need to restrict attendees or run a second meeting.

Props to Jonathan Desrosiers and Tammie Lister for discussing this idea with me, Pattie Reaves for starting the club at PMC and the PMC PEP team who ran the club I was a part of.

The post A WordPress Book Club appeared first on Aaron Jorbin.