This web site is three years and one day overdue, almost to the hour, a fact which neatly doubles as my first latency joke.
Back in 2009 I was building WordPress sites from the metal to the favicon, writing plugins, wrangling themes, presenting about WordPress, and helping customers make their existing web sites faster.
Creating an entire blog to share what I had learned about WordPress performance and scalability seemed like a natural next step, but as with many grand plans, life intervened.
So after a far-too-long hiatus, I’ve returned to WordPress work, and with it, TurboPress. I’m itching to write about what I’ve discovered so far, what I continue to learn each day, and how these might apply to your online publishing efforts.
On TurboPress you’ll find:
- Answers to all your questions about WordPress performance and scalability,
- Hints and tips for optimisation and tuning of WordPress sites and servers,
- Plugin and theme code reviews,
- Pointers to great resources and tools across the web,
- A generous helping of theory,
- … and a whole lot more!
If you’d like to propose a plugin or theme for review, suggest a topic we should cover, or want to ask a question, please get in touch!
At the second Velocity conference in June 2009, Microsoft (Bing), Google, AOL and Shopzilla presented strong evidence that page load latency has a direct relationship with accepted business metrics such as the number of page views per user or visit.
In September 2009, Alistair Croll reported on results an experiment by Strangeloop Networks which demonstrated that smaller websites also see greater engagement on their sites if they improve performance.
The evidence has only grown since 2009, further establishing a clear business driver for improving web site performance.
But hey, even if take the evidence and business out of the equation: Please your users, and they’ll keep coming back.
WordPress is kind of a big deal.
According to the W3Techs web technology survey, 16.7% of the top million web sites use WordPress, giving it a commanding lead in the large-scale content management system market. What’s more, it’s growing.
This, despite its reputation — and, it must be said, ongoing popularity — as “just a blog”.
You’ll find WordPress on huge sites with millions of readers, and tiny sites with only one or two. It has made online publishing delightful for some, and possible at all for others. Now that’s a fascinating audience for whom to write.
Why WordPress Performance?
Have you ever read the story about Steve Jobs convincing Larry Kenyon, a developer on the Macintosh team, to squeeze a few more seconds out of the boot time? As Hertzfeld tells it, Jobs reckoned Kenyon could “save a dozen lives” by making the Macintosh boot ten seconds faster.
Let’s fudge some numbers, kind of like Steve did, and see how many lives we could save by speeding up WordPress web sites.
Firstly, how many web sites exist in total? According to the August 2012 Netcraft web server survey, that comes to 628,170,204 sites. Let’s call it 600,000,000 (six hundred million).
How many of those web sites run WordPress? Let’s take W3Techs’ 16.7% and stretch it over the next 499 million web sites. Let’s call it 15% of six hundred million: 90,000,000 (ninety million).
What about the number of page views for those sites? WordPress.com publishes weekly page view stats and serves a massive range of web sites large and small, so hopefully that’s a pretty good proxy for WordPress sites across the web. The last few weeks have hovered at around 765,000,000 (seven hundred and sixty-five million) page views. Let’s call it 3,000,000,000 (three billion) per month across 30,000,000 (thirty million) sites, for an average of 100 page views per site, per month.
How slow is WordPress? Ilya Grigorik gave a fantastic presentation at WordCamp San Francisco 2012 in which he showed off cool performance statistics compiled from the top 1000 WordPress sites. The median time-to-first-paint — time taken before the browser renders anything at all — was about 2 seconds.
It’s not much of a stretch to shave 250ms off a 2000ms response time. It’s only an eighth, and I’ve done it before. But let’s be miserly, and call it 200ms saved per page view.
90,000,000 sites × 100 views × 200ms = 500,000 hours = 57 years saved per month!
So, now I’ve given you real numbers and dodgy numbers. Let’s do this.