Whether you have your JavaScript running in a render-blocking context, or if it's delay loaded in some way and gets evaluated after the rendering of the page has begun, it will still affect front-end performance.
That is because in the render-blocking phase it will increase the time until rendering starts, while when evaluated at a later time, it will interfere with the user's ability to interact with the page, possibly creating long-tasks and increasing your TBT score.
Aside from the evaluation time, an arguably bigger cause of front-end performance problems is the transfer size. That is because due to network latency we are likely to see delays that are longer than the evaluation itself.
This is particularly bad if the scripts are render blocking, which is why we want to make sure that scripts are minified and compressed.
fig. 1
download time vs evaluation time
To obtain this data, I have run over 6,000 tests on the top 1,000 client-side libraries via PageGym in desktop mode, so the evaluation time has been extracted in the same conditions in which regular page speed tests are being performed.
The actual evaluation time for your users will depend on the hardware and browsers they are using, as well as whether you are using any type of tree shaking or if you are cherry-picking library sections, but this dataset should give you a decent and stable starting point when assessing JavaScript library weight.
All the packages are built and minified. The ones that come prebuilt and preminified are left as is.
If there's a specific library that is missing from the dataset, drop a message to the email address in the footer with your request, and if it can be included I will add it to the list.
Similarly, if you notice an issue in the data, let me know and I'll look into it.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。