Sentry Issues 突然出现“Large Render Blocking Asset”和“Uncompressed Asset”

Question

Large Render Blocking Asset /
New Issue
/static/js/main.779fa2a0.js

Large render blocking assets are a type of resource span delaying 
First Contentful Paint (FCP). Delaying FCP means it takes more time 
to initially load the page for the user. Spans that end after FCP are 
not as critical as those that end before it. The resource span may 
take form of a script, stylesheet, image, or other asset that 
requires optimization. To learn more about how to fix large render 
blocking assets, check out these resources:

https://web.dev/fcp/

在 Sentry 中从未收到过此错误之后，突然间我们在应用程序的最后一天收到了 20 个这样的错误。我们的网站 https://cbbanalytics.com/ 没有最快的主页加载速度，但我们在最后一天没有更改任何会导致此问题的重大内容。进一步解决此问题以解决问题的推荐方法是什么？

编辑： 也许这个问题是最近添加到 Sentry 的，这就是为什么我们没有更早收到这个问题的原因......

Edit2： 我们也突然在 Sentry 中遇到了很多

Uncompressed Asset

问题。 Sentry 是否将这两个都添加为要跟踪的新问题？

Resources and Whatever
Uncompressed assets are asset spans that take over 500ms and are 
larger than 512kB which can usually be made faster with compression. 
Check that your server or CDN serving your assets is accepting the 
content encoding header from the browser and is returning them compressed.

这两个问题都是引用文件

/static/js/main...

，这让我认为这些问题可能与我们整个Web应用程序构建太大有关？我们如何开始解决这个问题？

Answer 1

我认为这与您的构建大小无关，而且您也不想忽略它。

您可以使用 PageSpeed Insights 查看一些细节。它会在 2.7 秒时显示您的 First Contentful Paint，最大时在 5 秒，并提供一些建议。我相信这些是在3G网络速度下测得的。该页面看起来非常活泼，但是一旦我将速度限制为快速 3G，它就更加明显了。

您有一些需要一段时间才能加载的大图像。我注意到着陆页上的一张 4.4MB 和一张 2.5MB 的图片可以显着减少。这些是最近添加的吗？这可能是刚刚触发 Sentry 的原因背后的一个小变化。

我还注意到从 api 返回了绝对大量的数据。 Insights 也注意到了这一点，并显示网络有效载荷为 18,227KiB。这些数据中的大部分似乎都没有在任何地方的着陆页上使用。分解这些请求，以便它们仅在必要时触发，并在可能的情况下考虑对它们进行分页。

我认为这会让你在减少 FCP 时间和消除哨兵错误方面做得很好。