Google +1 Button Performance Review • Hacker News Board

Re: Google +1 Button Performance Review

#11

Post by stingraycharles » Tue, Jun 07, 2011, 11:49 AM UTC

wladimir wrote: post #9

thezilch wrote: post #2

In short, and as a rule with all scripts, load scripts asynchronously / non-blocking when possible, including Google +1. (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'); Load it as far up your page as possible, as to benefit from the parallelism early on and not han…

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 ... Pretty interesting. Care to explain a bit?

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.

Re: Google +1 Button Performance Review

#12

Post by dave1010uk » Tue, Jun 07, 2011, 11:52 AM UTC

wladimir wrote: post #9

thezilch wrote: post #2

In short, and as a rule with all scripts, load scripts asynchronously / non-blocking when possible, including Google +1. (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'); Load it as far up your page as possible, as to benefit from the parallelism early on and not han…

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 ... Pretty interesting. Care to explain a bit?

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

Re: Google +1 Button Performance Review

#13

Post by jarin » Tue, Jun 07, 2011, 11:56 AM UTC

wladimir wrote: post #9

thezilch wrote: post #2

In short, and as a rule with all scripts, load scripts asynchronously / non-blocking when possible, including Google +1. (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'); Load it as far up your page as possible, as to benefit from the parallelism early on and not han…

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 ... Pretty interesting. Care to explain a bit?

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."

Re: Google +1 Button Performance Review

#14

Post by wladimir » Tue, Jun 07, 2011, 12:11 PM UTC

stingraycharles wrote: post #11

wladimir wrote: post #9

Earlier quoted context omitted.

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 ... Pretty interesting. Care to explain a bit?

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 docum…

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 &.

Re: Google +1 Button Performance Review

#15

Post by stingraycharles » Tue, Jun 07, 2011, 12:21 PM UTC

wladimir wrote: post #14

stingraycharles wrote: post #11

Earlier quoted context omitted.

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 docum…

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 &.

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.

Re: Google +1 Button Performance Review

#16

Post by mhansen » Tue, Jun 07, 2011, 12:51 PM UTC

jarin wrote: post #13

wladimir wrote: post #9

Earlier quoted context omitted.

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 ... Pretty interesting. Care to explain a bit?

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."

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.

Re: Google +1 Button Performance Review

#17

Post by jarin » Tue, Jun 07, 2011, 12:54 PM UTC

mhansen wrote: post #16

jarin wrote: post #13

Earlier quoted context omitted.

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."

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.

Sure, but what's the drawback? I think very simple premature optimizations are just fine, especially when someone else does them for me.

Re: Google +1 Button Performance Review

#18

Post by wladimir » Tue, Jun 07, 2011, 1:10 PM UTC

mhansen wrote: post #16

jarin wrote: post #13

Earlier quoted context omitted.

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."

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.

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.

Re: Google +1 Button Performance Review

#19

Post by za » Tue, Jun 07, 2011, 1:17 PM UTC

If the latency cost of multiple requests is so significant couldn't google just lump everything into one (base64 encode the image)?

Re: Google +1 Button Performance Review

#20

Post by mquander » Tue, Jun 07, 2011, 2:08 PM UTC

johnsocs wrote: post #7

Google has added the +1 option to all their search requests / results, I'm sure if the performance was such an issue they would of found a way to fix it as it would degrade their page load times, granted I'm sure it's not the same 'exact' code.

I find it mildly irritating that a guy writes a several-page article explaining individual, specific performance problems together with measurements and suggested fixes, and you respond that you're sure there's no issue because Google is smart.