Front-End Performance 101

Q. I’m new to front-end performance. What should I look for, and how should I look for it?

Jason Ormand: Page load time, specifically to get the page load time as low as possible. Two tools you can use are Chrome’s Dev tools network tab and Web Page Test. You should also track page weight (e.g. size in MB) and the number of HTTP requests.

Ian Carrico: Page load time isn’t the time to load everything, though […] Paul Irish just had a great talk at FluentConf about thinking about performance as his “RAIL” idea.

Gabriel Luethje: Filament Group does a great job of illustrating it too.

Q. What’s the single most challenging aspect to front-end performance?

Ormand: Since Vox has an ad-based revenue model … it’s ad performance. Many advertisers and vendor tools have the expectation of being loaded synchronously. We are working to change that (to all async) but it’s a very difficult task with many considerations. Ensuring a web asset makes performance sense is relatively straight forward. But ensuring performance goals align with business goals can be very tricky business.

Carrico: Also, legacy code. There was a time on the web where Vox wrote JavaScript synchronously. Where we used tables, and didn’t use floats. But much like the change to RWD required a change in thinking about how we write code, a change to a focus on performance will require the same. And just like RWD requires altering how we design, how Vox thinks about projects, how we test our sites: Performance requires changing/challenging current perceptions on the development cycle and how we design/build web experiences.

Chilton: A large component of Vox’s job is to educate the rest of the team (designers, developers, editorial) about the potential performance implications of their decisions. We believe very strongly that performance should be everyone’s concern, not just the purview of our small team.

Daniel Bachhuber: Two more cents: 1) knowing where to begin with optimizations, and 2) making sure you don’t take one step forward during a performance sprint, and two steps back as a part of your normal product development. Fusion had a “performance week” a month and a half ago. We captured lessons learned on our blog. As a part of the process, we set up Speedcurve to monitor site performance. However, we haven’t successfully adopted it.

Chilton: Vox has an internal tool called Tempo and is also running Speedcurve.

Q. What’s one front-end performance trick you wish you had learned at the very beginning?

Carrico: The trick is that there are no tricks. It’s all about where you get your information. There are a lot of people out there who are doing great work, writing posts, etc. Finding those people, reading their things, and trying to implement is more useful than anything.

Ormand: To get started, you should investigate and measure. Form a hypothesis. Make a change with as limited scope as possible. Measure again. Invalidate/validate hypothesis. If the data checks out, push to production. If not, wash rinse repeat.

Chilton: It was learning to dig deeper into the dev tools. Some recommended videos:

Ryan Murphy: Giving things a pass with Google Pagespeed is crazy illuminating.

Common Issues in Front-End Performance

Q. What’s a front-end performance issue you’re currently working on?

Carrico: Asynchronous JavaScript code. This isn’t a “quick fix”, nor something we expect to get out the door tomorrow—but certainly something worth focusing on. Vox is working with several team to get a better way of running all of our JavaScript in a unified fashion, and getting legacy code up to speed in the process.

Ormand: SPDY/HTTP2.0 are coming to static assets at Vox pretty soon, which is exciting. Async ads are also on the roadmap, as is evolving performance tools around metrics tracking and workflow automation.

Carrico: I’ve been working on loading our fonts with LoadCSS and using Font Face Observer to ensure Vox don’t get any FOIT. So far, we have had great results. Jonathan Suh has a great post.

Q. Regarding LoadCSS and inlining critical CSS, have you found that challenging to work into CMS workflows?

Carrico: A little: When I was at Four Kitchens, we used it in Drupal, and just did some manual running / testing to ensure the output was right. But we got it to work fairly easily just by committing our critical CSS to git and having Drupal load it inline. The critical inline CSS was broken apart based on different template files (e.g. home vs. article).

Chilton: Web Page Test is an invaluable tool, and Vox is leveraging it internally with our Tempo app.

Q: Have you run into any push-back over the Flash of Unstyled Content?

