Performance

Performance Calendar 2013

Howdy perfers! December is an easy month to stay on top of web performance news because the Performance Calendar is the gift that keeps giving all month. The first entry is a great one from calendar curator Stoyan Stefanov. He conducts some user research via the power of search engine autocomplete.

By doing some unfinished searches like “why is my website so…” Stoyan shows that no matter which giant web property you’re talking about, one of the most common complaints will be that it’s slow. It’s pretty telling that this complaint spans across Facebook, Yahoo, and even Google who makes a very public show of serving fast pages. We all have our work cut out for us!

Reading the comments a few good points are brought up about the initial search query and other factors like the extensions each user has installed (not to mention the tendency for humans to complain more than compliment), but I think the consistency across the searches says something about the basic expectations of users on the web.

Keep checking the Performance Calendar each day in December for more web performance tips!

DevTools for mobile

Howdy perfers! In the US we’re gearing up for a long Thanksgiving weekend, so if you find yourself with some free time on your hands try digging into one of these awesome DevTools resources for mobile development.

Chrome Dev Summit mobile talks

Last week was the 2013 Chrome Dev Summit, so if you missed the action due to a busy work schedule, fear not. There are lots of slide decks to catch up on and a few videos too. Paul Irish brings us up to speed on the state of mobile web development, showing how you can use Chrome to emulate many more device properties such as pixel density, edit local dev environments from the browser using Workspaces, and a slew of performance tips thrown in as a bonus. Grab the slides, watch a video recorded previous to the dev summit, or read a longer article on HTML5 Rocks.

If you’re keen to optimize the critical rendering path but aren’t quite sure where to start, Bryan McQuade goes on a deep dive that walks you through that process. Many pieces are well-known frontend performance tips, but he helpfully explains how it affects the rendering of the page and hopefully brings some perspective on how much impact you can have to make a mobile site fast. Read the slides.

Paul Kinlan’s session about the Best UX patterns for mobile web apps explains how you can use some new UX tools within Google PageSpeed to help identify and resolve common problems that appear on responsive and mobile websites. I’ve appended the necessary query string ?ux=1 to the PageSpeed link so feel free to try your site out!

General reference

Just a reminder that you can always fond up to date information at both the Official Chrome DevTools docs and the Firefox Aurora devtools.

Performance: design, budget, and test

Howdy, perfers! Last week we looked at ways to speed up the initial render of a page. That’s a great optimization if you have the time/motivation, but for many people it’s not their primary duty, and for some it’s not even included in the job description! But even so, it still can make or break the experience of a particular website. As Ilya Grigorik notes, performance is not a checklist, but a continuous process (PDF, page 11). So how can you affect the process of building a site to make sure it ends up being fast and snappy?

Consider performance a design constraint

A great article by Brad Frost encourages readers to think of performance as a primary design element. Brad offers several examples that demonstrate how performance can be THE design element that users care about most. Whether they are aware is completely irrelevant, because ultimately poor performance equates to boredom or frustration, which results in people leaving your site or refusing to use your app. The fact that Facebook is a primary example should be a warning that no service is compelling enough to trump users’ expectations of instant gratification on the web.

Assuming you’re convinced, you’re probably asking yourself how you can enact change within your organization.

Setting a performance budget

Tim Kadlec has an excellent article advising us all to set a performance budget on each project. While it can be helpful to include speed or performance as a high-level project goal, eventually it will be the victim of another design decision unless performance is quantified and measured in some way. Setting a performance budget is one method to help a team to determine when a new feature or design decision is negatively impacting a site’s performance. Here are several methods which could be used individually or in tandem:

  • Time until a certain event occurs. This should be accompanied by the device class or network connection. For example, “the homepage must begin rendering within 3 seconds on devices using a 3G connection”
  • Total page weight. For example, “the homepage cannot exceed 500K”
  • Amount of latency. For example, “individual article pages must not make more than 30 HTTP requests”

While your exact metrics may vary from site to site, a performance budget is an effective way to maintain a fast site throughout development, rather than scrambling to make optimizations at the last minute before launch.

Tools for measuring performance

If you’re looking for ideas on how to measure and track performance, take a look at some of my previous Webperf Wednesday posts: Automated Frontend Tools and DevTools link roundup. Good luck, and keep fighting the good fight! You users will thank you.

Optimizing the Critical Rendering Path

Howdy perfers! Today I have a few links for those who want to optimize the critical rendering path, which is especially useful on mobile browsers. The critical rendering path is the minimum set of assets that a browser needs to start rendering a web page. Carefully rearranging some of your HTML and CSS to help the browser with this process can result in significantly faster rendering times. This means that even if the page doesn’t finish loading much faster than it did before your optimizations, it will start rendering sooner, causing your users to think it is loading much quicker due to their ability to see the page sooner.

