
Prevent skewed analytics when using Speculation Rules
I like the new Speculation Rules API which allows sites to prerender (potential) next navigations. But I'm not a fan of third parties loading right away.
Can't get enough? I'm regularly sharing snack bite tips and advice on LinkedIn as well.

I like the new Speculation Rules API which allows sites to prerender (potential) next navigations. But I'm not a fan of third parties loading right away.

This blogpost contains links from my last slide and will be updated to also include the PDF.

Let's support my previous claims by actually researching the performance impact of using a JS and CSS-only solution for headline text balancing

Whatever you do as a third party, there's an interesting nuance that we ran into with a Matomo implementation. The issue: the website was too quick.

INP will observe the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user's visit to a page. The final INP value is the longest interaction observed, ignoring outliers. But what does that mean?

Do you also just implement third party code without consideration? Here's a use case where it impacted user engagement and specifically the FCP metric by at least 445ms, based on a Webpagetest analysis.

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?

"Interaction to Next Paint", INP for short, measures the time between a user interaction (click, tab, type) and basically the visual feedback to a user. And it should be below 200ms.

Wordpress recently wrote about the performance impact of jQuery, but it seems like they are choosing to not call out the real pagespeed bottleneck.

To reduce page size plus your user's data usage and improve loading speed (depending on your audience) it is best to minify JS and CSS files. Fortunately, many developers or just plugins are already doing this by default. However..

Wait, what!? Obviously, I could name some great PWA solutions out there, but it wasn't always so. Today's case, migrated in November, is proving that you can build perfectly performant solutions, for real users, the traditional way.

A lot has been said and written about Google's AMP. I even implemented AMP in the boilerplate CMS that I use for own cases. But how about AMP and Core Web Vitals?

Alpine is lightweight compared to Bootstrap, jQuery, Vue or React. So, why the complaints, you wonder?

The sad part of third party chat widgets is that it really is up to chat widget providers to improve performance, caring about the performance of their clients' websites and webshops at the same time. But even when they don't, we can make a difference.

I wrote my own chatbot + livechat and this created quite some fuzz on LinkedIn. I even received swear words, luckily just for chatbot testing purposes 😅. But let's talk about the harm of chat bots such as Zopim (Zendesk), and how I visualized this.

Render blocking JS? Use Cloudflare Rocket Loader JS they said! But then Core Web Vitals came around, changing things 😕 However, Cloudflare Rocket Loader already came with a handful of pitfalls:

Sometimes a LinkedIn post of mine is leading to new questions as well. This time: "How do you get a high PageSpeed score when a site is using HTTP/2?"

Have websites been misusing push notifications? Website owners started to abuse push notifications with user complaints as a result. The idea was great, but now Google itself is stopping it.

Progressive Web Apps have quite some advantages. The biggest one being a web-product with a native-like feeling. But it is also fast and mobile first, or rather should be. This is the untold story about PWA, impacting your conversion.

As of version 2.3.3, Magento introduced CSS critical path. Users will experience a faster loading product-page when applied (correctly)!

Should you favor skeleton loading over spinner loading, and what would be the difference between building a PWA or server rendered website?