6 ms·

How fast is apple.com?

81 points by leak 14y ago

redguava 14y ago
"External JavaScript files in <head> – All of those JavaScript files nested inside the <head> tag, further delaying the start of page rendering." Sometimes the head is the best place to put the javascript. I didn't look into what javascript they are loading there, but there are times the user experience is improved by it.
- d0ugal 14y ago
  For example?
  - redguava 14y ago
    What if you are displaying different elements based on the users location/country (eg. currency, contact details), and you use javascript to detect and do this. You wouldn't want the page to load first and then this appear.
    - rimantas 14y ago
      So you would delay the whole page just because of some location specific elements? How about render what you got first so the user has something to look at and then fill in your specific bits later?
      - redguava 14y ago
        Possibly. I am just saying that you might have things that are more important to do before the page loads that might warrant putting it in the head. It's not a set rule that javascript in the head is always bad, you just need to know the tradeoff and make a decision.
      - jaffathecake 14y ago
        @redguava ...but you can't come up with a single example?
    - redguava 14y ago
      @jaffathecake I supplied a single example. Also, you might have a very javascripty web application that the users will have had the files cached 99.9% of the time so retrieving the files isn't an issue.
  - padolsey 14y ago
    For example, setting up event delegation on enhanced elements is best done in the HEAD before the elements load. If you setup all your user-event listeners in the bottom of BODY then your users will have a short time when they'll be interacting with elements which A) will do the non-enhanced behaviour B) do nothing whatsoever. Neither A nor B is ideal.
    - jaffathecake 14y ago
      Nah, have a small inline script that records events and replays them to your full script when it loads. Or, if something only works with js, don't show it until the scripts have loaded, but let plain content load & render in the meantime.
      - padolsey 14y ago
        Yeh, both viable solutions. Tbh, I can't think of any other reason to have JS in the HEAD.
        SquareWheel 14y ago
        Google Analytics is generally the only JS I put in the head. If some code is absolutely required for the page to work though then it may make sense to put it ahead of the content.
  - voidr 14y ago
    Sometimes you render content with JavaScript and want to avoid FOUC(Flash Of Unstyled Content) also sometimes you have JavaScript polyfills that you want loaded as soon as possible. But I assume that in Apple's case, they are doing it even when they shouldn't be.
- oelmekki 14y ago
  They could be using http streaming, like the feature introduced in rails 3.1 : http://weblog.rubyonrails.org/2011/4/18/why-http-streaming/ http://weblog.rubyonrails.org/2011/4/18/why-http-streaming/ That actually makes <head> the preferred place for loading scripts. Also, I find it a bit extreme to recommend putting inline javascript in a <script> tag. I'm ok with trying to maximize performances, but please, do not recommend to produce un-seperated and unclean code. Concatenating javascript in a single file (and compressing it) is way enough, having one single request to get all javascript is not so bad.
  - judofyr 14y ago
    I think he meant something like: <script><%= File.read("file.js") %></script> Not that they should literally move the script inline.
  - jaffathecake 14y ago
    In which case loading the scripts async would be the right thing to do. Early loading, but non render-blocking http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#dom-script-async http://www.whatwg.org/specs/web-apps/current-work/multipage/...
  - emidln 14y ago
    What's unseparated about it? Maintenance doesn't have to be performed on the rendered final product. Template systems and processing pipelines are pretty common for letting devs keep code structured in useful ways while still allowing for optimal end results.
faizanaziz 14y ago
Would really prefer if you make all the changes how much improvement can be seen. This would put into perspective what the optimisation means.
- mjs 14y ago
  The mod_pagespeed service does some of these optimisations (plus others). It's almost certainly applying JS concatenation, and in the end there's not much difference in load time: http://www.webpagetest.org/result/121024_K0_78b60a17cae988da846285d8e3d1f75c/ http://www.webpagetest.org/result/121024_K0_78b60a17cae988da... EDIT: Actually, it is applying some concatenation, but it's not concatenating everything: http://www.webpagetest.org/result/121024_35_049258ec5056f5b4b03f839edbe0d773/1/details/ http://www.webpagetest.org/result/121024_35_049258ec5056f5b4...
