Transport website relaunched on WordPress (not by us)

There’s a new website at the Department of Transport; and it’s running on WordPress. Sadly, it’s not one we’ve been involved with; we weren’t even approached, in fact. (I wonder why.) However, there are definite similarities with the work we’ve done for Defra; so we’ll console ourselves with the knowledge that we’ve at least been influential.
Transport issued a tender document in March, with an explicit requirement for open source-based solutions, specifically either WordPress or Drupal. The target launch date was 20 June, making for an aggressive schedule; and to their great credit, and that of developers Bang Communications, they made it with more than a week to spare.
I haven’t yet seen a total cost quoted for the work; that will come in due course, of course. But I’ve been told what the budget was, as quoted in the tender document – and I have to say, it was pretty generous. I’ll be keeping a close eye out for the next departmental spending data (as it’ll be well above the threshold); or if any MPs fancy drafting a PQ, that’ll make life even easier.
The site bears all the hallmarks of a WordPress v3.x build. Multiple subsites being stitched together, as we did for Defra, with liberal use of custom post types and taxonomies. The design is fairly low-key, based on the YUI grid system, with a bit of jQuery front-end gloss, but not too much. It declares itself to be coded in HTML5, but doesn’t make much use of 5’s new features, so there are no rendering problems in older versions of IE (that I’ve spotted myself).
But there’s one major problem with the site: performance.
Each page’s source code includes, at the bottom, a statement of how many database queries were required to gather up the information, and how long it took. Naturally, for better user experience, and to keep your server from falling over, you’d be looking to minimise both of these.
If you look at the homepage, for example, you’ll see it requires over 1,000 queries, and seems to take between 3 and 5 seconds to generate. The News homepage quotes 300-odd queries, and 4-6 seconds. If you then try to filter news items by Minister or topic, you’re looking at as many as 1,800 queries; and I’ve seen times as long as 15 seconds. To put it bluntly, that’s just too much. (By way of comparison: the Defra news page also includes this data at the bottom of its source code: 87 queries, 0.6 seconds.)
It might be OK if you were then caching the pages, and delivering static copies for a defined period afterwards, hence only taking the hit once per hour (or whatever); but we can see no evidence of that. Each time you refresh a page, you’ll see a different generation time at the bottom. There may be some caching going on that we can’t see from outside; but even then, those high numbers and the often slow response times are ominous.
You’re looking at a server which is in real danger of falling over as soon as there’s a significant spike in traffic. It doesn’t have to be like that; any WordPress veteran reading this will be thinking of the same couple of plugins, which would help instantly. And you’ll find them with one Google search.
But that’s enough criticism for now. It is of course great news to see another major government department moving to WordPress. Some may question the timing, given Alphagov’s stated intent of eliminating departmental websites within a year. But if there’s a net saving to the taxpayer, that’s reason enough to go ahead… and a challenge to other departments to do likewise, too.
Welcome to the world of WordPress, guys. Just sort out the caching, please, before you live to regret it.