Measure, Optimise & Automate Frontend Performance
Why? Because there’s no point building a beautiful, responsive, touch-friendly site if it can’t load a page before the user decides to leave. Researchshows: 47% of users expect a web page to load in 2 seconds or less, 40% of people abandon a website that takes more than 3 seconds to load and a 1 second delay in page response can result in a 7% reduction in conversions.
Website performance is user experience. As you design and develop a new site, you’ll consider many components of its user experience: layout, hierarchy, intuitiveness, ease of use, and more. Page load time and how fast your site feels is a large part of this user experience and should be weighed equally with the look and feel of it.
A performance budget is exactly what it sounds like: you set a “budget” or threshold for your page size and speed and do not allow it to exceed that.
The idea of creating a metric for performance is nothing revolutionary, and of course page size is only one part of performance, but using the ‘size budget’ to refer back to during UX and visual design (and of course at build time) can be very helpful in helping you to build a better site. If you come up against your thresholds, then it’s time to swap some functionality out, or look for more optimal ways to meet your design.
Looking at every decision through the design/build process, as something that has a consequence. Having a pre-defined ‘budget’ is a clear, and easy to understand way to frame decisions about what can and can’t be be included, and at a suitably early stage in the project.
There are many tools designed to help benchmark website performance and help pinpoint where improvements can be made. Here are just a few popular ones:
- Yahoo YSlow — it provides visual static charts and grades on each measurement as well as overall grade for your website.
- Google Pagespeed — scores on speed and user experience in mobile and desktop, also suggest fixes.
- WebPagesTest — comprehensive coverage report of website performance analysis, include screenshots
- Web Browser inspectors — Audits by Chrome, Performance by Firefox,Timeline by Safari.
Let’s speed up page load time. The general principle is to only load what’s needed at the time. Some best practices which I consider to be essential:
You probably already know:
- Make fewer http requests
- Minify and concatenate CSS, JavaScript, HTML
- Optimise images (lazyload, compress and make them truly responsive)
- Enable GZIP compression
- Caching
- Use CDN (content delivery network)
The tricky part:
- Defer non-critical asset loading
- Inline critical assets
Critical assets are everything that’s absolutely required to present the user with a minimally usable web page. This means they’re able to start interacting with your content while other assets load in the background. Think the visual area of computer or device on initial load. Anything that doesn’t appear in this area doesn’t need to load until after the page has been rendered by the web browser.
Web Browsers will usually stop when they encounter a new asset and fetch it before continuing to render the page. This means that if you have dozens of CSS and JavaScript files in the <head> section of your page, rendering will be blocked until those files have been retrieved from the web server. To avoid blocking the render the page, load CSS and JavaScript asynchronously.
However, sometimes there is a conflict between the principle, such as moving JavaScript to bottom of the page and providing a usable page. The workaround? Write minimal inline CSS and Javascript in the header to load critical assets.
To help with this, Abhinay Rathore produced a good checklist with comprehensive coverage of performance optimisation.
It doesn’t matter which tool you decide you want to use, there are plenty out there to choose from and all have their own advantages. I am going to highlight a few useful Grunt plugins for automated performance testing. If you haven’t used Grunt before, check my blog post “Automating workflow with Grunt.js” with step-by-step tutorials.
It uses either a public or private instance of WebPageTest to perform tests on a specified URL. It compares test results to budgets you specify. If the budget is met, the tasks successfully completes. If it the page exceeds your performance budgets, the task fails and informs you why.
Once installed, click here to acquire API key.
Usage example
perfbudget: { default: { options: { url: 'http://yoursite.com', key: 'API_KEY_HERE', budget: { render: '3000', SpeedIndex: '5500' } } } }Result
This plugin runs both mobile and desktop performance tests for your deployed site using Google PageSpeed Insights
Usage example
pagespeed: { options: { nokey: true, url: "http://yoursite.com" }, prod: { options: { url: "http://yoursite.com", locale: "en_GB", strategy: "desktop", threshold: 80 } } }Result
Based on phantomas and grunt-phantomas with performance metrics and configurable warnings. What I like about it is that it can test multiple urls at once, very useful.
What is Phantomas?
A command line performance metrics tool which scans any site viaPhantomJS and provides visual graph results by d3.js
Usage example
grunt.initConfig({ devperf: { options: { urls: [ 'http://yoursite.com', 'http://yoursite2.com', 'http://yoursite3.com' ], numberOfRuns: 5, timeout: 120, openResults: true, resultsFolder: './devperf', warnings: [ { // Change warning message variable : "jsonCount", limit : 5, message : "This is new warning message" } } } });Result
Performance is a key part of how users experience your website and it can make a real difference to their perception. There are now a wide range of tools and techniques that allow you to measure and manage performance early in your development process and they’re quite simple to automate and use. It doesn’t matter which tool you prefer, but by picking and making best use of just one performance tool you can make a huge difference to response time and improve your user journey.
By Jessie Wang, Senior frontend developer
