For the last few months, Core Web Vitals are all the rage in Speed and SEO optimization circles. Everyone is talking about how to improve their numbers and get Google’s blessing. But what are Core Web Vitals and why are they so important?
If you are thinking about why a server panel provider is talking about all of this, read the article and you will know how important a good panel with an excellent stack can be and how CyberPanel helps you save hours of work and loads of money. To understand the whole story we have to understand how a page loads. You type in your page and whatever you had on that page shows up in a second or 2 or 4 or 8. Well if someone has been waiting for that long, let’s accept it they will close the page and probably won’t visit your site again. But let’s not get ahead of ourselves and focus on the process. We are going to use the example of the CyberPanel installation instruction page in this article which can be seen here.
Time to First Byte TTFB
DNS Lookup
The first step of any page load is a DNS lookup. DNS or Domain Name Server lookup is a process in which your computer asks your DNS provider for the IP address of your site. As you know, computers connect via IPs, and all your domains are hosted on some server that has one or more IP address(es). In our case when we enter 01 - Installing CyberPanel - Docs - CyberPanel Community in the browser, our computer checks if it has a cached record for the IP address of cyberpanel.net, if it does, it moves to the next step.
But if it doesn’t, the browser sends that request to our Internet Service Provider or ISP and they provide us with an answer from the authoritative name server. As we are talking about speed, this can take 6ms to 600ms depending on the DNS provider you use. Cyberpanel uses PowerDNS which is the fastest open-source DNS daemon to serve DNS requests to your clients, the only latency you might have is due to the distance between your client and your server, but we have that covered too. According to DNSPerf, Cloudflare is the fastest DNS provider on the planet right now and yes, CyberPanel has an integration so you can sync your DNS records with your Cloudflare account. This makes sure that your users spend less than 30ms from anywhere in the world to look up the IP address of your site.
Connect Duration
Now that the browser knows where your site is, the next thing to do is to ask that server for that page. Over the course of the internet, HTTP connections have been evolving but as of right now there are 3 main connection protocol in use
- HTTP version 1 which includes HTTP/1.0 (doesn’t support SSL but we will come to that later) or HTTP/1.1 which came with the security headers and started HTTPS
- HTTP version 2 which includes HTTP/2 ( Google developed SPDY which is an equivalent) allows for server push and multiple simultaneous loading of files on a single TCP connection
- HTTP version 3 which includes HTTP/3, is based on QUIC protocol which uses UDP for the fastest data transfer. As of today, Chrome and Safari support HTTP/3
HTTPS Connection (SSL/TLS)
Remember our page address included “HTTPS://” at the beginning? Yeah, that means this page has to be served over a secure connection. HTTPS is one of the major ranking factors in Google’s SEO guidelines and unless you have some really reasonable explanation on why you want your site without an SSL connection, your website already has it. I mean, no one likes their customers or reader seeing that dreaded “Not Secure” warning in the browser.
You might be asking why is this important if it takes more time? Well, it creates a secure stream of data over insecure internet with the help of long-term private key and short-term public keys to create session keys which encrypt all the data from and to your customer/reader. Without it, anyone from your ISP or wifi provider or anyone with malicious intent can try to inject data onto your page while it’s being transmitted or eavesdrop on whatever is being transmitted and neither of those is appreciated in 2020. Like HTTP, TLS ( the underlying mechanism for encryption) has evolved. There are three versions in use 1.1,1.2 and 1.3 with loads of encryption mechanisms, ciphers, and algorithms. CyberPanel automatically gets a Let’s Encrypt SSL certificate for your site (it’s free thanks to ISRG) and the configures LiteSpeed webserver to use the most secure and fastest algorithm supported by the browser to keep HTTPS duration at a minimum.
Backend Duration
Now that connection has been made and it’s secure and the browser has for the page over a secure connection, it’s time for the server to find the page and give it back to the user’s browser. If it’s a simple HTML page the server will pick it up and send it browser immediately without any delay but what if you are using a CMS or complex application (like in our case WordPress). In that case, the server asks the application processor (PHP or Python or Ruby or Node.js) to evaluate the page and send the give it the result so it can serve the user. Most of Web 2.0 application like a blog or an online store or a web application checks the URL, processes the checks of what has to be served, usually gets data from some form of database and then puts its all together. The time taken to do all of these calculations is usually known as backend duration and this can be a significant part of page load duration 
Have you ever used cache or heard of cache plugins/extensions? Yeah, this is why they are used. Instead of having the application to process all of that again and again, a cache application or plugin makes a copy of the HTML which was generated when the page was loaded for the first time and serves that. This reduces the load on your server and makes sure that your users get the data as quickly as possible. Cache plugins/extensions usually don’t have a server-level cache mechanism which means the application processor has to be invoked at least once to check if there is an HTML version of that page saved or not. CyberPanel comes with a Litespeed cache plugin/extension which is a server-level cache plugin, which means your server won’t even have to check in with the application. It has an option to integrate PHP’s OP-cache and database cache mechanism like Redis and Memcached to decrease the load on the database and load it swiftly.
Time to First Byte (TTFB)
If you have ever tried to optimize for speed, you would probably know this word. All of the steps above, when combined, result in the first byte ( and the subsequent data) received by the user. Hence the time taken by all of the above is known as Time to First Byte (TTFB). It is one of the Web Vitals but not included in Core Web Vitals.
Page Load/ Render Time
Now that the page is finally starting to be received, it has to be displayed and there are several measurements on how quickly it happens. Now the next few steps don’t necessarily happen in the sequence presented here but usually, this is the case.
First Paint
First Paint is when your browser renders something on the page, it can be a text or an image or an audio/video player, or even a white/colored background. As most of the sites just load white background this is usually an insignificant metric unless you have a colored background, this can be as important as the next step.
First Contentful Paint (FCP)
When the first content appears on the page, it’s called first paint time. It’s imperative to keep this time as low as possible as this is the first time your visitor sees “something” appearing on the site, so they wait for the rest of it to load. This is the first impression on the user and it has to be great. It is one of the Web Vitals but not included in Core Web Vitals.
Both the first view and the speed have to be persuasive for the user. The time recommended until this point is 1 second or less. Here are a few ways to make sure it’s loaded quickly and looks great. This can be done by doing the following:
- Generate Critical CSS: Any piece of stylesheet which is needed to display the page without breaking the UI and to avoid Flash of Unstyled Content (FOUT).
- Inlining critical resources: Anything (including CCSS in the step above) that is absolutely needed to display the first chunk of the page.
- Deferring non-critical resources: Adding an async tag to any JS not needed at the beginning and forcing the rest of CSS (except CCSS from the first step) to load after the page is loaded
- Removing JS-based elements and lazy-load for above the fold content: JS Evaluation can make the page load slower and lazy-load wait for the full page to load before downloading and displaying the content. Both need to be avoided.
- Inline small images: Most of the browsers support allow base64 encoded images, so it’s a good idea to inline logos and social media icons.
- Alternative fonts during font load: Sites usually use third-party fonts like Google Fonts or TypeKit fonts from Adobe, and they take some time to load, alternative system fonts must be declared, so the data isn’t invisible till the font has loaded.
- Prefetch, pre,-connect, and preload: Most modern browsers allow prefetching DNS and preloading requests so if you are using files from other sites they will be already.
Sounds too much work? LiteSpeed cache plugins generate critical CSS for you ( for free ) and provide options to do all of the above in settings.
Largest Content Paint (LCP)
Yes, we are finally here. This is the first of three Core Web Vitals defined by Google. Largest Content Paint is considered as the time when the largest content of your page has fully loaded. It can be an image or a title heading or a paragraph, it just has to be the largest one. Till Google choose this to be a ranking factor, FCP was used in its place. FCP has some shortcomings as it needs something to show up, that something can just be a logo or a loader image or the top menu. LCP focuses to be a more meaningful metric as this is when your site shows something the user wants, the title of your blog or heading of your article, first product in the category, first bi-line in your testimonial, or anything that the user actually needs. Google recommends that your site shouldn’t take more than 2 seconds to display or at a maximum of 4 seconds. If you have read the suggestion for FCP, all of them apply to LCP with the addition of a few more below
- Compress and combine CSS, JS: To display most of the content on your site you will need many CSS and JS files which increase the total number of requests hence delaying the rendering of the page. These files can be compressed and merged into smaller fewer files which will make it faster and easier for browsers to display your content.
- Pushing CSS and JS files: HTTP/2 came with the option for the server to push files before they are requested so you can use that option too.
- Using cache: Although this has already been mentioned in the connection section, external scripts and stylesheets can also be cached and served in combination which makes it much faster and better
- Browser Cache: Any file served from your site can be cached by the browser. This doesn’t help with the first load of the page but with any subsequent load, browsers won’t have to load the critical CSS and most of the resources so the page will be loaded swiftly.
LiteSpeed Cache provides an option for all of this in form of on/off toggles. Alternatively, CyberPanel provides access to .htacess and Vhost files if you want to get nitty-gritty and add those settings to the server’s directives.
DOM Content Loaded Time
This is the time when all of the content on the page has been downloaded and the browser is ready to execute JavaScript. If you have followed all the steps in the last stages, there isn’t anything left to fix here except for images. Images are usually the heaviest part of the site and they need to be optimized. It’s preferred to use the latest version of images like JPEG and WebP and use PNG only when transparency is needed ( and you can’t create an SVG for it). CyberPanel provided Imagick and GD libraries with PHP for your applications to resize and generate the smallest best-looking images via code, while LiteSpeed cache uses cloud-based technology to do the optimization for you. All you need to do is enable it.
Onload time
It’s the measurement of time, after which no other request is made and all the resources have been downloaded including the ones requested by the javascript files during execution. No additional suggestions here.
Interaction
After some or most of the page has loaded, Google and other UI/UX observers including your users are focused on interacting with the page. Scrolling up and down, choosing elements, clicking things, and whatnot. Whenever a browser is processing a javascript, it can’t respond to the user’s input. So the time for that must be short enough to make sure that users don’t feel a lag in response
Time to Interactive (TTI)
Time to Interactive is one of the lab measures which defines when the last blocking javascript tasks run. Anything that takes more than 50ms is considered a blocking task. Time to interact is a lab test for calculating the time after which any user input can be responded to swiftly.
It is one of the Web Vitals but not included in Core Web Vitals.
Total Blocking Time (TBT)
This is another lab metric that relates to the user interaction of your website. When can a user be blocked? As we established in the last section that if there is a javascript that runs for more than 50ms, it is considered a blocking task. OK, but when can a user be blocked? A user won’t interact before FCP as there is nothing to interact with and as we know there are no blocking tasks after TTI, hence it’s fair that TBT is calculated as a sum of time taken by all blocking tasks between FCP and TTI. It is one of the Web Vitals but not included in Core Web Vitals.
First Input Delay ( FID )
Yes, yes, I know finally the second Core Web Vital. The first input delay is the field version of TTI and TBT, it’s the time between a real user’s interaction and your site’s response to it. Google recommends having an FID lower than 100ms and allows a maximum of 300ms before it ranks you as poor. You might be asking, hey where are those suggestions? As the interaction section is a mix of lab and field data, there was no suggestion for them individually. But here are a few suggestions for optimizing the interactions
- Remove unnecessary JS: Do you really like that scrolling animation with the pop-up? If you do make sure it doesn’t take more than 50ms to process or get rid of it. If you aren’t using input validations on a page, don’t load that JS or it will try to evaluate after every keystroke making it slower.
- Break a large task into smaller one: If you have many JS functions that are absolutely needed, make them smaller and run them one by one.
- Browser Cache: I know I have mentioned this one before, but if your JS loads quickly and anything it might ask for is cached in the browser too, you are looking at a significantly lower time to run tasks.
- Using better plugins (optional): If you are using a CMS make sure all the plugins/extensions you are using aren’t resource-hungry or at least do it in a non-blocking way. ( Remember those admin-ajax.php calls on WordPress? )
LiteSpeed cache comes with an option to break down JS in parts according to size and tries to optimize calls to functions so that it doesn’t interfere with the interaction
Visual Stability
Have you ever tried clicking on a link but you before you touched it, the content on the page shifted and you clicked on some unwanted link or an ad? Yeah, no one likes a site that keeps shifting the content while loading or interacting. This is why Google added a separate metric for this and a whole new category in measurements.
Cumulative Layout Shift (CLS)
Cumulative Layout Shift depends on three things.
- How many elements changed their position?
- How large those elements were?
- How much distance did they change their position to?
In order to be considered a visually stable site, the value must be lower than 0.1 which can roughly be considered similar to less than 5% change. A site can be made visually stable by making sure that the following precautions are taken
- Set sizes and attributes for images and other media: If you have any images infographics, videos, GIFs, embeds, tweets, etc, make sure their dimension are already defined and they don’t shift the layout after being loaded.
- Avoid Flash of Unstyled Text (FOUT): FOUT happens at the very beginning when a flash of text appears and then it slows starts to get styled and getting into position. Yeah, no so much visually stable right? This much be avoided
- Reserve ad space: Make sure that if and when the ads load, they don’t push content up or down.
Remember free critical CSS generation and free image optimization provided with LiteSpeed cache included in CyberPanel that I mentioned somewhere above in the article? Well, those make sure that all of this is already done and your page is visually stable. Now you know what web vitals, core web vitals, and other metrics are, how you can improve them and how CyerPanel can help you speed up your site for your user and customers. So what are you waiting for? Spin up a CyberPanel instance at one of your favorite VPS providers or install on your own server with a single command. Get Started NOW