Web Page Analyzer and overall traffic

I the last weeks I used Fiddler to see what is sent over the lines on initial start of a web site and during the web application is running. You can simply mark more than on request line. On the right side you will then see in the Performance Statistics how many bytes are received from the client.

When you have a look at Live.com you will have this result:

When selecting all requests I get about 89 requests at all including all HTML, CSS and JavaScript files, including all images are used for initial display. Switching to the Performance Statistics tab I can see that the client received about 587.113 bytes. If you add the HTTP header for the request and response (each around 500 bytes, depends on the cookie values) you will have a total size about 678.113 bytes.

If you are using a 28,8 modem (3.600 bytes/sec) you will need more than 3 minutes to show this page. I'm currently searching for a tool that will restrict the bandwidth use when accessing a web site (maybe as HTTP proxy) to see current web sites running on slow connections. Yes, you can use ZIP compressing for all the files, and this will speed up the request, of course!

If I think on old days where I was working for an internet agency we used web sites that returned us the total size of each page showing details for all objects (CSS, JavaScript, images,...) used on the page. If you use this the web page analyzer from WebSiteOptimization.com for Live.com your will see a big difference in the total size.

Why do we have this difference? The reason is that Live.com is already using the ATLAS library which will load more files when the page is loading. If you disable JavaScript on your web browser the web page will return only the search bar with a total of about 78.000 bytes.

 

Published Tuesday, April 04, 2006 7:43 AM by Michael Schwarz
Filed under: , , ,

Comments

# re: Web Page Analyzer and overall traffic

Tuesday, April 04, 2006 2:13 AM by blah
You could try Sloppy to slow proxy your connection if you like... It's Java, I've thought about porting it as it's fairly simple, but alas I've not gotten around to it. Anywho, http://www.dallaway.com/sloppy/

# re: Web Page Analyzer and overall traffic

Tuesday, April 04, 2006 3:54 AM by Bertrand Le Roy
Live.com is optimized for cacheability.

# re: Web Page Analyzer and overall traffic

Tuesday, April 04, 2006 4:06 AM by Daniel
Yes, but how do you want to run this with mobile devices? First download 1 MB of JavaScript files...?

# re: Web Page Analyzer and overall traffic

Tuesday, April 04, 2006 8:18 AM by kevin
is there an anti-atlas theme going on here? also, there's gotta be a way to generate an atlas-lite version, similar to those prototype-lite versions, that will help optimize the download.

# re: Web Page Analyzer and overall traffic

Tuesday, April 04, 2006 1:03 PM by Michael Schwarz
Hi Kevin,

no, I love Atlas (maybe because some parts are working very similar), but I'm a little bit frustrated because I get a lot of feedback that web sites are slow using AJAX (with different frameworks/libraries).

Yesterday I got a request that an Ajax.NET method was slower than using the common ASP.NET postback. The problem was that the JSON converted DataSet was about 2.5 MB. Ajax.NET uses the "eval" method to parse the JSON string, and this maybe slower than the ASP.NET runtime needs to parse the viewstate, very interessting.

The main problem I see today is not which framework to use, it is more to find the best way to develop web applications. If a page needs to long with slower dial-up connections then I cannot use this web application. Here in Germany we have about 27% users working with DSL, with this Germany is top 1 in Europe, see http://www.heise.de/newsticker/meldung/70911, so what is the rest of web users using?

Regards,
Michael

# re: Web Page Analyzer and overall traffic

Wednesday, April 05, 2006 12:05 PM by kevin
I here ya Michael. When I started using Atlas I was very tempted to just stop what I was doing and use Ajax.Net - which is much easier to use out of the box. (props to you indeed)

But after digging through the atlas documentation (the slim amount of it that does exist) and then checking out some great examples via ScottGu and some fellow atlas developers (most of the one's that blog well about the Atlas product are on the Atlas Microsoft team I am noticing) I've decided to stick with Atlas as my ajax framework just because it does provide asp.net centric functioanlity (server controls, page level events, etc) and because it's a Microsoft product that they will continue to support and optimize (I assume). Yes, I know Anthem.net (and products similar) do provide similar functionality, etc, etc but I'm just not fully comfortable relying on a community developed product versus a product we know will be supported by Microsoft.

But I am still not confortable with the xml script component. Seems like extra work for those developers who are comfortable with javascript.

Anyway... I digress. Yes, the question comes down to who your users are. I'm lucky in that I know everyone will be on a t1 using a specific browser which makes it a whole lot easier :)

Also, that is very interesting about the JSON issue and Asp.net viewstate parsing.

# re: Web Page Analyzer and overall traffic

Thursday, April 06, 2006 11:05 AM by Michel
You can emulate slow connection with Speed Limiter from Delight (http://www.delight.ch/)