5 ms·

In short, and as a rule with all scripts, load scripts asynchronously / non-blocking when possible, including Google +1. <script> (function(d, t, g, s)

In short, and as a rule with all scripts, load scripts asynchronously / non-blocking when possible, including Google +1. <script> (function(d, t, g, s){ g = d.createElement(t), s = d.getElementsByTagName(t)[0]; g.async = true; g.src = 'https://apis.google.com/js/plusone.js'; s.parentNode.insertBefore(g, s); })(document, 'script'); </script> Load it as far up your page as possible, as to benefit from the parallelism early on and not hanging it off the end of or extending your page load.

wladimir 15y ago
I suppose these are JS performance tricks? - Define g and s as parameter even though they're only given a value inside the function - Pass document into the function instead of using it from global scope - Insert a script tag in front of the other script tags on-the-fly using insertBefore, instead of simply doing <script async src="...">...</script> Pretty interesting. Care to explain a bit?
- stingraycharles 15y ago
  I can only comment on the following two points: - Define g and s as parameter even though they're only given a value inside the function - Pass document into the function instead of using it from global scope This is not necessarily true: javascript passed arguments by reference, and thus g and s are actually "given back" to the caller, who can then do different things with those objects. d is not necessarily a document, but can be something different too: consider, for example, the contentWindow of an iframe.
  - wladimir 15y ago
    This is not necessarily true: javascript passed arguments by reference, and thus g and s are actually "given back" to the caller Pass by reference doesn't work that way in JS; function a(b) { b = 10; } var foo; a(foo); alert(foo); Won't display "10". It behaves like passing pointers, not mutable references such as the C++'s &.
    - stingraycharles 15y ago
      I stand corrected, you are right. Then the only thing I can think about is that accepting it as an additional parameter in the function call is less overhead (as in, bytes) than defining 'b' as a var: function a(b) { b = 10; } is smaller than function a() { var b = 10; } and doesn't pollute the global namespace. EDIT: I see dave1010uk also said this.
- dave1010uk 15y ago
  Defining variables as parameters saves bytes (", x" vs "var x") but shouldn't increase performance. Passing document into the function saves writing "document" twice or doing a "var d = document". Creating a new script tag with JS lets you get asynchronous script loading for older browsers that don't support the async attribute. Some other ways to reduce bytes are outlined at https://github.com/jed/140bytes/wiki/Byte-saving-techniques https://github.com/jed/140bytes/wiki/Byte-saving-techniques
- jarin 15y ago
  From the comments: "As for your question, we pass in `document` that way to prevent unnecessary scope lookups. We could’ve used `var d = document` inside the IIFE, but that would trigger an additional scope lookup. For `'script'` it doesn’t matter; you could initialize that inside of the IIFE if you want."
  - mhansen 15y ago
    It's premature optimization. The extra time taken for a scope lookup is completely insignificant compared to the network costs in loading the script. Perhaps if this was inside a tight inner loop, I could understand, but here it's completely unneccessary.
    - jarin 15y ago
      Sure, but what's the drawback? I think very simple premature optimizations are just fine, especially when someone else does them for me.
    - wladimir 15y ago
      It looks like the kind of optimization that a compiler could do pretty trivially, and you shouldn't have to be concerned about as a human, as it makes the code less readable. Then again, Javascript is a strange animal here as the code is provided to the execution environment as plaintext instead of bytecode/assembly. I guess a JS-to-JS compiler such as closure could handle it.
    - thezilch 15y ago
      Is it premature or unnecessary, if the methodology comes natural? Why not get into the habit of reading and writing Javascript with optimization naturally ingrained into the first pass? The optimization(s) may not be immediately necessary here, but there's no harm in practicing these patterns in all facets of language use, unless we want to have a separate conversation whether the patterns are detrimental to syntax.
speleding 15y ago
If you need the button in any other language than English insert this line in the snippet above: g.appendChild(d.createTextNode('{"lang":"fr"}'));

wladimir 15y ago

I suppose these are JS performance tricks? - Define g and s as parameter even though they're only given a value inside the function - Pass document into the function instead of using it from global scope - Insert a script tag in front of the other script tags on-the-fly using insertBefore, instead of simply doing <script async src="...">...</script> Pretty interesting. Care to explain a bit?

stingraycharles 15y ago
I can only comment on the following two points: - Define g and s as parameter even though they're only given a value inside the function - Pass document into the function instead of using it from global scope This is not necessarily true: javascript passed arguments by reference, and thus g and s are actually "given back" to the caller, who can then do different things with those objects. d is not necessarily a document, but can be something different too: consider, for example, the contentWindow of an iframe.
- wladimir 15y ago
  This is not necessarily true: javascript passed arguments by reference, and thus g and s are actually "given back" to the caller Pass by reference doesn't work that way in JS; function a(b) { b = 10; } var foo; a(foo); alert(foo); Won't display "10". It behaves like passing pointers, not mutable references such as the C++'s &.
  - stingraycharles 15y ago
    I stand corrected, you are right. Then the only thing I can think about is that accepting it as an additional parameter in the function call is less overhead (as in, bytes) than defining 'b' as a var: function a(b) { b = 10; } is smaller than function a() { var b = 10; } and doesn't pollute the global namespace. EDIT: I see dave1010uk also said this.
dave1010uk 15y ago
Defining variables as parameters saves bytes (", x" vs "var x") but shouldn't increase performance. Passing document into the function saves writing "document" twice or doing a "var d = document". Creating a new script tag with JS lets you get asynchronous script loading for older browsers that don't support the async attribute. Some other ways to reduce bytes are outlined at https://github.com/jed/140bytes/wiki/Byte-saving-techniques https://github.com/jed/140bytes/wiki/Byte-saving-techniques
jarin 15y ago
From the comments: "As for your question, we pass in `document` that way to prevent unnecessary scope lookups. We could’ve used `var d = document` inside the IIFE, but that would trigger an additional scope lookup. For `'script'` it doesn’t matter; you could initialize that inside of the IIFE if you want."
- mhansen 15y ago
  It's premature optimization. The extra time taken for a scope lookup is completely insignificant compared to the network costs in loading the script. Perhaps if this was inside a tight inner loop, I could understand, but here it's completely unneccessary.
  - jarin 15y ago
    Sure, but what's the drawback? I think very simple premature optimizations are just fine, especially when someone else does them for me.
  - wladimir 15y ago
    It looks like the kind of optimization that a compiler could do pretty trivially, and you shouldn't have to be concerned about as a human, as it makes the code less readable. Then again, Javascript is a strange animal here as the code is provided to the execution environment as plaintext instead of bytecode/assembly. I guess a JS-to-JS compiler such as closure could handle it.
  - thezilch 15y ago
    Is it premature or unnecessary, if the methodology comes natural? Why not get into the habit of reading and writing Javascript with optimization naturally ingrained into the first pass? The optimization(s) may not be immediately necessary here, but there's no harm in practicing these patterns in all facets of language use, unless we want to have a separate conversation whether the patterns are detrimental to syntax.

speleding 15y ago

If you need the button in any other language than English insert this line in the snippet above: g.appendChild(d.createTextNode('{"lang":"fr"}'));