Optimizing the Critical Rendering Path

Ilya Grigorik presented at VelocityConf in 2013 (slides available). His presentation of the material is great, explaining the psychology behind our actions when we use devices while also explaining the very real limitations set forth by mobile networks, from radio chips to the gory details of TCP latency. He starts with the goal, which is to break the “1000ms time-to-glass barrier,” and works backwards creating the ideal web page for meeting his 1000ms target. For the true performance nuts it’s great to have this kind of a carrot out in front of us.

But now you’re probably asking yourself “how can I go about this?”

WTCSS

To me one of the most interesting critical rendering path optimizations is inlining basic CSS within the response HTML. Inline CSS can apply to the render tree immediately, meaning the browser does not have to wait on any further requests to render a basic version of your page.

Enter WTCSS, a tool to help visualize how your selectors affect various parts of a page.

WTCSS splits your screen, with one half being your site, and the other half is your CSS. It draws lines connecting each selector to all of the nodes it affects. This visualization makes it really obvious how much influence a generic rule like div or a can have on a page, and more importantly it can help you understand which CSS you need to inline to get above-the-fold content to render. Before anyone reacts with the old design adage “there is no fold,” there really is one in a modern browser’s render pipeline, and we should take advantage of it.

If you’d like an informal demo, take a look at the WTCSS for DrupalCamp Austin. We modified our files after inspecting them with WTCSS, so it might help you get a feel for the desired outcome, with the top of the CSS document containing selectors for the top of the webpage. As you scroll down, you’ll notice that more and more of the blue lines point offscreen at the bottom of the document, due to async loading of our footer assets.

This is just one of many optimizations you can make while working toward the goal of sub-second page loads. Tune in next week for another perfbite to help get you closer!

Other tools to automate this process

Update 2014-03-19: If you’d like to try out another tool that is a bit more opinionated, try Paul Kinlan’s critical CSS bookmarklet or the CasperJS implementation.

Automated Frontend Tools

Howdy, perfers! This week I’ve got some awesome resources for those of you looking to automate ALL the things! While you don’t have to use automation to achieve great performance on your website or webapp, it sure does help to keep things running smoothly and consistently. So have a look!

Frontend Ops

Back in June Alex Sexton wrote a great piece on how he perceives the not-yet-common position of frontend operations. He goes in depth about what he envisions when he says this, touching on deployment, builds, page load performance, rendering performance, developer workflows, and (of course) automating all of this stuff when possible. It’s a great, inspirational article that should get you thinking about how to handle the complex world of modern frontend development.

Automating Frontend Workflow

Addy Osmani recently posted this excellent, comprehensive overview of automated frontend workflows. It is jam-packed with tools, and even if you’re used to following this area of web development, there’s sure to be a few tool combos that you haven’t seen yet. Definitely worth a read for everyone who does frontend development. It goes from the basics of Grunt to scaffolding generators like Yeoman, and includes everything in between. While there aren’t as many in-depth examples, the breadth of tools covered will give everyone, designers and developers alike, something to chew on.

Intro to Frontend Ops

This is a slide deck of my own creation, presented at both DrupalCon Prague and BADCamp. In contrast to Addy’s all-encompassing overview, it is intro level and aimed specifically at people who build Drupal sites. However, the slides are accompanied by working code samples that you can install instantly after cloning the slides (and after installing ruby, homebrew, node.js, and npm :p). My hope is that you can start using these tools today, rather than “getting around to it” eventually.

DevTools link roundup

Today I looked through my collection of links and realized I have enough resources pooled up to put together a decent little post on browser devtools. In case you’re not familiar, development tools ship with each web browser, enabling us to analyze and debug our increasingly complex websites and apps. From finding a background color to profiling frame rate issues, browser devtools bring sanity to the world of frontend development.

Discover (Chrome) DevTools

Put together by Google and Code School, Discover DevTools takes you from zero to master using Chrome DevTools. It’s a series of 17 videos with over 75 challenges for you to complete along the way. Although the course is Chrome-specific, other browsers’ tools are similar or identical in many cases, and the real takeaway is the ability to use these tools regardless of how the buttons are laid out in a given browser.

Secrets of the Browser Developer Tools

Secrets of the Browser Developer Tools provides bite-size tips for all browsers’ development tools. There are enough that you’ll probably learn something new just by skimming. They’re broken up into various categories, and each tip is accompanied by a list of platforms where the feature can be found. This fantastic resource is brought to you by @AndiSmith and he welcomes contributions.

DevTools can do THAT?

