Frontend Performance Optimisation and why it’s important.
If this doesn’t make perfect sense to you, let’s try to exemplify this by taking a look at a streaming service like Netflix that most of us know and use.
When visiting any of the Netflix frontends, whether this being their computer web application that lives in a browser, their Apple TV app or if you are streaming a few episodes of your favourite tv series on your phone, you’ll notice that you, as a user, can interact with a lot of data in a fast, predictable and easy manner.
You can browse a lot of data (movies, series and descriptions) through mouse clicks, swipes, presses and gestures, and you are most likely not even thinking about how fast and easy this usually is - until it’s not. You are likely to only experience negative feelings like annoyance and impatience when the experience is NOT fast and easy, as we are all so used to modern digital services being fast.
So what happens when a visitor hits your website? The answer to this question is not simple but one thing is sure - before any content magically appears in the browser, a lot of work has had to be done behind the scenes, and how fast this work is done, or rather, how the user experiences this, can be very impactful in many ways.
The practice of Frontend Performance Optimisation (FPO) is often interpreted as making the load times as low as possible, which should also be true to a certain extent, but good FPO is a multivariable equation and the variables are many. Asset optimisation, resource timing, backend response times, lazy loading, spinners, micro interactions, predictability, animations timing, code splitting and error handling are some of the topics and the list goes on and on and on.
All of the above mentioned buzzwords and the areas they cover, are all of equal importance, or are they? How do we prioritise setting up a budget for performance optimisation on a project, or even, SHOULD we prioritise a performance budget? Are developers not delivering state of the art performance metrics as a simple side effect to their everyday work? If this were the case, there would be no difference in the experience of shopping on the Zalando webshop, versus a random cheap webshop.
Websites whose project team understand how to prioritise performance and user experience, will have a competitive advantage over those who don't.
A performant website is basic. Something you must have. So, in our opinion it is obsolete to invest heavily in aesthetics if the frontend performance is sub-standard.
Establishing performance goals and budgets
Good website performance is not simple, but it doesn’t have to be extremely complex and expensive. If everyone involved in the project is aware of the importance of it and makes it a priority from the beginning, great things can happen. Therefore, we recommend discussing these matters early on, and like mentioned earlier, everyone should be involved.
Good developers will be aware of the importance of performance optimisation, and will understand how to prioritise their performance optimisation effort within a budget, even without anyone in the project team detailing the topic. However, it is naive to expect a certain result, without discussing the boundaries of the effort made to obtain a good result.
It is easy to agree that something like Search Engine Optimisation (SEO) is important as it is very logical that your website is not worth anything until someone uses it, but so is good performance, as the same users will abandon your site if it’s not performant. Google as well knows the value of a well optimised website, therefore speed and user experience is increasingly important for their ranking of sites. This in itself could be an article, and so we recommend reading the Search Engine Land piece about the new update. In short, performance and how it affects the user experience with content loading and shifting elements will be increasingly important in the future. So how do we prioritise our effort? We should start by understanding what good performance is, and the RAIL model can help us with this.
Measure web performance with the RAIL model
The RAIL Model is a user-centric performance model that breaks down the user's experience into key actions.
RAIL is an acronym for “Response, Animation, Idle and Load.” The model categorizes user interactions under these four domains. Users have different expectations whenever they tap, click on or scroll over your various page elements. Therefore, the RAIL model measures each user interaction with different context-specific goals in mind.
Response time reflects how rapidly your website reacts to inputs. A response time under 100 ms feels immediate; anything slower is noticeable to the user.
Reponse’s primary interactions are tapping and clicks, e.g. tapping a menu icon to open off-screen navigation.
If we are to respond responsively and provide a good performance for our user, we need to provide feedback in less than 100 milliseconds after initial input. It is completely fine if the initiated action takes longer than 100 milliseconds, the important thing here is to acknowledge the user so that they don’t start wondering whether their tap/click etc was registered.
Animation speed applies to any visual animations you have on the page as well as user scrolling and dragging. The ideal goal is 60 frames per second (FPS), or one frame every 16 ms.
Animation includes any visual animation like state changes, loading indicators, scrolling and drag. Smooth animations require 60 FPS.
Idle work refers to what is happening in the background of your website after it initially loads. Idle work should be divided into 50 ms blocks so that it doesn’t drag down response time.
We can use idle time to complete deferred work. For example, for the initial page load, load as little data as possible, then use idle time to load the rest. An example could be to fetch updates on a dashboard, when the user has been idle for some period of time, or loses focus on the screen by switching to another browser tab etc.
Load, in the context of the RAIL model, means the first meaningful paint, which should appear less than one second after the user requests your page.
First Meaningful Paint is the time it takes for a page's primary content to appear on the screen.
The project team wants and needs clear guidance on what “performant” means to users, because that’s who we’re building for, and by utilising the RAIL model as a framework for thinking in performance, this will be much more clear. We can look at performance as user experience based on interactions and by understanding how users interact with a given site we can set performance goals that will work.
Working with and testing performance at Adapt
There are tools to help us automating RAIL measurements. Which ones to use depends on what type of information is needed, and what type of workflow is preferred.
At Adapt we like to use several performance tools, but we will highlight a tool called Calibre in this post. Calibre provides a good overview of performance metrics we care about, and keeps track of the performance history.
It also allows for easy setup of multiple devices, as testing on multiple devices and network connections are important for more real world results.
Sometimes, to get real world usage statistics, we change the sample rate of the page speed collection data from Google Analytics, in that way we remove the synthetic benchmarks and collect all of our users performance data. However since Google Analytics performance metrics are a bit lackluster, we prefer a combination.
As stated in the start of this article, optimising perceived performance using the RAIL framework can help get the discussion going and make sure performance and its many metrics become parameters that we talk about when developing new functionality for clients.
Therefore we have introduced performance budgets on several clients at Adapt.
Whenever we suggest a new functionality ourselves or the clients wish for a new feature developed, we always look at how the introduction of the feature might impact the set performance budget. Will the added functionality put us above the performance thresholds we have set? Can we implement the functionality in a performant way?
The performance budget is not just arbitrary numbers we have just because we like fast sites. We talk about performance budgets because the implementation of new functionality that should help the customers convert better may be detrimental to these efforts because of the extra load. New slow functionality could cause a dip in performance and conversions across the board that might hurt conversions more than the new feature can help.
Good performance is often better business than new shiny features
Are you slowed down by legacy technology?
When talking about general user needs, user expectations and performance in general, it can be a very good idea to take a look at the possible technical debt you might have accumulated over the years working in the same monolithic setup.
Your users demand blazing-fast digital products, web standards are evolving at the speed of light, yet a lot of digital solutions rely on 10-years-old solutions like WordPress, Sitecore etc, that can force slow, low-quality user experiences.
Unoptimized images, heavy pages and a shameful overall performance score, it’s not anyone's fault - the web is just much harder than it used to be, and legacy tools simply can’t keep up, and it forces developers to solve performance issues on their own.
Old school monolithic setups are often, or will become, cumbersome and they will almost always carry their weight onto the performance metrics, front- and backend, but also in the ability to keep up with the industry and user expectations.
By removing the monolith architecture, it is possible to selectively choose the best services for the different parts of your digital business and thus make it easier to move freely in an increasingly demanding market.
We are of course talking about microservice architectures and headless setups.
Klaus Jespersen Colding, Director of ecommerce, wrote a piece on Headless setups in the context of ecommerce that we can recommend reading.
Headless setups makes it much easier to increase performance metrics in almost every aspect of your digital business, and maybe most importantly, keep them there.
If you’d like to learn more about headless CMS, you can find relevant links in the bottom of this post.
How to get started with performance optimisation
Talk about performance
Talk about performance a lot. Everyone should be involved in this discussion, developers, stakeholders, project managers etc. Performance optimisation is everyone's responsibility and a focus on performance should always be present.
Understand that frontend performance is more than fast load times
Performance is everything the user experiences on a website. Think about perceived performance as much as technical performance. Utilise the RAIL model, prioritise smoothness over speed and focus on the user, always.
Set performance goals and prioritise them
Set performance goals and allocate a part of the budget into obtaining these goals. Think about how the choice of architecture/platform and introduction of specific features might affect performance.
Define the metrics required by the design team, define a strategy to visualize them and set specific objectives.
Set up performance monitoring tools
There are many good performance monitoring tools out there. Make use of them and get a grasp of how well positioned your digital business is in terms of performance and the user experience that comes with it.
Take a look at your tech stack and the possible accumulated technical debt
Does your current tech stack allow for keeping up with the ever increasing demands for digital businesses? There’s a possibility that your current tech stack works against your goals, and not towards them.
The Google Page Experience Update: User experience to become a Google ranking factor
What is a headless CMS?
Headless ecommerce er customer experience ecommerce
Calibre performance testing
Headless CMS that we like:
Technical Lead Frontend Technologies