• 10 Best Practices to Speed up Your Website

    1) Minify JavaScript and CSS

    Minification is the practice of removing unnecessary characters from code to reduce its size thereby improving load times. When code is minified all comments are removed, as well as unneeded white space characters (space, newline, and tab). In the case of JavaScript, this improves response time performance because the size of the downloaded file is reduced. Two popular tools for minifying JavaScript code are JSMin and YUI Compressor. The YUI compressor can also minify CSS.

    Obfuscation is an alternative optimization that can be applied to source code. It’s more complex than minification and thus more likely to generate bugs as a result of the obfuscation step itself. In a survey of ten top U.S. web sites, minification achieved a 21% size reduction versus 25% for obfuscation. Although obfuscation has a higher size reduction, minifying JavaScript is less risky.

    In addition to minifying external scripts and styles, inlined

    An alternative in PHP would be to create a function called insertScript.

    1
    
    <?php insertScript("menu.js") ?>

    In addition to preventing the same script from being inserted multiple times, this function could handle other issues with scripts, such as dependency checking and adding version numbers to script filenames to support far future Expires headers.

    3)Minimize the Number of iframes

    Iframes allow an HTML document to be inserted in the parent document. It's important to understand how iframes work so they can be used effectively.

    iframe pros:

    Helps with slow third-party content like badges and ads
    Security sandbox
    Download scripts in parallel

    iframe cons:

    Costly even if blank
    Blocks page onload
    Non-semantic

    4)Reduce Cookie Size

    HTTP cookies are used for a variety of reasons such as authentication and personalization. Information about cookies is exchanged in the HTTP headers between web servers and browsers. It's important to keep the size of cookies as low as possible to minimize the impact on the user's response time.

    For more information check "When the Cookie Crumbles" by Tenni Theurer and Patty Chi. The take-home of this research:

    Eliminate unnecessary cookies
    Keep cookie sizes as low as possible to minimize the impact on the user response time
    Be mindful of setting cookies at the appropriate domain level so other sub-domains are not affected
    Set an Expires date appropriately. An earlier Expires date or none removes the cookie sooner, improving the user response time

    5) Use Cookie-free Domains for Components

    When the browser makes a request for a static image and sends cookies together with the request, the server doesn't have any use for those cookies. So they only create network traffic for no good reason. You should make sure static components are requested with cookie-free requests. Create a subdomain and host all your static components there.

    If your domain is www.example.org, you can host your static components on static.example.org. However, if you've already set cookies on the top-level domain example.org as opposed to www.example.org, then all the requests to static.example.org will include those cookies. In this case, you can buy a whole new domain, host your static components there, and keep this domain cookie-free. Yahoo! uses yimg.com, YouTube uses ytimg.com, Amazon uses images-amazon.com and so on.

    Another benefit of hosting static components on a cookie-free domain is that some proxies might refuse to cache the components that are requested with cookies. On a related note, if you wonder if you should use example.org or www.example.org for your home page, consider the cookie impact. Omitting www leaves you no choice but to write cookies to *.example.org, so for performance reasons it's best to use the www subdomain and write the cookies to that subdomain.

    6) Minimize DOM Access

    Accessing DOM elements with JavaScript is slow so in order to have a more responsive page, you should:

    Cache references to accessed elements
    Update nodes "offline" and then add them to the tree
    Avoid fixing layout with JavaScript

    7) Choose "link" over @import

    One of the previous best practices states that CSS should be at the top in order to allow for progressive rendering.

    In IE @import behaves the same as using "link" at the bottom of the page, so it's best not to use it.

    8) Don't Scale Images in HTML

    Don't use a bigger image than you need just because you can set the width and height in HTML. If you need
    My Cat
    then your image (mycat.jpg) should be 100x100px rather than a scaled down 500x500px image.

    9) optimize Images

    After a designer is done with creating the images for your web page, there are still some things you can try before you FTP those images to your web server.

    You can check the GIFs and see if they are using a palette size corresponding to the number of colors in the image. Using imagemagick it's easy to check using identify -verbose image.gif When you see an image using 4 colors and a 256 color "slots" in the palette, there is room for improvement. Try converting GIFs to PNGs and see if there is a saving. More often than not, there is. Developers often hesitate to use PNGs due to the limited support in browsers, but this is now a thing of the past. The only real problem is alpha-transparency in true color PNGs, but then again, GIFs are not true color and don't support variable transparency either. So anything a GIF can do, a palette PNG (PNG8) can do too (except for animations). This simple imagemagick command results in totally safe-to-use PNGs: convert image.gif image.png

    10) Avoid Empty Image src

    Image with empty string src attribute occurs more than one will expect. It appears in two form:

    straight HTML

    1
    2
    3
    4
    5
    6
    
    <img src="">
     
        JavaScript
     
            var img = new Image();
            img.src = "";

    Both forms cause the same effect: browser makes another request to your server.

    1. Internet Explorer makes a request to the directory in which the page is located.

    2. Safari and Chrome make a request to the actual page itself.

    3. Firefox 3 and earlier versions behave the same as Safari and Chrome, but version 3.5 addressed this issue[bug 444931] and no longer sends a request.

    4. Opera does not do anything when an empty image src is encountered.

Comments on this post

Leave a Reply

  • Security Code :


    6 − two =