So, FID is only tracking delay during first interaction and didn't come with real nuances per stack. But what about the new INP metric and WP, Magento or SPA's?
Table of Contents
WordPress and WooCommerce
Improved FCP is more likely to lead to bad INP
And sometimes, JS is deliberately delayed in a quest to get an optimal lab data score, despite the fact that Lighthouse scores do not affect Google search / SEO. But delaying JS could mean it's only going to be executed when users start to interact. If during that moment, JS was actually still executing, then the paint action (as part of Interaction to Next Paint) could be delayed and could then be penalizing INP.
- Using RocketLoader, which I wouldn't recommend using;
- Or just relocating it to the footer.
Magento and third parties
SPA / PWA
There is legitimate concern when it comes to Single Page Applications, such as most Progressive Web Apps. The same way CLS is a concern as well. In the end, SPA's were the reason why the way CLS is being tracked, already changed by now.
Hard versus soft navigations
When it comes to Core Web Vitals, the important difference between SPA's and non-SPA's are their navigation type:
- navigating within non-SPA's are considered hard navigations. These are taken care of by browsers as these usually will taken place by following semantic hyperlinks;
- while navigations as part of SPA's are soft navigations. Developers or frameworks are trying to mimic browser behaviour instead. This already comes with additional SEO and UX challenges, but also with tracking challenges (even when using Google Analytics).
So, the summary is: When it comes to SPA's, browsers aren't able to differentiate legitimate soft navigations from non-legitimate soft navigations. Sure, you're changing the URL when the page changes, and some contents. But you just choose to replicate browser behaviour. How are browsers able to know for sure that you meant to perform a page navigation?
Google is actually working on a browser API so that frameworks are able to let browsers know when it's a legitimate page navigation. The next challenge is to have all developers and frameworks to implement such API. But once implemented, browsers will then know for sure that a navigation happened when receiving such API signal.
But for now, we might want to be aware of challenges in combination with SPA / PWA's as any INP issues could then be attributed to the very first visited URL, while users already navigated to another URL. The same currently still applies to the CLS metric, making it harder to debug this metric within SPA sites.
I actually wrote a multi-page article about the untold story of PWA's 2.5 years ago. And it seems like we finally have a metric to get a better understanding of the UX challenges.
Lightspeed, Shopify and INP
And during pagespeed audits, I've seen Lightspeed and Shopify shops with a lot of technical debt, which often just increased over time. But nevertheless, it's often plugins or apps that is the real offender.
Plugins or apps
A plugin called Yottaa Rapid JS was used to improve performance. But it was actually negatively impacting multiple metrics instead. Most of its JS was inlined, which can be good as you then got rid of a file download. But even inlined JS will be parse blocking. So detection of other important resources could be pushed back. That could then impact both FCP and LCP.
As a result, this is a good example of a plugin where the webshop owner expected it to help performance, but actually made things worse in multiple ways.
Laravel and Shopware (6)
We just weren't able to illustrate this until now. So once INP becomes part of the Core Web Vitals set of metrics, quite some Laravel or Shopware shops could then end up failing Core Web Vitals.