Posts on Web Performance
Whenever I come across articles on web performance, they typically focus on a single aspect of making high performance websites - usually the backend. That's why you'll often see posts on caching and the like, similar to what's in the first part of my series on building high performance Drupal sites (which I'll be returning to once I have a nice block of time for writing the lengthy second installment).
There are other areas that get less attention, however. Frontend performance, for example. Fortunately, the neglect of frontend performance seems to be ending and there are great tools now available to help diagnose and fix problems, first and foremost the outstanding Chrome DevTools. Also see webpagetest.org if you're not using it already. But the thing that's on my mind lately is neither of these two areas, but rather how the site performs once it's fully loaded in the browser. Yeah, I'm talking about runtime performance.
What follows is part one in a series of posts on web performance that I've wanted to write for quite some time. I'll not only be talking about optimizing web performance generally, but also providing specific guidance for speeding up Drupal sites.
Although I'm not a web performance specialist or expert, I have taken a keen interest in the topic in my work as a frontend developer building responsive websites. I love building fast sites and have gained some experience over the years getting Drupal to shed some its inherent sluggishness.
As a way of systematically tackling what can be a complex subject, we'll use the results of a test from WebPageTest.org, a Google-sponsored tool that provides very in-depth information about the performance of a site in nice, easily digestible chunks.
A lot of the time, when someone talks about making a website responsive, they mean that the layout will change depending on what device is being used to view the site. But there is more to responsive design than that. Perhaps an even more critical factor is the performance of the site, particularly on mobile.
At its heart, responsive design is about opitimizing the user experience across a wide range of devices. This can be a hard job, no doubt about it. But we've been making things harder than they need to be.
What follows are some tips on evaluating responsive websites across different devices. We'll see how to use several tools and techniques - using a real website as an example - that can provide hard data on how your site is going to perform on mobile devices and help identify problem areas.
Website performance has been on my mind a lot lately, especially with regard to responsive web design. It's quite important, but it also requires a shift in thinking that is still underway for many involved with web projects, particularly clients.
How quickly your page loads has a big impact on everything from your site's search rankings to the abandonment rate for shopping carts. But as I mentioned in a previous post, there are tensions between commonly desired features and mobile performance. I'll give you an example we run into here at Friendly Machine all the time.
I thought it would be fun to do a little experiment. I have a project for a client that is wrapping up and one of the final things I'm doing for them is optimizing the site's performance. The client is a good candidate for this little demonstration because they have their Drupal site in a shared hosting environment, something that's quite common, but often limiting with regard to what you can do to improve performance.
So here's how this will work, I'm going to step through a series of basic performance tweaks and then run the site through the Pingdom Tools page load tester. This will give us a good idea of what sort of improvement we get with each step.
I returned from a long vacation over the holidays to discover that one of the sites that I manage had developed some serious performance issues. Page load times had gone from 1 or 2 seconds to more than 8 seconds on some of the slowest loading pages.
After messing around with a few of the usual suspects, I decided to give the Drupal Boost module a try in hopes that it would speed up the site while I worked on tracking down the underlying issue.