Speeding Up Applications

There are tons of reasons why a site displays very slow, or the page loads very slowly.  I’ll discuss some of the reasons and some fixes that I may know of here.

I have known from experience that though it may be tough for beginners to learn coding itself, it is much harder to maintain and sustain codes over changing needs and requirements.  True?  Well, yes for experienced coders already.  Newbies, be ready for these course of actions in the future.

Okay.  Let’s take a very common scenario.  You love doing Friendster, Multiply, and Youtube.  True enough for most, I guess?  Yes.. and designing pages from herein is quite easy.  You’ll love to overload the page with blingy , glittery images, videos and stuffs.  Then you access your page, and it loads friggin’ slow, and you put the blame to your DSL provider.  Common.  You think of starting your own page and feel the freedom of overloading info into your page.  Now, you put in all the desired images, use the desired layout, and put tons of media to make your page more enjoyable.  Pretty.  Now here comes the dilemma.

At first, you enjoy the beautiful page and savor the beauty of your own site.  But soon, you get more visitors, and you get slower loading.  Why?  You didn’t do anything wrong, and here you thought that you have already trimmed down the stuffs you wanted to put.  Now how do you go about this?

Different sites require different approaches, but you feel that you shouldn’t be a part of this hustle and bussl; but in truth, you own a site, then you’re a part of it too.  Now, here’s to my 2 cents’ worth of rescue.  You need to refactor some code, consider learning some network hacks, SEO, and even some graphics hacks.

To experienced developers, the first thing that you think about is caching.  By definition, "cache" is:

Memory that holds copies of recently accessed data. Several Web browsers keep recently viewed pages in a cache so users can return to them quickly without suffering network delays.

– www.tamu.edu/ode/glossary.html

• Save space by cutting down CR/LF and on tabs and spaces. Not just as a part of Accessibility issues, and File size, but removing excessive line breaks can also have effects on different browsers.  IE, for example reads CR/LF and spaces that may appear as breaks for images that are held together by code.  Also, if you must provide readability, use tabs instead of spaces.  But later, you’ll see that this tip must also conflict with another tip.  Choose what suits you best.
• While XHTML forces every programmer to be organized, it is slower than Strict HTML. If you are worried about speed more than organization, then I suggest, drop the XHTML and move to Strict HTML instead.. Its a lot faster.  Although it has its benefits, some might not actually need to work on XHTML (and besides, IE doesn’t really render XHTML very well).  Take your pick, you should know best.
• Cookies versus Sessions As much as you can, please use sessions instead of cookies.  Cookies are transmitted to your site for every requests, and therefore require more computing process and latency.  If you must use cookies, keep them to a low, and don’t forget to expire them.  Use time expiry that will only amount to the total time that the cookie will be needed.
• Use Content Delivey Networks If you must use a lot of images, and/or media, use content delivery networks.  There are a lot of these available, with varying costs.  I recommend use of S3 of Amazon.  Use of their services, will allow clients all over the world to access your data from the nearest data center, thereby reducing latency of page rendering.
• Minimize HTTP requests Separate images require different loading times each. Move some of your image declarations in your CSS as background-images.  Or, you can also use imagemaps to cluster similar images or images close to each other, as one.
• Keep your page components small CSS and Javascripts are usual page components.  Keeping them small may cause you to save time retrieving them.  Remove unnecessary documentations and comments.  Documentations can be put in your archive section of files, not in your production environment.
• Add an expires header to your page components This can be done to your stylesheets, javascripts and pages themselves. When this is set, the HTTP requests can cache the component until the Expires time.  The web server can also do this if the ExpiresDefault directive is turned on.
• Enable HTTP compression I’m not really sure how this should be done in IIS, but Apache supports the mod_deflate module.  This provides the DEFLATE output filter that allows output from your server to be compressed before being sent to the client over the network.

  Gzip is the most popular and effective compression method at this time. It was developed by the GNU project and standardized by RFC 1952. The only other compression format you’re likely to see is deflate, but it’s less effective and less popular.

  Gzipping generally reduces the response size by about 70%. Approximately 90% of today’s Internet traffic travels through browsers that claim to support gzip. If you use Apache, the module configuring gzip depends on your version: Apache 1.3 uses mod_gzip while Apache 2.x uses mod_deflate.

  –Developer.Yahoo.com

