Page Speed Analysis: Search Engine Roundtable

I am planing to do a series of posts on analyzing popular websites I visit frequently. By now I am so obsessed to optimize for speed that I’ve run out of sites to optimize, hence I’m doing it for other sites.

To start with I’ll analyze Search Engine Roundtable.

Before I start, wanna make it absolutely clear that I am not looking to make the site owners or webmasters look bad. Barry Schwartz, editor of SERoundtable.com, tells me “The site is old and is being completely revamped from bottom up.”

About SERoundtable.com :-

Traffic Rank: 5,738 (Alexa), 16,804 (compete)
Browsers : Assuming lesser than average Internet Explorer users based on the nature of the target demographics.

My assumption is that the site targets regular (loyal) readers, so I place more emphasis on repeat views and caching.
The Problem

The website is slow, I access it regularly and loose productivity while waiting for the pages to load.

Page Load times (using WebPageTest.org - here and here):
Page Start Render Load Time
Home Page - First View 1.894s 9.733s
Home Page - Repeat View 0.914s 4.619s
Individual Post - First View 1.539s 11.855s
Individual Post - Repeat View 0.858s 5.171s

Web Speed Rankings (Using Show Slow):-
Page Yslow grade Page Speed score
Homepage D (65) C (74)
Individual Post D (64) C (75)

Visual Latency (tested from Dulles, VA using IE7):

Homepage : 2.5 seconds
Post Page : 2.6 seconds

(The timing I’ve used here is the time at which the page becomes somewhat usable, this in my definition is the time at which the content title and body is shown on the screen. This is the time at which the user can start engaging with the site while other stuff loads.)Sajal Kayan

No Windows, No Gates, It is OPEN; No Bill, It is FREE


* Home
* About
* Links

Page Speed Analysis: Search Engine Roundtable
July 31st, 2010

I am planing to do a series of posts on analyzing popular websites I visit frequently. By now I am so obsessed to optimize for speed that I’ve run out of sites to optimize, hence I’m doing it for other sites.

To start with I’ll analyze Search Engine Roundtable.

Before I start, wanna make it absolutely clear that I am not looking to make the site owners or webmasters look bad. Barry Schwartz, editor of SERoundtable.com, tells me “The site is old and is being completely revamped from bottom up.”

About SERoundtable.com :-

Traffic Rank: 5,738 (Alexa), 16,804 (compete)
Browsers : Assuming lesser than average Internet Explorer users based on the nature of the target demographics.

My assumption is that the site targets regular (loyal) readers, so I place more emphasis on repeat views and caching.
The Problem

The website is slow, I access it regularly and loose productivity while waiting for the pages to load.

Page Load times (using WebPageTest.org - here and here):
Page Start Render Load Time
Home Page - First View 1.894s 9.733s
Home Page - Repeat View 0.914s 4.619s
Individual Post - First View 1.539s 11.855s
Individual Post - Repeat View 0.858s 5.171s

Web Speed Rankings (Using Show Slow):-
Page Yslow grade Page Speed score
Homepage D (65) C (74)
Individual Post D (64) C (75)

Visual Latency (tested from Dulles, VA using IE7):

Homepage : 2.5 seconds
Post Page : 2.6 seconds

(The timing I’ve used here is the time at which the page becomes somewhat usable, this in my definition is the time at which the content title and body is shown on the screen. This is the time at which the user can start engaging with the site while other stuff loads.)

Thus you can see that for whole 2.5 seconds the user is doing nothing but staring at an almost blank screen.

So we have a problem here, unoptimized websites open exponentially slower from across the globe in Thailand especially when using crappy ISPs. So whats the solution?
The Solution

Firstly, kudos to SERoundtable.com for using Source Ordered Content(SOC). This ensures that the title and text of the post is the first thing to render on the page, lesser susceptible to Frontend SPOF. The reason for SOC here may or may not be for SEO purposes, but in terms of page speed this is a valuable optimizations. Also try to move the adslot SER-HOME-468×60-1 to below the content.

Now the things that needs to be changed (In order of importance as I see it) :-

