Are you using progressive booting already? What about tree-shaking and code-splitting in React and Angular? Have you set up Brotli or Zopfli compression, OCSP stapling and HPACK compression? Also, how about resource hints, client hints and CSS containment — not to mention IPv6, HTTP/2 and service workers?

Back in the day, performance was often a mere afterthought. Often deferred till the very end of the project, it would boil down to minification, concatenation, asset optimization and potentially a few fine adjustments on the server’s config file. Looking back now, things seem to have changed quite significantly.

Performance isn’t just a technical concern: It matters, and when baking it into the workflow, design decisions have to be informed by their performance implications. Performance has to be measured, monitored and refined continually, and the growing complexity of the web poses new challenges that make it hard to keep track of metrics, because metrics will vary significantly depending on the device, browser, protocol, network type and latency (CDNs, ISPs, caches, proxies, firewalls, load balancers and servers all play a role in performance).

So, if we created an overview of all the things we have to keep in mind when improving performance — from the very start of the process until the final release of the website — what would that list look like? Below you’ll find a (hopefully unbiased and objective) front-end performance checklist for 2017 — an overview of the issues you might need to consider to ensure that your response times are fast and your website smooth.

(You can also just download the checklist PDF¹ (0.129 MB) or download the checklist in Apple Pages² (0.236 MB). Happy optimizing!)

Front-End Performance Checklist 2017 Link

Micro-optimizations are great for keeping a performance on track, but it’s critical to have clearly defined targets in mind — measurable goals that would influence any decisions made throughout the process. There are a couple of different models, and the ones discussed below are quite opinionated — just make sure to set your own priorities early on.

Getting Ready And Setting Goals Link

1. Be 20% faster than your fastest competitor.
   According to psychological research³, if you want users to feel that your website is faster than any other website, you need to be at least 20% faster. Full-page loading time isn’t as relevant as metrics such as start rendering time, the first meaningful paint⁴ (i.e. the time required for a page to display its primary content) and the time to interactive⁵ (the time at which a page — and primarily a single-page application — appears to be ready enough that a user can interact with it).Measure start rendering (with WebPagetest¹⁶⁸⁶) and first meaningful paint times (with Lighthouse¹⁷²⁷) on a Moto G, a mid-range Samsung device and a good middle-of-the-road device like a Nexus 4, preferably in an open device lab⁸ — on regular 3G, 4G and Wi-Fi connections.

   ⁹

   Look at your analytics to see what your users are on. You can then mimic the 90th percentile’s experience for testing. Collect data, set up a spreadsheet¹⁰, shave off 20%, and set up your goals (i.e. performance budgets¹¹) this way. Now you have something measurable to test against. If you’re keeping the budget in mind and trying to ship down just the minimal script to get a quick time-to-interactive value, then you’re on a reasonable path.

   ¹²

   Share the checklist with your colleagues. Make sure that the checklist is familiar to every member of your team to avoid misunderstandings down the line. Every decision has performance implications, and the project would hugely benefit from front-end developers being actively involved when the concept, UX and visual design are decided on. Map design decisions against performance budget and the priorities defined in the checklist.

2. 100-millisecond response time, 60 frames per second.
   The RAIL performance model¹⁴ gives you healthy targets: Do your best to provide feedback in less than 100 milliseconds after initial input. To allow for Be optimistic¹⁵ and use the idle time wisely. Obviously, these targets apply to runtime performance, rather than loading performance.
3. First meaningful paint under 1.25 seconds, SpeedIndex under 1000.
   Although it might be very difficult to achieve, your ultimate goal should be a start rendering time under 1 second and a SpeedIndex¹⁶ value under 1000 (on a fast connection). For the first meaningful paint, count on 1250 milliseconds at most. For mobile, a start rendering time under 3 seconds for 3G on a mobile device is acceptable¹⁷. Being slightly above that is fine, but push to get these values as low as possible.

Defining the Environment Link

1. Choose and set up your build tools.
   Don’t pay much attention to what’s supposedly cool these days. Stick to your environment for building, be it Grunt, Gulp, Webpack, PostCSS or a combination of tools. As long as you are getting results fast and you have no issues maintaining your build process, you’re doing just fine.
2. Progressive enhancement.
   Keeping progressive enhancement¹⁸ as the guiding principle of your front-end architecture and deployment is a safe bet. Design and build the core experience first, and then enhance the experience with advanced features for capable browsers, creating resilient¹⁹ experiences. If your website runs fast on a slow machine with a poor screen in a poor browser on a suboptimal network, then it will only run faster on a fast machine with a good browser on a decent network.
3. Angular, React, Ember and co.
   Favor a framework that enables server-side rendering. Be sure to measure boot times in server- and client-rendered modes on mobile devices before settling on a framework (because changing that afterwards, due to performance issues, can be extremely hard). If you do use a JavaScript framework, make sure your choice is informed²⁰ and well considered²¹. Different frameworks will have different effects on performance and will require different strategies of optimization, so you have to clearly understand all of the nuts and bolts of the framework you’ll be relying on. When building a web app, look into the PRPL pattern²² and application shell architecture²³.

