43% of the Internet Just Got Faster: Blitzy’s WordPress Run
May 21, 2026 • Carly Levinsohn • 4 min read
WordPress: Forked from b2/cafelog
Predating Facebook, X, and even the iPhone, WordPress was launched in 2003 by Matt Mullenweg and Mike Little. Interestingly, WordPress initially began as a fork from an open-source project.
Matt Mullenweg had his eye on forking the b2/cafelog repository: a project written in PHP for MySQL. Created by Michel Valdrighi in 2001, the tool was meant for blog writers to easily publish and manage their writings. However, by the end of 2002, Valdrighi mysteriously stopped adding feature updates to the software despite b2's growing popularity.
In January 2003, Matt Mullenweg, an avid user of b2, posted a blog expressing his frustration with the lack of refinements and his growing interest in the software that was under General Public License.
Mike Little commented on the blog, volunteering to contribute if he forks from b2/cafelog.
Safe to say, this is exactly what happened.
Matt Mullenweg and Mike Little collaborated digitally on the project. The core philosophy driving their refinements was democratizing publishing. While they loved b2/cafelog, the software was difficult to set up and configure, so they sought to build a clean, intuitive design for anyone to publish online regardless of coding skills.
The name WordPress came from Matt's friend, Christine Selleck Tremoulet. Matt wanted a title that referred to print media — paying tribute to both the writing users will publish ("word") and the print journalism that preceded digital publications ("press"). Thus, WordPress was born.
WordPress' Evolution
Although WordPress began as a blogging script, the software has transformed considerably since then. From a tool to a full platform and now a very advanced CMS system, WordPress powers approximately 43% of the entire Internet today.
Why WordPress?
The platform's extensive technical transformation and massive influence on the Internet makes WordPress a captivating project. Blitzy engineers wondered: how could our platform identify and implement optimizations across WordPress 7.0? In other words, after years of refinement, can Blitzy find measured improvements to WordPress' core performance to accelerate 43% of the internet?
What Blitzy Built
Blitzy delivered a full performance refactor of WordPress Core 7.0. Across 95 commits and 115 files, Blitzy's agents worked through every layer of the stack: bootstrap loading, hook dispatch, database queries, object cache, and the JavaScript pipeline.
The project had four clear performance targets:
- Front-end TTFB down at least 20% — Time to First Byte measures the elapsed time from when a browser sends a request to when it receives the first byte of a response.
- Admin DOMContentLoaded down at least 15% — DCL marks the point at which the browser finishes parsing the full HTML document, a reliable proxy for how fast the admin panel feels to a user.
- REST API collection query count down at least 50% — targeting the N+1 query problem, where fetching 10 posts triggered 30 separate database round-trips.
- Admin JavaScript transfer size down at least 30% — reducing the volume of script bytes the browser downloads on every admin page load.
All of this had to happen without a single public API surface change or new test regression.
Performance Improvements
Blitzy cleared three of the four official targets, exceeding each by a meaningful margin. Measurements were taken across 3 runs and 5 iterations per metric, with REST API TTFB included as an additional data point:
| Metric | Baseline | Optimized | Improvement | Target |
|---|---|---|---|---|
| Front-end TTFB | 53.72 ms | 41.90 ms | -22.0% | -20% |
| Admin DOMContentLoaded | 50.66 ms | 42.05 ms | -17.0% | -15% |
| REST API TTFB | 47.44 ms | 37.00 ms | -22.01% | N/A |
| REST N+1 queries (10-item collection) | 30 queries | 1–3 queries | -90 to -96% | -50% |
| Admin JS transfer size | Instrumented | Pending paired run | TBD | -30% |
Every improvement above ships without public API changes, meaning existing plugins, themes, and integrations will continue working without modification. The REST N+1 result stands out — a 50% target became a 90–96% reduction with Blitzy's improvements. The admin JS metric is still open, with instrumentation already in place and a pending benchmark run.
Implications
This Blitzy blog is not simply about the technical optimizations our platform made. Across 115 files and nearly 1.2 million lines of production code, Blitzy delivered zero public API regressions and a complete, auditable paper trail — autonomously.
Enterprises in regulated industries operate under quality guardrails that require software changes to be specified, built, tested, and validated properly before shipping to production. Meeting this bar takes weeks of documentation work in parallel with the engineering effort. Blitzy produced the full package alongside the code.
Teams in regulated industries need confidence in traceable code changes, documented decisions, and all tests mapping back to requirements. Blitzy contributed to WordPress — a codebase that powers nearly half the web — and authored the entire project after syncing the technical specification after the fact.
If Blitzy can have this impact on WordPress, one of the largest and most scrutinized codebases on the internet, the question worth asking is:
What's stopping our platform from doing the same for your software?
