Slashdot Mirror

← Back to Stories (view on slashdot.org)

The ASP.NET Code Behind Whitehouse.gov

Posted by kdawson on from the netcraft-confirms-it dept.

An anonymous reader writes "The author looks at the markup for the new whitehouse.gov site, launched today. It uses ASP.NET and various JavaScript libraries. It suffers from various inefficiencies, most easily remedied. Check the images and techniques used to build the site front-end."

3 of 143 comments (clear)

  1. Re:This page is a way by ergo98 · · Score: 3, Interesting

    for the author to show his superiority to the Internet. None of what he cites really matters.

    True enough. Indeed, the page in question actually validates as XHTML Transitional which is something that is remarkably rare and shows a concern for craftsmanship.

  2. New robots.txt file by Cyclopedian · · Score: 5, Interesting

    The switchover of the whitehouse.gov site also meant that the robots.txt file has changed. From around 2400 lines to just 2 lines: http://www.kottke.org/09/01/the-countrys-new-robotstxt-file

    --
    /.'s 10 Millionth
  3. Pick the low hanging fruit. by mr+sharpoblunto · · Score: 3, Interesting
    Most of the optimization suggestions in TFA are going to offer no real performance benefit. With gzip on, whitespace, long ID's & viewstate make pretty much no impact on the final page weight, but doing these "optimizations" is going to make your page a hell of a lot harder to maintain. Don't believe me, go to webpagetest.org and have a look, HTML accounts for only around 5% of the final page size. The best thing these guys could do to optimize the site would be to
    • combine the css and javascript files.
    • minify the javascript (as it is its taking up around 20% of the page weight)
    • perform more aggressive css spriting of the gif and jpeg images to slash the request count further.
    • remove ETag headers and add far future expiry headers to the images to speed up repeat page views and cut down on 304 responses from the server.

    Who cares about a 30 byte http header when your page is over 800k and ~45 requests, there's plenty of low hanging fruit to pick first. Interesting thing is in the post above a tool called the rpo is mentioned, it seems to do most of the important optimizations automatically.