Front-end performance optimization and why it’s important
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.
- 6. October 2022
Front-end performance
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 been 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 Front-end Performance Optimization (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 optimization, resource timing, back-end response times, lazy loading, spinners, micro-interactions, predictability, animation timing, code splitting, and error handling are some of the topics and the list goes on and on and on.
All of the mentioned buzzwords above and the areas they cover are of equal importance, or are they? How do we prioritize setting up a budget for performance optimization on a project, or even, SHOULD we prioritize 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 Amazon, versus a random cheap webshop.
Websites whose project team understands how to prioritize 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 front-end 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 optimization and will understand how to prioritize their performance optimization 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 Optimization (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 knows the value of a well-optimized website, therefore speed and user experience are 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 prioritize 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, or scroll over your various page elements. Therefore, the RAIL model measures each user interaction with different context-specific goals in mind.
Response
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.
Response’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 good performance for our users, 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
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
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
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 utilizing 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 automate 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. 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 at the start of this article, optimizing 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 for several clients at Adapt.
Whenever we suggest a new functionality or the clients ask for a new feature, 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 for 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-year-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. 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 back-end, 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 make 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 at the bottom of this post.
How to get started with performance optimization
Talk about performance
Talk about performance a lot. Everyone should be involved in this discussion, developers, stakeholders, project managers, etc. Performance optimization is everyone's responsibility and a focus on performance should always be present.
Understand that front-end 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. Utilize the RAIL model, prioritize smoothness over speed and focus on the user, always.
Set performance goals and prioritize 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.
Wait! We have more