The last link is a set of performance-oriented slides from Ilya Grigorik detailing some of the finer points within Chrome DevTools. He highlights not only particular settings but how to configure them in order to easily test for different situations (e.g. cold/warm cache). Also included is a quick walkthrough explaining network waterfalls, the life of a request as visualized in DevTools, options for exporting and processing HAR files (a JSON format for storing network waterfalls), and overviews (plus examples) of Timeline and Profiles tabs, which help you debug rendering and memory issues.

Chrome DevTools Revolutions 2013

Update 2013-11-13: Since I published this, another awesome HTML5 Rocks tutorial has been posted showing some of the latest features of Chrome DevTools, including Sass source maps, remote debugging, and some sick tools to help you debug rendering performance. Eat it up ;)

Browsers want your feedback!

Although they have a ton of features, browser makers always want to hear from YOU, the one in the trenches. Most browsers have a dedicated developer relations team to ensure that the tools stay up to date and sensible for the hard-working people of the web. Here are their twitter accounts:

Magic: Frontend Performance for all themes

Howdy perfers!

This week’s Webperf Wednesday is short and sweet, just like your page loads when you install this new module that enhances any Drupal theme. Magic is a set of frontend performance and development workflow tools for themers. Previously many themes had their own advanced settings — many of which did the same things as other themes, but they all did it a little differently — no more with Magic.

Built by Web Chef Ian Carrico and Sam Richard (of Aurora) with contributions from Sebastian Siemssen (of Omega), Magic was built by the desire to work together to make all themes better, instead of siloing improvements within specific themes.

What’s inside?

Performance features:

  • Enhancements to CSS Aggregation
  • Exclude CSS files from being included
  • Option to move JavaScript to the footer
  • Backport of Drupal 8 JavaScript handling
  • Exclude JS files from being included

Development goodies

  • Rebuild Theme Registry on Page Reload
  • Display a Viewport Width indicator
  • Display an indicator with classes applied to the HTML. Useful when used in conjunction with Modernizr
  • Export theme settings

That last one is super important, as it makes Drupal themes a little more DRY. With Magic, you can take your settings from one theme to another — or to another site completely — because they’re fully exportable. Have two different projects, and want similar asset output despite one being Omega and one being Zen? No problem, just export!

Note: the full import process has yet to land, but it’s coming very soon.

If you have an awesome trick that you always rely on during theming, open an issue and propose it to Magic. They’d love to hear from you.

Give it a shot today! Go to drupal.org/project/magic

One less JPG

I’d like to demo a simple how-to. There are many, many techniques to make pages load faster, but this post attempts to demonstrate large gains from very small code changes.

People often build beautiful sites with multiple easy-to-use JavaScript libraries. Then, when it comes to addressing frontend performance, suddenly those libraries are an enormous download that the users are forced to bear.

Just one image

Before you go worrying about how to minify every last library or shave tests out of Modernizr, try and see if you can remove just one photo from your design. It will make a bigger difference.

Coined by Adam Sontag, the “one less JPG” idea — nay, MOVEMENT — is summed up perfectly here:

Real example

Last year we re-launched Pressflow.org. We have some mobile traffic, but it’s likely people just browsing for info, since no one has a good reason to download Pressflow onto a phone or tablet. Let’s keep their attention and make the experience fast.

We have this huge, beautiful mountain on the homepage. It’s great. But it’s also 160K. I tried making it smaller, or splitting the photo off of the background pattern, but it decreased the quality of the photo too much when I lowered the file size. We made a wonderfully small SVG logo, but that’s not an option for a photograph with this kind of detail.

How much impact does it have?

A mountain is a big thing — just like the amount of traffic Pressflow can handle — and the image we chose was meant to convey that vastness. Since it doesn’t really pack the same punch on smaller screens, why include it at all? I decided to use Modernizr and conditionally load the stylesheet that references the mountain. That way it never gets loaded by tiny screens that don’t need it.

Using the Modernizr Drupal module, I added a conditional load into the .info file of my theme:

; Load CSS with Modernizr
modernizr[Modernizr.mq('screen and (min-width: 42em)')][yep][] = css/big.css

This tells Modernizr to output a Modernizr.load() statement with the test I specified. In this case, Modernizr will only load big.css if the test is true. My test checks the width of the window using a media query — .mq() — and returns true if the screen is at least 42em, causing the CSS to be fetched. Here’s the JavaScript output:

Modernizr.load({
  test: Modernizr.mq('screen and (min-width: 42em)'),
  yep : 'http://pressflow.org/sites/all/themes/pfo/css/big.css',
});

So that’s it, instant savings!

..oh what’s that? Always test your work? Thanks for keeping me honest.

Here’s some data.

