website

Web Performance Done Right

Sharing my views on my favourite and most interesting topic in the web industry. My views on this post are mostly derived from FrontEnd Masters web performance workshop. So to start with I will state performance golden rule by steve souders which is

80-90% of the end-user response time is spent on the fronted. Start there

Below is the backend frontend split waterfall diagram from linkedin and again I took this from steve souders blog.

Screen Shot 2015-08-15 at 9.36.24 PM

From the graph we can easily conclude that we should spent most of our resource for optimization on frontend. Web is all about measurement and perception and we should know how to balance between these two. If our site loads quickly but our user hate the experience of the way our site loads then we have not actually won. Then the user will start hating us more because may we are loading bizarre content first. So we need to properly balance measurement and perception.

We need to focus on improving the efficiency, speed, memory. We need to focus on how well its doing its job the way it was supposed to do. It doesn’t matter that site loads in 6 seconds but what matters is how much bandwidth it takes to load. Measure your website performance, benchmark it and find out where we need optimization and work on it to make it better.

Optimization is all about critical versus non critical. In our software we can find out which part needs optimization and which didn’t. I will state another quote from Donald Knuth

Programmers waste enormous amount of time … worrying about the speed of noncritical parts of their programs… we should forget about small efficiencies, say about 97% of the time … Yet we should not pass up our opportunities in that critical 3%

Non critical optimization or optimization done wrongly is the root of all evil. This article focuses on mature optimization. Most of the frontend optimization happens in the middle-end (term coined by kyle simpson) which is url routing, templating, headers, caching, ajax, etc. and optimizing middle-end is all about focussing on YSlow, resources (Images, CSS/JS), architecture, communication.

YSlow:

  1. Fewer HTTP Requests
  2. Use a CDN
  3. Expires/Cache-control Header
  4. Gzip
  5. Stylesheets at top
  6. scripts at bottom
  7. Avoid CSS Expressions
  8. External CSS/JS
  9. Fewer DNS lookups
  10. Minify JS/CSS
  11. Avoid Redirects
  12. Avoid Duplicate Scripts
  13. ETags
  14. Cacheable Ajax

Don’t use Expires/Cache-control header and ETags both at the same time, you will end up putting extra headers. Some useful tips on fewer HTTP requests are below:

Fewer HTTP Requests:-

  1. Image Sprites – Combine all images into one and optimize it. Remember horizontal sprites are more performant than vertical sprites because CPU takes more time to process vertical sprites.
  2. Concat JS/CSS – Concatenate (combine all files into one) JS and CSS
  3. GZip – gzip your content. Test if gzipping is done correct or not.

This article contains detailed description about all the above rules.

Resources:

  1. Image – Compress(lossless) images and sprite it.
  2. Minification – Minify your JS and CSS files. You can use google closure compiler for the same. This article has the list of tools for concatenating and minifying CSS and JS files based on the development environment.

Architecture:

The architectural approach should be like doing the least amount of work for making something visible on the page. Single Page Architecture (SPA) is performant for web applications as it reduces round trips to the server. Take an example of gmail which is a huge single page application, it has lots of data but its performant.

Communication:

  1. JSON – When it comes to data transfer, JSON size should be optimal. Don’t put duplicate entries, don’t put data which can be easily derived with the help of existing properties. If you put redundant data, it will increase the JSON size and will take more time for transfer.
  2. Web Sockets and Ajax – Use web sockets  over Ajax. Ajax requests are heavier because on every connection it uses extra resources like HTTP packets over the wire, server side resources, connection resources. On the other hand web sockets connection happens only once in the request response cycle. There are 1600 overhead bytes in the request response cycle, so why you want these bytes again and again by using ajax.

That was all about middle-end optimization. There is some useful information that I want to share:

Resource loading:

  1. Preloading Images – Preload your content by using the below code:

    <link rel=”prefetch” href=”image.jpg”>

    <script>
      var img = new Image();
      img.src = “image.jpg”;
    </script>

  2. Lazy load – (On demand loading or post loading)
    Use script loaders like LABjs or you can do the following:

    function scriptLoaded(){
      //done
    }

    var script = document.createElement(“script”);
    script.src = “abc.js”;
    document.head.appendChild(script);

    script.onload = scriptLoaded; // not supported in some browsers so have to use onreadystatechange

    script.onreadystatechange = function(){
      if(script.readyState === “loaded” || script.readyState === “complete”)   {
        scriptLoaded();
      }
    }

  3. Reduce abstractions in your JavaScript code.
  4. Use CSS animation over JS animations.
  5. Use websites like jsperf to test performance of your JS code.
  6. Do every UI operation in less than 100 ms because user can perceive an action which takes more than 100 ms. According to research if an action(on button click etc.) takes more than 100 ms then user can treat it as a slow operation. Perceived performance matters.

There are lot of things you need to focus when it comes to optimizing web application. I listed some of them, hope it helps.

My Views on handling website load (Basic version ;-) )

Handling load depends upon various things. May be I am not the right guy for this but I can share my thoughts over it. I made a flowchart which depicts basic website modal:-

Wesite basic Flow

Flow:-
Requests hits LB(Load Balancer) and LB passes the request to the server which is in rotation. Server picks up the request and do some business logic which includes talking to the services and then to the DB and then somehow requests completes and user sees the webpage in the browser.

Load Balancer:-
Every request comes directly to the Load Balancer. Its a smart device that acts as a reverse proxy and distributes network or applications traffic across no. of servers. They are used to increase capacity and reliability of applications. So it basically distributes requests to various servers based on the configured algorithm. Some Algorithm are:-

  • Round Robin
  • Weighted Round Robin
  • Least Connection
  • Least Response Time

CDN:-
A content delivery network or content distribution network is a large distributed system of servers deployed in multiple data centers across the internet. The goal of CDN is to serve content to the end users with high availability and high performance. They are basically used to store static contents. For eg:- Amazon cloud, Akamai, Microsoft Azure, etc.

Handling Load:-

In my views handling load is really hard task. First of all our code should be performant. One should not write unoptimised code. One should take care of the time and space complexities while writing code. When you write code, show it to your friend for code review so that he/she can point out your mistake.

Then comes the DB interaction. Minimum calls should happen to the DB. Use optimised SQL queries is a must. In my opinion the best practise is to write all the data to the file and write a CRON job which writes the data from the file to the DB. So there will be no direct connection to the database and your database will never be choked.

Caching should be used as much as you can. THe data which is constant or does not change like static HTML should be cached. Cache dynamic content for a constant amount of time say for 5 minutes and have some mechanism to refresh the cache. There are various system for caching like memcache, PHP:APC cache, etc.

Move static contents(CSS, JS, Images, Sprites, etc.) to CDN so that the requests for these contents will not hit LB. You can see in flowchart there is a dotted line between CDN and LB which depicts if CDN fails then the requests will go to LB for the particular content.

Write tests for your Application which can detect amount of load your website can handle. Write a script which will hit your website and checks for how many concurrent hits your website can serve response. This way you can judge your website capacity.

I don’t have the 100% knowledge of it but shared my views of what I had now. Will share all the other tips and tricks once I will explore it and will get more and more into it.