How To Measure Your Page’s UX with Web Vitals

Reasonning about SSR and Deployment

This post is part of our ‘The Miners’ Guide to Crafting Code‘ series, designed to help aspiring developers learn and grow. Stay tuned for more!

Hey there! In today’s post we’ll talk about some topics that are often overlooked when you’re learning frontend development. The reason being that what’s the point in being a CSS master that designs beautiful pages if they take an eternity to load and users won’t bother sticking around to check out your art piece?

UX

One of the most important aspects of the pages you interact with (or build yourself, for that matter) is the user experience(UX). What is the point in knowing how to center a <div> if the user isn’t even able to see your page’s content due to bad color contrast, or tiny font size?

That being said, there are other aspects that can influence the UX such as:

  • How long does it take for the page to load?
  • How accessible is the page? Did you choose good fonts, color contrast, are you using the correct elements to make the website accessible for visually impaired users?
  • How long does it take for the user to be able to interact with the page after it loads?
  • How easy is it to navigate in your page?

And this isn’t even just a matter of empathy, but having an accessible and snappy website will definitely help you make more money since your user retention will be higher than similar pages — pages that take twice as long to load, boring the user so much that they don’t bother waiting for things to render.

Web Vitals

But how are we able to “measure” how good our user experience is? After all, you can’t make changes just based on wild guesses, r-right? Luckily for you, Google came up with an initiative called “Web Vitals” which provides guidance for some of the quality signals we talked about and more!

The Web Vitals initiative aims to simplify the landscape, and help sites focus on the metrics that matter most, the Web Vitals.

Web Vitals

Web Vitals is an initiative by Google to provide unified guidance for quality signals that are essential to delivering a great user experience on the web.

Loading

  • First Contentful Paint (FCP): measures the time it takes for the first visible content (such as text, images, etc) to appear on the screen after the page starts loading. To provide a good user experience, FCP should ideally occur within 1.8 seconds or less.

  • Largest Contentful Paint (LCP): measures loading performance. To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading.

  • Time to First Byte (TTFB): measures how quickly the browser receives the first byte of data after making a request to the server. For optimal performance, TTFB should be under 200 milliseconds.

Interactivity

  • Total Blocking Time (TBT): measures the total time between when the page starts loading and when the user can interact with it, specifically focusing on JavaScript tasks that block the main thread. To ensure a smooth user experience, TBT should be under 300 milliseconds.

  • Interaction to Next Paint (INP): measures interactivity. To provide a good user experience, pages should have a INP of 200 milliseconds or less.

Visual Stability

  • Cumulative Layout Shift (CLS): measures visual stability. To provide a good user experience, pages should maintain a CLS of 0.1. or less.

If you’re page looks like this while it’s loading, you might have to work on improving… uhmm, a few things.

Core Web Vitals

And this is useful; However, some of these metrics that are considered crucial and we should prioritize them first.

The current set focuses on three aspects of the user experience—loading, interactivity, and visual stability—and includes the following metrics (and their respective thresholds):

core web vitals

SSR

Alright, and what we do with the knowledge we acquired? Well, to understand what comes next we first need to know the difference between Client-side rendering and server-side rendering (also known as SSR).

Client-side Rendering

In short, client-side rendering happens by downloading a minimal HTML content and generating content, making API calls to fetch content, and creating the page entirely in the browser.

  1. You open a website.
  2. The page finishes loading.
  3. It is empty (or showing a loading spinner) while it’s fetching the data it needs.
  4. After the data is fetched, it is then dynamically displayed to the user.

This is a bit bad for SEO because crawler robots are impatient and need to be efficient, so they will still rank your page, just not as highly as it could be.

Server-side Rendering

Whereas server-side rendering happens by generating the full HTML content beforehand, so the page is sent to the browser with all of its already-constructed HTML.

  1. You open a website.
  2. Before loading, the server is fetching the data it needs.
  3. Only after finishing everything it needs to do, the page is built and sent to the browser.

This does not mean it will load immediately because we still have to wait for the time it takes for the server to do all this fetching magic under the hood, but once its complete, the main benefit is that the page will only load when it’s already filled with every piece of content it needs.

This is excellent for SEO because by the time the page loads, the crawler robots are already able to read the whole page and its contents and prioritize its ranking in search engines.

By the way, if you have no idea what I’m talking about when I mention SEO or web crawlers, check out this post.

Deploy

Now you need to host your website somewhere so your users can actually see your webpage live, so how do you do it?

Well, you could build a server, a robust power delivery system, a reliable internet connection, install a linux-based OS, configure your server, build your application, initializing the server, installing a process manager, scale the app horizontally, put your static assets on a CDN, do maintenance, or…

…you can simply use a PaaS (Platform-as-a-Service) such as Vercel or Heroku. That’s it.

The instructions vary for each of them so it isn’t in our best interest to go in-depth here, but it should be just a matter of a few button clicks to get an application live using Vercel (especially if you’re using Next.js)!

Conclusion

In summary, creating a great user experience isn’t just about making your website look good; it’s about ensuring your users can access and interact with it seamlessly. By using Web Vitals as a guiding framework, you can measure the critical aspects of UX like loading performance, interactivity, and visual stability. Understanding how your website behaves and how quickly it responds is key to improving user retention and boosting your site’s performance. And with modern deployment tools like Vercel, getting your optimized site live has never been easier. Thanks for reading!

References

https://web.dev/articles/vitals

We want to work with you. Check out our Services page!