

How fast is apple.com? - leak
http://zoompf.com/2012/10/how-fast-is-apple-com

======
mjs
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.

~~~
MartinodF
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
>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).

~~~
MartinodF
You didn't get my point, probably because of my terrible english :) The
browser has no way of knowing in advance if a script _doesn't depend_ on any
of the previous ones, so it cannot optimize this specific case and
parse/execute the script before the other ones have been executed. You can
manually tell the browser to load the scripts and execute them as soon as
they're ready, in no particular order, via the async attribute. If you don't,
the browser is going to assume that the order is important and load them one
by one.

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

~~~
oelmekki
They could be using http streaming, like the feature introduced in rails 3.1 :
<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
I think he meant something like:

    
    
        <script><%= File.read("file.js") %></script>
    

Not that they should literally move the script inline.

------
lelf
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/Content_delivery_network>)

EDIT: formatting, links

------
faizanaziz
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
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_78b60a17cae988da...](http://www.webpagetest.org/result/121024_K0_78b60a17cae988da846285d8e3d1f75c/)

EDIT: Actually, it is applying some concatenation, but it's not concatenating
everything:
[http://www.webpagetest.org/result/121024_35_049258ec5056f5b4...](http://www.webpagetest.org/result/121024_35_049258ec5056f5b4b03f839edbe0d773/1/details/)

------
georgespencer
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
Has the average bandwidth of web users really gone up, if you include the
increase of mobile usage?

~~~
demallien
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
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.

~~~
Shorel
Order of magnitude without any base specified is commonly understood as being
base 10, and it is extremely confusing to use other bases, as no one else uses
them as 'orders of magnitude'.

You can talk about logarithmic scales without risk of confusion.

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

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

~~~
padolsey
Tu quoque...

However, it is curious to discover they have quite hefty JS files loading in
their own HEAD element.

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

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

~~~
StavrosK
Ah, the ole "tu quoque" fallacy.

<http://en.wikipedia.org/wiki/Tu_quoque>

~~~
vacri
That's a subtle fallacy. It confused me at first, then I realised that
'pointing out hypocrisy' isn't the fallacy, it's 'claiming the argument is
wrong because it's hypocritical' that's the fallacy.

edit: on further examination, the examples given in the wikipedia article are
really bad - because they're merely pointing out hypocrisy ("but you're
-foo-") rather than claiming the argument is wrong. Person 2 in each example
could quite happily be in full agreement with the argument and make the same
comment.

~~~
StavrosK
Yes, exactly. Maybe I should edit the article to include this, it's an
important aspect. Sure, the person might be hypocritical, but this doesn't
invalidate the argument.

~~~
bduerst
It's like a chain smoker telling you that smoking is bad.

~~~
StavrosK
Yep, and it _is_ bad.

------
jasongaya
what it this?? some one make spam here.

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