deleted 14y ago
[deleted]
mjs 14y ago
Concatenating JS doesn't necessarily make things faster, since (as the article mentions) modern browsers will download up to 8 assets in parallel. If JS is delivered separately, the browser doesn't have to wait for all of it to be downloaded before parsing and executing any of it--they can be parsed (and potentially executed) in parallel.
- deleted 14y ago
  [deleted]
- jaffathecake 14y ago
  That becomes true when your scripts are massive. With the sizes Apple are using, the connection & HTTP overhead become the bottleneck.
  - mjs 14y ago
    Well, images.apple.com is Akamai'd (22ms for me) and it also supports keep-alive.
- MartinodF 14y ago
  AFAIK the scripts cannot be parsed and executed in parallel since they're not explicitly async. The browser doesn't know if any of the following scripts may depend on the previous ones (think jQuery), so it just downloads them and then waits to parse and execute them in order, blocking rendering. It's true that delivering them in parallel may in some cases reduce the actual download time, but given the small file sizes Apple is serving, the connection overhead (TCP handshake, HTTP headers, slow start, ...) just makes it worse. Most browsers (especially mobile ones) aren't even going to download more than 4-6 files at a time, since they're not using domain sharding.
  - pixelbath 14y ago
    >The browser doesn't know if any of the following scripts may depend on the previous ones Yes it does. That's why the way they're ordered on the page is important. If I include jQuery after I'm trying to make jQuery function calls, it won't work (in all browsers I've tested, anyway).
growt 14y ago
Well, zoompf.com takes a minute to respond at the moment. So maybe they're not the ones to judge.
- padolsey 14y ago
  Tu quoque... However, it is curious to discover they have quite hefty JS files loading in their own HEAD element.
- sepeth 14y ago
  I was thinking the same thing, but still this doesn't make what he says any less true.
- grecy 14y ago
  If Hitler called you cruel for kicking a dog, he'd still be right.
georgespencer 14y ago
Question: have the average file-sizes of websites gone up proportionately to bandwidth increases? It seems to me like bandwidth has increased enormously, but filesizes have capped between 600k–1 megabyte. Shaving tenths of seconds off pageloads might not be as important as improving the speed of render.
- jacobr 14y ago
  Has the average bandwidth of web users really gone up, if you include the increase of mobile usage?
  - demallien 14y ago
    I can't speak for every country, but as I work for a French telecom, I happen to know the figures for this on our own network. Firstly, the vast majority (around 80%) of browsing on mobile devices is going through wifi. It turns out that at least in France, most people that use mobile devices seem to use those devices in areas where they have wifi available (at home, or in the office) most of the time. This of course means that as soon as you increase landline data speeds, you also increase mobile data speeds, because most mobile usage is routed through landlines. Secondly, even when clients are out and about, they often have 3G coverage which is not too far off wifi speeds (a typical 3G connection has about a third of the bandwidth of a typical landline/wifi connection). OK, it's a third of the speed, but it's the same order of magnitude, and it only applies about 20% of the time. What this means is that a mobile user is getting data at (100 * 0.8) + (33 * 0.2) = 86% bandwidth of a landline connection. This means that a 16% increase in landline bandwidth would be enough to balance out everyone moving to mobile devices. Landline bandwidth has of course improved a lot more than 16% in the last few years, and not everyone has moved to exclusively mobile device web-browsing. So yes, I think it's fair to say that the average bandwidth of web users has gone up, at least in France.
    - pacaro 14y ago
      1/3 is not the same order of magnitude in base-3 or less, I tend to think in base-2 at least as much as base-10 when considering order of magnitude issues. Put another way, if I coded something where the performance delta was 1/3 or 3x, I would certainly be complaining or bragging about an order of magnitude change.
