The performance of web pages and applications is crucial for a variety of reasons. Maybe you can simply see your app is slow, or you’ve heard that performance is important for SEO. It could be you’re concerned about the experience of your users, of which more than half are going to leave your site if it’s too slow or that you’ve got some non-functional requirements that you have to meet. Whatever the reason for your curiosity, you will likely find a lot of articles about Web Vitals.

Web Vitals

Web Vitals is an initiative by Google aiming at providing guidance for web developers for assessing their websites’ performance. It provides a set of metrics that you can measure and compare to Google’s guidelines, other websites’ results or previous results of your own website. Let’s not delve too deep into this topic as there’s a lot of content out there already, but let’s take a look at the core web vitals - the metrics that Google says apply to all web pages:

  • Largest Contentful Paint (LCP) measures loading performance and reports the time at which the browser rendered the largest image or text block visible within the viewport,
  • First Input Delay (FID) measures interactivity and reports the time between user’s interaction (like clicking a link or tapping a button) to the time when the browser processes that interaction. It’s not easily measured in a simulated environment, so you can often see it replaced with Total Blocking Time (TBT), which reports how long the main thread was blocked by a long-running task,
  • Cumulative Layout Shift (CLS) measures visual stability and reports how much the content shifts during loading due to elements being added above it.

There are also other measurements like Time to First Byte, First Contentful Paint and Time to Interactive.

Alternatives

Web Vitals, while widely accepted, aren’t the only measurements you can consider while thinking about the performance of a web application. Here are some other metrics that you can find in popular benchmarking tools:

  • Speed Index and variations of it measure avarage time to display visible parts of the page,
  • Visual Complete % measures how long it takes to display some percent of the viewport compared to the loaded page,
  • Time needed for the browser to compile, parse and evaluate the webpage’s code,
  • Size of the page’s source, which also affects the speed of downloading it.

If you’re interested with learning more or would like to see how your website does against them, you can run Lighthouse from within Chrome Devtools on your machine or check out PageSpeed Insights and WebPageTest which are going to run those benchmarks on their servers. Another great tool is sitespeed.io which you can either install on your machine or use through a Docker image and supports benchmarking the metrics mentioned above and much, much more.

Where’s the catch?

The metrics mentioned above are the result of decades of work done by the best experts in the field, and Google isn’t wrong in saying they apply to all websites. The problem you might’ve already picked up on is that they’re all concerned with the time between entering the website and displaying the content - that’s because that’s all that static websites or multi-page applications are about, and those were the staple of the web for many years. For a single-page app, however, the initial navigation is just the start - the user can later log in, navigate or interact with the application in multiple other ways. The initial load time is just as important for single-page app as for all the other websites, but what’s it for the user that the table he wants to access loads quickly if any sort of filtering he wants to do takes ages?

If you’re curious about the solutions I have to this issue, stay tuned - I’m going to cover them in a future blogpost.