Embedding Player V4: Performance Troubleshooting

When using the debug player, the console will report two key metrics: Player Load, and Time-to-First Frame.

(PERF) PLAYER LOAD TIME: 8212.824951171875ms
(PERF) PLAYBACK START TIME: 2245.875244140625ms

These are key indicators of performance. The above indicates a major impediment to the player being able to initialize load resources and initialize (8.2s). The start time (aka time-to-first-frame) indicates the time took from the play start to frames starting to render on the video canvas. This is an extreme example where something is clearly delaying the player resources from loading, either locally in the page, in the local network, with the APIs the player needs to initialize, and/or with the CDN.

Very good performance would be below 500 ms for each of these metrics, and good performance is below 1s for each. Poor performance is above 2s for the player initialization. For start time, it has a large dependence on the CDN and processing profile (what bitrate is being loaded initially - the higher the bitrate, the larger the files needed to buffer before playback begins).

These timing metrics are built into our debug page directly, and no part of the player code itself. So these are only useful for seeing how the player is performing with a basic environment. If the same player and asset is performing much worse in a customer’s site compared to the debug player, then it indicates that the customer’s embedding is impeding one or both of these metrics.

We monitor these metrics broadly across our customers using Librato (10% sampling). These metrics are slightly different than the debug page because Librato can only start measuring after it loads in the page, whereas the debug page measurements are ready to measure before the scripts are even loaded. Regardless, we currently see the following from Librato:

Player Load

Player load has dependencies on a variety of things. These include:
  • Player embed type (Standard (single script), Advanced (script for each plugin), iFrame
  • Plugin initialization delays
  • API response times (SAS, Content Tree, Player Metadata)

While these things can depend on the surrounding page (i.e. competing for browser resources), in general, script embeds tend to result in a faster player load than the iframe embed, all things being equal.

If the player initialization is slow (takes time to render the poster), evaluate things like:
  • Can the player’s embed script be put higher in the page (i.e. header)?
  • Are there other things competing with the player APIs, or are those APIs slow to respond?
  • Are some plugins loaded much later in the page, and the initialization sequence needs to wait a long time (or is timing out) waiting for plugins to register?
  • If custom poster images are used, make sure they are small. They shouldn’t be more than ~50kb.

Stream Start (Time-to-first-frame)

Once the player is initialized, the time-to-first-frame (also called “join time”) is the time it takes a user to start seeing the video playing after selecting the ‘Play’ icon. Note that for an autoplay scenario, the Player Initialization and Time-To-First-Frame become a blended metric (for an end-user’s perspective).

In general, time-to-first-frame should be very fast if there’s no ad preroll involved, particularly if preloading is enabled. If prerolls are enabled, then the time-to-first-frame is controlled by the ad manager being used combined with the ad creative itself. Some things to watch for here:

If your content has no ads:
  • If content is slow to render, check if the you are seeing cache misses in the segment requests. It may simply be a matter of the CDN not yet being primed. If segments are requested from the origin, they will typically be slow (3s to load is common).
  • If cache misses are not happening, yet segments are still slow to respond, make sure the CDN in use has good coverage in your region.
  • Check the segment sizes. If you are using 10s segments, playback cannot start until the first full segment is downloaded (excluding CMAF-type streams). Using shorter segment sizes can help, particularly if the lowest bitrate available in the stream is relatively high compared to the network bandwidth.
If your content has ads:
  • Enable ad preloading, if possible
  • Check your Ad Manager dashboard metrics indicating specific ad(s) have issues. Poor ad creative (including non-standard compliance are common). Such ads should be blocked.
  • If using programmatic, check the number of redirects occurring in your ad requests. If more than 4 redirects are happening, performance will typically be poor. You can limit the number of redirects allowed to enhance performance, but it will mean a lower ad fill rate metric.
  • Consider enabling simultaneous ad and content loading. This allows slow ads to move from being in a strict pre-roll slot to having the player go ahead and start playing content until the ad loads, and then play the ad. While this may seem a bit jarring of an experience to watch the main content for a few seconds and then see and, it’s arguably a much better experience (and less likely to bounce the user) than watching a slow ad load in front of all content.
https://help.ooyala.com/sites/all/libraries/dita/en/video-platform/reference/pbv4_embed_performance_troubleshooting.html

Was this article helpful?