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:
https://video.eko.com/v/MY_PROJECT_ID?debug=true&profiler=true
The Profiler adds a tab to the debugger:
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:
Analytics reports count
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.
Decisions without defaults
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.
Interactions not sent
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.
Interaction report without id
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.
Large app size
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.
Large audio memory size
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.
Large image size
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.
Large intro size
Similar to the app.min.gz.js 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.
Large item in storage
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.
Large sound size
Readiness of assets in timeline based programming is extremely important for the overall experience. Large audio files should be avoided. Try to improve compression.
Long distance between checkpoints
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.
Low fps
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.
Low QoE
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.
Many download errors
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.
No sparkable nodes
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.
Node pushed on critical time
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.
Node with many prefetches
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.
Pushed node not in prefetch array
If a node can be played after another node it should be defined in its prefetch array. You should define it via Node.addPrefetch or via player.decision.add (depending on your implementation)
Save checkpoint called many time
If you have defined your own player.checkpoints.save calls make sure you meant to call them in the times specified.
Seek from short node
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).
Short decision duration
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 startTime and endTime options).
Short sparkable node
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.
Single prefetch not auto pushed
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.
Invalid sounds type
We recommend using mp3, m4a or webm format for sounds in your project, since it is widely supported on all platforms and devices.
Stats put called many times
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.
Unrecommended events listeners
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.