1. Minimize the number of requests : The time taken to load the page is somewhat directly proportional to the number of requests. Most people these days use high speed internet access which basically gives them a higher bandwidth but not better speed (latency). The following steps need to be implemented to reduce the number of requests.
1. Disable Etags and add far futures cache headers for static objects (Easy/Urgent/Obvious): 49 of the 50 requests made to www.seroundtable.com are non frequently changing static files (CSS, images, etc). Currently the browsers send a If-Modified-Since requests to all of them to check if it has changed since then or not. My advise is to send expires headers to at least 7 days( > 30 days preferred) in the future. This would make repeat views amazingly fast. Quite easy to implement cache control in Apache. Etags don’t serve much purpose here, require a tiny bit of CPU for each request, useless information IMHO.
2. Use CSS Sprites (Easy - Intermediate): Request for following files can easily be sprited (after converting everything to either gif or png - png prefered) — nav_previous.gif, nav_next.gif, h2.gif, 3dots.gif, pen.png, sphinn-favicon.png, Twitter-16×16.png, digg-favicon.jpg, barry.png, entry-footer.png, comforminput.gif, comformtextarea.gif, sbauthors.gif, sbarchives.gif, sbmoreinfo.gif, mbg.jpg, sbhome.gif, sbourforums.gif, delicious-favicon.png, google-favicon-16.png, sbtheforums.gif, arrow_yellow.gif, rss.gif, foo.jpg, credits.jpg - Thats a reduction of 24 requests!
3. Use Data-URI for the tiny background files (Advanced/Optional): Embed the tiny background files directly inside the CSS using Data URI Scheme. The drawback is IE7 and below dont support this, the workaround is to use the star hack to send them the current background settings. Another drawback is this would increase the size of the CSS file, but the total size after compression(see below) would be about the same as the current total size. This optimization reduces the need for the following files in all non IE browsers and IE8 — sbbg.gif, formbg.gif, mbg.jpg, sbhbg.gif, sboxbg.gif, tbbg.gif, rcredbg.gif, rcbg.gif, threadlibg.gif, bg.gif, hbgleft.jpg, msep.gif, fbg.gif - Thats elimination of 13 requests! Another advantage is that the css file starts to download much before actual rendering starts, this at the start of rendering, these files would already be available, making the background graphics appear almost instantly without additional blocking of rest of the page.

So Out of 50 requests made to www.seroundtable.com, 37 of them can be completely eliminated for first view, for repeat views almost all but base page should be cached.
2. Enable Keep-Alive(Easy/Obvious): An uncached pageload makes about 50 requests to www.seroundtable.com. For each of these requests, the client must make a new connection with the server. Enabling Keep-Alive can get the job done in much fewer(depends on browsers parallel connection policies) connections, thus saving dozens of round-trips. Enabling keep-alive does increase memory utilization on the server, but the benefits are greater. See this chart, the brown portion of the loadtime can be removed for ~90% of the requests. Here are some instructions for Apache.
3. Optimize each request : Reduce the size of each request/response using the following methods
1. Gzip text assets (Easy/Obvious): About 75% of data transfer for the base page and the css file can be reduced by simple enabling gzip on Apache.
2. Compress images(Easy) : My favorite tool for this is Smush.it by Yahoo! Similar results can be achieved using say GIMP or Photoshop.
3. Use cookie-less domain for static content(Easy/Important): Serve static files(images/css/etc) from an external domain. Currently, the site sets cookies which the browser automatically sends with each subsequent request to the server while requesting static files. This cookie information is absolutely useless to the server and causes the request size to be big. The workaround is to host these files on another dedicated cookieless domain, say www.serassets.com or something. This tip may not sound important, in fact I used to ignore it, but once implemented the effects are HUGE.
4. Minify code (Easy/Optional): Minify HTML, run the inline javascript using Google’s Closure Compiler for faster execution. Smaller files also require lesser resources on the browser.
5. Use a CDN(Easy): A CDN (Content Delivery Network) mantains POPs (Point Of Presence) globally, and can be used to serve the static files(images, javascripts, css, etc) which would be served from a server closer to you. The charges are not much. So if SERoundtable.com used say Internap, I would be accessing the static files from a server in Singapore instead of US. In case of Akamai I’d be accessing the static assets from a server within my ISPs network! Choose any from this list of CDNs.
4. Onpage/rendering optimizations:
1. Choose over @import (Easy): Yahoo! explains it better than I can. Affects usability in IE, delays rendering.
2. Move the inline JavaScript into an external file (Easy): This would make the page load faster for repeat users since the base page would be lighter and the JavaScript file would already be cached in the client’s browser (or at upstream proxy). Make sure to minify the JavaScript (see point 3-4)
3. Move JavaScript to the end (Intermediate): The JavaScript files/codes that are not necessary to be accessed during the page rendering, should be moved to the bottom of the page just before or just before they are needed.
4. Use the Async Google Analytics Code(Easy): The new method really doesn’t block the rest of the page. The current document.write method in the section blocks rendering on many browsers.
5. Move DFP code lower(Intermediate): Right now, the javascript code for DFP is placed within the section, this makes 3 serial blocking requests which must be downloaded and executed before rest of the elements download and render blocking the page for 500 to 1000 ms. My suggestion is to move this just above the first Adblock(the GA_googleFillSlot() calls) in the HTML. This combined with the current Source Ordered Content architecture will ensure that the users will feel minimal impact even if DFP has problems.
6. Try using DFP’s Iframe tagging (Easy but Experimental/Risky): The major drawback to this is that it may mess up expandable ads, which I don’t think SERoundtable.com uses. If you notice the video above, notice starting from about the 4 second mark, currently the 6 adblocks load one by one. With the Iframe tagging, they would load independently, not blocking each other or the rest of the page. A major protection from frontend SPOF due to 3rd party ad networks. Personally I am impressed with the results of this method.
7. Domain Sharding (Advanced): Split requests across several domains like static1.seroundtable.com, static2.seroundtable.com, static3.seroundtable.com, etc to increase parallel downloads. The downside is that this results in increased DNS lookups which is bad. Fortunately there is a workaround to this issue.