Carrico: Not yet! But I did work heavily with designers to make sure they had some reasonable fallback fonts. The FoUT is not FoUT as much as Flash of Less Styled Text

Q. Has anyone found lazy-loading images to be a big performance booster on news sites?

Ormand: Vox uses JS client side to load images async and hopefully as close to the perfect size as possible in most places. Async image loading is a big win. Next up, support for Webp to save bandwidth and async load times.

Q: For your lazyloaded images, what happens when JavaScript on the page breaks? We (Fusion) had lazyload in production for a while, but were running into a variety of implementation issues that caused the general quality/reliability of images on our site to be subpar.

Carrico: Don’t let JavaScript break. But really, there should be some good testing in to make sure broken JS isn’t added, and more importantly error handling. Four Kitchens ran into this issue with some Drupal code, where one small piece would break, and everything else would. We ended up implementing more solids tests to check for that.

Q: How does Vox fit refactors into the product backlog?

Chilton: It depends on the scope of the refactor. We are constantly pushing and iterating Chorus with small refactors, but large ones (like making The Verge fully responsive) is approached more like a new vertical. In that case, we devote a team to the refactor project and take our time to make it as solid as possible.

Tools & Processes to Borrow

Q. What tools / processes do you use to make performance a feature of every project?

Ormand: Vox has Justice.js for everybody on product to view the performance impact of what we building, as we are building it and after it’s pushed to production.

Carrico: Vox also to wants to have testing on each branch and notify in GitHub PRs, but we haven’t yet gotten to a point that we can achieve that in a productive manner. The repo shows a really simple example of getting TravisCI performance testing into every PR. Clearly: a very simple one… but something we want to do in a larger fashion.

Ormand: Vox is also looking to extend Tempo with Elastic Search + Kibana for getting more comparative metrics and map those back to our commit log. Mapping commits to performance changes is of high importance, we are considering automated reports that will go out to devs post commit.

Q. What else do you use for performance dashboards?

Ormand: SpeedCurve and Tempo are two synthetic perf tools Vox uses to measure long term perf trends. This is mostly for the for the perf team but all team members can look at our dashboards. We collect a lot of data via Tempo and use Grafana to compile and represent visually. Pretty power interface to perusing data.

Q. What are your pain-points for doing performance testing on Travis?

Carrico: Two things: 1) Having an accurate testing environment that mimics production BEFORE code gets to production. 2) Setting up clear budgets on a legacy code base that reflects the end limit of what is allowed.

Q: Have you built a slackbot for these things yet?

Chilton: Good idea for Vox!!! I would love to see alerts sent out for both big perf gains and losses.

Q. There are more and more tools for measuring page load, what do people use for measuring jank / user experience after the page has load and the scrolling begins?

Carrico: I test jank purely in Chrome’s dev tools. It may not work to show everybody’s experience, but the tools are incredibly deep—and can help find a variety of issues

Ormand: Justice.js has a streaming FPS meter which was designed to give developers feedback on scroll related issues. If you see peaks and valleys during scroll, you may have an issue. Then open up dev tools and find out why.

Carrico: Super critical JS should be inline, but everything else should just be progressive enhancement.

Evangelizing for Performance

Q. How do you evangelize performance to the rest of your team / company?

Carrico: Vox is working on a mixture of things. We are lucky that we have a team that already understands the need for frontend performance, but there are many ways to get a team “on board”. Sharing performance stats, goals, budgets are all great—but generally require an understanding of what things like “Speed Index” actually mean. Something we stole from Etsy / Lara Hogan is to share videos from Web Page Test of our site loading at different speeds and compared to other competitors. Nothing beats having a video that anybody can take a look at to see the exact impact performance can make. We also like to share stats or studies that we find that has the impact of performance included. The most excellent Chris Ruppel and I did a talk on creating a culture of performance, and specific things you can do to everybody in the team (from CXO to developer) to get more buy-in.

Chilton: Surfacing important performance metrics is one of our most important tasks. We want to make those numbers omnipresent and supremely accessible