cookpete / react-player

A React component for playing a variety of URLs, including file paths, YouTube, Facebook, Twitch, SoundCloud, Streamable, Vimeo, Wistia and DailyMotion
https://cookpete.github.io/react-player
MIT License
8.94k stars 1.12k forks source link

Lighter Youtube Embeds #448

Closed oyeanuj closed 5 years ago

oyeanuj commented 5 years ago

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 commented 5 years ago

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:

oyeanuj commented 5 years ago

@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 commented 5 years ago

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

cookpete commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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

cookpete commented 5 years ago

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

oyeanuj commented 5 years ago

@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 commented 5 years ago

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

cookpete commented 5 years ago

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 commented 5 years ago

Great, thank you for the quick fix!