diff options
Diffstat (limited to 'src/published/2014-08-11_building-faster-responsive-websites-webpagetest.txt')
| -rw-r--r-- | src/published/2014-08-11_building-faster-responsive-websites-webpagetest.txt | 124 |
1 files changed, 124 insertions, 0 deletions
diff --git a/src/published/2014-08-11_building-faster-responsive-websites-webpagetest.txt b/src/published/2014-08-11_building-faster-responsive-websites-webpagetest.txt new file mode 100644 index 0000000..fa82f90 --- /dev/null +++ b/src/published/2014-08-11_building-faster-responsive-websites-webpagetest.txt @@ -0,0 +1,124 @@ +--- +title: Building Faster Responsive Websites with Webpagetest +pub_date: 2014-08-11 12:04:25 +slug: /blog/2014/08/building-faster-responsive-sites-with-webpagetest +metadesc: All the usual performance best practices apply to responsive web design, but there are some extra things you can do to speed up your responsive websites. +tags: Responsive Web Design, Best Practices +code: True +tutorial: True + +--- + +All the normal best practices for speeding up your website apply to responsive web design. That is, optimize your database and backend tools first, eliminate bottlenecks, cache queries, etc. Then move on to your server where you should focus on compressing and caching everything you can. + +It makes no sense to optimize front end code like we're about to do if the real bottlenecks are complex database queries or other back end issues. Because those sorts of things are way beyond the scope of this article, I'll assume that your back end code or the team responsible for it has already optimized and everything is cached as much as possible. + +Before we dive into how you can use Webpagetest to speed up your responsive web sites let's clarify what we mean by "speed up". + +What we really care about when we're trying to speed up a page is the *time to first render*. That is, the time it takes to get something visible on the screen. The overall page load time is secondary to getting *something* -- ideally the most important content -- on the screen as fast as possible. + +Give the viewer something; the rest of the page can load in the background. + +The first step is to do some basic front-end optimization -- eliminate blocking scripts, compress images, minify files, turn on cache headers, use a CDN for static assets and all the other well established best practices for speeding up pages. Run your site through [Google PageSpeed Insights](https://developers.google.com/speed/pagespeed/insights/) and read through Yahoo's [Best Practices for Speeding Up Your Web Site](http://developer.yahoo.com/performance/rules.html) (it's old but it's still a great reference). + +Remember that the single biggest win for most sites will be reducing image size. + +There are many tools for testing your site and running performance audits that look at specific areas of potential optimization. There's desktop software that simulates all kinds of network conditions and web browsers, but for now we'll stick with [Webpagetest.org](http://www.webpagetest.org/) (hereafter, WPT), a free, online testing tool. + +When you first visit WPT, you'll see a screen that looks like this: + +[](/media/images/2014/wpt-01.jpg "View Image 1") +: Webpagetest basics + +Before you do anything, expand the advanced options. This is where the good stuff is hidden. The first thing to do here is change the number of tests to run. I like to go with 5. If you want you can use a higher number (the max is 9), but it will take longer. Use odd numbers here since WPT uses the median for results. + +I like to set it to First View Only and check Capture Video so I can see the page load for myself. Here's what this would look like (note that I've also set it to emulate a 3G connection and the device is set to iPhone 4): + +[](/media/images/2014/wpt-02.jpg "View Image 2") +: Webpagetest advanced config options + +Before we actually run the test I want to point out a slightly hidden, but super cool feature. Click the scripts tab to the right. See the empty box? What the? Well, click the documentation link and have a look at all the possibilities. There's a ton of stuff you can do here, but let me give you an example of one very powerful feature -- the `setDnsName` option. + +You can use this to test how much your CDN is helping your page load times. To do that you'd enter your overrides in the format: `setDnsName <name-to-override> <override-name>`. If your CDN served files from say `www.domain.com` and your origin was `origin.domain.com` you'd enter this in the box: + +~~~.language-bash +setDnsName www.domain.com origin.domain.com +~~~ + +That way you can run the test both with and without your CDN and compare the results without altering the code on your actual site. + +Right now we'll keep it simple and run an ordinary test, so hit the yellow button. Depending on how many times you told it to run, this may take a little while. Eventually you'll get a page that looks like this: + +[](/media/images/2014/wpt-03.jpg "View Image 3") +: The test results overview page + +The main results there at the top are pulled from the median run. In this case that's run 3. Notice the Plot Full Results link below the main table. Follow that link to see a breakdown of all your tests, which can be useful to see if there are any anomalies in load times. Since there weren't any anomalous results for this page, let's take a closer look at the median, run 3. + +So what jumps out here? Well, the time to fully loaded is almost 15 seconds. I consider that terrible, but it actually passes for reasonably fast over 3G these days. Why is it so bad? Well, I picked this URL for a reason, it has nearly a dozen images, which take a while to load. + +But I'm not really interested in total load times, I want to get a sense of how long it takes to get something on the page. The number we want to look at for that information is the Start Render time. Here you can see it's about 2.5 seconds for the median run. + +In this case though I'm going to focus on the worst test, which is run 1, where nothing appears on the screen for 5 seconds. That's terrible, though it is a lot better than 15 seconds. + +Now I know there's a lot I can do to improve the overall load time of this page, but what I'm most interested in is shaving down that 5 seconds before anything shows up. To get a better idea of what might be causing that delay I'll go back to the test results page and click on the waterfall view. + +[](/media/images/2014/wpt-04.jpg "View Image 4") +: The test results waterfall view + +Here I can see that there are some redirects going on. I recently switched from http to https and haven't updated this post. So I need to do that. Then there's the images themselves, which are most likely the bottleneck. I ran the same test conditions on another page on my site that doesn't have any images at all and, as you can see from this filmstrip image (yes, you can export WPT filmstrips as images, look for the link that says "Export filmstrip as an image...") the above the fold content is visible in 1 second: + + + +So the problem with the first URL is likely three-fold, the size of the images, the number of images and how they're loaded. + +I was in a hurry to get that post up, so I just let my `max-width: 100%;` rule for responsive images handle scaling down the very large images. In short I did what your clients will likely do -- be lazy and skip image optimization. I really need to automate an image optimization setup on my server, but in lieu of that, I manually resized the images, ran them through [ImageOptim](https://imageoptim.com/) (if you want a Linux equivalent check out [Trimage](http://trimage.org/), which hasn't been updated in years, but runs just fine for me in Debian stable and testing) and reran the tests: + +[](/media/images/2014/wpt-06.jpg "View Image 6") +: Things are getting better + +That's a little better. We're down to worst case scenario of 3 second load time over a 3G connection. So it looks as if my hunch is right, the images are the bottleneck. + +I'm convinced, but suppose this were a client site and I wanted to show them why they need to optimize their images. You know what makes a powerful argument for image optimization? Making your client sit through those painfully slow load times. So go back to your main text results page, click the link on the right that says "Watch Video." + +It will take a minute for WPT to generate your video, but when it does scroll to the bottom and grab the embed code. Here's the two videos from the WPT results I've run so far, embedded below for your viewing pain: + +<iframe src="https://www.webpagetest.org/video/view.php?id=140806_XB_Z5T.1.0&embed=1&width=332&height=716" width="332" height="716"></iframe> + +<iframe src="https://www.webpagetest.org/video/view.php?id=140808_0G_RZW.2.0&embed=1&width=332&height=716" width="332" height="716"></iframe> + +Convincing no? + +Now I'm going to keep testing and trying to speed up my page. My next step is going to be tweaking the server. Yeah I know I said at the beginning that you should start here and I didn't. Neither, I'd be willing to bet, did you. That's okay, we'll do it now. + +I use Nginx to serve this site and I compile it myself with quite a few speed-oriented extras, but the main tool I use is the [Nginx Pagespeed module](https://developers.google.com/speed/pagespeed/module). For more on how I set up Nginx and how you can do the same, see my post: [Install Nginx on Debian/Ubuntu](https://longhandpixels.net/blog/2014/02/install-nginx-debian-ubuntu). + +I'm going to turn on a very cool feature in the `nginx_pagespeed_module` that I haven't been using until now, something called the [`lazyload_images` filter](https://developers.google.com/speed/pagespeed/module/filter-lazyload-images). Here's the line I'll add to my configuration file: + +~~~.language-bash +pagespeed EnableFilters lazyload_images; +~~~ + +This will tell PageSpeed to delay loading images on the page unless they're visible in the viewport. Even better, as of version 1.8.31.2, this filter will force download images after the page's `onload` event fires. That means you won't get that janky scrolling effect that happens when images are fetched as they enter the viewport, which happens with a lot of websites that do this with JavaScript. + +So I turned on the `lazyload_images` filter on my server and reran the tests to find that... + +[](/media/images/2014/wpt-07.jpg "View Image 7") +: That's more like it -- Test results showing 1 second load time over 3G. + +The page is now filling the initial viewport in about 1 second over 3G. I can live with that, but honestly it could probably be better. For example, some sort of responsive image solution would reduce the size of images on mobile screens and bring down the total page load time (not to mention saving a bunch of bandwidth) + +I could also do some other little optimizations, including combining the prism.css code highlighting file with my main CSS file to save a request. I could probably ditch the web fonts, create a single SVG that holds the logo and icons and then position everything with CSS. + +That would eliminate a request and probably reduce the overall size of the page as well. And I could put everything behind a CDN, which would probably have more impact than everything else I just mentioned combined, but that costs money and frankly, 1 second over 3G is fine for now. + +Hopefully this has given you some idea of how the tools available through Webpagetest can help you speed up your responsive website (or even your non-responsive site). It's true that I didn't really do anything here you can't do with the Firefox or Chrome developer tools, but I find -- particularly with clients who need a little convincing -- that WPT's filmstrips and videos are invaluable. And I should note that there are plenty of things WPT can do that your favorite developer tools cannot, but I'll save those for another post. + +While Webpagetest and its ilk are great tools, you should always also test on real devices in the real world. Ideally you'll test your site on an actual, slower network and see what it feels like to wait. Three seconds might sound fine, but actually sitting through it might inspire you to dig a little deeper and see what else you can optimize. + +If you don't have access to a slow network, <strike>then come to the U.S., they're everywhere</strike> then simulators will have to do. If you want to do some live testing over constrained network simulations there are some great dedicated tools like [Slowy](http://slowyapp.com/), [Throttle](https://github.com/dmolsen/Throttle) or even the Network Conditioner tool which is part of more recent versions of Apple's OS X Developer Tools (see developer Matt Gemmel's helpful overview of [how to set up Network Conditioner](http://mattgemmell.com/2011/07/25/network-link-conditioner-in-lion/) if you're using Mac OS X 10.7 or higher). + +## Further Reading + +If you'd like to learn more I recommend you start at the beginning. First learn [how to read the waterfall charts](http://www.webperformancetoday.com/2010/07/09/waterfalls-101/) that these services generate. Then I suggest you read Steve Souders' [High Performance Web Sites](http://stevesouders.com/) and the [Web Performance Today](http://www.webperformancetoday.com/) blog, both excellent resources for anyone interested in speeding up their site. Finally, few people know as much about [optimizing massive web applications](http://www.igvita.com/2013/01/15/faster-websites-crash-course-on-web-performance/) and sites as Google's Ilya Grigorik, who's part of the company's Make The Web Fast team. Subscribe to Ilya's blog and [follow him on Twitter](https://twitter.com/igrigorik) for a steady stream of speed-related links and tips. + +For some more details on all the cool stuff in Webpagetest, check out [Patrick Meenan's blog](http://blog.patrickmeenan.com/) (he's the creator of Webpagetest) and especially [this short video](https://www.youtube.com/watch?v=AEAj-HSfYSA). |