Lighter Youtube Embeds

[oyeanuj]

Hi @cookpete, back again!

One of the issues that I've been facing on my site is that even having a single Youtube embed on a page can really slow down the site. On researching further, it seems like Google+ and others use a slightly different technique for not loading Youtube videos by default, and instead only on click using the methods described below:

1. https://www.labnol.org/internet/light-youtube-embeds/27941/
2. http://www.skipser.com/p/2/p/youtube-video-embed-like-google-plus.html

Thoughts on whether this library should support that?

[cookpete]

At a glance it looks like it just renders an image that loads the player properly on click. There's no reason you can't do this right now by just rendering a thumbnail that gets replaced with ReactPlayer after clicking.

Some possible problems with including it as a feature of the library:

• Does this break autoplay with sound? Most players in latest Chrome require user interaction to autoplay with sound, and I'm assuming a click on a placeholder before the player loads will not count as enough "interaction" to enable autoplay. The user then needs to click twice which is lame.
• Styling the placeholder/button will require either a CSS file to be imported (which adds friction to using the component) or some inline style attributes that may cause CSP problems.
• It would be nice to do this with all players for consistency, but we'd need to figure out how to get a thumbnail of the video for each player type without loading the full player SDK.

[oyeanuj]

@cookpete All valid points. Some follow-up thoughts:

At a glance it looks like it just renders an image that loads the player properly on click. There's no reason you can't do this right now by just rendering a thumbnail that gets replaced with ReactPlayer after clicking.

Totally, I figured it would be repeating logic for a lot of users. To fetch the thumbnail image, etc.

1. On breaking autoplay: Both the above links this and this seems to not have that problem on Chrome.

2. On styling: I was thinking it would be an opt-in prop, and then you we could supply an example for styling it, similar to how you do today for responsive videos.

3. Yes, that would be a nice tracking goal that maybe community can help with as well once we have a standard implementation/example :)

---

I think what I was realizing was that the benefits on page load and speed might be significant to recommend as a best practice for a popular library like this - standardizing an efficient soliution (even if it is opt-in).

Thoughts?

[oyeanuj]

@cookpete Just following up if you had any more thoughts based on the above comment?

[cookpete]

Sorry @oyeanuj, all good points:

On breaking autoplay: Both the above links this and this seems to not have that problem on Chrome.

They do for me. Is it possible that these sites are over the new "media engagement" threshold on your Chrome, that allows autoplay?

https://developers.google.com/web/updates/2017/09/autoplay-policy-changes#mei

On styling: I was thinking it would be an opt-in prop, and then you we could supply an example for styling it, similar to how you do today for responsive videos.

Yeah fair point. We could have an import 'react-player/light.css' or something, with some basic CSS for a centred play button.

Yes, that would be a nice tracking goal that maybe community can help with as well once we have a standard implementation/example :)

I guess as long as it is documented somewhere which players support thumbnail previews, then that's good enough.

I think it's a good idea and wouldn't be too intrusive to implement. Happy to leave this issue open and look into it.

[oyeanuj]

@cookpete I was doing a little bit of research for something else and realized that Youtube and Vimeo both support thumbnail previews. Did you get a chance to look more into it as per your above comment?

[oyeanuj]

@cookpete Any updates on this one? Did you get a chance to look into it more?

[cookpete]

@oyeanuj light prop added in 1.8.0. Let me know if everything works ok for you.

[oyeanuj]

@cookpete Thanks you! Just got a chance to implement it - it mostly worked great except for a couple of little things:

1. The request to NoEmbed is made it via http which is blocked by default on https site. Is there a reason to prefer http over https when making the noEmbed call?

2. On clicking, can we default to playing to prevent repeat clicking on the play button?

[oyeanuj]

@cookpete Just wondering if you had any thoughts on the above issue? (1) is particularly a blocker on using this feature.

[cookpete]

Hey @oyeanuj, the https problem should be sorted in 1.9.1.

As for defaulting to playing, that's just a case of passing in playing={true} to the light player.

I've added a light mode toggle to the demo app so you can play around a bit more now.

[oyeanuj]

Great, thank you for the quick fix!