That's why the code in the example above doesn't specify preloading for the video/webm video. Instead, the best practice is to specify preloading only for the type the majority of your users are likely to actually use. Therefore, specifying preloading for multiple types of the same resource is discouraged. Note that for users whose browsers have both video/mp4 and video/webm support, if in that code a element were also specified, then both the video/mp4 and video/webm videos would be preloaded - even though only one of them would actually be used. That makes the video player hopefully smoother/more responsive for users who have video/mp4 support in their browsers. The code in the example above causes the video/mp4 video to be preloaded only in supporting browsers - and for users who have video/mp4 support in their browsers, causes the video/mp4 video to actually be used (since it's the first specified).

Set the correct Accept request headers for it.

Apply the correct content security policy to the resource.

Store in the cache for future requests, reusing the resource if appropriate.

Prioritize resource loading more accurately.Using as to specify the type of content to be preloaded allows the browser to: Resources that JavaScript can request, like JSON, imported scripts, or web workers.

Resources that are pointed to from inside CSS, like fonts or images.This example is trivial, as the browser probably discovers the and elements in the same chunk of HTML as the preloads, but the benefits can be seen much more clearly the later resources are discovered and the larger they are. Here we preload our CSS and JavaScript files so they will be available as soon as they are required for the rendering of the page later on. JS and CSS preload example bouncing balls HTML table advanced features and accessibility.From object to iframe - other embedding technologies.Assessment: Structuring a page of content.

Mean head google chrome logo