There are many possible ways to improve your Core Web Vitals and web performance. But also some myths that we like to debunk, so you can get started with the right knowledge to make your own website faster.
Myth 1: Hosting is the key to improving core web vitals
Some people think that all Core Web Vitals metrics like Interaction to Next Paint (INP) and Total Blocking Time (TBT) are directly influenced by their hosting provider, they are not. The primary factors affecting these metrics are the amount of JavaScript running on your site and the capabilities of the devices your visitors are using, particularly memory. Instead of switching hosting providers, focus on optimizing your JavaScript and considering the limitations of various devices.
When you're suffering with a high Time to First Byte it's recommended to look into the hosting. Checking if your hosting has enough power for your needs and is configured properly.
On the screenshot below you can see a case where one of our clients upgraded their hosting and got help with their configuration thanks to Hypernode.
Myth 2: More pages equal slower performance
Having a larger number of pages doesn't directly impact your Lighthouse or Core Web Vitals scores. In fact, a higher page count can lead to increased pageviews, providing sufficient data for analysis in your Search Console. This, in turn, can benefit your SEO efforts as search engines gain a better understanding of your website's importance and authority.
Myth 3: Image size is everything
While it's crucial to keep image file sizes as small as possible for optimal performance, adhering to a strict 100kb limit may not always be feasible. Remember, website performance isn't solely about the amount of data loaded but also how it's loaded. Performance is influenced by various factors, including how you deliver your content and the location of your audience.
Google wrote an amazing article about the common misconceptions about optimizing the Largest Contentful Paint.
"I've optimized my image, I'm done all/the main thing I can do to make this better" is a narrative we'd like to change.
Barry Pollard, Web Performance developer advocate at Google
Myth 4: Lazyload all images
Lazyloading has gained popularity, especially on platforms like WordPress, but it's essential to use it judiciously. Lazyloading a Largest Contentful Paint (LCP) element, such as a hero image, can negatively impact LCP performance. Similar to using a background image for hero images, lazyloading LCP elements and elements above the fold (that people can see without scrolling) can hinder both performance and user experience.
On the image below you can see what impact having loading=lazy on your LCP image has, almost 400ms.
Myth 5: HTTP/2 and HTTP/3 Solve Everything
With the introduction of HTTP/2 and HTTP/3, the number of requests is no longer the sole concern when it comes to speed. While monitoring for 4xx and 5xx errors remains important, these protocols have alleviated some of the negative consequences associated with a high number of requests.
Having too many request remains a thing, however we tend to get away with it a bit more. Over the last 3 years we've barely made any changes in the way we deal with the amount of requests as can be seen on the HTTP Archive.
Myth 6: Removing Unused CSS and JS is a quick fix
Eliminating unused CSS and JS files is often considered an effective way to boost performance. However, this process can be time-consuming and carries the risk of breaking functionality on other pages. Carefully evaluate the impact of removing unused code and consider alternative approaches that yield similar results with less risk.
If you're dealing with really large bundles it's definitely something that needs to be done, but on many bigger projects that never considered this it's a big project that needs time and love.