I’ve got two network waterfalls here for comparison. They show a pretty stark difference following this one-line change to my code. If a screen isn’t big enough for the mountain, it’ll only take 20 HTTP requests and 193K total. If the screen is big enough, it takes 24 HTTP requests — for the CSS and then the images inside it — totalling 384KB total. That’s a savings of 191KB (almost exactly 50%) from a single change to my code. You’d have to remove 19 copies of jQuery 2.0 to achieve this kind of bandwidth savings.

(by the way, didja hear that jQuery 2.0 has small QSA-only custom builds?)

Small screens

Waterfall: Conditional load small

Big screens

Waterfall: Conditional load big

You can see in the second waterfall that the Initiator of big.css is modernizr.min.js, meaning that JavaScript loaded the file after running the test.

ThoughtContentLoaded

I hope this shows how easy it can be to reduce your page weight without worrying about shaving bytes of JavaScript that are supplying valuable functionality if you know how to use them right.

If you want to know more about the conditional loading API within Modernizr, head over to yepnope.js documentation and start reading. For more Drupal-specific examples check out the official documentation for conditional loading using the Modernizr module.

Webperf Wednesday: Video Roundup

Hey, speeders! There have been some great presentation videos put up on the web recently, so I’ve got links to a couple videos this week.

Breaking the 1000ms time-to-glass barrier

Last week we checked out slides from Ilya Grigorik, so if you enjoyed those you have to check out his 45-min presentation recorded during the last SFHTML5 meetup. For mobile web developers this is required watching. He starts with the constraint that he wants to load a mobile web page in less than 1000ms, and proceeds backwards, walking through the realities of phone chips/towers, mobile network latency, and battery usage, in addition to more familiar concepts like image compression, the browser rendering stack, and reflow/repaint gotchas. Warning: you might need a cigarette after watching this video!

Steve Souders HTML5 DevConf keynote

Steve Souders delivered a great keynote at the HTML5 Developer Conference, and he makes it very clear that users want speed. One of the original powerhouses in the frontend performance world, Steve has created more resources and tools than is possible to list here, so I’ll just encourage you to check out his site if you’re not familiar with his work. His latest blog post also contains some errata from this video so if you like it please head over there to pick up the corrections.

Webperf Wednesday: Inaugural edition

I’ve been kicking around this idea for quite some time and finally sat down to get it published. Four Kitchens has always taken performance very seriously, but traditionally most people only focus on backend server performance when thinking about these types of issues. I’m not a hardcore backend dev, but I have plenty of experience making things fast and useful within a web browser.

To that end, I’d like to spread the word about frontend performance by publishing a periodic blog post series highlighting techniques, articles, and other webperf stuff that we’re talking about day-to-day in the office. So without further ado, here are this week’s links:

Building Faster Mobile Websites (.pdf)

Ilya Grigorik presents an extremely compelling case for putting speed at the top of your priority list, especially on responsive and otherwise mobile websites. He explores the realities of network latency and suggests methods that could be used to break the 1000ms “time-to-glass” barrier. It’s a low-level, deep dive into the effects of TCP/IP and HTTP requests on your site’s loading speed, and contains tons of great information to help you build fast sites. To make the most of these slides, you’ll have to work closely with backend and/or deployment people who help manage your sites, but the payoff is well worth it.

Double-whammy from Alex Sexton

Alex has recently published a couple great resources that can actually help you achieve the lofty goals in Ilya’s slides. First is a blog post entitled Deploying JavaScript Applications that talks about building a web application which matches user action patterns, relies on intelligent caching, and employs distributed deployment (like CDNs) whenever possible. He also lists some lower hanging fruit such as reducing use of images before shaving bytes of JavaScript.

Next are his slides from HTML5 Developer Conference that highlight the awesome new Modernizr v3 workflow. Very closely related to deploying JS apps, he outlines how the Modernizr v3 will help you build applications which adapt to the browser loading it, allowing for tiered, optimized experiences that match each browser’s capabilities while minimizing the loading of unnecessary assets. Having helped out with the v3 work, I’m especially excited to see people begin to use it.

Prerender in Chrome for Faster Page Loads

A couple weeks back I wrote about a feature of Chromium that Ilya has helped publicize in his upcoming book, High-Performance Browser Networking. It’s a <link> tag which lets you suggest pages that Chrome should prerender in cases where your traffic funnels are extremely predictable. This is a great example of using data to accurately predict user actions rather than directly altering the load time of your pages. Although they still load at the speed of the network, the end result can reduce apparent load times to 0.0s in some cases! Check out my example which is live on Pressflow.org.

Auf Wiedersehen

I hope you enjoyed these links! As I mentioned earlier, these posts won’t always be limited to links, so check back for code snippets, full implementation walkthroughs, and other goodies in the future.

Feel free to leave feedback or topic requests in the comments, and happy perfing!

Pages