• Avoid using Tabled Layouts Only use tables for tabular data. Use Divs along with CSS style declaration, never for design and layout.  If there is a bulk of computation that is falling in one grid, then it will delay the progressive render of the rest of the page.
• Put Stylesheets at the Top and avoid CSS expressions If you put the stylesheets at the head, then the styles will be rendered for the content progressively.  The client will then have to view the content immediately rather than waiting for the page to be completely rendered (including scripts).  CSSes can also contain expressions, although its advisable not to use them, since these stylesheets are more often found in the head portion of the page, and might cause delay of page loading.
• Put scripts at the bottom I haven’t really tried this, though I most understand that the logic is that each and every script declared at the head, is loaded before any of the content.  I suggest that you put only the scripts that will be included in the "onLoad" and include each of the scripts as it is needed in the body.  This will definitely save time in the loading of the page.
• Avoid timeouts and delays in scripts Different applications define different strategies.  For whatever purpose that timeouts and delays should serve, they must never be used in scripts that get loaded in the head or your document or upon loading of the document.
• Put scripts and stylesheets in external Since we’ve been talking about saving time in page loading, let’s also consider caching done by the browser.  When you call in your page from the browser, it gets cached locally into your computer until you delete your cache (or temporary files).  Putting your stylesheets and scripts in external location (relative to the file being loaded) will allow the browser to cache these components for future use (consider loading of another page that uses the same set of components).
• Reduce DNS Lookups Say if you have tons of buttons and badget in your sidebar, consider hosting the images in your directory for faster rendering.  This would mean lower latency for lookup of the domain name where the element resides.  Or if you have your images pointed in another subdomain, why not consider putting it somewhere accessible from the domain of the page you requested.  This way, you only get a single DNS lookup.
• Avoid redirects For some, this may seem absurd.  Of course when you do want to redirect your viewers to some page else, we can’t stop you.. well, I can’t stop you if that’s what you want.  But what I’m referring to here, is the unwanted redirects.  Some sites, wherein the filenames of pages are exposed, need not worry about this.  But, for some who love beautiful urls, and use them, this may pose a problem. You see, for example, accesses to http://sweetperceptions.com/home/about must redirect to http://sweetperceptions.com/home/about/. This is carried out by the server itself, finding the closest possible match, and is thereby doing redirects.  Best thing to do is use url rewrites using htaccess.
• Stay DRY Don’t ever Repeat Yourself.  Keep your images and scripts in one copy.  Don’t write out methods in your scripts that may possibly appear in another file.  If there will be cases like this, refactor your code and isolate the repeated method into another file that you can include as needed.  Same goes for images.  Don’t keep another copy of exactly the same image using another name.  Your browser and server will treat them as two different files, thereby giving them the same amount of effort for loading.
• Create images for the exact size needed Well, is this easy enough to understand or what?  Well, I say, some graphic artists are still guilty of this practice.  Ever seen something like "img src="somefile.gif" width=’10? height=’20‘" where the somefile.gif is really 20×40 in actual file?  It makes loading slower because after rendering the file itself, it has to resize the image to the given dimensions.  Save your browser’s effort and create images for the exact size needed, and don’t bother setting its height and width.  Just lay it on the platter as it is, no extra dressing.
• Compact your images Well, images created using Gimp, Photoshop, Corel and others leave some extra header information in your images.  Some of these bytes can be shed off.  Heard of image optimization?  Do this.  There are lots of them available online like DynamicDrive, and some software like PhotoFiltre, and GIF Optimizer.  This will unload some extra bytes from your images.  Remember, every ‘byte’ counts.
• Reduce external elements Worse comes to worst, even after applying some of the techniques here, and you still find yourself wondering why its still the same as ever, maybe you should consider unloading some external elements.  Try removing button images and use text as replacement, or better yet, offer an alternative stylesheet that is more minimalist.  That could add to the fun and twist (so that your users could choose from whatever loads faster on their end).  Sweet isn’t?
• Watch out for memory leaks Hmmm.. bad programmer.. Well, for everytime that a patch is done with the original coding, consider spending time to refactor and improve.  This is more often than not the cause of too much memory leaks.  Always bother to collect garbage.  Free each memory consumption by every DB call and it can save time for loading.
• Use frameworks, and tools If you don’t really want to go through all the nitty-gritty details of these speeding up, why not try using frameworks and tools that offer you a easy shiny solution?  I’ve heard of PHP Speedy which is an application that you unzip into your server and it takes care of faster loading.  But, I would highly recommend that you’d go for using Smarty and AdoDB if you should start your coding.  Smarty separates the model, controller, view logic of your files, and allows you to set what can be cached (either one whole page or a fragment at a time).  AdoDB on the other hand caches the database queries in your server machine.  This will save the memory and CPU resources, thereby speeding up loading time.

I’ve also managed to list down the resources I mentioned above, and some that you can also use:

• Firebug
• Web Developer
• YSlow
• PHP Speedy
• JS Minifier or Javascript Minimizer
• PhotoFiltre
• Gimp
• GIF Optimizer
• Smarty
• AdoDB