Conclusions

Apart from the tips above make sure to read the best practices for faster websites. Most of what I’ve suggested is redundant from the best practices, tailored to this particular website. Lots more can be done, but at the moment compare to what I’ve mentioned above, the effects of additional optimizations may seem like a waste of time.

Just a reminder that I’ve been told that SERoundtable.com is revamping the entire site and it “is really a full revamp from the CMS to the html on the frontend.”.

Implementation of most of the above tips would make at least one reader of SERoundtable.com very happy :).

Total time spent : >= 5 hours.

Appreciate any criticism of my analysis via comments below.

A word of caution to other optimizers, don’t get over obsessed with yslow, Google page speed or page load times, its the visitors experience which matters the most. Optimize for visual latency more than bragging rights!
Shameless Plug

I am available for consulting on web speed issues, contact details in the right sidebar.

Posted in Webmaster Things | No Comments »
ATTN Big Media: Web page speed matters!
July 4th, 2010

I am not a front-end kinda guy, but these days my latest obsession is to test and improve web page loading times. With this blogpost, I intend to show with examples of some selected websites and what are they doing right and what *desperately* needs to be improved. As I learn more about this I will be posting more in-depth posts on these issues.
Why does it matter?

These days almost everyone is on high-speed ‘broadband’ connections so the sites should load fast. Right? No! With faster connectivity, users get more impatient and expect websites to load faster.

E-Commerce websites have done studies which proove faster sites results in more sales. Google has also been advocating to webmasters to improve their pageload times. Now pageload is a signal for ranking in Google, abit a minor signal, but it still matters.

Overall faster websites results in a higher user retention. Faster websites also lower operational costs. Not directly related, but an optimized website is also less susceptible to Frontend SPOF.
Analysis of pageload time

My favorite tool for this is webpagetest.org. They also have an active forum where users can discuss results and exchange tips on making it faster.

Some test results :-
Site Alexa Rank First View Repeat View
My Sites
Main blog page 436,669 1.512s 1.038s
A single post page on my blog. 436,669 0.822s 0.648s
Thaindian.com Homepage 5,368 0.740s 0.514s
A story page on Thaindian News 5,368 4.517s 3.411s
Sites for Geeks/nerds
Stack Overflow 445 2.233s 1.734s
A single thread at Stack Overflow 445 2.846s 2.645s
Slashdot.Org 1,393 3.773s 2.175s
A single thread at Slashdot 1,393 3.817s 2.100s
New media
The Huffington Post 152 6.945s 4.044s
A single post on HuffPo 152 7.563s 4.416s
TechCrunch 357 16.462s 14.760s
An individual post on TechCrunch 357 10.987s 6.764s
ReadWriteWeb 1,996 17.766s 11.643s
A single post on ReadWriteWeb 1,996 18.890s 10.408s
Big media
Google News 1 3.253s 1.365s
Single story on Google News 1 2.688s 1.238s
Yahoo! News 4 3.174s 1.707s
Single story on Yahoo! News 4 5.310s 2.335s
New York Times 91 7.038s 2.200s
Single single story on NYT 91 4.650s 4.507s
BBC 40 7.485s 3.427s
Single story on BBC 40 7.148s 3.851s
CNN 58 10.197s 2.528s
An Article on CNN 58 7.989s 3.523s
MSNBC 9 8.172s 6.638s
Single story on MSNBC 9 12.064s 4.191s
The Washington Post 316 9.878s 3.828s
Single story on WaPo 316 15.435s 4.530s
ABC News 492 14.761s 4.205s
Single story on ABC News 492 8.697s 3.037s
RollingStone 3,376 18.700s 3.572s
An article on RollingStone 3,376 10.707s 2.905s
Fox News 201 26.755s 8.761s
Single story on Fox News 201 16.281s 5.839s

