Fix Core Web Vitals

1. First-time visitors typically spent less time on unknown websites. Among the criteria to stay or not on a site, is how fast it loads. Website speed affects the user experience. If the page is slow, they won't wait but jump to the next browser tab (high bounce rate, drop-offs). You can't expect time-consuming content to become viral. Who likes to share a slow page?

2. Provided that the page offers quality content, visitors might enjoy the speed to browse more pages (page views are good for rankings) and return later. Customers may make up to 7 visits before purchasing anything or convert otherwise. High-performance content results in more conversions, higher engagement, better rankings in organic search.

3. Since 2021, Google has introduced a new mobile algorithm (Page Experience) to ranking websites. Sites with no Search performance issues that are fast have better chances of getting more organic traffic. The algorithm is complemented in March 2022 by desktop ranking signals.

4. Speed is affected by the server location. It makes sense to measure loading time near the server location and not get biased results from distance points at the other side of the world. Time to first byte (TTFB) should be between 200 and 500 milliseconds on average. Higher values are considered very slow and lower values, ideal.

Core Web Vitals measure user experience on 6 areas:

1. First Byte (First Contentful Paint - FCP)

2. Speed (Speed Index)

3. Largest Code Block (Largest Contentful Paint - LCP)

4. Interaction (Time To Interactive - TTI)

5. Blocking Time (Total Blocking Time - TBT)

6. Layout Shift (Cumulative Layout Shift - CLS)

Important note for debugging the issues: Google Search Console gets its data from tracking Chrome users [Chrome User Experience Report (CrUX)] dry run or field data, who have visited the pages in the last 28 days. If the Core Web Vitals are within acceptable range (see recommended thresholds below each Core Web Vital), what is left to do is hit the validation button on the GSC report.

Page Speed Insights reports live (lab) data, (fresh run) that may have fewer or no issues compared to the outdated field data. The discrepancies betweeen the tools under the same Google roof create confusion among webmasters just because Google engineers can't sync the tools or explain why the fail to do so and why they insist on using outdated field data from the past, instead of lab data, to rate websites. Another area where they fail (an embarassing GSC bug) is when all issues are fixed, it is way past 28 days, and GSC will still show errors!!

The FCP is the first content byte. It should be close to the value of Time To First Byte (TTFB). Recommended FCP value <2

57% URLs from a sample of 20.000 URLs fail on LCP. The LCP measures how long it takes for the most meaningful content to load and/or how quickly users perceive your site to load (loading performance). The LCP is about large (unoptimized) images, content blocks and code blocks e.g. page builders within the viewport or further below if the issues above are fixed. The LCP errors can be solved by reducing the size of images, content and code bloat within the viewport. The LCP is different between the mobile and desktop versions of your site. Recommended LCP value <2.5

The TBT measures the estimated total amount of time your browser is blocked when a site is being loaded. Loading images, text, Javascripts, and everything else, draws power from the CPU, which blocks your browser from doing more. By estimating the amount of time your browser is blocked because it’s loading something, Lighthouse can measure how good the user experience is. The less time your browser spends being blocked, the better the user experience.

54% URLs from a sample of 20.000 URLs fail on CLS. CLS (AKA Layout shift) is about visual stability. Layout shifts happen when elements are out of place or block the content e.g. ads, iframes, fonts creating FOUT effects, etc. Anything that disturbs the layout even in a small percentage. The fixes depend on the source of the issue, e.g. CSS faults, ads, code bloat (page builders). The source of the problem dictates if the fixes will be site-wide or page-specific. Typical examples of CLS include menus bouncing, hero sections moving left to right or diagonally, images or ads shrinking on the fly, pop-ups, etc. Recommended CLS: <0.1

Website speed is a ranking factor with the release of the Page Experience (Core Web Vitals) update in June 2021. Sites that fulfill the new speed criteria will get a boost leaving the slower competitors behind. The mobile website is the preferred version that Google indexes, but the speed optimization takes care of both versions, mobile, and desktop. Of course, different metrics will show for each version as the requirements are different too.

To measure how much the speed improved, I use two of the most common speed measuring tools: Google Page Speed Insights and GTmetrix.com. There are more options like WebPageTest.org, Pingdom.com, all of them will show positive results.

Speed metrics will be different between mobile and desktop versions. Typically, mobile speed has more requirements, and websites with their current functions pose many limitations that you only find after accessing the backend. For example, not all website themes/templates are best for mobile even though they say mobile-optimized, but changing a theme is a drastic move and rarely an option. One has to work within the limitations posed by the client business decisions.

Check how the themes perform on this article.

Any website setup can be optimized for speed, be it e-commerce, Wordpress simple and Woocommerce, Joomla, Shopify, Squarespace, Drupal, CS-cart, Magento, Prestashop, HTML, PHP, etc. A disclaimer here: Not all websites can make it to 100/100 due to poorly coded templates/themes/plugins, wrong server setup, overloaded with plugins and not always necessary features, etc.

