digg

Join DiggAbout

Discover the best of the web!
Learn more about Digg by taking the tour.

Optimizing HTML Page load time

die.net — Google engineer Aaron Hopkins has written an interesting analysis of optimizing page load time.

Bury
show profanity settings
expand all
  • koretico, on 10/12/2007, -1/+7just read it and the issues this article highlights are really interesting, from the both sides of the web development (requesting/serving)
    a must read
  • slasherx, on 10/12/2007, -1/+10If you've seen the html/javascript source for google, you don't have to be a genius to know that the only method they implement is minimalism in their source. And it seems to be working pretty well for them.
  • axel2k, on 10/12/2007, -2/+13How ironic that this appears on the digg front page...
    • AlanKc, on 10/12/2007, -18/+3Ironic?
    • axel2k, on 10/12/2007, -5/+14Uh, yes... ironic. The digg front page takes quite some time to load. Do I really have to explain it? Geez...
    • dbr_onix, on 10/12/2007, -4/+3I think what axel2k meant to say was, it's ironic this article got to the front page of Digg, that is.. erm, not exactly optimized (Loading digg takes far too long)
      ..okay I didn't state that particularly well either
      - Ben
    • AlanKc, on 10/12/2007, -2/+2"Uh, yes... ironic. The digg front page takes quite some time to load. Do I really have to explain it? Geez..."

      I don't know what the hell your talking about, but front page has never taken that long to load for me (Ive got verison DSL, there cheapest service). Maybe you should up grade from dial up.
    • slashdotislame, on 10/12/2007, -0/+2Digg seems to have 200kb+ of dynamic page loading for EVERY CLICK YOU MAKE!. Javascript can be cached, css can be cached - why doesn't digg do this?. Is it to create a larger bandwidth to look important? Or are the devs just lazier than most?
  • RyeBrye, on 10/12/2007, -1/+11If you also try to validate Google's page - it isn't valid xhtml... so I guess breaking standards may be one way to optimize your site.
    • Loath, on 10/12/2007, -4/+5You usually need a considerable amount less code if you aren't trying to be validated. The major browsers are forgiving, so it's really not that important unless you want to be some pompous Web 2.0 site.
    • pengu, on 10/12/2007, -9/+2or god forbid you understand WHY you should follow standards. god forbid you care about a browser that isnt as "forgiving" for dodgy ***** like yourself.

      you keep writing your dodgy non-compliant code, and the rest of us will write code that conforms to the standards, and is actually accessible.
    • slasherx, on 10/12/2007, -0/+8@pengu

      Well the thing about google is that it's so simple that they can break standards and still have their site render perfectly in most browsers. A centered image, a centered submit and text input and that's pretty much it. For google they can get away with it, but for other sites that wish to render the world, they have to follow the standards to get it working properly.
    • Loath, on 10/12/2007, -2/+3@pengu

      "you keep writing your dodgy non-compliant code, and the rest of us will write code that conforms to the standards"

      The rest of who? I design websites for a living, and I come a lot closer, than most others in this occupation, to keeping a uniform standard and still maintaining compatibility between browsers. I bet you wonder why race car drivers don't go the speed limit.
  • Subcide, on 10/12/2007, -1/+11I always find digg really slow to load. Don't know where the bottleneck is though...
    • dbr_onix, on 10/12/2007, -1/+11The number of scripts, around 20 different .js files are loaded..
      - Ben
    • tagawa, on 10/12/2007, -0/+2Try speeding up page rendering and enabling pipelining (if you're on broadband) in Firefox:
      http://www.mozilla.org/support/firefox/tips#oth_rendering
    • zacmccormick, on 10/12/2007, -0/+8Digg has a lot of javascript executing after the page loads, and there are 10 js script references on every page, including prototype and scriptaculous, which augment the javascript environment which takes quite a bit of resources (and has to be done on every page load). Pages with comments are even slower to load because every single comment div has multiple events attached to it (not to mention how verbose xhtml is to begin with). They might be able to get it a little faster with some intelligent bootstrapping of their javascript code, and stream in the client script that isn't needed for initialization once the page loads. That might not be worth it, depending on how much code that ends up being. Also, IE users probably experience even slower refresh times because of the onunload hacks required to fix the cyclic COM reference memory leak in IE (or else IE will eat up 100's of MB of memory after a few refreshes). Most of the slowness I experience on the web now is because some page has an absurd amount of script executing and the page freezes up for a few seconds when it loads. Either that or it's 9PM and youtube is just plain slammed :)
    • everling, on 10/12/2007, -0/+1The most quickest methods that digg can do to fix their page load time are:
      - to combine all their javascript files (17) into one javascript file
      - to combine all their css files (4) into one css file
      - use CSS sprites
      - set their files to expire sometime in the future

      Right now, it's all set to expire in 1970. So that's why things don't improve even if you're a frequent visitor. Surfing digg with CSS and JS blocked (I use a proxy server) makes for a very responsive digg.com, except that you can't contribute.
  • bpapa, on 10/12/2007, -1/+1It's pretty funny that an article about reducing load time of HTML pages bloats a page by adding javascript to it. :)

    Anyway this is a good article besides that, a very interesting scientific approach. Dugg for that.
  • Dotnetsky, on 10/12/2007, -0/+1Eh. My pages load instantly; I use the Telepathy API. So who cares?
  • dirq, on 10/12/2007, -0/+0The article makes some very good points and is definitely worth reading if you have a few minutes.

    There are a lot of other things that a developer can do to speed up page loads. They can start by taking out extraneous characters from their html and javascript, such as spaces and tabs, and shorten IDs and variable names. That can save LOTS of bandwidth right there.

  • dunkin, on 10/12/2007, -0/+1Ah, had to laugh at the 'bad' DSL in New Zealand reference. Theoretically it's now uncapped... just hope a rat doesn't chew threw a wire and bring down the whole country like last year.

    Apart from that, this article was way over my head. I just keep external requests to a minimum and use compression. The Expires Header was interesting angle though.
    • burke, on 10/12/2007, -0/+4Basically it boils down to this:

      Most browsers will only download 2 items from a site at a given time to try to be nice to the server. If you don't care, you can trick the browser by telling it to load everything from a different domain name. This way, you can get the browser loading up to 8 objects at a time (in IE's case)
  • JacNet, on 10/12/2007, -0/+2Gzip, anyone?
  • chatdam, on 10/12/2007, -4/+1I don't have to be a genius to know that the only method they implement is minimalism in their source.

    http://www.siamaffiliate.com/
  • ellisgl, on 10/12/2007, -0/+0http://www.alentum.com/ahc/index.htm
  • tpowell, on 10/12/2007, -0/+0Helped to write a similar article a number of years ago that talks about the various code minimization techniques they use in HTML, JS, etc.

    See http://www.port80software.com/support/articles/developforperformance1

    That firm eventually built the http://www.w3compiler.com which does much of that automatically for you.

    I would disagree with the comments that it is just source minimization it is actually everything together but if you had to pick one thing it would be cache control headers that will cause the jaw drop (at least on revisit) and compression (both gzip and source or better both) which is the big deal on single visit.
  • tpowell, on 10/12/2007, -0/+0To break up the conspiracy on Google ignoring W3 standards....

    The obvious purpose of Google's breakage of standards markup on the home page is to fit inside of a single TCP response packet at least when Gzip compression is applied since packet fragmentation would in effect double the used bandwidth even if the packet is mostly "air" At least it was that way at first when I first looked into this, some tweaks to their source may have ruined that, but it was pretty clearly the goal since you could have white space optimized further but once you are below single packet size what's the point since it effects nothing.
  • truckjack, on 10/10/2007, -0/+0Very usefull article! digg it
  • eastwoodjans, on 10/10/2007, -0/+0dont waste your time, just use compression on your server
  •  

    Login or register to add a comment

    Create a new account or login to join in the conversation on Digg. You'll also be able to Digg stories to help promote things you like.


© Digg Inc. 2008 — Content posted by Digg users is dedicated to the public domain.
DIGG, DIGG IT, DUGG, DIGG THIS, Digg graphics, logos, designs, page headers, button icons, scripts, and other service names are the trademarks of Digg Inc.