Slashdot Log In
Optimizing Page Load Times
Posted by
kdawson
on Mon Oct 30, 2006 05:05 AM
John Callender writes, "Google engineer Aaron Hopkins has written an interesting analysis of optimizing page load time. Hopkins simulated connections to a web page consisting of many small objects (HTML file, images, external javascript and CSS files, etc.), and looked at how things like browser settings and request size affect perceived performance. Among his findings: For web pages consisting of many small objects, performance often bottlenecks on upload speed, rather than download speed. Also, by spreading static content across four different hostnames, site operators can achieve dramatic improvements in perceived performance."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Erm.. huh? (Score:2, Insightful)
I can see it's use on large sites but this seems aimed at smaller sites.
Then again HTML isn't my thing so it goes over my head I guess.
Re:Erm.. huh? (Score:4, Informative)
Firstly if the ISP has a proxy server then using it will reduce the trip time for some stored content meaning it only has to go over a few hops than prehaps all the way across the world. You can also look at something like Onspeed [onspeed.com] which is a paid for product but compresses images (though makes them look worse) and content and can give a decent boost on very slow (GPRS/3G) connections and also get more out of your transfer quota.
Parent
Re: (Score:2)
Re: (Score:3, Interesting)
5 Seconds to refresh the page on slashdot. That's just to getting the page to actually blank and refresh, there's still then the time it takes to load all the comments.
Sometimes it's near instant, but most of the time it's around about that.
Most of the time is spent "Waiting for slashdot.org", or "connecting to images.slashdot.org".
It used to be a hell of a lot worse, but I installed adblock to eliminate all the extra unecesary connections (google analytics, and the various ad servers). I did
Re:Erm.. huh? (Score:4, Informative)
1 - keepalive/pipelining connections means only 1 dns lookup is performed, often cached on your local machine means this delay is minimal.
2 - the dns lookup can be happening for the second host while connections to the first host are still downloading, rather than stopping everything while the second host is looked up. This hides the latency of the second lookup.
3 - most browsers limit the number of connections to each server to 2. If you're loading loads of images, this means you can only be loading two at once (or one while the rest of the page is still downloading). If you put images on a different host, you can get extra connections to it. Also, cookies will usually stop an object from taking advantage of proxies/caches. Putting images on a different host is an easy to way make sure they're not cookied.
Parent
Re: (Score:2)
We are in the middle of the planning of a software release that rolls out to thousands of users. So that they can access it remotely, we are toying with the idea of supporting 3G PCMCIA cards.
In the area we're benchmarking in, latency and a retarded slow-start windowing algorithm are the limiting factors. Keep in mind that this software is crucial to the company, which is a fairly large one. Adoption
Those tenths of seconds add up (Score:5, Informative)
Parent
Re:Erm.. huh? (Score:4, Interesting)
Just because 1 seconds seems fast, it doesn't mean that it's fast enough to stop improving.
When you reach that 200ms barrier, the interface has perfect responsiveness, a bigger interval is always perfectible.
Parent
HTTP Pipelining (Score:5, Informative)
For those that don't know what that means: http://www.mozilla.org/projects/netlib/http/pipel
I've had it switched on for ages. I sometimes wonder why it's off by default.
Re: (Score:2)
Re:HTTP Pipelining (Score:5, Interesting)
Reference [operawiki.info]
Parent
Some reasons (Score:3, Informative)
Some reasons against pipelining [mozillazine.org].
HTTP/1.1 Design (Score:5, Insightful)
From TFA:
And:
From RFC 2616, section 8.1.4:
It's not a browser quirk, it's specified behavior.
Re: (Score:2)
It has been that way since I had dialup many years ago. It might have been prudent at the time, but now it is sadly outdated.
Things have changed. The popularity of FasterFox, which happily breaks all specifications, is a reflection of it.
I feel that 10-20 is a much more realistic figure now. I haven't seen many webmasters complaining about FasterFox.
Re: (Score:2)
I've seen webmasters complain right on FasterFox's download page on Mozilla Update.
Re: (Score:3, Informative)
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior
Re:HTTP/1.1 Design (Score:5, Interesting)
Parent
Re: (Score:2)
Re:HTTP/1.1 Design (Score:4, Insightful)
Parent
Re: (Score:2)
Re: (Score:3, Insightful)
At the end you have just one pipe to push that data even if you have say 100 connections.
By still having one pipe with certain capacity (i.e. bandwidth) but increasing amount of connections, you're wasting your bandwidth for maintenance of multiple connections.
Also you're wasting the resources of the server for the same reason.
At the end, you're slowing yourself down.
Yes, there are scenarios where using for example 4 connections as opposed to just 1 yields better download performance but AFAIK almost al
Simulation software available? (Score:4, Informative)
What (free) simulation is available for this? I only know dummynet which requires a linux server and some advanced routing. But surely there is more. Is there?
Re: (Score:2)
Re: (Score:3, Interesting)
trickle -d 100 -u 20 -L 50 firefox
should limit download, upload and latency rates.
Re:Simulation software available? (Score:4, Interesting)
Parent
Re: (Score:2)
Sloppy deliberately slows the transfer of data between client and server.
So basically a straight proxy then - only in Java!
Re: (Score:2)
Re: (Score:2)
And it is impossible so simulate faster lines than my current adsl.
Css and Scripts (Score:5, Informative)
I've done some benchmarks and measurements in the past which will never be made public (I work for Yahoo!). And the most important bits in those have been CSS and Scripts. A lot of performance has been squeezed out of the HTTP layers (akamai, Expires headers), but not enough attention has been paid to the render section of the experience. You could possibly reproduce the benchmarks with a php script which does a sleep() for a few seconds to introduce delays at various points and with a weekend to waste [dotgnu.info].
The page does not start rendering till the last CSS stream is completed, which means if your css has @import url() entries, the delay before render increases (until that file is pulled & parsed too). It really pays to have the quickest load for the css data over anything else - because without it, all you'll get it a blank page for a while.
Scripts marked defer do not always defer and a lot of inline code in <script> tags depend on such scripts that a lot of browsers just pull the scripts as and when they find it. There seems to be just two threads downloading data in parallel (from one hostname), which means a couple of large (but rarely used) scripts in the code will block the rest of the css/image fetches. See flickr's organizr [flickr.com] for an example of that in action.
You should understand that these resources have different priorities in the render land and you should really only venture here after you've optimized the other bits (server [yahoo.com] and application [php.net]).
All said and done, good tutorial by Aaron Hopkins - a lot of us have had to rediscover all that (& more) by ourselves.
Re: (Score:3, Informative)
I have also found that cached CSS and Javascript can play with you a little bit. When developing a site you tend to see an expected set of behaviors based on your own experience with a site - but you can find later that having the external files either
Re: (Score:2)
On the other hand, stylesheets are often static and used by many pages, so they could be cached (Opera does this). The same is true of scripts.
Caching of dynamic content (Score:5, Insightful)
Abolishment of nasty long query strings into nicer, more memorable URI's is also something we should be seeing more of in "Web 2.0." Use mod_rewrite [google.com], you'll feel better for it.
Re: (Score:2)
The problem is that things don't usually break if you don't use these headers effectively. In other words, you don't notice that something could be improved.
Pipelining (Score:2)
``Neither IE nor Firefox ship with HTTP pipelining enabled by default.''
Huh? So all these web servers implement keep-alive connections and browsers don't use it?
Re: (Score:2, Informative)
Pipeling means "multiple requests can be sent before any responses are received. "
Re:Pipelining (Score:4, Informative)
Keep-alive no:
Open connection
-Request
-Response
Close Connection
Open connection
-Request
-Response
Close Connection
-Repeat-
Keep-alive yes:
Open connection
-Request
-Response
-Request
-Response
-Repeat-
Close Connection
Pipe-lining yes:
Open connection
-Request
-Request
-Repeat-
-Response
-Response
-Repeat-
Close Connection
Parent
Re: (Score:3, Informative)
Pipelining sends requests out without having to wait for the previous to complete (this does also require a Content-length: header. This is fine for static files, such as images, but many scripts where output is sen
Connection Limits (Score:3, Interesting)
Anybody know why? This seems pretty dumb to me. Request a page with several linked objects (images, stylesheets, scripts,
Re: (Score:3, Informative)
If you have a second webserver for all static data, that can be a simpeler http deamon with 1 Mb/connection or less. You
Requests Too Large (Score:3, Interesting)
``Most DSL or cable Internet connections have asymmetric bandwidth, at rates like 1.5Mbit down/128Kbit up, 6Mbit down/512Kbit up, etc. Ratios of download to upload bandwidth are commonly in the 5:1 to 20:1 range. This means that for your users, a request takes the same amount of time to send as it takes to receive an object of 5 to 20 times the request size. Requests are commonly around 500 bytes, so this should significantly impact objects that are smaller than maybe 2.5k to 10k. This means that serving small objects might mean the page load is bottlenecked on the users' upload bandwidth, as strange as that may sound.''
I've said for years that HTTP requests are larger than they should be. It's good to hear it confirmed by someone who's taken seriously. This is even more of an issue when doing things like AJAX, where you send HTTP requests and receive HTTP responses + XML verbosity for what should be small and quick user interface actions.
Latency (Score:2)
Re: (Score:2)
Whoops. I somehow got confused into thinking that pipelining == keep-alive (despite clicking on the provided link). HTTP pipelining means that multiple re
Re: (Score:2)
Yeah, namely that there are so many sucky web servers and operating systems out there. So what we do? We protect these poor little things by writing their limitations into the standard. I mean, a web server worth its salt is able to cope with many concurrent connections, be they from one client or from many clients.
Gmail (Score:3, Insightful)
The fun is that newer AJAX products from google (like goffice) don't suffer from this behavior, they have a much more cleaner code (just pick view code on your favorite browser and see). Probally Gmail HTML/Javascript is already showing it's age, and paying the price for being a first at google AJAX apps.
Re: (Score:2)
Is this really news? (Score:2)
Also, the reason pipelining is turned off by def
Page load time is still important (Score:2)
There are a lot of posts here asking "why is this important" and saying that pages already load fast enough on their broadband Internet connection. That may be true for you, but I'm frequently in a position where I am designing a site that needs to load over a slow satellite connection in rural Africa, say, or into a remote village in Nepal. They have a fairly recent computer, OS and browser on the recieving end, but their Internet connection is dog slow; anything I can do to speed it up will be greatly a
All the offsite stuff is ads anyway. Block them. (Score:3, Insightful)
This is an excellent argument for ad blocking. The article never mentions the basic truth - almost all offsite content on web pages is ads. (Of course, this is someone from Google talking, and Google, after all, is an ad-delivery service which runs a search engine to boost their hits.) Web page load is choking on ads. I noted previously that some sites load ads from as many as six different sources. This saturates the number of connections the browser supports. Page load then bottlenecks on the slowest ad server.
So install AdBlock and FlashBlock in Firefox, and watch your browsing speed up.
Web-based advertising looks like a saturated market. Watch for some big bankruptcies among advertising-supported services.
Re: (Score:2)
When I click on an element in a web page to manage my email or use a word processor, the response time is going to be around my ping (30-90 ms depending on where in the country it is) plus the time to load. That is long enough that I am clicking, and waiting. If I were working on a local native app, the response time would be under 30 ms and I would probably not even noti
Re: (Score:3, Interesting)
Why? Doesn't your javascript explicitly state document.domain to the common root?
You mean creating four hostnames for the same address? Or do you mean changing a few src="" attributes?