The Sajal Kayan award for excellence in web development goes to FOX News
Test conditions :-

* First View is simulated to act as the first time the visitor visits the website, the Repeat view is when the user visits the website again after a while, probably closes and reopens the browser in between.
* All tests were done on Internet Explorer 8. Yes, I know you hate IE, I hate it more than you! But since the majority of the web uses this browser we test on IE8. Also IE8 performs significantly better than its predecessors. Some of the sites tested may take upto 2x the time to load on IE7 due to lower parallel downloads per host.
* The tests were done from a test machine in Dulles, VA Provided by AOL set to work at DSL speeds(1500 Kbps down, 384 Kbps up and 50ms latency)
* The timings above show when the window.onload event was triggered. It is possible that the page was usable well before that. Very rarely is also possible that for the page needs to do more stuff after onload in order to be usable.
* Each test was repeated 5 times and its average was taken
* I have tried to be as fair as possible in selection of pages for the test. I didnt use pages filled with videos/many images, etc.
* Tests were conducted during this weekend(July 3rd and 4th) so traffic to those site would be much lower than usual.

You can see from the table above, that except for Google News, Yahoo! News and (to some extent) The New York Times and BBC, all other websites have not yet given a minute of thought on Frontend performance of their web pages. This needs to change. Even one of the biggest evangalist of Frontend performance Google, forgot to set correct cache control headers for images on Google News.

I place more emphasis on individual story pages since those are the pages which a first time user would encounter first - coming via search, links, tweets etc…

Now, when browsing un-optimized sites from Thailand, the load times increased exponentially due to a much higher latency and occasional packet loss.

Finally! compare each of the above link visually in IE7 in video mode. WaPo single story is missing due to a bug. For each URL, 3 first-view tests will be run from ‘Dulles, VA - IE7′ and the median run will be used for comparison.
How to improve?

Essential reading :-

* Yahoo! : Best Practices for Speeding Up Your Web Site
* Google : Web Performance Best Practices
* This awesome list of tools

An optimizers goal should not be simply to get the total load time low. Thats important, but more important is the time in which the website kinda becomes usable. This for a news publishing site is being able to display the title and body of the story. The user can start reading the content while other parts of the website loads. This for Thaindian News story page hovers around 0.9 to 1.5 seconds!

Posted in Webmaster Things | 1 Comment »
In a CDN’d world, OpenDNS is the enemy!
May 18th, 2010

While many people are happy with using DNS service providers such as OpenDNS, Google, etc… I will show you here why they may not produce optimal results.

The way most CDNs work is by using DNS routing. When a user attempts to resolve a hostname, the CDN’s DNS server responds with an IP which is closest based on the IP address of the requester. A more detailed insight into the workings of a CDN can be found on an earlier post “Make your own cheap charlie CDN”

For my test here, I tested from the following locations listed below :-

1. True - Thailand : My personal internet connection provided by the ISP called True Internet.
2. Softlayer - United States : A server hosted at Softlayer’s Washington DC Datacenter.
3. EC2 - United States : An EC2 instance at Amazons us-east-1c availability zone.
4. EC2-EU - Ireland : An EC2 instance at Amazons eu-west-1 availability zone. - Thanks Luke
5. EC2-APAC - Singapore : An EC2 instance at Amazons ap-southeast-1a availability zone.
6. Com Hem - Sweden : An ISP in sweden. - Thanks Adam
7. Tata - India : An ISP in India. - Thanks Angsuman

The following DNS servers were used to resolve the domains :-

1. OpenDNS (208.67.222.222 , 208.67.220.220 )- Has different caches in multiple locations(Anycasted) - Chicago, Illinois, USA; Dallas, Texas, USA; Los Angeles, California, USA; Miami, Florida, USA; New York, New York, USA; Palo Alto, California, USA; Seattle, Washington, USA; Washington, DC, USA; Amsterdam, The Netherlands and London, England, UK
2. Google Public DNS (8.8.8.8 , 8.8.4.4 ) - “Google Public DNS servers are available worldwide” . I think Google has their DNS servers in all countries where they have hosting infrastructure.
3. Local DNS - The ISP provided DNS in the different locations.

The test was done to the following CDN providers :-

