A través de www.seraccesible.net la magnífica web de
Marco, he caido en la web de un ponente de atmedia-2007, Nate Koechley, y
extraigo o fajo, citándole obviamente, las recomendaciones para mejorar el
rendimiento. La base como siempre, separar, separar, separar…
Comienzo cita:
I’d
been following the performance research by Yahoo![http://alastairc.ac/wp-content/themes/alastairc/images/je_outbound.gif]()
for a while, but still wanted to see if there was anything new,
and there was.
Starting
with a premise that recent interfaces have to some extent reduced the
performance impact of the using modern method and separated CSS and JavaScript,
he noted that there are two types of performance when sending a page:
·
Back-end: 5% of time
·
Front-end: 95%
Most
things to improve performance are on the front end.
Cache
I’ll
skip the jokes as they won’t work written down, but they went down well ![:)]()
The
difference between the first page load and a cached page load are quite
dramatic due to assets being cached. The difference (I think for the Yahoo
homepage) are:
168K
2.4 sec, to 28k and 0.9 sec.
They
did some experiments by setting expiration in the past for an image compared to
one that should be cached, the graph of the experiment goes from no-one having
it cached, to 40-60%, but no further.
20%
have a empty completely cache (presumably new visitors), and yet the images for
40-60% were not cached? Perhaps that was due to the homepage effect in IE they
found, where IE doesn’t cache the browser’s homepage.
Cookies
Broad
scope cookies also get sent to sub-domains, e.g. .yahoo.com gets sent to
finance.yahoo.com, so it’s worth keeping those high level cookies to a minimum.
Parallel
downloads
Browsers
download several items (generally 2) in parallel, and you might expect that if
they downloaded more items in parallel they would be quicker. However, the data
didn’t back it up. Doing 2 in parallel is quicker than one, but no further
benefit was found for 3 or more.
The
main causes are likely to be things like CPU thrashing, DNS lookup times vary
by geography, and DNS hostnames may not be cached.
Also,
if you divide assets it over different severs, the time goes up dramatically.
12
Rules
The
best aspect of the presentation was Nate’s consolidation of the research into
12 rules:
a.
Make fewer HTTP
requests. It’s the single best thing you can do.
Combine scripts and CSS files, so you have one of each.
Use things like CSS sprites (combining images then referencing
by co-ordinates), the combined size is smaller, and less requests are made.
b.
Use a CDN (Content
distribution network)
For example, Akamai, which is geographically closer to the
users, and tend to be cached more (DNS). Start with static stuff,
images, css and JavaScript.
c.
Add an expires header
It’s not just for images, if there is no expires header, files
won’t be cached.
d.
Gzip all your components
You can really affect download times. 90%+ of browsers support
it, and it’s negotiated with the server to check first. The usual methods are
usually mod_gzip or deflate, mod_gzip seemed to perform better in their
testing.
It’s good for any text based content. Most large sites do HTML,
not all do it for JS & CSS. It is not suitable for images or
binary/compressed files (e.g. PDF)
For the text based formats it always save over half of the file
size.
Use central servers for libraries, e.g. yahoo’s YUi.
e.
Put CSS at the top of
you’re docs
o
Style sheets block rendering
in IE
o
Use link, not import. It
seems to defer @import. Although it was the fastest loading time, it had the
slowest perceived time. Sorry this one is a bit cryptic, there was a good
diagram of it which hopefully will go on the blog soon.
f.
Put scripts at bottom
Scripts block the rendering of everything below them in the
page.
Scripts block parallel downloads… (I missed something here, not
sure on the reasoning.)
NB: ‘defer’ is not considered a solution, it’s doesn’t work well
enough
g.
Avoid CSS expressions
Most execute many times, e.g. mouse move, hey press, resize,
scroll etc. [I’m still inclined to use one for page max/min width.]
h.
Use separate files for
CSS & JS
Whilst this seems obvious, there are actually occasions that you
might consider not doing that. Variables include:
o
page views per session.
o
empty vs full cache.
o
Component re-use.
NB: Home pages (as in browser ones) are an exception, and CSS/JS
can be inline for greater performance.
Post-onload download (not sure if that’s correct) is a method of
pre-loading files which you know are going to be used. Such
as sequential things like shopping baskets.
i.
Reduce DNS lookups
These can block parallel downloading, use a max of 2-4 hosts,
use ‘keep-alive’, so it downloads multiple files in one go without new
connections & lookups.
j.
Minify
Be careful with obfuscation, as the re-writing can introduce
bugs.
k.
Avoid re-directs
l.
Turn off ETags