HTTP/2 - The Future of the Web

Why are we loading web pages the slow way?

 

The problems with how the web works today. In the video, a browser (in a mobile or a desktop) communicates with a server to fetch a webpage. If the browser and server are using the HTTP/1.1 protocol for the communication, they exchange several messages to send the webpage, and doing so requires time. One reason for this taking time is that the messages need to be sent and delivered the whole way between the browser and the server.

The video shows that as the browser gets the first resource index.html, it decides that it needs a new file, "styles.css", and asks for it to the server. After the browser analyzes "styles.css", it decides it needs an image file and asks for it... Since the browser discovers incrementally what resources are needed to assemble the website, several round trips are needed to render the page.

Discovering resources in the browser therefore implies several round trips, and delays the moment when the page can be shown to the user. Website developers have known this for a time, and avoided round trips at all costs. One way to avoid them is bundling: creating relatively large files that contain many smaller files. However, no matter how many tools have been devised to help, bundling remains a burden for web developers, because at development time, we simply are more comfortable delimiting files by their function and not by their size. More often than not, this results in many small files.

Another issue with bundling is that the browser's cache works on individual files. A larger file bundling many smaller ones is much more "volatile" in the sense that it will change as soon as any of the smaller ones change, and the entire bundle will have to be fetched again. In other words, bundling helps with performance for first-time visitors, which are admittedly a majority for most websites, but it is detrimental for returning users, who will have to fetch large chunks of the website as soon as a very small piece of functionality changes.

The alternative for faster websites

Another possible scenario using HTTP/2 is also shown in the video: as soon as the server notices that the client is requesting "index.html", it sends both this file and most or all the other files that the client is going to need. This technical possibility has been present since SPDY and has been standardized in HTTP/2, through something called HTTP/2 PUSH.

However, serving everything in one go brings a few challenges. For starters, conveuntional web servers like Apache and Nginx are not wired to work in this model, and this is not just an issue of "having more" functions, but also of suppressing some of their habitual functions that would become problematic in the presence of PUSH.

And then there are some unknowns that one needs to consider, for example, what to push and when, and how to take into account previous visits of the user to the site. After all, we don't want to push files to the user that she already has. Finally, the most important issue of all is the human factor: PUSH should be a way of simplifying developer's lives, not of burdening them with more work, and therefore should be as automatic as possible.

The future of the web is a HTTP/2 accelerator

ShimmerCat is an AI-powered web-accelerator built from ground up in HTTP/2 to benefit from the pros of HTTP/2 PUSH. Being a greenfield implementation, it doesn't have the many constraints that would come with trying to honor more conventional ways of doing things. ShimmerCat uses HTTP/2 techniques like PUSH in combination with machine learning to improve the speed and ease of running of complex e-commerce websites. The accelerator aims to be the platform for making e-commerces faster, more secure and scalable, and it works with any popular e-commerce solution. And unlike most other acceleration services, ShimmerCat requires no changes in the source code of the website. The only thing needed is the php-code and the database.

The web can be faster if we use the new technologies that allow for a faster web, for example, HTTP/2 and HTTP/2 Push. The problem is that mainstream web applications, like the ones powering e-commerces world-wide are not specially built for any of this technologies, so they don’t benefit from any of them. But ShimmerCat is different and can make your standard website load between 30% and 60% faster. What would that mean for your business?

Want to know the story behind ShimmerCat?

Let us call you

We'll get back when it suits you

Team

Read more about the people at ShimmerCat

Work with us

We are growing and are looking for talents