Development related Core Web Vitals FAQ

Can I hack, mislead or deceive Core Web Vitals?

Probably not in such way. Obviously you could create very lean pages for Google's PageSpeed Insights testing, resulting in optimal "Lab data". However, it is the "Field data" that counts towards Google ranking and you can't hack the devices and network conditions of your visitors. You could implement best practices though, helping your overall score as well as real users.

For example, you could choose to also serve lean pages to real visitors. This is more of a best practice than hacking though, as lean pages are good for real user experience, which eventually is the purpose of Core Web Vitals.

Do I need better hosting to pass the Core Web Vitals?

Some platforms require very specific knowledge and architecture, such as Magento. However, most hosting companies (especially within The Netherlands) are often doing a good job already. Due to CPU boundaries of smartphone devices, the frontend code as produced by platforms and developers play a bigger role. Moreover, Core Web Vitals really is about user experience instead of pagespeed, so it often is a matter of frontend coding.

Hosting might not be the number one bottleneck when not passing Core Web Vitals yet, but as the TTFB is the starting point of all, hosting shouldn't be overlooked.

How to check if hosting or CMS is a bottleneck?

When Chromium could collect sufficient visitor data for your website or webshop, you can consult the free CrUX reporting to view historical TTFB data and detect changes and patterns. For example, when LCP patterns are the same as TTFB patterns, chances are that TTFB is the main bottleneck, impacting the LCP as well.

Does the e-commerce platform I'm using make a difference?

It is quite likely that the platform your company is using as a webshop or website solution is making a difference. For example, some content management solution might request all hosted resources, even unused resources on specific pages. Other platforms might always insert resources in the head without any performance strategy in mind, creating render blocking resources.

As a result, some platforms will give your developers a harder time to pass the Core Web Vitals, but it is achievable, no matter the platform.

Can we optimize within SaaS solutions?

Although SaaS solutions are closed source and only allow for frontend changes using templates and other resources, it is still possible to optimize for Core Web Vitals. I once optimized a site where no server side changes could be made. In my case, this meant no HTTP/2 and no next-gen WebP images. Nevertheles, we scored a 95% on mobile and the website was passing the Core Web Vitals.

However, most agencies creating templates, often create them in the same way. As a result, same mistakes can be seen within the average SaaS webshop, such as Lightspeed, Shopify, BigCommerce. This is where the role of in-depth developers or consultants such as myself are playing an important role.

Can I fix it with plugins?

Some of your performance and UX issues could be fixed using plugins. This might introduce new anti-patterns though. For example:

  • most plugins for inlining critical CSS often only include partial CSS, resulting in increased layout shifts;
  • most plugins for deferring JavaScript will result in deferred or delayed JavaScript execution. However, when JavaScript is responsible for the largest elements within the viewport, this may result in a poor LCP;
  • Even today, (JavaScript) resources are still bundled by plugins or even platform. This may result in decreased FID.

Moreover, with every new plugin chances are that you are unwillingly and unwittingly increasing the server response time and thus TTFB, pushing back the LCP metric even further. So, when you do choose to fix issues with plugins, keep a close eye on the impact on real user experience and metrics.

Can my agency/developers make a difference?

As frontend architecture and thus HTML, CSS and JS are responsible for the work a browser has to do, this very same frontend code will have its influence on the metrics. As a result, your developers are the ones that will have to do the coding, where CRO or SEO specialist are often the ones pushing for optimization work.

Obviously, one platform will allow more room for improvements than other platforms, but your developers should still be capable of optimizing for improved Core Web Vitals and conversion.

Should I choose PWA / CSR?

As always: it depends. Yes, Google engineers did come up with service workers, also part of PWA. At the same time, they always vouched for using only necessery JavaScript. Even Alex Russell, one of the founding fathers of PWA.

In the Technical section, I re-used Google's description of factors that could impact the three Core Web Vitals metrics. In each metric, JavaScript will often play a role as well. Rendering and layout work as done by the browser can only be done after JavaScript has been downloaded, compiled, parsed and executed. Keep a close eye on the impact on real user experience and metrics when moving to Client Side Rendering (CSR) such as the average PWA.

Rather have the full insights? Read about PWA and its technical implications.