Themes nowadays are almost at the same performance level, it's plugins and WYSIWG/Drag&Drop page builders like Divi, Visual Composer, Elementor, WP Bakery, Wolf, Beaver Builder, Themify Builder, Site Origin, Nimble Builder, etc., plus their addons (it seems that a page builder is not bloat enough by itself), that create most issues. The equation that reduces speed is Page builders + Number of Plugins or just Number of Plugins. Suppose you do a test and take down your visual composer plus unnecessary plugins, the site could be 40-60p up right off the bat.

1. Get a number above 80/100, which is pretty good if you start low. Usually client websites' range from 15 to 40/100.

2. Make the website load at speed below 2 seconds (recommended by Google for best rankings).

Several interventions are required both on the server and the website code. Enable server caching when available, optimize website core files, reduce the number of plugins, etc. The work will not affect the aesthetics, how the website looks and reacts to human visitors.

Opt for a faster hosting: You can stay on the same price category of server, i.e., Shared server and find a host who doesn't share your hardware resources (RAM, CPU) with many other clients. Or you can upgrade to a VPS (Virtual Private Server) or the most expensive option buying a Dedicated (physical) server (suitable for eCommerce sites). Another option is to rent space on the cloud, which offers on-location.scalability and resources, while doesn't need server maintenance.

Use a CDN (Content Delivery Network): Your content is hosted on an array of servers in different locations and served from the closest geographical location. The result is faster loading times and no downtime.

Caching and Compression: Files can be cached and compressed on the server before touching any local files. The files are stored on the server (even for dynamic database sites) for faster loading time and saving resources (don't render with each request). The files change when you update the pages o each hit doesn't evoke a database request. This technique has excellent results, but not all servers offer many options. Plus, you need to have access to the server to enable them.

Javascript and CSS: Reduce HTTP requests caused by many individual JavaScript and CSS files. You may group JavaScript into one file and CSS files the same. Here is where problems come up. Some files should not be touched because they affect the way the website works and how it is styled, so extra attention is needed. To alleviate HTTP requests, we use the grouping, minify, and load in the footer techniques. Additionally, we employ Defer, Async, and DNS or Link prefetching methods. Best results you can get if you have access to the local files (on the server).

Web Fonts: Today, fonts are requested from their online storage places, and with each page view, the requests increase. The fonts are retrieved from their depositories, which takes a few microseconds or seconds that slow down the performance. You can reduce the web fonts, delay their loading, use the modern browser format of WOFF2, or store them locally.

Image optimization: Large image files slow down the performance. You need to reduce the file sizes without losing any quality. You can do that via compression and other techniques. Image file types (formats) also play a role. We also enable lazy loading, so images way below the visual frame let the content load and then come into the show.

Website Caching: There are many solutions to speed up Wordpress or other CMSs via plugins and hand-coding core files. For Wordpress, you might look for Cache plugins, but the devil is in details. Not all plugins will work for your setup, and some settings may even compromise the performance. You need an expert to tweak those settings, plus there's work to be done with the core WP files.

Database Optimization: Dynamic websites like Wordpress, Joomla, eCommerce sites, etc., store data in databases under the form of tables. Databases still use formats from 3 decades ago, and very soon, they reach their performance ceiling. You see, when you install a new plugin, what it does is go in your central database and inserts its data by creating new tables. But when you don't need anymore the plugin and you uninstall it, its tables remain in the database and burden it with no reason. Then, we have posts in draft mode, comments, post revisions, transient data, etc., that make it hard for the database to perform well. What you need to do is restore the database to its previous state and optimize further its performance.

Plugins: Sites over-loaded with plugins can never achieve optimal speed. We reach a ceiling each time we try to optimize with a lot of plugins active. The best thing to do is to reduce the number of active plugins to the absolute minimum for optimal website function and user experience. Plus, each plugin has individual requirements that don't respond well to optimization protocols, so it's better to remove it or replace it with a better one.

Redirects: As said above, HTTP requests should be kept low. Redirects increase the HTTP requests. We need to assess the necessity of each redirect and find a solution that's best for performance and SEO.

Clickfunnels is not going to be faster any time soon. They have serious speed limitations there. Check what you can do with your Clickfunnels landing page to increase its speed before it's too late.

Google is introducing the fast links labeling via the link context menu on Chrome for Android to help users identify great experiences as they browse. Labeling is based on signals from the Core Web Vitals metrics that quantify key aspects of users’ experience, as experienced by real-world Chrome users. The Core Web Vitals metrics measure dimensions of web usability such as loading time, responsiveness, and the stability of content as it loads, and define thresholds for these metrics to set a bar for providing a good user experience.

No, it won't improve the indexing. Core Web Vitals have nothing to do with page indexing and I would argue, contary to the propaganda found on the web, they have nothing to do with rankings either.