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
WordPress is known for using a lot of JavaScript. And although we reached 2022 already, most JavaScript is still embedded in a render and parse blocking way, massively impacting WordPress performance.
Render blocking JavaScript will decrease chances of high INP
But at the same time, its render blocking JavaScript might save WordPress when it comes to the INP metric (as well as FID metric by the way). As the browser isn't able to render anything yet anyway, it will delay the FCP. At the same time, it is allowing the browser to already execute theme and plugin related JavaScript.
And while looking at a white screen (due to the render blocking JavaScript), users will be less likely to start any interaction yet. So chances of an input as well as input delay will decrease.
Do note that this situation isn't ideal either, as you actually want optimal early user engagement, but then just with an optimal JavaScript hygiene on top of it. So you actually want both a good FCP and INP metric score.
Improved FCP is more likely to lead to bad INP
One should actually want to defer all JavaScript to improve the FCP metric. But other metrics such as CLS, FID and soon INP is then more likely to regress. Just because issues are more likely to happen and to be noticeable as the page already got a chance of being rendered, and users being more likely to interact with the page in time.
Another common strategy within WordPress site where developers find it hard to optimize, is inline most or maybe even all JavaScript and CSS. I strongly advise against doing this in the first place. But by using plugins, it's way too convenient to implement such a strategy.
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.
Magento
When it comes to INP, Magento isn't that different from Wordpress when looking at the very basics. JavaScript usually is render blocking in both of them, but there are different ways of deferring JavaScript already:
- Using RocketLoader, which I wouldn't recommend using;
- Custom type attributes (basically how RocketLoader works as well), by changing JavaScript into
text/x-magento-init; - Or just relocating it to the footer.
When doing one of the above, FCP and maybe even LCP will often improve. But just like with WP, chances of a bad INP is likely to increase when deferring JavaScript. But even when not deferring, Magento will execute a lot of smaller files later on. This won't help chances of passing INP. So with, just like most platforms out there, JavaScript should be put on a diet.
Magento and third parties
I should add though that although Magento isn't the textbook example of optimal JavaScript usage, I always see a lot of third parties going on as well when doing Magento audits. Next to Magento's 1st party JavaScript, quite some performance wins can be found within third party JavaScript usage as well. And that will often be easier to address too to eventually improve Interaction to Next Paint.
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.
All-in on JavaScript
When building an PWA or just SPA, chances are a lot of rendering happens in the browser, client side. To achieve this, JavaScript is needed. However, we already had enough of that. For example third parties. And even non-SPA sites and shops will be using JavaScript for interactive elements and actions, such as adding products to cart or creating an image gallery.
So, when building an SPA, even routing will be done using JavaScript. Heck, everything will be done using JavaScript. And a PWA almost never comes alone: frameworks are just to improve developer experience and development time.
And this JavaScript combination then becomes a challenge. More JavaScript means more tasks that makes it more likely that the main thread of the browser is going to be blocked. And this is a massive risk towards the "Interaction to Next Paint" metric.
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
When it comes to performance, I'm often able to mention Lightspeed and Shopify in one sentence. Both are SaaS and one can use plugins, called apps, in both solutions. And both are server side rendered with additional JavaScript for a bit of interactivity.
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
In general, plugins and apps can introduce quite a bit of (long) JavaScript tasks. But there was one situation during an audit that surprised me the most.
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.
But this Rapid JS wasn't even needed. The purpose was to divide third parties into priorities. However, Google Tag Manager was used as well and could be used to achieve the same. So, they installed a plugin to achieve something that could've been achieved with other JavaScript (GTM) already. And this would only add up to already main thread blocking JavaScript.
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)
I once covered Shopware 6 and Core Web Vitals before in an article after doing a Shopware 6 audit. But the INP metric obviously didn't exist yet back then. And what I often see within Laravel and Shopware 6 is JavaScript being deferred by default. That's a good start. As a matter of fact, most performance issues within these platforms are often caused by third parties.
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.
The fastest solution often is to mimic third parties, such as chat widgets. This is called third-party facades. But don't forget to put 1st party JavaScript on a budget too, as shops themselves keeps growing as well and no user is browsing the web under the same conditions and expectations.
