New stats
16 views
Skip to first unread message
Charlie Clark
Feb 18, 2013, 11:06:11 AM2/18/13
to httpa...@googlegroups.com
Steve has made an extensive update on what he has been working on over the
last couple of months:
http://www.stevesouders.com/blog/2013/02/16/http-archive-new-stats/
First, of all: thanks very much for the new stats and particularly for
documenting each chart. When I've been working with the code I've
sometimes had to take informed guesses at stuff. Hopefully fewer of those
in the future.
A couple of points which I think are worth discussing.
"""
The Doc Size chart shows the size of the main HTML document. To my
surprize this has only grown ~10% over the last two years. I would have
thought that the use of inlining (i.e., data:) and richer pages would have
shown a bigger increase, especially across the Top 1000 sites.
"""
In my day job I advise on the building of websites. Most websites are not
in a continual process of development. Aside from the question of
developer resources, the most difficult thing is getting management to
agree to changes. This makes updates necessarily slow: 18 months is not
unreasonable for a large website. Of course, any good website owner is
going to be trying to rollout gradual improvements all the time but these
highly unlikely to include micro-optimisations such as inlining as they
are so fragile - I would argue that this is exactly the kind of
optimisation that Knuth warns about. mod_pagespeed (yes, I know this will
use inlining) and SPDY or your own suggestion of flushing will bring much
more noticeable improvements in performance.
The last two years have, in my experience, been dominated by the rise of
mobile and the rush to some form of responsive or adaptive design. A great
side effect of this has been the chance to embrace HTML 5 semantics and
consciously decide to drop support for older browsers (IE 8 is probably a
baseline for many now, though many of us are hoping to be able to drop it
before the end of the year). These two changes alone can lead to
significant cleanup of the HTML for page. As many are now realising, while
responsive design lets us work with a single codebase for desktop and
mobile sites, it doesn't resolve our problems. Over the last year the
mobile gods have given us a new thing to hate: extremely high pixel
densities. None of the proposed solutions are technically suitable but the
pressure to deliver sufficiently crisp images on managers' screens means
that resources are being devoted to this instead of trying to solve the
knotty problems of context-dependent content.
"""
Max Reqs on 1 Domain
The question of whether domain sharding is still a valid optimization
comes up frequently. The arguments against it include browsers now do more
connections per hostname (from 2 to 6) and adding more domains increases
the time spent doing DNS lookups
"""
Domain sharding is just plain hard work on any kind of large site. From
what I've seen, CDNs that don't force users to try and work out which
objects go where are much easier to work with. On the sites I'm involved
with it makes no sense to shard and I wish the recommendation would be
dropped from YSlow. Where latency is a problem, bytecode proxies like
Opera Turbo are far more preferable.
The number of domains per page is increasing but I suspect this is driven
by the promiscuity of social media websites. It's bad enough just waiting
for static resources to arrive but some of the Javascript can really
hammer performance. The same is true for some of the metrics companies
where websites may be using comScore, Adobe, Google, GfK and others.
Hardly surprising that many hard-core surfers have long blacklists to
prevent all the party poopers! Someone on The Economist regularly posts
with the suffix NPWTFL (not published with Twitter, Facebook or LinkedIn)
as a statement about the NSL (never stops loading) of some sites.
"""
Cacheable Reosources
The percentage of resources that are cacheable hasn’t increased much in
the last two years, hovering around 60%.
"""
The big reason for this is the ability to flush content at will: this is a
must be for any publisher of news. It's a pity that the CDN stats are so
new but I would bet that they are another of the big stories of the last
couple of years. It's interesting to see that you've decided to classify
Google as a CDN - and, of course, any site hosted by Google is on a
distributed network, just not one generally considered to be a SaaS CDN.
That's make on things based, as I said, on the sites I'm involved on. I'm
sure others have very different experiences.
Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Kronenstr. 27a
Düsseldorf
D- 40217
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
last couple of months:
http://www.stevesouders.com/blog/2013/02/16/http-archive-new-stats/
First, of all: thanks very much for the new stats and particularly for
documenting each chart. When I've been working with the code I've
sometimes had to take informed guesses at stuff. Hopefully fewer of those
in the future.
A couple of points which I think are worth discussing.
"""
The Doc Size chart shows the size of the main HTML document. To my
surprize this has only grown ~10% over the last two years. I would have
thought that the use of inlining (i.e., data:) and richer pages would have
shown a bigger increase, especially across the Top 1000 sites.
"""
In my day job I advise on the building of websites. Most websites are not
in a continual process of development. Aside from the question of
developer resources, the most difficult thing is getting management to
agree to changes. This makes updates necessarily slow: 18 months is not
unreasonable for a large website. Of course, any good website owner is
going to be trying to rollout gradual improvements all the time but these
highly unlikely to include micro-optimisations such as inlining as they
are so fragile - I would argue that this is exactly the kind of
optimisation that Knuth warns about. mod_pagespeed (yes, I know this will
use inlining) and SPDY or your own suggestion of flushing will bring much
more noticeable improvements in performance.
The last two years have, in my experience, been dominated by the rise of
mobile and the rush to some form of responsive or adaptive design. A great
side effect of this has been the chance to embrace HTML 5 semantics and
consciously decide to drop support for older browsers (IE 8 is probably a
baseline for many now, though many of us are hoping to be able to drop it
before the end of the year). These two changes alone can lead to
significant cleanup of the HTML for page. As many are now realising, while
responsive design lets us work with a single codebase for desktop and
mobile sites, it doesn't resolve our problems. Over the last year the
mobile gods have given us a new thing to hate: extremely high pixel
densities. None of the proposed solutions are technically suitable but the
pressure to deliver sufficiently crisp images on managers' screens means
that resources are being devoted to this instead of trying to solve the
knotty problems of context-dependent content.
"""
Max Reqs on 1 Domain
The question of whether domain sharding is still a valid optimization
comes up frequently. The arguments against it include browsers now do more
connections per hostname (from 2 to 6) and adding more domains increases
the time spent doing DNS lookups
"""
Domain sharding is just plain hard work on any kind of large site. From
what I've seen, CDNs that don't force users to try and work out which
objects go where are much easier to work with. On the sites I'm involved
with it makes no sense to shard and I wish the recommendation would be
dropped from YSlow. Where latency is a problem, bytecode proxies like
Opera Turbo are far more preferable.
The number of domains per page is increasing but I suspect this is driven
by the promiscuity of social media websites. It's bad enough just waiting
for static resources to arrive but some of the Javascript can really
hammer performance. The same is true for some of the metrics companies
where websites may be using comScore, Adobe, Google, GfK and others.
Hardly surprising that many hard-core surfers have long blacklists to
prevent all the party poopers! Someone on The Economist regularly posts
with the suffix NPWTFL (not published with Twitter, Facebook or LinkedIn)
as a statement about the NSL (never stops loading) of some sites.
"""
Cacheable Reosources
The percentage of resources that are cacheable hasn’t increased much in
the last two years, hovering around 60%.
"""
The big reason for this is the ability to flush content at will: this is a
must be for any publisher of news. It's a pity that the CDN stats are so
new but I would bet that they are another of the big stories of the last
couple of years. It's interesting to see that you've decided to classify
Google as a CDN - and, of course, any site hosted by Google is on a
distributed network, just not one generally considered to be a SaaS CDN.
That's make on things based, as I said, on the sites I'm involved on. I'm
sure others have very different experiences.
Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Kronenstr. 27a
Düsseldorf
D- 40217
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
Reply all
Reply to author
Forward
0 new messages