I have prepared a graphical proof of the type of optimization I suggested a couple of days ago in my post ASP.NET menu control optimization. I just saved into plain txt files the following requests:
- ~/default.aspx: The original menu sample page without any optimization
- ~/default-optimized.aspx & ~/resources/menu-js.aspx: The optimized version that split menu related html to an external client-cacheable file (that is requested only once).
Then, I opened those .txt files with MS Word, and reduced the font-size to 6,5 for all of them (to keep the number of pages to a reasonable number), and did some highlighting:
- Green: The useful real contents of the page.
- Red: The __VIEWSTATE variable.
- Blue: Menu related code.
- Light blue (in menu-js.aspx): Parsed & modified menu related code converted to a javascript string to be written by browser directly.
~/default.aspx
As you can see in the original non optimal version, the page is mostly filled with content related to the menu and __VIEWSTATE variable. The worst part of this original implementation is that in all the pages, 70%-80% of the contents is the same. The client's browser is downloading mostly the same contents once and again. My idea consists in taking that common factors out of the pages and place them in a single different cacheable page.
~/default-optimized.aspx
In the optimized version, menu related code is reduced drastically (blue). Content with white background is masterpage related code (formatting).
~/resources/menu-js.aspx
Most of the menu-related code is moved to an external file that is requested at the end of the masterpage. That file is client-side cached and thus requested only once per session. The result is that only pages with optimal contents are downloaded afterwards.
If you like this approach and want to see the whole post explaining the idea in detail, with source code project and all the stuff, see my previous post ASP.NET menu control optimization.
No comments:
Post a Comment