1. Internap ( cdn.thaindian.com ) - Uses DNS routing. POPs (Point Of Presence) in the following locations : Atlanta; Boston; Chicago; Dallas; Denver; El Segundo; Houston; Miami; New York; Philadelphia; Phoenix; San Jose; Seattle; Washington, DC; Sydney; Tokyo; Singapore; Hong Kong; Amsterdam; London
2. Akamai ( profile.ak.fbcdn.net ) - AFAIK they have a POP in almost all countries including Thailand. Note: Akamai does not entertain sales queries from Thai companies.

Results:-

1) Internap ( using cdn.thaindian.com )
Location Opendns Google Local
IP Returned Ping to IP (ms) IP Returned Ping to IP (ms) IP Returned Ping to IP (ms)
True (Thailand) 64.94.126.65 256 74.201.0.130 365 203.190.126.131 152
Softlayer (US-East Coast) 69.88.152.250 1.253 74.201.0.130 25.69 69.88.152.250 1.388
EC2 (US-East Coast) 69.88.152.250 2.144 74.201.0.130 20.229 69.88.152.250 2.094
EC2 (Europe) 77.242.194.130 13.331 64.7.222.130 159.422 77.242.194.130 12.504
EC2 (Singapore) 64.94.126.65 202 74.201.0.130 228 202.58.12.98 37.260
Com Hem (Sweden) 77.242.194.130 40.035 64.7.222.130 189.647 69.88.148.130 36.310
Tata (India) 64.7.222.130 313.2 64.74.124.65 304.1 203.190.126.131 150

2) Akamai ( using profile.ak.fbcdn.net )
Location Opendns Google Local
IP Returned Ping to IP (ms) IP Returned Ping to IP (ms) IP Returned Ping to IP (ms)
True (Thailand) 208.50.77.112 239.4 60.254.185.83 138.9 58.97.45.59 18.88
Softlayer (US-East Coast) 72.246.31.57 1.312 72.246.31.42 1.262 24.143.196.88 0.877
EC2 (US-East Coast) 72.246.31.73 2.581 72.246.31.25 1.792 72.247.242.51 1.941
EC2 (Europe) 195.59.150.139 13.449 92.122.207.177 29.022 195.59.150.138 13.516
EC2 (Singapore) 208.50.77.94 202 60.254.185.73 71.7 124.155.222.10 7.052
Com Hem (Sweden) 217.243.192.8 51.73 92.123.69.82 35.972 92.123.155.139 13.212
Tata (India) 209.18.46.113 300 203.106.85.33 196 125.252.226.58 100.5

The ping timings represent the lag to the destination server from the location in question. I will try to update the results from more locations if I can get shell access to a server or PC in other countries. If you are willing to run the tests for me please contact me(or post in comments)
Conclusion

Using OpenDNS or Google Public DNS may be fast in resolving the DNS, but they do not give the ideal results.

In the case of Global DNS providers, the IP of the original requester is not passed along to the CDN’s DNS servers so they are unable to route the user to the nearest POP.

As you can see in the result tables above, when using OpenDNS from Thailand, trying to access static assets of Facebook, I am directed to a server in the USA whereas when using Google’s DNS i am directed to a server in Japan and when using my ISP’s DNS server I access content locally, hosted within my own ISPs network!

While the effect on large websites using CDN is significant, smaller non-CDN’d websites are also effected. Most websites embed widgets, advertising and other assets which are likely to be CDN’d.

The solution would be to use your ISPs DNS server rather than these Global providers. If they really suck so bad, its fairly simple to set up BIND as a caching recursive resolver to resolve hostnames directly bypassing the ISPs crappy service.

Bill Fumerola, ex-director of network engineering at OpenDNS confirms this problem on OpenDNS forums.

You can run the tests from your own computer using this simple script: dnstest.py

Here is the named.conf for a recursive server. Set your computer to use 127.0.0.1 as the DNS. - config may differ for you, RTFM and adapt accordingly.

options {
directory "/var/named";
listen-on {
127.0.0.1;
};
auth-nxdomain yes;
allow-recursion {
127.0.0.1;
};
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";

};

//
// a caching only nameserver config
//
zone "." {
type hint;
file "named.ca";
};

include "/etc/named.rfc1912.zones";

include "/etc/named.dnssec.keys";
include "/etc/pki/dnssec-keys/dlv/dlv.isc.org.conf";

EDIT 1: Inverted the axis added test data from Europe
EDIT 2: Added test data from Singapore
EDIT 3: Added test data from Sweden
EDIT 4: Added test data from India
EDIT 5: Added link to Bill Fumerola’s explanation of the problem.