When taking on a redesign of an existing website project, we often begin by discussing the content management system and the benefits of moving away from what usually is a WordPress site. Our CMS pick is Perch, giving us the power we need, but with a user interface that’s still simple for clients to use.
In one recent instance, however, the tables were turned. It begins a couple of years ago, when we were hired by an agency to code a website for their client—a sizable company and a leader in their industry. We chose Perch for the project because of its flexibility. The site purred along for a couple of years, amassing content and visits.
Fast forward to this month. As it turns out, the end-client decided to have someone recreate the site using WordPress, but without any substantial changes to the look and feel of the website. In fact, from a few feet away, you’d think our version and the new WordPress site were one and the same, complete with the same layout, images, and content.
Well, we thought: what an excellent opportunity to see how a hand-coded Perch website compares to a WordPress equivalent, especially with nearly no change in layout. Is it smaller? Larger? Faster? Slower? Such an opportunity doesn’t come along often.
Now, before we get to the numbers, a few words about our hand-coded websites. When we build a site—regardless of the platform—we take considerable pains to bring page sizes down as much as possible. A lean site is a fast site where visitors won’t have to wait to learn more about you and your services or products. Patience, among website visitors, can be measured in milliseconds.
To achieve a fast site, we make sure to:
- Write clean HTML and CSS code
- Minify all JS files to make them smaller
- Keep the total number of files as low as possible to avoid bottlenecks during load
- Make sure server-side compression is on
- Make sure we’re not loading extraneous font files
- Push images through fine-tuned compression
- Test, test, test
So what happens if you use WordPress and rely on lots of plug-ins and overlook (through inexperience or lack of time/budget) the steps above? Well, it gets ugly—fast. Here’s what we found:
The homepage of the Perch-based site came in at 3 MB, pretty much the upper limit for us. The WordPress site, though, is 10 MB with no added features or content. One of our product pages came in at 2.1 MB. The WordPress version of the same product page is a whopping 8.6MB. The Information page we created was 2.3 MB. Now it’s 15.9 MB! Yikes! And worst of all, our 2.1 MB About Us page turned into a run-away bloat-fest. A bug in their code continuously loaded images, resulting in hundreds of MB and thousands of file downloads. Our first inclination, when we saw the numbers, was to suspect malware.
Size matters when it comes to websites, especially when you’re trying to also reach mobile users. While following our steps above would certainly tame some of the needless bloat of the new WordPress site, the size would still not be close to our previous Perch-powered version, as Perch doesn't require the kind of additional scripts and stylesheets that attach themselves to WordPress sites like barnacles.
The new WordPress site, presumably built partially with some kind of visual editor rather than hand-coded, also suffers in appearance, looking much like the site we hand-coded had gone out for a night of hard drinking and came back looking disheveled and appreciably worse for wear, a little uncertain of what acts it had committed in the intervening evening.
While we’re sad to see a finely tuned site end up as it has, the A/B testing experience makes for a good tale of what can happen when you choose the wrong CMS and a developer without the chops to make sure your site runs smoothly, quickly, and error free.