Thursday, July 12, 2012


A few General rules with scripts , CSS, Javascript and images

·         Loading scripts on page
                                                             While labsjs or any other conditional loader may be used to ensure the order all the scripts must be loaded at the end of body of html; because while a script is getting downloaded, nothing else may be downloaded; also make sure that your script doesn’t perform an action unless the DOM is stable.

·         Loading CSS at the start

                                                              Moving stylesheets at the head of the document makes the pages appear to be loading faster.



·         Keep Scripts and CSS external

                                                              Using external files in the real world generally produces faster pages because the JavaScript and CSS files are cached by the browser. JavaScript and CSS that are inlined in HTML documents get downloaded every time the HTML document is requested. This reduces the number of HTTP requests that are needed, but increases the size of the HTML document. On the other hand, if the JavaScript and CSS are in external files cached by the browser, the size of the HTML document is reduced without increasing the number of HTTP requests.

The key factor, then, is the frequency with which external JavaScript and CSS components are cached relative to the number of HTML documents requested. This factor, although difficult to quantify, can be gauged using various metrics. If users on your site have multiple page views per session and many of your pages re-use the same scripts and stylesheets, there is a greater potential benefit from cached external files.

               

·         Minify javascript and css
                                                                 You may use uglify or minify or YUI compressor and reduce the size of your javascript and css.




·         Minimize http requests
                                                                Combined files are a way to reduce the number of HTTP requests by combining all scripts into a single script, and similarly combining all CSS into a single stylesheet. Combining files is more challenging when the scripts and stylesheets vary from page to page, but making this part of your release process improves response times.



CSS Sprites are the preferred method for reducing the number of image requests. Combine your background images into a single image and use the CSS background-image and background-position properties to display the desired image segment.



Inline images use the data: URL scheme to embed the image data in the actual page. This can increase the size of your HTML document so make sure you don’t use large images as inline, rather pickup small images to be used as inline images. Combining inline images into your (cached) stylesheets is a way to reduce HTTP requests and avoid increasing the size of your pages.

·         Use Media queries to load optimum size of images

                                                                                                   We should not depend on the browser to resize images for us and rather use media queries to check for the change in size of screen and load appropriate image for that screen size, it’s suggested to keep 3 versions of every image – for diff. screen sizes of desktop, tablet and mobile or at least 2 versions of images will help.




·         Create images from CSS

                                                    Images that are mono-chrome or vector in nature may be converted straight into css, and be loaded from there.  It serves a few purposes



1.       There is no image, so in one go its loaded as normal text of markup

2.       You don’t need round trips to get the image.

3.       Because there is no image, it’s perfect to be used for html emails, users will always see images in there emails thus.




·         Use CSS transitions

                                               It’s better to use CSS transitions in place of javascript animations, css transitions are very easy to implement with least amount of code, thus reducing the size of page. However not all browsers are supported.




·         Try making pages with less images, depend over shades, colors and gradients

                                                    To reduce the overall size of pages, its better not to use too many images, just as a principle try making designs with sheer colors, shades {implement by CSS3}, gradients {CSS3}, and animations {CSS3}. Don’t even bother about jquery for animations; avoid using javascript too at instances to keep your code as less as possible.




·         Use MediaQueries for CSS loading

                                                    Use Media queries to determine the css to be include.


·         Use Application cache manifest

                                                    Using the cache interface gives your application three advantages:

1.       Offline browsing - users can navigate your full site when they're offline

2.       Speed - cached resources are local, and therefore load faster.

3.       Reduced server load - the browser will only download resources from the server that have changed.

The Application Cache (or AppCache) allows a developer to specify which files the browser should cache and make available to offline users. Your app will load and work correctly, even if the user presses the refresh button while they're offline.

THE CACHE MANIFEST FILE
The cache manifest file is a simple text file that lists the resources the browser should cache for offline access.

REFERENCING A MANIFEST FILE
To enable the application cache for an app, include the manifest attribute on the document's html tag:

<html manifest="example.appcache">
  ...
</html>
The manifest attribute should be included on every page of your web application that you want cached. The browser does not cache a page if it does not contain the manifest attribute (unless it is explicitly listed in the manifest file itself. This means that any page the user navigates to that include a manifest will be implicitly added to the application cache. Thus, there's no need to list every page in your manifest.

The manifest attribute can point to an absolute URL or relative path, but an absolute URL must be under the same origin as the web application. A manifest file can have any file extension, but needs to be served with the correct mime-type (see below).

<html manifest="http://www.example.com/example.mf">
  ...
</html>
A manifest file must be served with the mime-type text/cache-manifest. You may need to add a custom file type to your web server or.htaccess configuration.

For example, to serve this mime-type in your webserver, add this line to your config file:

AddType text/cache-manifest .appcache

STRUCTURE OF A MANIFEST FILE


A simple manifest may look something like this:

CACHE MANIFEST
index.html
stylesheet.css
images/logo.png
scripts/main.js
This example will cache four files on the page that specifies this manifest file.

There are a couple of things to note:

§  The CACHE MANIFEST string is the first line and is required.

§  Sites are limited to 5MB worth of cached data. However, if you are writing an app for the Chrome Web Store, using the unlimitedStorage removes that restriction.

§  If the manifest file or a resource specified in it fails to download, the entire cache update process fails. The browser will keep using the old application cache in the event of failure.



IIS - Add the mime type for manifest, but there is one already available in the iis , which is supported by Microsoft for click – once deployment – application/x-ms-manifest; Remove it.

·         Create your own mime type for .manifest with text/cache-manifest

·         Create your own mime type for fonts like .ttf as font/ttf for .ttf ; if a mime type already exists like application/octet-stream, remove it and add it as font/ttf.




    More Performance Tricks



(1) Using Async and defer - essentially people load the javascript in the DOM as a "comment" as they may not use it immediately. For e.g. when you open the inbox of a web based email browser you dont need the JS of the compose screen. But when you do open the compose screen, you dont want to wait for the JS for that screen to download and make the user wait. hence you download the JS altogether but comment out the JS for the compose screen. When user clicks on compose screen, you get the comments, remove the comment tags and run "eval" :-)



(2) When the first time the user downloads the page and we store stuff in the app cache or local storage, we also store a cookie with a list of all the artifacts and files stored. Next time when user requests the same page the cookie is sent by browser to the server. The server can look at the list of files already present on the client and NOT send them again. This way you can only send incremental data and avoid the heavy downloads.


There was an error in this gadget