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 中遇到了大量未压缩资源问题。 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 应用程序构建太大有关？我们如何开始解决这个问题？
最佳答案
我认为这与您的构建大小无关，而且您也不想真正忽略它。
您可以使用 PageSpeed Insights 查看一些具体信息。它显示您的第一次内容绘制用时 2.7 秒，最长时长为 5 秒，并提供了一些建议。我相信这些都是在3G网络速度下测得的。该页面看起来相当活泼，但一旦我将速度调至快速 3G，它就变得更加明显。
您有一些大图像需要一段时间才能加载。我注意到登陆页面上的 4.4MB 和 2.5MB 图像可以显着减少。这些是最近添加的吗？这可能是 Sentry 刚刚被触发的一个小变化。
我还注意到 API 返回了绝对大量的数据。 Insights 也注意到了这一点，并显示网络有效负载为 18,227KiB。大多数数据似乎没有在任何地方的着陆页上使用。分解这些请求，以便它们仅在必要时触发，并在可能的情况下考虑对它们进行分页。
我认为这将帮助您减少 FCP 时间并消除 Sentry 错误。
关于Sentry 问题 "Large Render Blocking Asset"和 "Uncompressed Asset"突然出现，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/75644281/