rorrr 14y ago
Ironically, Google Pagespeed tells us this about zoompf.com: High priority Compressing the following resources with gzip could reduce their transfer size by 235.5KiB (72% reduction). Compressing http://zoompf.com/js/jquery-ui.min.js could save 142.7KiB (74% reduction). Compressing http://zoompf.com/js/jquery.min.js could save 62.5KiB (66% reduction). Compressing http://zoompf.com/wp-content/themes/NewZoompf/style.css could save 24.9KiB (77% reduction). Compressing http://zoompf.com/js/animations.js could save 4.0KiB (75% reduction). Compressing http://zoompf.com/.../wp-page-numbers.css could save 1.4KiB (73% reduction). Medium Priority The following cacheable resources have a short freshness lifetime. Specify an expiration at least one week in the future for the following resources: http://zoompf.com/images/background_pages.png (expiration not specified) http://zoompf.com/images/clipboard.png (expiration not specified) http://zoompf.com/images/handles.png (expiration not specified) http://zoompf.com/images/pages.png (expiration not specified) http://zoompf.com/images/report.png (expiration not specified) http://zoompf.com/images/streak.png (expiration not specified) http://zoompf.com/js/animations.js (expiration not specified) http://zoompf.com/js/jquery-ui.min.js (expiration not specified) http://zoompf.com/js/jquery.min.js (expiration not specified) http://zoompf.com/.../wp-page-numbers.css (expiration not specified) http://zoompf.com/wp-content/themes/NewZoompf/style.css (expiration not specified) http://zoompf.com/.../freedownload.jpg (expiration not specified) http://zoompf.com/.../freeperformancescan.jpg (expiration not specified) http://zoompf.com/.../logo-disrupt.jpg (expiration not specified) http://zoompf.com/.../logo-virgin-america.png (expiration not specified) http://zoompf.com/.../social-icons-32.png (expiration not specified) http://zoompf.com/.../video-icon.png (expiration not specified) They basically don't follow their own advice. Credibility -> toilet.
- dbushell 14y ago
  That doesn't make their advice wrong.
  - rorrr 14y ago
    That however makes me skip their advice forever.
anonymouz 14y ago
I'm using the RequestPolicy addon for Firefox (I realize I'm in a tiny minority...). When visitng a website that uses domain sharding for the first time, that means I have to allow cross-site requests to the other domains. My plea to web-admins: Try to at least make the names of the shards recognizable. I've seen sites where the domain is essentialy "mynewspaper.com" and it needs data from "xac1h139a.com" to display correctly. Now go find the right domain to allow within the dozens of cross site requests that such sites are often using... Edit: This is a comment on his suggestion to use domain sharding. His site is fine.
codeka 14y ago
For me, the most noticeable thing is the time it takes to load that enormous .png file. It's only 500KB but it still took 2 or 3 seconds to load for some reason.
lelf 14y ago
And they didn't tell anything about what apple did to make it fast. About this for instance Betty:~ lelf$ dig www.apple.com […] ;; ANSWER SECTION: www.apple.com. 1434 IN CNAME www.isg-apple.com.akadns.net. www.isg-apple.com.akadns.net. 21 IN CNAME www.apple.com.edgekey.net. www.apple.com.edgekey.net. 21234 IN CNAME e3191.c.akamaiedge.net. e3191.c.akamaiedge.net. 20 IN A 23.32.109.15 […] (If you really don't understand: http://en.wikipedia.org/wiki/Akamai_Technologies http://en.wikipedia.org/wiki/Akamai_Technologies http://en.wikipedia.org/wiki/Content_delivery_network http://en.wikipedia.org/wiki/Content_delivery_network) EDIT: formatting, links
jasongaya 14y ago
what it this?? some one make spam here.
morgo 14y ago
I think the author merged in two terms of his analysis of performance that are really separate: - Response Time (how long does it take per task) - Throughput (how many tasks can we complete per N) For some of us, getting better responses means in-and-out quicker and so its easier to serve more throughput. For apple, they have plenty of capacity, so new product launches aren't really a motivation to improve response. They will we able to support that volume anyway. The motivation would be to improve user experience.
coolstorybrah 14y ago
lol argues about irrelevant js snippets on apple.com, doesn't even have a working comments page.

