All of us nowadays are talking about web performance, it’s the subject that is taking the most important place in talks, blogs, and podcasts, everyone is trying to give his point of view on why it’s primary and how we can achieve it. We are also witnessing rising competition in the JS Frameworks field, the discussion now is only about performance rather than Developer Experience, which was the subject with SPA Frameworks, but fortunately, now we consider that DX is becoming an acquired value that no one needs to argue about. New Frameworks are showing their ability in having big scores in PageSpeed Insights.
Here is a tweet from the CEO of Vercel, who is showing how with NextJS we will be able to build websites with extremely great performance.
Focusing on performance is an indirect approach to enhancing the User Experience, the user should have the best page load speed on our websites, he should not wait for a page to start loading, to be visible, to be interactive, and to be stable. These factors all play a part in what is known as Core Web Vitals, key metrics Google uses in its ranking algorithm. They are sort of standards that we will talk about in this article to test website speed. So developers utilize several performance testing tools such as GTmetrix or Google PageSpeed Insights to ensure that they respect the metrics to optimize their sites for better speed.
Why Web Performance is Important?
Engaging in a discussion about performance in general will not be significant without considering the real concern about it, the User, for whom we want to build performant websites, in other words without using political correctness the CONSUMER. To illustrate this we can draw a parallel to dining at a restaurant, Imagine you are in a restaurant, you ordered a beef bourguignon dish, you’re so hangry but you should wait 40 minutes for it, as the minutes tick away, your hunger grows, patience wears thin, maybe you will cancel your order within 15 minutes, maybe you will wait but vow never to return, you will share your disappointing experience with friends, write a bad review in google.
This scenario is remarkably comparable to the user experience on a website.
If a website fail to deliver a functional page quickly, the user's initial excitement can quickly evolve into frustration, a slow e-commerce website, for example, can lead the consumer to abandon his order and search for it on other websites, so like we can see performance is not only about technical issues but it’s a human phenomenon, an emotional state, and a psychological experience because it’s not about the website and what it’s offering, it’s about the user who searches for efficiency and immediate response. If we analyze for example apps like TikTok or Instagram Reels we will understand that users are searching for information in only 30 seconds, they don’t want to watch a documentary or a long video about a subject, a TikTok video with a minimum of seconds and a maximum of pieces of information that matches their needs.
But having Performance and UX as the main factors for building websites is not something coming from nowhere, in this article we will explore also how Google managed to establish these factors as important axes to respect when building websites.
History of Google's Website Ranking
Every website's goal is to appear on the first page of Google search results, perhaps even at the top of the list when users search for something related to the website's content. Google has the ability to define the criteria for displaying these results, and these criteria have been changing over the past few decades.
In the beginning, Google ranked websites based on links from other high-quality websites. For example, if you had a new website for your restaurant, it would likely have a low ranking because no one was linking to it. However, if a well-known blog with a large user base were to mention and link to your website in an article, Google would adjust its ranking, resulting in a higher placement in the search results.
But this approach was not efficient because there were a lot of spammers, so Google started implementing different methods such as keyword relevance and user experience and they did a lot of updates to chase websites who are spamming and buying links.
In the last years, Google decided to spotlight User Experience and Performance, so websites should not be slow or insecure to have a great user experience, for that, Google introduced Core Web Vitals in the game in 2020, which are a set of measures that give us a detailed view on the experience that will have a user in our website, and Google utilize them to rank results in Google Search. So to do things correctly from the start or to optimize an existing project we should have a deep understanding of Core Web Vitals.
Web Performance as a Criteria
Yes, we should be concerned about Core Web Vitals if we worry about our users. Core Web Vitals are increasingly becoming a topic and a challenge for new frameworks, or more precisely, meta-frameworks. Meta-frameworks such as NextJS, Astro, or Qwik City are more concerned with improving the performance of web applications. These tools each have their ways of rendering, hydration, partial hydration, and resumability, but the purpose is the same: to make websites faster to provide a better user experience.
Now let’s deep dive into our main subject, Core Web Vitals. These are metrics that Google uses, like we said to judge if a website has good performance or not, if it has a good user experience or not, and if it should be well ranked or not.
Largest Contentful Paint (LCP)
This metric measures the time that website takes to render the largest area (element) of the page, for example, if we take the adservio.fr, here in https://pagespeed.web.dev it indicates the element that is considered as "Largest Contentful Paint”:
On our page the LCP takes 2,5 s, which is not good to have a performant website, after 2,5s the user will see most of the page painted, so he will say that the page is almost ready.
Cumulative Layout Shift (CLS)
This measures the score for a page based on the entire time a page need to stop moving or shifting elements around in the DOM. If for example, we have a website for e-commerce, but after finishing showing the page, suddenly we have a bar that appears at the top of the page and moves the page to the bottom, that’s not good if we want to have a better score. Here is an example from the ft.com, in first we have the page correctly but suddenly it moves down to show an ad (colored in red):
It’s all about unexpected element shifting that will occur on our page, we should not keep injecting new elements in the DOM.
So now we can imagine the nightmare that we will have with Single Page Application, and how the score will be catastrophic.
First Input Delay (FID)
That’s an interesting metric, FID measures the necessary time that we should wait between when the page looks ready and when the user can interact with it, which means when the browser can fire an event.
| Page visible but not Interactive | After 3ms the page is interactive |
|---|---|
 |
 |
If for example, we are working with frameworks that do hydration, we will show the HTML page that is rendered the first time with SSR, but we should wait to download and execute our javascript files in order to add the necessary code to each node of the DOM. After doing this reconciliation, we will have our page ready.
First Contentful Paint (FCP)
This metric is used to calculate the necessary load time for meaningful content to be visible, from entering the URL to having something on our page, not a blank div, something visible must be rendered, here we show an example:
| Blank Page | First Meaningful Content |
|---|---|
 |
 |
When a user sees something on the page, he feels safe, he is sure now that he will have a result, that the website is working.
For more details here is a link to look at.
Conclusion
Our Article now was an overview of how Google ranks websites, and we focused more on modern metrics, Core Web Vitals, to give an overview and simple explanation of each one.
This article is one of a series that we will have. In the next article, we will deep dive into Core Web Vitals, and tools to measure them. If you found this article helpful? Share your thoughts in the comments below or share it with your network!
Top comments (0)