The major breakthroughs in the technology behind the internet have rapidly transformed our world. But while devices and browsers have become more powerful and internet speeds and coverage have increased, we still have to build optimised experiences for users.
One of the things we can do to ensure they get the best experience possible is assume they are always coming to our sites or applications on a slow network and a not-so modern device.
In the below video, I talk through the importance of optimising your performance to improve your customer experience, and six actions you can take now.
Google considers site speed to be of key importance and there is plenty of evidence to suggest that gains in site speed can not only improve user experience, but also have a significantly positive impact on conversion rate.
We audit sites to look for key metrics such as time to first byte (TTFB) and optimise how we deliver the many resources that sites are now made up of.
These audits usually focus on mobile devices as the majority of online traffic is via smartphones and typically, connections range from poor and patchy to reasonably good 3G, however these do not compare to the speed of a good broadband or fibre connection.
Benchmarking our site’s performance on a stable and very fast network potentially blinds us to issues most of our users might face when visiting our sites.
Various online tools can help you diagnose performance issues with a site. Chrome developer tools now comes packaged with an audit tab running Lighthouse that will emulate a slow 3G connection on a Nexus 4, and run some benchmark tests against various aspects of front-end performance.
It can also give you quick insights and recommendations for things to improve. You can save audits and check your progress when making amends via the Lighthouse viewer tool.
Some other useful tools in a developers toolkit to benchmark speed tests would be Google's mobile speed test, this will give you an idea how your site operates compared with similar sites in the same category and run similar tests to Lighthouse with a focus on mobile usability.
Also, pagespeed insight which gives us a similar set of results to Lighthouse but also for desktop connections, this runs on the network so no emulation takes place.
Once you know what issues your site faces, it's time to roll up your sleeves and get stuck into some optimisation.
Here are a few of our tips to ensure you deliver content to a user as fast as possible, without impacting their experience.
By not forcing a user’s client to download a whole page worth of resources, we can reduce the time they wait for a page to respond significantly, especially on sites that have lots of image content.
Make sure that images are optimised to reduce the file weight and fit the appropriate dimensions they are used in, and then lazy loading will prevent images loading initially and instead reveal them as a user navigates down your application.
Large sites with an extensive sitemap and functionality require large code bases. Some of the ways we can improve performance here is to ensure our code ships with as small a weight as possible.
This comes down to the choice of tools we use to build sites, whether to include a library or not is a decision that has to be taken early in development and considered for its performance impacts.
Either way, it’s always best practice to ensure you minify your code when you serve it to a user.
Minification not only in CSS and JavaScript but also the text content they receive, this can be done by ensuring your server is gzipping the content it serves.
Before a browser renders a page it has to build the DOM tree by parsing html markup. During this process, whenever the parser encounters a script it has to stop and execute it before it can continue parsing the HTML.
For external scripts, the parser has to wait for the external resource to download which may incur one or more network round trips and further delay the page.
By reordering a page to prevent render blocking scripts or letting them run asynchronously you allow the page to render content to the user sooner.
As well as removing render blocking scripts it’s important to note loading a CSS file in the head significantly increases the time is takes a web page to render.
This is because the default browser behavior will delay page rendering until it has finished loading, parsing and executing all the CSS files referenced.
You can move your styles into the footer however this will result in DOM elements loading in without any styles.
To resolve this it’s useful to include some inline styles known as critical path or above the fold css (minified of course) which covers all the styles a user may expect to see on first load.
This bridges the gap between time to first render and time to first meaningful interaction and prevents it looking like the site is broken while gaining significant performance increase.
A new a powerful tool to hit the web recently is the service worker API. Running as a replacement for the AppCache, it allows a page many features previously only accessible on a native application.
For the benefit of performance however, the part of the service worker worth mentioning is the cache. A service worker script essentially acts as a proxy server that sits between web applications, the browser and the network.
It gives developers the ability to fine tune and control what assets get cached and the real world performance metrics show that serving content from a service worker cache is faster than the HTTP cache.
While not an essential ingredient on a well performing site or web application given tooling available to easily generate one as part of a build it’s worth looking into.
A CDN or Content distribution network is a way to deliver content from your site or application to a user more quickly and efficiently, based on their geographic location.
A CDN is a network of servers in locations all around the world and a request for content is served from a CDN server closest to the user.
There are a number of ways you can improve your site or web applications performance, most of these optimisations should be considered during the build to prevent overhead at the end of a project, but this does not stop you retroactively adding in many of the methods even long after a go live date.
Making use of the various tools supplied by Google to monitor and increment changes while testing against a benchmark will let you see how much impact these changes make. And once rolled out you could expect to see a boost in user retention and a drop in bounce rates.