Internet users are increasingly demanding. They not only require your webshop to look nice and be intuitive, but it also has to be very quick. If they have to wait for a few seconds, they will probably leave your shop and open the next url from their Google search results. Sad but true - Internet users are becoming more and more demanding and the only thing we can do to make them stay is fullfilling all their desires. How to make sure that our website will always perform well and that users will stay? How to prevent they will leave your webshop because they had to wait for some page to load?
Colloquially speaking caching is about helping the Server in his hard and meticulous work that he has to do on daily basis. This is about taking some repetitive work from its shoulders. The result is obvious – the server is less loaded, which makes the users happier, because your webshop is considerably faster.
Generally, we can divide caching into two different levels:
- Output caching, and
- Data caching.
Output caching for the mass jobs
Output caching is strictly connected with a response sent to the end-user, to be displayed by the browser. Let’s imagine a user visits the following page: http://demo.21webmerce.com/product/tassen/1000007/22/gucci-tas. If he is the first one to enter this page, he will have to wait for a while. The page has to be generated by the server before it can be sent to the user. To prevent this will happen with the next user again, the generated result will be stored in a Magic Basket with a label “Might be used by someone else”. When another user enters the same page he will receive the response immediately, because it is already in the Magic Basket. So, no work by the Server has to be done. It is just a matter of taking the response from the Magic Basket and sending it back.
Cool, isn’t it? For the majority, yes. But, as mentioned above, one problem remains. If we handle the problem as described above, the first time user cannot get the response directly from the Magic Basket. To solve this problem we have to prepare the Magic Basket. To achieve this, we need some help from a web crawler.
This crawler will crawl from one page to another. It is very scrupulous – if there is a possibility to go to a certain page on your website by means of any link, it will get there. Excellent! We can use its help to go through all possible pages which will be automatically added to the Magic Basket. After the crawler finishes its job, all the pages will be ready for a quick presentation to any user. Our favorite crawler is HTTrack, but there are many others to choose from.
Data caching for the more personal jobs
Unfortunately, as life shows, Output Caching is usually not sufficient. Sometimes there is no possibility to cache a certain page, because they differ on every entry (e.g. they are user-dependent). Then we cannot take the response directly from the Magic Basket. One solution to this problem is donut caching (partial caching), but this is a technique used mostly for .NET, not supported well in other technologies.
Another possible solution is using second level caching - called data caching. In this case we use another Magic Basket, this time the one for storing certain pieces of the page and not the whole responses. Thanks to this, the server does not have to bother the Database to prepare all the data, because this data is already stored somewhere in the Magic Basket. Every technology has its own way of implementing data caching. When it comes to .NET technology some useful pieces of info can be found here.
As you can see it's our aim to assure that our database can have some free time (so generous!) meanwhile assuring that our webshop's visitors are pleased with the great performance.
2. Compressing and combining CSS and JS
Okay, let’s imagine a postman who has problems with logical thinking. He takes one letter from the post office and delivers it to the recipient. Then he comes back to the post office, takes another letter and delivers it to another recipient. Then again and again. Well, having such an approach you could deliver maximum several letters per day, which is a complete waste of your time. Every normal postman would take all the letters at once, without having to come back to the post office.
Now, let’s imagine that your webpage is a city. A postman (Server) has to deliver a lot of letters (CSS files and JS files) to different recipients (parts of the webpage). A normal behavior is that these letters are send one by one, like in the above example. And like in the above example, it is a complete waste of time. It goes without saying that we should send them all at once. The mechanism of gathering all CSS and JS files to one package is called combining. You can also use compressing to make that more letters can be put into one package. Thanks to this, it will weigh less and be easier for a postman to deliver every letter in time.
3. CSS sprites
Your website probably uses a lot of different images displayed on every single page. Each of these images has to be loaded one by one. So, as you can see, we have the similar problem to the one described above, but this time our “letters” are images. To send everything in a smaller amount of packages we can combine a few images together and make it one image. Our CSS will have to know where a certain image can be found on the combined images’ surface, but this is something that is quite easy to determine. You can read more about CSS sprites here.
4. NoSQL Search Engine
Recent studies show that more and more users use quick searching options instead of browsing through the whole website trying to find what interests them. This is especially significant in case of an eshop, where users want to find the products that interest them most in the shortest possible time. If your website does not have the quick option you probably lose a lot of potential customers. What’s more, it is not only relevant to have a quick search option, but to have a quick search that will show the real-time results after each letter typed . Okay, cool, but how to make it fast? How to make it real-time?
From our experience we know that the best possible solution is to use a NoSQL database, because it is too hard to perform such operations in real-time based on a normal SQL database. There are some ready no-SQL search engines that can be used and that can make your quick search genuinely fast. A good example is Solr, which you can communicate with by means of REST API, so in fact you can use this engine regardless of the technology your website is using.
There are hundreds of other ways to improve the speed of your webshop, but basing on our experience we believe the above ones are the most relevant and effective. We strongly recommend you to use them in your webshop. If you have any other good suggestion to improve the performance of a webshop feel free to share them with us. What are you favorite hacks? Leave a comment below!