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?
Can't get enough? I'm regularly sharing snack bite tips and advice on LinkedIn as well.
I've selected my most popular LinkedIn post of 2022. It might be convenient of you if you're not following me yet, or just didn't had the chance to read up on all of them.
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.
You think it would be clear to everyone that the Tower of Pisa is shifted. However, it also depends on the point of view and angle. The same applies to CLS as well: different conditions will result in CLS happening at different moments. Let's discuss toolings you can use to track CLS.
HTTP/2 is already around since 2015. Heck, HTTP/3 even got standardized as of June 6th 2022. So why even bother talking about HTTP/1?
We all get that woff2 is smaller than woff, or ditching custom fonts comes with best performance. But what are considerations if you really want to use custom fonts?
If you're concerned about the loading experience of your custom fonts, you might have run into the WebFontLoader. A 10 year old library. Should you still use it today.
If optimizing was only as simple as adding a few attributes. But this time, it really is and it's even easier to use than image preloading.
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.
Server side caching means that some form of caching is done server side. And from a pagespeed perspective, it makes most sense to do this for contents that tends to be dynamic. Let's dive into the basics of server side caching a bit more.
In general, people know that I'm not the one to ask which plugins to use for their stack. However, given the fact that I'm a pagespeed and performance enthousiast, I'm sometimes asked which plugins people should be using.
While two completely different things, there actually is a correlation between pagespeed and accessibility.
Even clients that are convinced they should work with me, still want to know how a collaboration and an auditing trajectory is going to look like. This article is giving background information.
We've all heard of the 'eliminate render blocking resources' recommendation in Lighthouse. But to understand why it is important to fix this, it first is convenient to know a few basic principles of browsers.
A platform can take a long time to generate a webpage. But when the content is cached, TTFB and users will benefit, but the first user accessing new contents will pay a penalty. How to prevent this and improve the cache hit ratio?
Rarely can you increase your PageSpeed with a single line of CSS. Today, though, I will share two separate CSS lines of code that will improve pagespeed and performance.
I've seen pagespeed audits where Google Analytics' Average Page Load Time was used to determine bad performing pages and claiming the webshop was missing revenue. However, pagespeed is more nuanced.
WordPress started a performance team to improve its Core Web Vitals scores. I read their pagespeed optimization spreadsheet and boy do I have an opinion regarding their performance backlog.
Google hasn't been sitting still. Both LCP and CLS have been seeing drastic changes already, so why not changing the FID metric?