

Why are pages slow? - eduadecastro
http://themvcblog.typepad.com/programming/2012/12/why-are-pages-slow.html

======
rhplus
I'm interested to see what's said for "poor cache-ability". It's an area where
the assumption of "more caching is better" can be wrong. I've seen real-world
A/B test results that indicate _client-side_ caching can often be _slower_
than re-fetching a resource from the network. Typically, this is true for
small resources being loaded from the disk cache (i.e. your home page on a new
browser session). It's counter intuitive, but many network connections to hot
CDNs are faster than fetching from a local physical (spinning) disk.

~~~
Negitivefrags
Until some guy from New Zealand that doesn't have an edge in his country comes
along. Don't actually apply this optimisation just because it's faster for
you. It's probably slower for a lot of the rest of the world.

~~~
rhplus
The "real world A/B test" I mentioned was part of ongoing performance test for
a global top 20 site. I'm talking about millions of hits across all browser
variants, OSes, markets, networks, etc. I can't cite the data directly because
it's not public. You're right though that there will be plenty of cases where
optimizations like this will be not work for some users. The most important
thing, obviously, is to gather data from your own users and make the right
choices based on them. Things change fast: new browser features; new user
groups; new networks routes or proxies in your way. Results that were
conclusive previously need to be retested regularly, including the following.

The particular scenario where we saw network-loading of resources consistently
being faster was on first load of a frequently viewed page. In this scenario
we found that loading certain scripts and images from cache (which we inferred
to be physical disk because it was 'home page' activity) was slower for a
significant portion of the experiment group than loading from the network. In
this context loading from 'network' meant either a hot HTTP request to a CDN
or inlining small images and scripts directly in the HTML on every single
request.

As I mention above, it's worth regularly re-evaluating assumptions. I'd bet
that the big CDN players have a _huge_ presence in New Zealand and Australia,
given the latency, cost of ingress and density of the actual population
centres.

------
olegp
I've spent a fair amount of time (over) optimizing <https://starthq.com> and
would say that network latency needs to be at the top of the list of things to
look at.

The solution has been to serve static HTML, i.e. the index page of the single
page app part, with a one hour cache expiration and links to other static
resources (JavaScript, CSS, images etc.) decorated with their E-Tag and loaded
from a CDN. For non static pages the set up is the same, but the caching time
is lower. The static resources have far off (one year or so) expiration
headers so are cached permanently.

By using a CDN for all your assets you can reduce a 200ms roundtrip to 8ms for
all users worldwide, bringing the page loading time to way below 200ms with an
empty cache and well below 100ms with a primed cache since you still need to
do an XHR to check the login status.

Small time saving tip: if you go with CloudFront, go all out and use all edge
locations - it's cheap. I tried using Europe only at first only to eventually
find out that I was still being given an edge location in the US despite being
in Finland.

------
lennel
Most single page javascript apps that don't prerender are the biggest sinners
in a multitude of ways. 1) with the amd loading system you spawn multitude
http requests, where 2) none of the code went through a tree shaking to remove
dead code (ala the closure compiler in advanced mode - or something which
cross compiles) you download a whole steaming heap you don't need thus extra
bytes 3) no pre-rendering, so now you are blocking the users experience till
your whole steaming pile has managed to trickle down onto a mobile device, the
joy

------
ww520
Install the YSlow plug-in and see the bottlenecks right the way.

------
ohwp
Says the page that take 3.43s to (down)load in my browser, loading 8 CSS files
and a lot of JS files.

On a serious note: I think Opera Dragonfly is also a great tool for this
providing even more information.

