How to optimize a website to load in less than 2.5 seconds?
BRIGHT LIVINGSTONE
CEO & Founder - Webnexs | E-commerce & VOD Solutions | Tech Entrepreneur | DM & BD Specialist
Hey Guys! Good to meet you through my discussion on how to optimize your website loading speed below 2.5 seconds and increase your conversions. Before moving on to exactly the points, I would like to draw some facts and clear myths on why these loading speed is important in todays web world. Many Coders speak this language, many SEOs need this and today even google need it to rank you top among SERPS.
- More than 42% of online customers visiting your website need your website to load in less than 2 seconds.
- 40% + people abandon a website that takes more than 3.5 seconds to load.(Think how you are at risk).
- 80% of the shoppers who feel dissatisfaction over the performance of the website will never return to the same website for buying again.
- 55% of the website visitors state that they are loyal, if the website will load in less than 2.5 seconds.
- A 3 second loading increases customer dissatisfaction over 16% and conversion is reduced to 16%
- 77% of online shoppers will be brand ambassadors if your website loads in less than 2 seconds and spread your site to popularity.
- 3% of people will wait less than a second before making their way out of the site reducing a lot of your conversions.
- If your website is loading beyond 6 seconds, only 30% of the acquisitioned traffic will be patient to buy from you.
Do you still need more stat to prove how it is to have a website which is loading for seconds together? Speed is a killer. Master it before it could make the website a graveyard of incoming traffic.
We should know here that website load speed is a combined factor of Server optimization + Website Code Optimization + Browser Optimizations.
Lets see them.
1.Minimising HTTP requests.
The website, when you make any request on the browser to load them, it searches and posts at the least a minimum of 40 requests to the server and fetches them and a file size of 1 MB has to be loaded before showing you the live website which is designed purposefully to be shown for every users. Our requests are parsed and the complicated codes are compiled before you get the live website.
If the website has to post more HTTP requests, it actually needs more time than we may predict and we are at loosing side. Our customers are made to quit the website without taking the intended actions. Before making any further works, right away from the point of optimisation, we have to look for minimizing the requests posted from server to the browsers.
The basic way of optimizing this is,
- Combing all the style-sheets into one.
- Making all the image requests into one sprite image.
- Minimizing the redirects on the website using htaccess.
- Run all the scripts just above the footer of the page.
- Combining CSS and JS files.
- Using Base 64 Encoded URLs to call the images.
2.Leverage Browser Caching.
The very next step to reducing the browser requests is to leverage browser caching of js, css and images. If the same user is visiting your website for the second time or consecutive times, the browsers cache will show the files from its end and there would be a load which is less on the server and it can fasten your website loading speed. Here is an example of the code you have to add to .htaccess to leverage browser caching.
## EXPIRES CACHING ##
<IfModulemod_expires.c>
ExpiresActive On
ExpiresByType image/jpg “access 1 year”
ExpiresByType image/jpeg “access 1 year”
ExpiresByType image/gif “access 1 year”
ExpiresByType image/png “access 1 year”
ExpiresByType text/css “access 1 month”
ExpiresByType application/pdf “access 1 month”
ExpiresByType application/x-javascript “access 1 month”
ExpiresByType application/x-shockwave-flash “access 1 month”
ExpiresByType image/x-icon “access 1 year”
ExpiresDefault “access 2 days”
</IfModule>
## EXPIRES CACHING ##
3.Server Response Time:
The time between request made by the user over browser to the time by which the website loads is defined as server response time.
As usual, there is a standard gold metric by google.
“ A server responding less than 200 ms is better”
Why better? It is because the pages can be rendered faster if the server loads by 200 ms. If the loading is slower, google could drop off the website from indexing in its search results and you are pathetic. So it’s no matter how you have optimized your codes, you are dependent on your server to respond. SRT is more depended on hardware, the Internet connectivity, the OS of server, your website traffic.
If your website could have more than 1000 concurrent users, there is a different way you have to handle your website for optimization. If the website is having more than 10000 hits/ second, it should be handled in more different way than it is thought normally, as even the above will have an impact on Server response time.
4.Keep Alive
There is a time when the browser requests for files from server and the HTTP request made to the server has to be parsing the files and sending them back to browser. Over this process of sending and fetching them, the browser could need additional files to fulfill the index.php file; which could be Javascript, Style-sheets, images, Jqueries etc.
So when fetching these files, it will, by default send individual requests to the server and fetch them. But, when keep alive is enabled, it fetches all these files in a single request and saves load time. Also it happens the vice-versa when requests are sent each time to load resources from the server i.e, the load time of website increases by manifold.
By default most web servers would not have this function enabled.
5.Enable Compression.
For some reasons, we would be forced to use images which are over 1 MB and there would also been some files which are to be retrieved and pulled out from server to make the website a complete whole. As discussed above, it is dependent on several other features to make it go good. But this feature of compression adds-up value to the load time optimization.
If a request is made to the server, it compresses all the files using a tool named Gzip and gives output which is optimized by 70%.
For Compressing:
In Apache: Use mod_deflate(https://httpd.apache.org/docs/current/mod/mod_deflate.html)
In Nginx: HTTPGzip module.( https://wiki.nginx.org/HttpGzipModule)
In IIS: Configure HTTP compression.(https://technet.microsoft.com/en-us/library/cc771003(v=WS.10).aspx)
6.Cacheable Redirected Sub domains/Directories.
When users go mobile, the users have to be honored with mobile site. The webmaster have to understandthat these users are floating population and just browse the website and have very lesser time to find out things on their own with mobile comparing desktop users. So optimizing by showing the right content for mobile users have to be a priority. The UI has to be very unique. It differs a lot from desktop UI.
As like the desktop versions are made cacheable, the redirected mobile version of the site has to be cached to make the load on the server reduced. More than 55% visitors to any websites are through mobile.
7.Minify Resources:
There are many tools and themes which are pre-done to have a very good visual impact. But the impact of codes on the performance of the website could be very less than what could be expected from the codes. Hence to optimize them, each line of code have to be re-looked for empty hooks, extra piece of codes, repetitive class functions which otherwise could be one class serving many div’s.
8.Combine CSS & JS
Also care has to be taken that we optimize, combine all CSS into a single style sheet and also combine all JS to one. So combing to one could as well save resources on the server and could make the website load less than 2sec.
There are some tools to compress HTML: PageSpeed Insights Chrome Extension
For CSS Minifying: YUI Compressor and cssmin.js.
For Minifying JS: Closure Compiler, JSMin or the YUI Compressor.
9.Optimize Images:
There are fewer steps you have to focus while optimizing images.
- The image dimensions
- The image Formats
- The Image SRC
a. Image Dimensions:
There could be places where your image would need 600*300 Px image, but as you have designed an image for 1800*900, you would send it to the server and load it. This is not wrong for one image. Supposing there are 100 images with the same need and if 100 visitors request these images, 300% increase in load can be seen. Hence optimizing server by 300% is done once we do images for specific size. Or, if done, there are some services, which are helping to minimize to the best possible Px without loosing the image quality.
Here is one for your consideration: JPEG minifier
b. The image formats.
JPG, PNG, BMP, TIFF, GIF are some well-known formats of images. But it is always recommended to use JPG as it is less sized and it supports all browsers. Though PNG has good compatibility, they are not as good as JPG images in smaller sizes.
c. SRC Attribute.
After optimizing your images for the formats, size and dimensions its time that your codes which request the images has to be taken care. Img SRC attribute has to be filled with urls and it should not be left blank so that the empty requests will not take much of time and delay the website loading.
Remove such codes which are left blank on imgsrc tab.
<imgsrc=””>
10.Optimise CSS.
The style sheet which makes the website load as pleasing as you wish has to be optimized for delivery. There are two ways you can presume while optimizing this CSS. I recommend you to split it into two segments.
- Above the Fold CSS.
- Below the Fold CSS.
Rendering of images over above the fold CSS has to be faster and have to perform much better than below the fold CSS. For this purpose, what I would suggest is, above the fold CSS has to be made as an inline element and below the fold can be external. So when it loads from the HTML file, the rendering of above the fold will be faster and it is very easier to load the website faster than putting all into one.
Then make below the fold CSSas an external File.
Note: Delivery of CSS from an external file is always good and it is preferable as it avoids duplicate writing of CSS inline.
11.Deactivate Plugins.
Deactivate any un-necessary plugins which you are not using as the unused codes could add up to your resources and it will cause a delay in the load speed of your website. You could install some plugins which are used by you when you start your business, but in due course, it would not be anymore needed and you will start using another plugin which provides an advanced functionality. Consider weeding out this.
12.Server Environment.
Use the right server resources for your codes. Your codes, architecture would need 8GB RAM and if you consider deploying a 4 GB infrastructure, your performance delays a lot and you will not be in a situation to deliver the right performance as expected by your visitors. Choosing the right server at times will be harder and for this you should try consulting an server architect specialist. Don’t just go with any another server company which donot understand the basics of operations.
13.Redirects
Minimise the redirect to your website. Every redirect will need fewer seconds and before the content is delivered to the browser, the redirects will eat up your customer to the full extent and you are left with no visitors who are really satisfied with your business. Consider minimizing them.
14.CDN
If the website has a lot of media resources like videos, presentations, images, GIF’s , PDF’s, try deploying them in a CDN(content delivery network). It should give you the best solution. Your contents are delivered from alternate server in the digital space and your master server will be used only to render the codes. This could be one of the best way you can optimize your server and website, if your images are consuming more GB’s
15.Split the server.
If you consider saying your business will grow bigger in no time, it is advised to have your frontend and DB servers separate. Give your Database the necessary resources and frontend the needed resources so it can be rendered. Normally a frontend would require lesser resources than DB, so it is not needed always to deploy the same configuration to both the servers.
If you consider splitting your admin server, you are welcome. It is an welcomed move especially if your admin team is doing operations each day over the server.