Go to this page... and wait... and wait... okay, now right-click and select View Source... and wait... and wait... okay, now check out the file size and line count. You should see (assuming you are using Notepad2 or some such editor) this:
In what reality is rendering a 1.02 megabyte, 3120 line page reasonable? Certainly not over the web! No wonder all these MSDN2 pages take forever to render.
Posts
Comments
.Net
(35)C#
(20)Microsoft
(18)Dynamic
(16)LCG
(16)lightweight code generation
(15)DynamicMethod
(14)SQL
(14)CodePlex
(13)fun
(13)Asp.Net
(12)IL
(9)best practice
(8)bug
(8)DateTime
(7)personal
(7)Emit
(6)RSS
(6)blinding science
(6)MethodInfo
(5)Reflection
(5)CLR
(4)RssToolkit
(4)URI
(4)UriTemplate
(4)exception
(4)DataSource
(3)GetHashCode
(3)IFilter
(3)LocalDB
(3)ObjectDataSource
(3)REST
(3)SQL Server 2005
(3)UriPattern
(3)Web design
(3)books
(3)code review
(3)cool
(3)funny
(3)job
(3)meme
(3)rant
(3)Annoyances
(2)Backup
(2)COM
(2)DATEADD
(2)DATEDIFF
(2)DynamicComparer
(2)HTML
(2)IDL
(2)Internet Explorer
(2)MVC
(2)Politics
(2)Serialization
(2)Source
(2)TFS
(2)Team Foundation
(2)Utilities
(2)Visual Studio
(2)end of month
(2)interesting
(2)javascript
(2)kids
(2)music
(2)rants
(2)zebra fun
(2)ArgumentValidation
(1)Atom
(1)C++
(1)CDN
(1)CSS
(1)CompareTo
(1)Connect
(1)Crypto
(1)Cryptography
(1)DRM
(1)Database
(1)DisposableAction
(1)Double
(1)Enterprise Library
(1)EntityFramwork
(1)Enum
(1)Equals
(1)FCL
(1)GitHub
(1)HotFix
(1)IE
(1)IIS
(1)IP Address
(1)Insert
(1)Ladybug
(1)Localization
(1)Locks
(1)Nullable
(1)OperationContext
(1)RDF
(1)Random
(1)Recovery
(1)Restore
(1)SOAP
(1)SQL Server
(1)SQLServer
(1)SSDS
(1)SSO
(1)SVG
(1)Secunia
(1)Shelveset
(1)Sidekick
(1)Single sign-on
(1)UDT
(1)UndoableAction
(1)Vista
(1)WCF
(1)WF
(1)WTF
(1)WebForms
(1)Workflow
(1)XEN
(1)XML
(1)antivirus
(1)architecture
(1)authentication
(1)cURL SQL Server Data Services
(1)concurrency
(1)delegates
(1)generic
(1)goodbye
(1)injection
(1)patch
(1)patterns and practice
(1)performance
(1)provider
(1)query notifications
(1)references
(1)sad
(1)stupid studies
(1)thread
(1)thread-safe
(1)tools
(1)validation
(1)visualizer
(1)whatwg
(1)
7 comments:
So, do you think that you are better than that?, start up fiddler, an test the relevant page, and test you of blog-page.
The MSDN page makes 14 request, but yours uses 67 request.. that's a lot.
The total downloaded amount from MSDN is 1149437 bytes in my case, and from your page it is 711906, not very big difference. And it takes even longer to render than MSDN because of all the silly stuff on the page.
So, clean your own backyard before yelling on others..
(I know you are using blogger, so you are not guilty of the full page, but alas..)
To be fair, you should compare a single-post page to a single article page from MSDN. This post, for example is just 211K. Most of that is the blogroll on the right side of the page which I am thinking of eliminating and that is served dynamically as the page is rendered, not inline HTML.
As you note, much of the rest is due to the fact that this is hosted by Blogger.
My own ASP.Net pages rarely have viewstate over 150 bytes, unlike the MSDN pages, and the my page menus nodes are dynamically loaded on demand, unlike the enormous MSDN treeview, which is present, and redownloaded for each page.
The VIEWSTATE size is ~130kb! And the Html+JS code size for the tree ~836Kb! Well, that's not nice! :D
Note that the HTML downloaded for the table of contents is only displaying the table of contents that you see. Whenever you expand a node, it retrieves more and redraws the table of contents. Unfortunately, the System.Web.UI.WebControls namespace is huge with hundreds of classes.
Hey Marc,
Well I'm glad you pointed this out, it shocked me too. I did some digging around here at MS and got an answer as to what's being done about it. Here's the reply from the MSDN doc team. -Noah
From the MSDN side, we’re using a few approaches. First, we turned on GZIP compression of pages a couple of weeks ago. Obviously this doesn’t change the size of the HTML itself, but does significantly speed up the pace at which it goes over the wire.
Next, we are planning several changes in August that should address the root cause: turning off viewstate, using an adapter to emit CSS instead of the default table-based TreeView and looking at an Atlas panel to populate the TOC after the page load (this last one real makes the pages feel snappy although doesn’t directly hit the size concern).
Lastly, I’ve asked a few folks to consider deepening the managed ref TOC such that namespaces were nested instead of all lying flat as they do today and that may be something considered for Orcas.
Please keep in mind that the CSS adapter may not pan out perfectly (it has a strange habit of trying to expand every single node) and it may an iframe rather than an Atlas panel in August. The underlying message remains the same: we know these are big pages and we are trying to get that size down.
Noah, thanks for dropping the teasers about the upcoming changes. Mostly, though, I appreciate knowing that Microsoft is listening. We're out here on the front lines trying to "do it the Microsoft way", and lately I've been feeling that something is out of sync. Your (and other Microsoft people I've been in contact with lately) interest, openness and efforts to really deal with these issues is a new and exciting change.
Ack! Did someone from microsoft say GZIP? as in GNU Zip? Haha. Sorry, I couldn't resist. Where's our copy of the GPL with that gzipping algorithm?
Ok. I'm done. That was fun.
Post a Comment