While developing your project you are probably using a powerful computer and a stable internet connection. This will not be the case after the project is published. Viewers are just as likely to use mobile devices with unstable internet connections.
The Profiler helps finding and identifying issues and bad practices implemented in your project. These types of issues affect viewers and are hard to find while testing your code on a powerful development machine.
To enable profiling just add the query string profiler to the url in addition to enabling debug mode. For example:
Different flows of your project may result different issues. It is recommended to run your project with the Profiler in all of its potential flows.
After each flow you ran with the Profiler you can click on the Summary button to see if you passed all the tests in that flow.
Here is a list of the main tests executed by the profiler:
Each interaction with content, interaction with controlbar, share and linkout must be reported. When you QA-ing your project make sure that for each one of these actions you see a report.
Decision without a default node will cause the project to end if no decision was actively made.
If you used Eko Studio in order to define decisions, and you got a report about not having a default node, use Eko Studio to set one.
If you defined the decision in code, see the player.decision.add API for setting a default node.
Each interaction must be reported, since many components rely on the interactions plugin events. If you’re implementing your own custom UI components from scratch, you must take care of sending interactions reports by calling player.interaction.report explicitly each time the user interacts with your UI.
Each interaction report should contain the id of the interaction. If you’re implementing your own custom UI components from scratch, make sure you pass the id when you call player.interaction.report.
Most of your project’s files are packed into a single file called
app.min.gz.js. If it is too big it will affect loading time for your viewers. Common pitfalls:
- Using external libraries that add a lot of overhead.
- Inlining binary assets as base64 strings in your code.
Audio files have to be decoded before they can be played back, and as long as a sound is loaded, the decoded buffer is kept in memory at runtime. These decoded buffers can easily get huge and can cause an iOS Safari tab to instantly crash.
If you see this issue you can manage the loading and unloading of your sounds.
Readiness of assets in timeline based programming is extremely important for the overall experience. Large images should be avoided. Try to reduce resolution, use vector images or improve image compression.
Similar to the
intro.min.gz.js includes the logic needed for the intro. The size of this file should be as small as possible, as no video is seen by the user until it finished loading.
A common pitfall would be using external libraries that add a lot of overhead.
Reading and writing large objects from and to the storage can cause performance issues. If you encounter this issue see if you indeed need everthing you save or it is possible to save less data.
Readiness of assets in timeline based programming is extremely important for the overall experience. Large audio files should be avoided. Try to improve compression.
Checkpoints allow users to go back and forth between scenes in your project.
If you see this issue it means that you have two checkpoints with more than 2.5 minutes of time in between. You will want more granular disbursement of checkpoints in your projects.
You can use the checkpoints.save API in order to add more checkpoints in your project.
The browser fps can be affected by many things such as inefficient code, complex animation rendering and more. This is especially true for less performant devices. If you encounter this issue at similar time points in your project, investigate what in your project might be causing the performance issues at those point. If you see this issue throughout the session it may be a broader issue in the implementation of your project.
The qoe stands for “quality of experience” and it is affected from fps and buffering percentage during the session. Like with the previous fps issue, you should investigate your project’s implementation with the issue timing serving as a guide and a clue.
This issue can hint at too many download calls at the same time. Check to see if perhaps you’re downloading something unnecessary or too early in the project.
If you don’t have any sparkable nodes, you need to define where sparks should be placed via the sparks plugin API, see: player.sparks.attach.
For best performance it is better to push nodes to the playlist as soon as you know they should be played. Investigate in which point in the project did this issue occur and examine whether can push the node earlier to the playlist.
The prefetch array of a node is used by the player for downloading the next possible videos to follow that node. If there are too many the player might not be able to download all of those in time. See if the high number of prefetches is really necessary. Perhaps you can split the parent node in order to split the number of prefetched nodes.
If you have defined your own player.checkpoints.save calls make sure you meant to call them in the times specified.
Lots of seek calls from short nodes can cause a performance issue since the player may not have enough time to download the node you seek to. See if you actually need these calls. If you do, a possible solution might be be to add the node you seek to as a prefetch to previous nodes and not only to the short parent node (see: Node.addPrefetch).
When a decision is too short it will not give the user enough time to make the decision. It is advisable to make the decision duration longer. You can do so via Eko Studio (if that’s where the decision was defined)
or via player.decision.add (see
At the beginning of a sparkable node the player calls our sparks service to bring the relevant spark dynamically. If the sparkable node is too short the player may not have enough time to download the spark and push it to the playlist. In this scenario the spark won’t be played. Consider whether the spark must follow the short node. If it does, see if you can concat the short node’s video with the previous node’s video to have longer sparkable node.
If a node has only one prefetch node in its prefetch array it means that is the only possible node that can be played after that node. In that case it is better to push it immediately to the playlist. If you see this issue you probably didn’t use the decision plugin or you have your own custom decider function without that functionality.
We recommend using mp3, m4a or webm format for sounds in your project, since it is widely supported on all platforms and devices.
If you have used the stats plugin and you call player.stats.put method make sure you meant to call it in the times specified.
It may be more than one way to implement a requirment for your project, sometimes one can be better than the other. Pay attention to warnings and their recommendation.