All About E-v1.js

What is E-v1.js?

In the simplest terms possible, E-v1.js, or "E-v1" for short, is the Wistia player. More specifically, it's the Wistia JavaScript library which loads all the player code, builds the player on a webpage, and enables you to access all the player features that Wistia has to offer. It looks like this:

<script src="https://fast.wistia.com/assets/external/E-v1.js" async> </script>

E-v1 is included in the HTML of any Inline or Popover embed code you copy from Wistia. This makes it pretty easy for E-v1 to get onto your page and do its thing. However, E-v1 can often be modified or removed by a content management system (CMS) or site building app, particularly within WYSIWYG/visual and rich-text editors. Sometimes it is removed manually for a custom implementation. When this happens, things can break and expected behavior can go out the window 🍃.

🚫

Alert

The first rule of E-v1.js: do not self-host E-v1.js. This script is specifically set up for embeds to receive updates in a timely fashion. Self-hosting or making static copies of this script will mean using out-of-date code within days or weeks. If E-v1 falls out of date with player code loaded asynchronously (of which there is a lot) and server side code, embeds could totally stop functioning on that site.

Let's talk more about why E-v1 needs to be on the page in the first place, and how we can make sure it gets there.

Why is E-v1.js important?

For most of our embeds, E-v1.js is essential for the Wistia player to function. If you're using an Inline, Standard or Popover embed code, the player will not appear on the page at all if E-v1 is missing. When a webpage loads, E-v1.js needs to be there to build the player, deliver your video files and thumbnail, and include any customizations or plugins you've chosen for the video. It also controls any integrations you have set up for lead capture and tracking, and much more.

Generally speaking; no E-v1, no Wistia player.

E-v1 and iframe Embeds

There is a slight exception to the above rule; the Fallback embed, which is an iframe-based embed code, can still mostly function without E-v1.js on the webpage. Iframes are essentially another HTML document within your main webpage. This means embedding with the Fallback embed type is akin to embedding a window to another page with a Wistia player and your video.

Here's an example of an iframe URL or iframe src, which is the page displayed within an iframe. If you click on it you can see it's just a page with a player:

https://fast.wistia.net/embed/iframe/bl2upaub45

These iframe URLs already include E-v1.js on that external page, which means that even if E-v1 is stripped from an iframe embed code or from a page with an iframe embed on it, you can still get a player on the page and the basic player features.

However, there are still some key limitations that apply when E-v1.js is missing from your webpage, even with a Fallback/iframe embed. They pertain to features that rely on E-v1 being there for various on-page interactions or page-specific functionality.

Without E-v1 on your webpage, these features will not work as expected:

• Google Analytics
• Marketing Automation Integrations (Hubspot, Marketo, Pardot)
• JavaScript Player API
• Domain Restrictions

E-v1 FAQs

Do I need E-v1.js more than once per page if I have multiple videos?

Good news, everyone! E-v1.js only needs to be included once per page with your videos. If you had 50 videos embedded on one page, you'd still only need a single instance of E-v1.js on that page, and all the videos would still function (disclaimer: we'd really recommend against having 50 videos on one page due to speed concerns, but you do you).

We include E-v1 with each embed code to ensure it gets onto the page at least once. If you did have 50 copies of E-v1 on a single page (again, not recommended) it would only execute once. Removing the duplicate snippets of code is mainly an optimization for the amount of total HTML on the page, though it will also cut back on those extra instances of E-v1 simply checking to see that initialization has already happened with the first. The performance gains won't be huge, but you will slightly decrease the total size of the loaded HTML document and code running on page load.

Why is E-v1 making so many network requests?

As mentioned above, E-v1.js controls the whole Wistia player. Whether it's building the player on the page, delivering video files, collecting stats, displaying your customizations, et cetera, you'll probably see a lot of network activity coming from E-v1, especially if the page has more than one video. This happens for a few good reasons.

Async and Deferred Loading:
E-v1's network activity should all be asynchronous, meaning it won't block or slow down other page elements from loading at the same time. A lot of this activity is also deferred based on other important page elements being loaded in. Some aspects of the player are also lazy-loaded, for example the volume slider is only loaded when you first hover on the volume control.

Contextual Plugin Loading:
You may see additional .js files being loaded by E-v1. These are the customizations and plugins you've enabled for the video. By separating these features into plugins, we can conditionally load those things you need, and exclude any that you've left out. For example; a video with captions will load captions.js, and one without captions will not.

Adaptive Video Streaming:
Our default video delivery mechanism, HTTP Live Streaming (HLS), serves video files in small chunks or blobs. These chunks are small pieces of the video delivered in .ts file format. By breaking the video into small pieces, we can easily switch video quality mid-playback, by hopping to the next chunk at a higher or lower quality level, and do so dynamically based on the viewer's connection.

Each chunk is its own request that's much smaller than a full video, so you will probably see a lot of these during playback. This is especially true for autoplaying videos, which will start serving chunks of the video as soon as the player is loaded on the page.

I think E-v1 is slowing down my webpage, how can I optimize it?

Questions about E-v1 and page speed are often inspired by 3rd-party auditing tools which suggest optimizations for load times and/or SEO benefit. While these can be informative, there are several consistent suggestions from some of the more common auditing services for which we can add some context. The questions below should help.

Why isn't E-v1 cached for more than 1 hour?

One common recommendation from page speed audits is to "leverage browser caching", aka increase the time that E-v1.js and other Wistia assets remain cached in the viewer's browser so they don't need to be frequently re-loaded. The context piece that is missing: E-v1 is intentionally kept on a 1-hour caching expiry time so that any updates to the Wistia player will be quickly delivered to all embeds in the wild. This is especially important for bug fixes and security updates being applied in a timely fashion.

onload vs finish time

If you're looking to audit your page speed or generally optimize for load times, we recommend using the browser window.onload / Window: load event as the metric:

The load event is fired when the whole page has loaded, including all dependent resources such as stylesheets images

(source: https://developer.mozilla.org/en-US/docs/Web/API/Window/load_event)

The load event represents when the visitor can actually see and interact with the page.

This example is a page with just a Wistia embed. Notice the stark difference in the load time vs finish time. E-v1 has a lot of jobs to do!

As a contrast, fully loaded time / finish time is a different metric sometimes used by auditing tools. This represents the time that all network activity has ceased, including async background activity with little or no visitor-facing impact.

The player is often doing tasks in the background such as loading video files, collecting stats, or capturing integration data, so fully loaded time will always be inflated due to immediate loading of video files in the background. Thus onload will provide a better picture of how quickly the page loads for your visitors.

Do you have a minified version of E-v1, or can I host my own copy?

This is a question so important we answered it twice: self-hosting E-v1 is a "big no". E-v1.js is already heavily minified and we continue to optimize and compress that file for super fast loading times. Paired with E-v1's regular updates, any self-hosted or copied versions of our script will quickly become out of date.

If you are using a self-hosted copy of E-v1, that's considered unsupported code. It will also quickly fall out of sync with code that is loaded in asynchronously (there's a lot of this) and server side code, which means at a certain point embeds could totally fail to load. If something breaks, or if you need support with an embedding or playback issue, the first suggestion will always be to replace the self-hosted E-v1 with the Wistia-hosted, up-to-date version. We won't be able to troubleshoot issues with out-of-date code, plus it's so much easier to get all the updates automatically.