- Aufgeklärt: Die Core Web Vitals in aller Kürze
- Largest Contentful Paint: Wie schnell lädt die Website?
- First Input Delay: Wann kann der User mit der Website interagieren?
- Cumulative Layout Shift: Wie stabil ist die Website?
- So kannst du die Core Web Vitals abrufen
- Pagespeed Optimierung mit JENTIS
- Ressourcen beseitigen, die das Rendering blockieren
- Infrastrukturprobleme, Hosting und technisches Know-how
- Zahlen, Daten, Fakten
- Fazit: Mit JENTIS den Pagespeed optimieren und zusätzlich profitieren
|A special thank you to Johannes Fröhlich and the Digital Marketing Agency Dreifive for the mutual assistance for the blog article.|
Since June 2021, Pagespeed has become a crucial ranking factor with the integration of the Core Web Vitals into the Google algorithm. It can be decisive when it comes to displaying your website as high as possible in the search engine.
Google even goes a step further and says: the faster your website, the more conversions. Hmm…
But imagine the following: You’re standing in the middle of your favorite city and decide to look for a burger joint because you just met up with an old friend. You have the latest iPhone with perfect 5G connection.
The hunger is great.
The competition is greater – a burger joint on every corner.
The distraction is the biggest – the friend is already chatting with you cheerfully, the traffic around you is noisy….
Now every second counts and page load time can actually be the decisive conversion bringer for the burger joint.
But even with a bad smartphone and an even worse internet connection, the desired information should be found quickly – that’s Google’s goal.
So yes… page load time can be crucial when it comes to whether customers find YOUR brand, trust YOUR business, and ultimately buy from YOU.
No matter what you prioritize in 2022 – revenue growth, customer retention, or scaling internationally – it all depends on the performance of YOUR website.
But where are the biggest levers when it comes to pagespeed optimization? And how can server-side tracking, and specifically JENTIS, help? You can find out all about this in this blog post.
Enlightened: The Core Web Vitals in a nutshell
The Core Web Vitals are THE new core metrics from Google, which together with other metrics result in the ranking factor “Page Experience”:
The Core Web Vitals consisted of three KPIs for evaluating the usability of websites:
- Speed: Largest Contentful Paint (LCP)
- Interactivity: First Input Delay (FID)
- Stability: Cumulative Layout Shift (CLS)
|Important: Google will adjust the Core Web Vitals to the technical requirements as well as the user behavior and evaluates them regularly. Adjustments of the metrics are therefore not excluded.
Largest Contentful Paint: How fast does the website load?
In a nutshell: The Largest Contentful Paint (LCP) measures the loading time that passes until the largest content element (images, videos, text blocks) in the visible area of your website is loaded.
Google defines the following values:
- good: up to 2,5 seconds
- needs improvement: 2,5 – 4 seconds
- bad: 4+ seconds
The loading status determines which is the largest content element of your website. The largest element is usually loaded at the end. The following is an example of our JENTIS website:
You can find all the details and the exact calculation basis of the LCP here in the Google documentation on Largest Contentful Paint.
First Input Delay: When can the user interact with the website?
In a nutshell: First Input Delay (FID) measures the amount of time that elapses between the first user interaction with the website and the browser response.
When you visit a website, you may click a button without waiting for the website to fully load. However, the browser usually does not react at that time because it is busy loading the website. To prevent users from jumping off now, the FID measures how much delay passes between the user input and the browser’s response. The main factor for the calculation is the “Time to Interactive”.
Google defines the following values:
- good: up to 100ms
- needs improvement: 100-300ms
- bad: 300 ms or more
You can find all details about the FID here in the Google documentation about the First Input Delay.
Cumulative Layout Shift: How stable is the website?
In a nutshell: The Cumulative Layout Shift (CLS) indicates whether and to what extent unexpected layout changes occur while the user interacts with your website.
Unexpected layout changes happen when layout shifts occur as the site loads, and elements slide down as other elements are reloaded. This can have undesirable consequences for the user.
Google defines the following values:
- good: 0.1
- needs improvement: 0.1-0.25
- bad: 0.25 or more
All details and the exact calculation basis of the CLS can be found here in the Google documentation on the Cumulative Layout Shift.
So much for the definition of the Core Web Vitals (LCP, FID, CLS).
How to retrieve the Core Web Vitals
You can check how well your website is performing either via Google Lighthouse, the Google Search Console or directly in Google PageSpeed Insights. Simply enter your domain in the input field and click on “analyze”.
After a few seconds you will receive information on whether your website has passed the evaluation according to the Core Web Vitals – or not.
You also get a speed score for mobile and a speed score for desktop. This score is between 0 and 100, where 90-100 is good, 50-80 needs improvement and below 49 is bad.
|Tip: Since March 2021, Google indexes only “mobile first”, it is important that your speed score fits mobile. As a result, it usually automatically fits for desktop as well.
The result of the Core Web Vitals is provided as field data and lab data. Field data is anonymous data of real users on different devices and with different connection speeds. Lab data is simulated data on a single device and with a fixed network connection.
Depending on the results, you will receive a set of recommendations from Google that can be used to reduce the loading time of your website, as well as a prediction of how many seconds it can be reduced by:
What are the biggest optimization levers?
Every single recommendation from Google is a good optimization lever.
However, you have to put costs and benefits in perspective (as always). Google still values good content the most. So before you invest tens of hours to make your website 100 ms faster, it probably makes more sense to invest this time in good, user-friendly content.
In the following, however, we would like to show how server-side tracking and JENTIS in particular can support PageSpeed optimization. In doing so, we will directly follow the recommendations from Google’s PageSpeed Insights:
Pagespeed Optimization with JENTIS
JENTIS is an innovative, powerful and compliant server-side tracking solution.
| You can read about the benefits of server-side tracking and how server-side tracking compares to client-side tracking in this blog article:
Paradigm Shift in Web Tracking. Why your standard solution is at a dead end and how you can overcome these challenges with JENTIS.
Eliminate resources that block rendering.
So clean code accounts for a considerable portion of Google rankings.
To optimize Core Web Vitals, Google often recommends eliminating resources that block rendering:
The classic setup – an example: your website uses Google Tag Manager (GTM) and within it several tags for tracking and marketing.
Let’s stay with tracking first: for Google Analytics you track not only the pageview but 25+ other events like newsletter signup, clicks on banners, etc. If you run an online store, you might want to add Enhanced Ecommerce Tracking.
Of course the GTM loads the tags asynchronously and therefore parallel to the actually much more important content. However, the amount that needs to be loaded remains the same.
Additionally, there is a lot of effort in the client’s browser, because the Google Tag Manager basically loads ALL code into the browser – which has to process the requests first.
This takes time.
The following graphic should clarify the problem:
How JENTIS helps
JENTIS provides its own tag manager – the JENTIS Tag Manager (JTM) – with the advantage that it ONLY performs basic communication in the client’s browser – asynchronously, of course.
ALL other tags are executed on the server side and thus do NOT load in the client’s browser – and the less code has to be executed on the client side, the faster the website, and so the better the loading time.
Here, too, web analytics has its finger in the pie, since countless 3rd-party tracking tags are often loaded into users’ browsers. So, for example, besides conversion tracking for your 5+ social networks, you also have a heatmap tool like Hotjar, an A/B testing tool like Optimizely, AWIN for affiliate, (…) configured.
However, the order in which the tags are triggered cannot be regulated via the Google Tag Manager. They are executed asynchronously and thus in parallel – this is good, but whether images and texts are loaded before the Facebook pixel is no guarantee.
This is where JENTIS comes in:
Here’s how JENTIS helps
This automatically eliminates the need for all 3rd party libraries. The order of the tags to be executed is therefore no longer important, because the execution is done later on the server side. The website is automatically faster.
Depending on whether Hybrid Tracking or Backend Tracking is then used, the 2nd stream can also be saved.
The JENTIS loading process is shown as follows:
A positive side effect of JENTIS: significantly higher data quality! Another advantage of fast-loading code on the client side is that data discrepancies between actual and tracked visitor numbers and sales can be reduced. Keyword: ad-blocker and tracking prevention methods (IT/ETP/TP).
This means that the marketing team has a much more reliable overview of user behavior and conversions. This in turn simplifies budget control and delivers even more effective campaigns.
Third-party codes actually affect the landing speed of websites tremendously. Google further recommends in PageSpeed Insights:
Redundant third-party tags?
You probably have them too.
For example, you use Google Ads and Facebook and want to record your sales as conversions. To do this, you configure a Google Ads conversion tag and a Facebook conversion tag – in other words, two tags that track the same thing, namely the sale, the transaction.
From Google’s point of view: double tracking.
In addition, traditional client-side tracking will again load the library from the vendor, which in turn uses the CPU and RAM from the visitor’s computer to generate streams that are sent over the visitor’s network.
It is precisely this tracking efficiency that JENTIS takes care of:
Here’s how JENTIS helps
The goal: to reduce the size of the source code even further, so that the transfer of data is even faster and more efficient.
The following graphic shows how this works:
Numbers, data, facts
Not in all cases. It depends on the Internet connection:
- 2G GPRS with max. 56kBit/s bandwidth: 82 seconds
- 2G EDGE with max. 220kBit/s bandwidth: 22 seconds
- 3G EDGE, UMTS: up to 13 seconds
- 3G HSDPA: 0.7 seconds
- 4G LTE: 0.24 seconds
The following graphic gives a better overview again:
So even in 4G, JENTIS can be the icing on the cake, because every improved millisecond has a positive impact on conversion rates and customer satisfaction, and thus on Google rankings.
How are the 604kb calculated?
We tested this with our customers.
In this case, with a large online store that is mainly active in the D-A-CH region and has switched from Google Tag Manager to JENTIS. For a while, both tracking systems were running in parallel and we took this as an opportunity for our testing.
In total, the GTM accounted for 365kb. Additional third party scripts added another 281kb to the user’s browser load. TOTAL: 646kb
In comparison, the JENTIS library loads at 42kb. This makes an advantage of 604kb over the Google solution.
You can see the details in the following graphic:
Conclusion: Optimize pagespeed with JENTIS and profit.
With the Core Web Vitals, Google has given webmasters, web developers and SEOs three KPIs that have several advantages: They are clearly communicated, apply to everyone in the same way and can therefore can be optimized in a targeted and comprehensible way. SEO is thus no longer a black box.
An excellent Speed Score is therefore relevant for ALL websites – for highly competitive companies it is even fundamentally important, as a fast loading time leads to an even better user experience and thus to more conversions.
However, costs and benefits must ALWAYS be put into perspective. With JENTIS, and thus with a performance-oriented and at the same time powerful server-side tracking solution, you can reduce your Pagespeed by up to 82 (!) seconds.
It’s the greatest possible leverage with comparatively low resource requirements and at the same time manageable costs, because you can start using JENTIS today for as little as €500 per month.
|Note: Pricing is based on the number of events you need for your tracking plus the number of pixels implemented through JENTIS. Find the right plan for you here.