81 points by leak 14y ago

"External JavaScript files in <head> – All of those JavaScript files nested inside the <head> tag, further delaying the start of page rendering." Sometimes the head is the best place to put the javascript. I didn't look into what javascript they are loading there, but there are times the user experience is improved by it.

d0ugal 14y ago
For example?
- redguava 14y ago
  What if you are displaying different elements based on the users location/country (eg. currency, contact details), and you use javascript to detect and do this. You wouldn't want the page to load first and then this appear.
  - rimantas 14y ago
    So you would delay the whole page just because of some location specific elements? How about render what you got first so the user has something to look at and then fill in your specific bits later?
    - redguava 14y ago
      Possibly. I am just saying that you might have things that are more important to do before the page loads that might warrant putting it in the head. It's not a set rule that javascript in the head is always bad, you just need to know the tradeoff and make a decision.
    - jaffathecake 14y ago
      @redguava ...but you can't come up with a single example?
  - redguava 14y ago
    @jaffathecake I supplied a single example. Also, you might have a very javascripty web application that the users will have had the files cached 99.9% of the time so retrieving the files isn't an issue.
- padolsey 14y ago
  For example, setting up event delegation on enhanced elements is best done in the HEAD before the elements load. If you setup all your user-event listeners in the bottom of BODY then your users will have a short time when they'll be interacting with elements which A) will do the non-enhanced behaviour B) do nothing whatsoever. Neither A nor B is ideal.
  - jaffathecake 14y ago
    Nah, have a small inline script that records events and replays them to your full script when it loads. Or, if something only works with js, don't show it until the scripts have loaded, but let plain content load & render in the meantime.
    - padolsey 14y ago
      Yeh, both viable solutions. Tbh, I can't think of any other reason to have JS in the HEAD.
      - SquareWheel 14y ago
        Google Analytics is generally the only JS I put in the head. If some code is absolutely required for the page to work though then it may make sense to put it ahead of the content.
- voidr 14y ago
  Sometimes you render content with JavaScript and want to avoid FOUC(Flash Of Unstyled Content) also sometimes you have JavaScript polyfills that you want loaded as soon as possible. But I assume that in Apple's case, they are doing it even when they shouldn't be.
oelmekki 14y ago
They could be using http streaming, like the feature introduced in rails 3.1 : http://weblog.rubyonrails.org/2011/4/18/why-http-streaming/ http://weblog.rubyonrails.org/2011/4/18/why-http-streaming/ That actually makes <head> the preferred place for loading scripts. Also, I find it a bit extreme to recommend putting inline javascript in a <script> tag. I'm ok with trying to maximize performances, but please, do not recommend to produce un-seperated and unclean code. Concatenating javascript in a single file (and compressing it) is way enough, having one single request to get all javascript is not so bad.
- judofyr 14y ago
  I think he meant something like: <script><%= File.read("file.js") %></script> Not that they should literally move the script inline.
- jaffathecake 14y ago
  In which case loading the scripts async would be the right thing to do. Early loading, but non render-blocking http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#dom-script-async http://www.whatwg.org/specs/web-apps/current-work/multipage/...
- emidln 14y ago
  What's unseparated about it? Maintenance doesn't have to be performed on the rendered final product. Template systems and processing pipelines are pretty common for letting devs keep code structured in useful ways while still allowing for optimal end results.

faizanaziz 14y ago

Would really prefer if you make all the changes how much improvement can be seen. This would put into perspective what the optimisation means.

mjs 14y ago
The mod_pagespeed service does some of these optimisations (plus others). It's almost certainly applying JS concatenation, and in the end there's not much difference in load time: http://www.webpagetest.org/result/121024_K0_78b60a17cae988da846285d8e3d1f75c/ http://www.webpagetest.org/result/121024_K0_78b60a17cae988da... EDIT: Actually, it is applying some concatenation, but it's not concatenating everything: http://www.webpagetest.org/result/121024_35_049258ec5056f5b4b03f839edbe0d773/1/details/ http://www.webpagetest.org/result/121024_35_049258ec5056f5b4...

