 |
|
 |
Gzip is the way to go. Removing extra tabs and spaces will not help much with gzip.
|
|
|
|
 |
|
 |
What he provided is not an alternative solution to compression, it is how to reduce the size of the page what ever with compression or not, it is always better to minimize the size of the page as much as possible even if you are using the compression specially if wasted spaces like Tags spacing
|
|
|
|
 |
|
 |
Few Questions:
1. How much size you can reduce by doing this?
2. How much loading time you can save by performing such string operation?
I don't want to play with my Html Output on or after render because my inline JavaScript code doesn't work some times.
|
|
|
|
 |
|
 |
This is not good advice/approach.
Use built-in web server / asp.net features (Gzip)
|
|
|
|
 |
|
 |
What about 1st reduce the size with this and then use Gzip ?
Besides Gzip requires more CPU utilization both in server and client side.
On low end machines, the browser looks still loading until the data is decompressed.
And the browser's HTML parser can save some time for trimming these white spaces and extracting and needed HTML for rendering.
|
|
|
|
 |
|
 |
No, you cannot just remove whitespace, sometimes it's actually significant.
Off the top of my head, the <pre> tag comes to mind - I use this quite often for code snippets.
Look here
this is code line one
line two indented four spaces
line three indented eight spaces
line four indentet two spaces
and no indentation in line five
Removing viewstate and using compression is the way to go.
|
|
|
|
 |
|
 |
Yes you are rite. But u can simply extend this to override the PRE tags.
|
|
|
|
 |
|
 |
I cant give you high marks because this is not the best way to reduce page size.
The following two ways are the best:
1) Dont retain ViewState in the page, turn that off and retain ViewState on the server (in memory or SQL server) instead. There is an article on MSDN on how to implement this. ViewState is frequently very HUGE in .NET pages.
2) Turn on IIS HTTP compression for your web site, this is a very simple no-code-involved way to reduce page weight on the network transport. Browsers will decompress pages delivered by web servers implementing standard compression.
The method you present is really not the best approach, but nice try at solving the very important problem of page weight. .NET brought about many great changes, but retaining ViewState in the page payload was a big mistake in my opinion, fortunately there is a way to keep ViewState out of the page. It becomes especially bad when users need to HTTP POST a large page, as .NET only supports one FORM tag per page, posting all or nothing including the ViewState.
|
|
|
|
 |
|
 |
Ofcourse there are other ways. Just only an additional technique to further reduce the size. See Orkut.com's view source
|
|
|
|
 |
|
 |
Hi,
This is not a bad technique, but you can also apply the same methodology by writing a response filter and handling it within a HttpModule. That will mean that you will not need to inherit a new class for all your pages and retrofit this to existing sites.
We have also been able to move and compress the viewstate using this method.
|
|
|
|
 |
|
 |
Thanks for the suggestion.
|
|
|
|
 |
|
 |
Bad advice, IIS compression is the way to go, as well as not retaining page view state in the page, keeping view state on server will reduce page size.
|
|
|
|
 |
|
 |
Ofcourse I know this technique is not the only way to reduce the page size.
Only an additional technique, dats all.
|
|
|
|
 |
|
|
 |
|
 |
Is there any reason why you are using sb.AppendLine(data) insted of sb.Append(data)? By using sb.Append(data) you can shrink the page more.
|
|
|
|
 |
|
 |
Yes there is a reason. Consider below html fragments
<a href="/script/Content/Chapter.aspx?chptId=1"
onclick="return ToggleMenu('Chapter1')>My Content</a>
or
<a href="/script/Content/Chapter.aspx?chptId=1" onclick="return ToggleMenu('Chapter1')>My
Content</>
If you use Append instead of AppendLine then final html will be like as below
1. href="/script/Content/Chapter.aspx?chptId=1"onclick="return
2. MyContent
The spaces inside the HTML tags will also get trimmed, that may cause unexpected output
|
|
|
|
 |
|
 |
Hi guy,
I think you should give us a sample to show how many seconds your technique reduced.
eg: the normal loading time,and your special laoding time
|
|
|
|
 |
|
 |
Will give u a comparison shortly.
|
|
|
|
 |
|
 |
Update the code as below
protected override void Render(HtmlTextWriter writer)
{
using (HtmlTextWriter htmlwriter = new HtmlTextWriter(new StringWriter()))
{
.........
Existing code
.........
}
}
|
|
|
|
 |
|
 |
Just enabling GZIP will do wonders for you, you really do not need to think about removing the white spaces and all.
|
|
|
|
 |
|
 |
That raises two problems: CPU utilization and output caching. Myself, for one, can't use http compression because of those two.
My point is: don't take things for granted, it just shows you're lazy.
Nice article, can't wait to try it.
---------
Andre Sanches
"UNIX is friendly, it's just picky about its friends"
|
|
|
|
 |
|
 |
Agreed.
Just to make this discussion more complete, in the IIS there are levels for gzip from 1-10. I think if you really do not want batter your cpu you can set it to low. For most people 8-9 kind of works optimally, but may be 2 or 3 will be good for the CPU's your are using.
There is another idea where like in this article your are sending the stripped version of your HTML page you can send the gzipped version, but the page it self gzipping. I think this can take care of the page output caching.
Anyway this are some of the options I am providing over here.
As with everything else, this might not be the solution for everyone.
|
|
|
|
 |
|
 |
Where it came from the variable "htmlWriter"
|
|
|
|
 |
|
 |
Thanks for pointing it out...missed some code..
|
|
|
|
 |
|
 |
This is my 1st in codeproject...do u have any idea how to modify the article ?
|
|
|
|
 |