Advanced php tutorials

IT is easy to embed YouTube videos in your website. You just have to copy the IFRAME embed code and paste it anywhere on your web page. YouTube does offer basic customization options – like you can modify the player dimensions or hide the YouTube branding – but if you would like to have more control over the layout or behavior of the embedded player, YouTube Player API is the way to go.

This tutorial explains how you can embed a YouTube video that will automatically play when the web page is loaded but with muted audio.

For instance, a products website may use short screencasts to highlight features and these videos will autoplay when the page is loaded. The volume is however set to 0 and the user can manually click to unmute the video. Similarly, if you are using YouTube video backgrounds, it makes more sense to embed muted videos that run in a loop.

Embed YouTube Player with Autoplay and Sound Muted

See the demo page to get an idea of what we are trying to do here. The page loads, the video plays but with the audio slide is all the way down.

This is easy. Go the YouTube video page and note down the ID of the video from the URL. For instance, if the YouTube video link is http://youtube.com/watch?v=xyz-123, the video id is xyz-123. Once you have the ID, all you have to do is replace YOUR_VIDEO_ID in the following code with that string.

<div id="muteYouTubeVideoPlayer"></div>
 
<script async src="https://www.youtube.com/iframe_api"></script>
<script>
 function onYouTubeIframeAPIReady() {
  var player;
  player = new YT.Player('muteYouTubeVideoPlayer', {
    videoId: 'YOUR_VIDEO_ID', // YouTube Video ID
    width: 560,               // Player width (in px)
    height: 316,              // Player height (in px)
    playerVars: {
      autoplay: 1,        // Auto-play the video on load
      controls: 1,        // Show pause/play buttons in player
      showinfo: 0,        // Hide the video title
      modestbranding: 1,  // Hide the Youtube Logo
      loop: 1,            // Run the video in a loop
      fs: 0,              // Hide the full screen button
      cc_load_policy: 0, // Hide closed captions
      iv_load_policy: 3,  // Hide the Video Annotations
      autohide: 0         // Hide video controls when playing
    },
    events: {
      onReady: function(e) {
        e.target.mute();
      }
    }
  });
 }
 
 // Written by @labnol 
</script>

Next place the edited code on your web page and the embedded video would automatically play but the sound is muted.

You can further customize the player by modifying the various player variables as commented in the code. For instance, if you set loop as 1, the video will play in a loop. Set fs to 1 to show the fullscreen button inside the video player. Internally, the player is embedded using the YouTube IFRAME API. When the page is loaded, the onReady event runs that mutes the video.

The embedded YouTube video will autoplay, but muted.

Yesterday Twitter announced that it was moving away from client-side rendering back to server-side rendering in order to improve page load time. Today I found myself having to defend my position that server-side rendering will almost always be faster. I figured I'd blog about it.

I want to point out a couple things. First, I'm talking specifically about render performance and page speed. There might be other compelling advantages to thick-clients; I'm talking about performance. Secondly, I'm going to get on a high horse here and say that it worries me that developers think client-side rendering is faster. This is basic and fundamental knowledge about how the web and browsers work. Maybe I'll be proven wrong. If I am, I'll admit it. It'll be embarrassing because it means that I don't know the fundamentals. But I'll be glad to have learned (which is why I blog).

How It Works

With client-side rendering, your initial request loads the page layout, CSS and JavaScript. It's all common except that some or all of the content isn't included. Instead, the JavaScript makes another request, gets a response (likely in JSON), and generates the appropriate HTML (likely using a templating library).

With server-side rendering, your initial request loads the page, layout, CSS, JavaScript and content.

For subsequent updates to the page, the client-side rendering approach repeats the steps it used to get the initial content. Namely, JavaScript is used to get some JSON data and templating is used to create the HTML.

Updates using server-side rendering is where a lot of developers start going off the deep end. They actually think page refresh. Instead, what I thought we've all been doing for the last half decade, is some form of:

$('#loadTweets').on('click', function(e) {    $.get('/tweets/person', {last_id: 239393939}, function(r) {      $('#tweets').prepend(r);    });    e.preventDefaults();  });

In other words, we are still only doing a partial update, but letting the server do the rendering and inserting that finalized output into our DOM.

So those are the two workflows. Let's see why client-side rendering is slower.

Initial Load

Comparing the initial flow of the two approaches, it should be obvious that client-side rendering is going to be slower. It requires more JavaScript to be downloaded, which is more JavaScript to parse. It requires a 2nd HTTP request to load the content, and then requires more JavaScript to generate the template. Even if the initial JavaScript gets cached, it still needs to get parsed, and the 2nd request isn't going to happen until the document is loaded.

I could see bootstrapping the initial request to include the initial data as a JavaScript object. But I don't see many frameworks advocating this approach. I'm not sure I like it. And it would still be more JavaScript to download, parse and more cycles on the CPU to render it.

Control

One of the biggest problem with client-side rendering is that you lose control over the experience. Developers are building sites with 8-core boxes and 16 gigs of ram, running the latest OS and latest non-IE browser. With the site running locally. They think "geez, this is fast!" Meanwhile I'm trying to load your site on my horrible Samsung Galaxy S or my underpowered air.

Parsing JavaScript is slow..especially on some still popular browsers. Even on modern browsers, parsing some JavaScript is going to be slower than parsing less JavaScript.. This is especially true when you consider mobile devices. If you do rendering on the server, you have a lot more control over how fast and how consistent that rendering is. Overloaded? Buy more hardware. The client still has to render the HTML (it has to do this either way), but it doesn't have the extra JavaScript and templating overhead.

Caching

If your end points only return JSON, then all you'll be able to cache on the backend is JSON. The client will always have to spend time building the HTML elements from that data. If your end points return HTML, you can cache that instead. By rendering on the server, you can cache the final shape of your data. So not only does your client not have to generate templates, your server doesn't have to either.

And while we are at it, I want to point out that generating JSON on the server isn't a no-op operation. I'll admit that rendering JSON is probably quicker than rendering an ERB template, but people talk about it as though it just magically happens for free. (Although, if you are caching the HTML template, you can certainly cache the JSON as well).

Bandwidth

With client-side rendering your initial load will be and feel heavier: again, more JavaScript and a 2nd request. However, subsequent updates will require less bandwidth. JSON is pretty verbose, but it's probably less verbose than HTML with classes and ids. This is an area where client-side rendering will be faster (if we ignore the fact that we client-side rendering still needs to spend time transforming the JSON to HTML).However, both HTML and JSON should compress quite well.

I'm legitimately drawing a blank trying to come up with a pattern where the JSON data would be significantly smaller. If it's a collection of data (like search results), it'll just be the same divs with the same class name...much like it'll be the same JSON fields. I guess client-side rendering might have a real edge if you are using Word to generate your html...

A single API/Endpoint

I know I said I'd only talk about performance, but one argument that often gets brought up is that by consuming JSON, the browser is just another consumer your public API. The result is a single endpoint and clean routes.

Your server-side framework should let you respond to different requests types with minimal effort. In Rails this is done via respond_to. If your framework doesn't support something similar, either build it, or change frameworks.

Conclusion

Only considering performance, should you ever use client-side rendering? There's one obvious scenario where it makes sense: when you render based on existing data. That is, if you don't need to go to the server to render, say because you are going to display known data in a different perspective, client-side rendering makes sense.

Otherwise, client-side rendering requires a heavier initial load with a 2nd request, not being able to cache the final output and greater dependency on slower CPUs and rendering engines. Any one of those is a going to make client-side rendering slower. Combine them? Well, Twitter's server-side rendering takes 1/5 the time as client-side rendering.

If you are interested in learning more, I suggest you also check out How Basecamp Next was built to be so fast.

Advanced php tutorials

Labels

Pages

How to Embed Facebook Message Buttons in your Website