{"id":929,"date":"2009-02-10T17:51:37","date_gmt":"2009-02-10T22:51:37","guid":{"rendered":"http:\/\/alsplace.aldenbaker.com\/alsplace\/internet\/929\/how-to-make-your-website-really-really-fast\/"},"modified":"2009-02-10T17:52:24","modified_gmt":"2009-02-10T22:52:24","slug":"how-to-make-your-website-really-really-fast","status":"publish","type":"post","link":"http:\/\/alsplace.info\/?p=929","title":{"rendered":"How to make your website really, really fast"},"content":{"rendered":"\n\n

February 9th, 2009 <\/h4>\n

Posted by Andrew Mager<\/p>\n

Steve Souders<\/a> knows how to make a website speed through a web browser.<\/p>\n

cialis ejaculation<\/a> href=”http:\/\/www.flickr.com\/photos\/mager\/3267072847\/” title=”Steve Souders from Google by magerleagues, on Flickr”>\"Steve<\/a><\/p>\n

And he works at Google<\/a>, one of the fastest websites around.<\/p>\n

Web performace is a two-pronged beast: efficiency and response time. Efficiency deals with the scalability challenges of building a top 100 global website. You have millions of users and billions of page views, and it’s awe-inspiring to understand the full scope of the backend architecture of something that large.<\/p>\n

The set of directions that the HTML document gives to every process really determines the speed of the page.<\/p>\n

On iGoogle<\/a> for example, only 17% of the page is backend, non-cached data and needs to be requested each time. The rest is front-end processing.<\/p>\n

80-90% of the end-user response time is spent on the front-end. Start there when you want to figure out how you can make your site faster.<\/p>\n

If you can cut this front-end time in half, your users will notice it.
Offer greater potential for improvement and notice simple performance tweaks on the backend too.<\/p>\n

14 tips for performance<\/h2>\n
    \n
  1. \n
    Make fewer HTTP requests<\/div>\n<\/li>\n
  2. \n
    Use a CDN<\/div>\n<\/li>\n
  3. \n
    Add an Expires header<\/div>\n<\/li>\n
  4. \n
    Gzip components<\/div>\n<\/li>\n
  5. \n
    Put stylesheets at the top<\/div>\n<\/li>\n
  6. \n
    Put scripts at the bottom<\/div>\n<\/li>\n
  7. \n
    Avoid CSS expressions<\/div>\n<\/li>\n
  8. \n
    Make JS and CSS external<\/div>\n<\/li>\n
  9. \n
    Reduce DNS lookups<\/div>\n<\/li>\n
  10. \n
    Minify JS<\/div>\n<\/li>\n
  11. \n
    Avoid redirects<\/div>\n<\/li>\n
  12. \n
    Remove duplicate scripts<\/div>\n<\/li>\n
  13. \n
    Configure ETags<\/a><\/div>\n<\/li>\n
  14. \n
    Make AJAX cacheable<\/div>\n<\/li>\n<\/ol>\n

    YSlow<\/a> is a Firebug<\/a> extension that gives developers the chance to analyze every slow part of your website and test it against the 14 points mentioned above.<\/p>\n

    O’Reilly Velocity<\/a> is a web performance and operations conference co-founded by Souders and Tim O’Reilly. There should be some really good talks this year.<\/p>\n

    Souders also taught a class at Stanford called High Performance Websites<\/a>.<\/p>\n

    Why focus on Javascript? They have a huge impact on the page load time.<\/p>\n

    \"Time<\/a><\/p>\n

    AOL has about 5 scripts accounting for about 60 or 80% load time.<\/p>\n

    \"Why<\/a><\/p>\n

    Facebook has about a megabyte of Javascript.<\/p>\n

    \"Why<\/a><\/p>\n

    JS is downloaded sequentially, even if the HTML document has already been downloaded. It won’t draw anything on the screen unless the script is finished downloading.<\/p>\n

    Cuzillion<\/a> is a tool that does batch testing on webpages.<\/p>\n

    \"Cuzillion<\/a><\/p>\n

    HTTPWatch<\/a> is his preferred packet sniffer.<\/p>\n

    If you can split the Javascript in what’s needed to render and “everything else”, you will dramatically improve your page load time. Microsoft has a whitepaper that talks about how this can be done automatically with something called Doloto<\/a>. Look at the source code of MSN.com and see how they do it.<\/p>\n

    \"Steve<\/a><\/p>\n

    But even if you can split the initial page load, you will still have external scripts that will have an impact on your page.<\/p>\n

    There are many ways to make your scripts load all at the same time. XHR evaluation is an option but you are open to XSS<\/a> attacks and all scripts must have the same domain.<\/p>\n

    \"Fast<\/a><\/p>\n

    Putting a script in an iframe causes the JS to be downloaded in parallel with other resources on the page. You can use the DOM method for creating the head element using createElement<\/a>.<\/p>\n

    Try the <script defer src="file.html">. This works in IE and FF 3.1, but it’s not the best method. Domains can differ and you don’t have to refactor your code though.<\/p>\n

    Don’t even use the document.write method. It’s terrible for many reasons.<\/p>\n

    It’s always good to show busy indicators when the user needs feedback. Lazy-loading code sucks, but the user needs to know that the page isn’t done.<\/p>\n

    Ask yourself three questions:<\/p>\n