²⁴

²⁵

1. AMP or Instant Articles?
   Depending on the priorities and strategy of your organization, you might want to consider using Google’s AMP²⁷ or Facebook’s Instant Articles²⁸. You can achieve good performance without them, but AMP does provide a solid performance framework with a free content delivery network (CDN), while Instant Articles will boost your performance on Facebook. You could build progressive web AMPs²⁹, too.
2. Choose your CDN wisely.
   Depending on how much dynamic data you have, you might be able to “outsource” some part of the content to a static site generator³⁰, pushing it to a CDN and serving a static version from it, thus avoiding database requests. You could even choose a static-hosting platform³¹ based on a CDN, enriching your pages with interactive components as enhancements (JAMStack³²).Notice that CDNs can serve (and offload) dynamic content as well? So, restricting your CDN to static assets is not necessary. Double-check whether your CDN performs content compression and conversion, smart HTTP/2 delivery, edge-side includes, which assemble static and dynamic parts of pages at the CDN’s edge (i.e. the server closest to the user), and other tasks.

Build Optimizations Link

1. Set your priorities straight.
   It’s a good idea to know what you are dealing with first. Run an inventory of all of your assets (JavaScript, images, fonts, third-party scripts and “expensive” modules on the page, such as carousels, complex infographics and multimedia content), and break them down in groups.Set up a spreadsheet. Define the basic core experience for legacy browsers (i.e. fully accessible core content), the enhanced experience for capable browsers (i.e. the enriched, full experience) and the extras (assets that aren’t absolutely required and can be lazy-loaded, such as web fonts, unnecessary styles, carousel scripts, video players, social media buttons, large images). We published an article on “Improving Smashing Magazine’s Performance³³,” which describes this approach in detail.
2. Use the “cutting-the-mustard” technique.
   Use the cutting-the-mustard technique³⁴ to send the core experience to legacy browsers and an enhanced experience to modern browsers. Be strict in loading your assets: Load the core experience immediately, the enhancements on DomContentLoaded and the extras on the load event.Note that the technique deduces device capability from browser version, which is no longer something we can do these days. For example, cheap Android phones in developing countries mostly run Chrome and will cut the mustard despite their limited memory and CPU capabilities. Beware that, while we don’t really have an alternative, use of the technique has become more limited recently.
3. Consider micro-optimization and progressive booting.
   In some apps, you might need some time to initialize the app before you can render the page. Display skeleton screens³⁵ instead of loading indicators. Look for modules and techniques to speed up the initial rendering time (for example, tree-shaking³⁶ and code-splitting³⁷), because most performance issues come from the initial parsing time to bootstrap the app. Also, use an ahead-of-time compiler³⁸ to offload some of the client-side rendering³⁹ to the server⁴⁰ and, hence, output usable results quickly. Finally, consider using Optimize.js⁴¹ for faster initial loading by wrapping eagerly invoked functions (it might not be necessary⁴² any longer, though).

   ⁴³

   Client-side rendering or server-side rendering? In both scenarios, our goal should be to set up progressive booting⁴⁵: Use server-side rendering to get a quick first meaningful paint, but also include some minimal JavaScript to keep the time-to-interactive close to the first meaningful paint. We can then, either on demand or as time allows, boot non-essential parts of the app. Unfortunately, as Paul Lewis noticed⁴⁶, frameworks typically have no concept of priority that can be surfaced to developers, and hence progressive booting is difficult to implement with most libraries and frameworks. If you have the time and resources, use this strategy to ultimately boost performance.

4. Are HTTP cache headers set properly?
   Double-check that expires, cache-control, max-age and other HTTP cache headers have been set properly. In general, resources should be cacheable either for a very short time (if they are likely to change) or indefinitely (if they are static) — you can just change their version in the URL when needed.If possible, use Cache-control: immutable, designed for fingerprinted static resources, to avoid revalidation (as of December 2016, supported only in Firefox⁴⁷ on https:// transactions). You can use Heroku’s primer on HTTP caching headers⁴⁸, Jake Archibald’s “Caching Best Practices⁴⁹” and Ilya Grigorik’s HTTP caching primer⁵⁰ as guides.
5. Limit third-party libraries, and load JavaScript asynchronously.
   When the user requests a page, the browser fetches the HTML and constructs the DOM, then fetches the CSS and constructs the CSSOM, and then generates a rendering tree by matching the DOM and CSSOM. If any JavaScript needs to be resolved, the browser won’t start rendering the page until it’s resolved, thus delaying rendering. As developers, we have to explicitly tell the browser not to wait and to start rendering the page. The way to do this for scripts is with the defer and async attributes in HTML.In practice, it turns out we should prefer defer to async⁵¹ (at a cost to users of Internet Explorer⁵² up to and including version 9, because you’re likely to break scripts for them). Also, limit the impact of third-party libraries and scripts, especially with social sharing buttons and