With asset trending you can:

• View a chart of backend performance trending over time for a single asset
• Add multiple metrics to the chart to compare performance at different stages of delivery
• View trending of changes in content size

How to View Asset Trending

Yottaa users can access this feature directly from the waterfall chart in any monitoring sample. The following is a typical use case of the feature, which demonstrates how to access and use Asset Trending.

The image below shows a slice of a waterfall chart for a popular music forum. The purple bar represents the load time of the tiny “Twitter” image that’s superimposed. The image took over half a second to load — far lonFger than most other assets on this page. We can use Asset Trending to see if this long load time is an isolated incident or part of a performance trend. Answering this question will help us make an informed decision about what steps need to be taken to improve performance of the asset, if any.

Each row in the waterfall represents an individual asset, and clicking the playbutton shape on the left side of each row reveals a dropdown showing detailed information. Here we find the “Trending” button.

The Trending button brings us to a new page where trending data will be collected and displayed. The page includes summary data (averages) and the trending chart.

Some important notes on this page:

• By default, the page will pull asset trending data from the past 72 hours. If you wish to view data from further back in time, click the text in the top right corner that says “Asset Performance Trending Available From [Date]”. This reveals a dropdown menu where you can select a date from which you’d like to see data, or select the option to view all data from the beginning of the monitor.
• You can revisit this asset trending page, and any others you create, by clicking “Your Assets” in the left navigation of Yottaa Site Monitor.
• Viewing this information does not count against your monitoring usage. It is simply a new way to access data that has already been collected on the asset.

Returning to our example, the trending chart reveals that the small “Twitter” image typically performs much better than the .5 seconds we first saw. The chart defaults to display Time to Last Byte, a metric that encompasses the total backend delivery time. In this view, it seems that the performance problem occurred for several hours before, but for the two days prior performance was smooth.

Not content with the three day view, we doubled the date range to show 6 days of data. With this expanded view we see that, while baseline performance is solid, spikes like the one we first observed actually occur on an almost daily basis.

Now that we know there is a recurring performance problem, we want to find out more. Clicking the “Edit Filter” button, we can add data from stages in delivery from the beginning of the process (“DNS Time”) up through “Connection Time” “Waiting time” and “Time to First Byte”. Each of these stages indicates the performance of different components or transactions that must occur for the asset to travel to the visitor’s browser.

DNS time: we see completely even performance (the DNS for this address had already been resolved when the HTML document was downloaded, so this is an expected result).

Connection time: There’s one big spike, but otherwise performance is consistent. This could explain a performance issue for that small time span where the spike is, but doesn’t explain the rest of the performance issues we saw.

Waiting Time: Bingo – at first glance it looks like these spikes in waiting time match up exactly with the ones we saw in “Time to Last Byte”!

To make sure, let’s add “Time to Last Byte” to that graph.

With one exception at the left side, there’s almost no difference between “Waiting Time” and “Time to Last Byte”. The two are so similar that one almost obscures the other on the chart. From this we can extrapolate that spikes in Waiting Time – that is, a lag between when a server connection is established and when the first byte of the image is sent along to the browser – is what’s causing spikes in overall performance.

With this information we can check out other assets on the site and look for this trend to be replicated. If we find that Waiting Time is an issue for other assets, and that such issues occur with some regularity, steps can be taken fix it. (Waiting time is caused by poor server performance, usually due to poorly configured or outdated server code).

Find YOUR Problematic Assets

The example shown above is just one of the many possible use cases for asset trending. Almost every web page has some assets that stick out from the others, meaning they could be worth investigating. Take a look and let us know what you find, and if there are features you’d like to see added to Asset Trending! We’d love to hear from you.