deleted 14y ago

[deleted]

mjs 14y ago

Concatenating JS doesn't necessarily make things faster, since (as the article mentions) modern browsers will download up to 8 assets in parallel. If JS is delivered separately, the browser doesn't have to wait for all of it to be downloaded before parsing and executing any of it--they can be parsed (and potentially executed) in parallel.

deleted 14y ago
[deleted]
jaffathecake 14y ago
That becomes true when your scripts are massive. With the sizes Apple are using, the connection & HTTP overhead become the bottleneck.
- mjs 14y ago
  Well, images.apple.com is Akamai'd (22ms for me) and it also supports keep-alive.
MartinodF 14y ago
AFAIK the scripts cannot be parsed and executed in parallel since they're not explicitly async. The browser doesn't know if any of the following scripts may depend on the previous ones (think jQuery), so it just downloads them and then waits to parse and execute them in order, blocking rendering. It's true that delivering them in parallel may in some cases reduce the actual download time, but given the small file sizes Apple is serving, the connection overhead (TCP handshake, HTTP headers, slow start, ...) just makes it worse. Most browsers (especially mobile ones) aren't even going to download more than 4-6 files at a time, since they're not using domain sharding.
- pixelbath 14y ago
  >The browser doesn't know if any of the following scripts may depend on the previous ones Yes it does. That's why the way they're ordered on the page is important. If I include jQuery after I'm trying to make jQuery function calls, it won't work (in all browsers I've tested, anyway).

growt 14y ago

Well, zoompf.com takes a minute to respond at the moment. So maybe they're not the ones to judge.

padolsey 14y ago
Tu quoque... However, it is curious to discover they have quite hefty JS files loading in their own HEAD element.
sepeth 14y ago
I was thinking the same thing, but still this doesn't make what he says any less true.
grecy 14y ago
If Hitler called you cruel for kicking a dog, he'd still be right.

georgespencer 14y ago

Question: have the average file-sizes of websites gone up proportionately to bandwidth increases? It seems to me like bandwidth has increased enormously, but filesizes have capped between 600k–1 megabyte. Shaving tenths of seconds off pageloads might not be as important as improving the speed of render.

jacobr 14y ago
Has the average bandwidth of web users really gone up, if you include the increase of mobile usage?
- demallien 14y ago
  I can't speak for every country, but as I work for a French telecom, I happen to know the figures for this on our own network. Firstly, the vast majority (around 80%) of browsing on mobile devices is going through wifi. It turns out that at least in France, most people that use mobile devices seem to use those devices in areas where they have wifi available (at home, or in the office) most of the time. This of course means that as soon as you increase landline data speeds, you also increase mobile data speeds, because most mobile usage is routed through landlines. Secondly, even when clients are out and about, they often have 3G coverage which is not too far off wifi speeds (a typical 3G connection has about a third of the bandwidth of a typical landline/wifi connection). OK, it's a third of the speed, but it's the same order of magnitude, and it only applies about 20% of the time. What this means is that a mobile user is getting data at (100 * 0.8) + (33 * 0.2) = 86% bandwidth of a landline connection. This means that a 16% increase in landline bandwidth would be enough to balance out everyone moving to mobile devices. Landline bandwidth has of course improved a lot more than 16% in the last few years, and not everyone has moved to exclusively mobile device web-browsing. So yes, I think it's fair to say that the average bandwidth of web users has gone up, at least in France.
  - pacaro 14y ago
    1/3 is not the same order of magnitude in base-3 or less, I tend to think in base-2 at least as much as base-10 when considering order of magnitude issues. Put another way, if I coded something where the performance delta was 1/3 or 3x, I would certainly be complaining or bragging about an order of magnitude change.

rorrr 14y ago

