Fix your actual slow-loading assets with Resource Monitoring
One common method to address asset performance is using the local development environment to inspect production and observe slow apps in action. Some organizations might go a step further and analyze asset size as part of CI, or employ synthetic tests to identify issues.
As you can see in the walkthrough above, the Resource module displays all the assets that your website loads, along with their load duration and size information.
Most modern web development setups use bundlers like Webpack , vite, or esbuild to automatically add output bundles to served HTML. Monitoring the weight of these assets in your dist folder is challenging, especially since modern frameworks have preloading and chunking to lazy load built-in.
Using our resource monitoring workflow, the SyntaxFM team at Sentry discovered a 4kb render blocking script originating from a polyfill for the popover API.
It turned out there was no reason for this asset to be render blocking - so a fix was made to make the loading of this logic non-blocking, and we updated the polyfill docs to make it easier to not use the blocking pattern.
While asset byte size is an important metric for understanding page performance, it’s not the sole factor that determines page loading speed. Optimizing for filesize alone provides only a partial view — you also need to look at how resources are loaded, what pages they load on, and what functionality the resource has to understand if it really is a performance problem.
To cut through the noise and zoom in on problematic assets, you can filter for render-blocking resources and the pages they are impacting.
The screenshot above shows the resource summary page, providing helpful aggregate stats about a specific resource loaded by your site. By displaying resource size alongside duration in the displayed charts, you can directly correlate the size of a resource to its duration over time. This helps you to visualize the impact of bundle size optimizations you make (e.g. sometimes bundle size decreases might surprise you and cause no noticeable change in duration).
With Sentry, it’s easy to see how often a third-party script is used and how it’s affecting your site’s performance. In fact, we were able to discover that three of the top 5 most-used resources on the Sentry frontend were from third-party scripts we were loading.
Soon, we’ll be connecting the resource module with Sentry’s web vitals module, where you can easily identify when a resource is contributing to a bad LCP, FCP, or FID score. We’re also looking to add more network-related info to resources, including network timing information (e.g. time spent requesting a resource vs. time spent on the response for a resource and cache hit/miss information). This will help you understand if you need to optimize your networking/caching setup.
Loading resources can bottleneck your web app’s performance, especially with modern bundlers that obscure how resources are loaded and split up. Large or render-blocking resources aren’t always an immediate issue — you instead need to make a performance decision by evaluating how and where a resource is used alongside all its performance metrics.
Sentry’s resource monitoring makes it clear what your resources are, where they’re used, and how they are performing with real customers. This helps you prioritize the fixes that matter.