New Naukrigulf English Desktop Homepage is designed with the goal of providing better interface to our users. Of course, the new site comes with eye-pleasing aesthetics, enhanced usability and is simply faster. Lets first look at some speed-metrics to see really how fast our homepage has become.

Benchmark report of Previous Homepage vs New Homepage

	Old Homepage	New Homepage
Homepage	TTFB = 1.17	TTFB = 1.02

*TTFB : Time To First byte

 

Let us see what we did to achieve this

• Low Resolution Images Before Page Load and High Resolution Image After Page Load:

1. To give our users some sense of Page we display low resolution images at Page Load and change it to high resolution after Page Load. In this way our site UI wouldn’t break even at low network speeds. Also data transferred is less which means faster loading of page.

Below is a short description on how we did this

• Blur image is achieved by this css

@media screen and (-webkit-min-device-pixel-ratio: 0).bg_default {
background-image: url(../i/bg.webp);
}

 

1. Original high resolution image: This is achieved using Javascript. On page load, we set inline element to new image using inline css. As the priority of inline css is more as compared to classes, new high resolution image is visible.

 

• Lazy Loading of Top Employer Banners

1. Browse to http://www.naukrigulf.com/. When you scroll down, you will notice that some images started to display. This is because those images will only be displayed when you scroll down to that section decreasing Page Load time considerably.

 

 

• Redis as a Cache System

• Why we choose redis

1. Redis can be accessed by all the processes of your applications, possibly running on several nodes (something local memory cannot achieve). This means we don’t have to keep local files on each server. So if we want our data to scale across multiple servers we want Redis.
2. Redis is a bit more than a simple cache: it provides various data structures, various item eviction policies, blocking queues, pub/sub, atomicity, Lua scripting, etc …
3. Redis can replicate its activity with a master/slave mechanism in order to implement high-availability.
4. Since redis is key value database, search complexity is close to O(1).

• How redis helped us

1. When a user comes to Naukrigulf homepage, he sees data cached by redis. In this way server latency is less as there are no DB hits and very less processing time. Time To First Byte (TTFB) reduces significantly, hence decreasing Page Load Time and increasing User interaction

• HTML Minify

When it comes to increasing Page Load Time, every single Byte matters. We did HTML minify to remove those unwanted spaces, line breaks and html comments. So, by doing html minify we have saved 5KB, which makes it worthwhile to do.

• Using webp for chrome

  which make images 25% smaller in size hence rendering them faster on chrome browsers. Some reference sites which convert images to webp are given below:

1. http://image.online-convert.com/convert-to-webp
2. http://webp-converter.com/
3. http://www.zamzar.com/convert/png-to-webp/

• Header Footer From Javascript :

1. Header and Footer on homepage are javascript based. They are made after dom ready and these javascript are browser cached the other time you open it.e

• AJAX For complex widgets

1. Profile Widget and Feedback Button
   1. This widget displays all profile data to user. The widget is dynamic and may have taken considerable amount of time if we have not made it Async. Notice the Profile-updates ajax call below. It gives a Json Response, which we then insert into corresponding HTML. In this way a lot of page load processing is saved at page load time.

 

 

These are just few important approach we took to make naukrigulf homepage deliver better performance. These are generic approaches and hence can be used by all sites.

See something which interests you, join us!!!

Related Posts

• The All-New Naukri iOS App (6.0)
• Understanding Disk I/O – when should you be worried?
• Understanding Linux CPU Load – when should you be worried?
• Use of “Kill” & “Kill -9”
• Garbage Collection in Elasticsearch and the G1GC