AI-Powered waterfall chart analysis: fix the right requests first

Knowing your page is slow is the easy part. The harder part is knowing which of the 80-odd requests on a typical product page is the one worth fixing first, and what specifically needs to change. The AI analysis built into the browser waterfall in Niteco Performance Insights is designed to answer both questions.

This article covers what the AI analysis does, how to run it, and how to read the output so you can act on it.

When you run a performance test in Niteco Performance Insights, the waterfall records every request the page makes: the URL, HTTP status, file size, timing stages (DNS, connect, wait, download), and the order requests fired relative to each other.

The AI analysis reads the full request dataset and looks for patterns that indicate problems. It flags things like: images being served without compression, scripts loading synchronously that could be deferred, third-party calls with unusually high wait times, large files without cache headers, and requests that appear to be blocking rendering based on their position in the load sequence. Each flag is attached to the specific request that triggered it, not surfaced as a generic list of best practices. That specificity matters.

A Lighthouse audit will tell you "eliminate render-blocking resources." The waterfall AI analysis tells you that vendor-analytics.js loaded from a specific domain at 340ms, blocked the main thread for 1.2 seconds, and can be deferred.

Once the analysis finishes, some request bars will show a badge. Not every request gets one. The badges appear only where the AI found something worth flagging, which keeps the output focused rather than overwhelming.

Click on a request bar with a badge to open the request detail panel, then open the Recommendations tab. You'll see AI-generated fix suggestions for that request, for example how to compress an image, defer a script, or reduce the impact of a third-party call.

Each suggestion includes enough detail to act on. It will typically identify the problem type, the impact on load time or rendering, and a recommended fix.

The suggestions are attached to individual requests, but the order in which you tackle them matters. A few things to look at when deciding where to start:

Render-blocking requests come first. If a script or stylesheet appears early in the waterfall and has a long bar, it holds up everything that loads after it. The AI analysis will flag these, and fixing them often has a disproportionate effect on Time to First Byte (TTFB) and Largest Contentful Paint (LCP), both of which directly affect user experience and search ranking.

Large files with no cache headers are quick wins. If an image or script is being downloaded in full on every visit because there are no cache headers, adding a Cache-Control policy reduces repeat load times without touching the asset itself. Low effort, measurable result.

Third-party requests require a different conversation. The waterfall groups third-party requests by vendor when you have that setting enabled. If a vendor's scripts are adding 600ms to your load and you have a suggestion on them, the fix may mean loading them asynchronously, delaying them until after interaction, or having a broader conversation about whether the vendor is worth the cost. The AI can recommend the technical change; the business decision sits elsewhere.

The AI suggestions work best read alongside the other data the waterfall shows. A few combinations that are useful in practice:

The Summary tab on a flagged request shows the timing breakdown for that specific request: DNS, connect, wait, and download. If the AI flagged a slow request and the Summary shows most of the time is in the wait phase, the problem is server response time, not file size. That points to origin server performance, CDN configuration, or a backend query rather than a front-end optimisation. 

The Performance History chart in the same report shows how metrics like LCP, TTFB, and CLS have moved over time. If a metric deteriorated after a specific deploy, pulling the waterfall from that test run and running the AI analysis on it can surface what changed. A new marketing script, a newly added font file, an image that lost its compression during a CMS update — these show up as new or changed requests. 

The Content Requests and Content Sizes graphs break down how many requests each resource type generates and how much data each type transfers. If images account for 70% of your total page weight, that context reinforces why image compression suggestions from the AI should sit near the top of your fix list.

The AI analysis in the browser waterfall gives you request-level diagnosis: which files are problematic, why, and what to change. Run it from the star icon in any waterfall toolbar, look for recommendation badges on specific requests, and use the Recommendations tab alongside the Summary timing breakdown to understand both the fix and its root cause. Start with render-blocking requests, move to cache and compression wins, and use the Performance History chart to tie regressions to specific deploys.

Run a test on your site with Niteco Performance Insights and see what the waterfall surfaces.