Ironically, Google Pagespeed tells us this about zoompf.com: High priority Compressing the following resources with gzip could reduce their transfer size by 235.5KiB (72% reduction). Compressing http://zoompf.com/js/jquery-ui.min.js could save 142.7KiB (74% reduction). Compressing http://zoompf.com/js/jquery.min.js could save 62.5KiB (66% reduction). Compressing http://zoompf.com/wp-content/themes/NewZoompf/style.css could save 24.9KiB (77% reduction). Compressing http://zoompf.com/js/animations.js could save 4.0KiB (75% reduction). Compressing http://zoompf.com/.../wp-page-numbers.css could save 1.4KiB (73% reduction). Medium Priority The following cacheable resources have a short freshness lifetime. Specify an expiration at least one week in the future for the following resources: http://zoompf.com/images/background_pages.png (expiration not specified) http://zoompf.com/images/clipboard.png (expiration not specified) http://zoompf.com/images/handles.png (expiration not specified) http://zoompf.com/images/pages.png (expiration not specified) http://zoompf.com/images/report.png (expiration not specified) http://zoompf.com/images/streak.png (expiration not specified) http://zoompf.com/js/animations.js (expiration not specified) http://zoompf.com/js/jquery-ui.min.js (expiration not specified) http://zoompf.com/js/jquery.min.js (expiration not specified) http://zoompf.com/.../wp-page-numbers.css (expiration not specified) http://zoompf.com/wp-content/themes/NewZoompf/style.css (expiration not specified) http://zoompf.com/.../freedownload.jpg (expiration not specified) http://zoompf.com/.../freeperformancescan.jpg (expiration not specified) http://zoompf.com/.../logo-disrupt.jpg (expiration not specified) http://zoompf.com/.../logo-virgin-america.png (expiration not specified) http://zoompf.com/.../social-icons-32.png (expiration not specified) http://zoompf.com/.../video-icon.png (expiration not specified) They basically don't follow their own advice. Credibility -> toilet.

dbushell 14y ago
That doesn't make their advice wrong.
- rorrr 14y ago
  That however makes me skip their advice forever.

anonymouz 14y ago

I'm using the RequestPolicy addon for Firefox (I realize I'm in a tiny minority...). When visitng a website that uses domain sharding for the first time, that means I have to allow cross-site requests to the other domains. My plea to web-admins: Try to at least make the names of the shards recognizable. I've seen sites where the domain is essentialy "mynewspaper.com" and it needs data from "xac1h139a.com" to display correctly. Now go find the right domain to allow within the dozens of cross site requests that such sites are often using... Edit: This is a comment on his suggestion to use domain sharding. His site is fine.

codeka 14y ago

For me, the most noticeable thing is the time it takes to load that enormous .png file. It's only 500KB but it still took 2 or 3 seconds to load for some reason.

lelf 14y ago

And they didn't tell anything about what apple did to make it fast. About this for instance Betty:~ lelf$ dig www.apple.com […] ;; ANSWER SECTION: www.apple.com. 1434 IN CNAME www.isg-apple.com.akadns.net. www.isg-apple.com.akadns.net. 21 IN CNAME www.apple.com.edgekey.net. www.apple.com.edgekey.net. 21234 IN CNAME e3191.c.akamaiedge.net. e3191.c.akamaiedge.net. 20 IN A 23.32.109.15 […] (If you really don't understand: http://en.wikipedia.org/wiki/Akamai_Technologies http://en.wikipedia.org/wiki/Akamai_Technologies http://en.wikipedia.org/wiki/Content_delivery_network http://en.wikipedia.org/wiki/Content_delivery_network) EDIT: formatting, links

jasongaya 14y ago

what it this?? some one make spam here.

morgo 14y ago

I think the author merged in two terms of his analysis of performance that are really separate: - Response Time (how long does it take per task) - Throughput (how many tasks can we complete per N) For some of us, getting better responses means in-and-out quicker and so its easier to serve more throughput. For apple, they have plenty of capacity, so new product launches aren't really a motivation to improve response. They will we able to support that volume anyway. The motivation would be to improve user experience.

coolstorybrah 14y ago

lol argues about irrelevant js snippets on apple.com, doesn't even have a working comments page.