HTTP/2 is another method for making your site stack much speedier by dispensing with numerous wasteful aspects connected with the present adaptation of HTTP. The best thing about it? You don't need to go to much push to get it up and running.
Isn't that right?
WHAT IS HTTP/2?
When HTTP1 and HTTP1.1 were originally developed, the web was very different to what it is today. Websites had fewer resources (JavaScript files, CSS files, images) than today. Connections to the internet weren’t very fast, and users were not very picky with website loading speed.
Users start to get itchy fingers when a site takes longer than 3 seconds to show a response.
You were happy that a website loaded full stop. You might have secretly complained that loading was slow. But you couldn’t really do much about it. That’s because the slow loading time was typically coming from factors which were independent of the web server and technology you were using. Mostly it was the actual internet connection which was the major limiting factor.
Fast forward to today. Great website loading times are measured in milliseconds rather than seconds.
Users start to get itchy fingers when a site takes longer than 3 seconds to show a response.
In this kind of situation, inefficiencies counted in milliseconds associated with the original versions of HTTP start to make a real difference. That’s why you get so many articles discussing how to make your website faster. Because milliseconds matter.
The new version of HTTP, known as HTTP/2 addresses specific known problems of HTTP. Its goals are to address a number of problems which have become more pronounced as the web has evolved to larger and larger websites with many more CSS, JS and image files than originally anticipated.
But what is wrong with HTTP1.x, and why do we spend so much effort making it faster?
THE PROBLEMS OF HTTP1.X
HTTP1.x has a number of inherent problems. Actually, let’s refrain from calling them problems. HTTP1.x has a number of ways in which it can be more efficient.
HTTP 1.x is text based: originally the idea was that HTTP1.x should be humanly-readable so it was fully text based. By definition all text based protocols have inefficiencies associated with them such as whitespace, link breaks, capitalization, etc.
Only one file is in transfer at any one time: this is one of the biggest problems with the 1.x versions of HTTP. Just imagine being a deliveryman who is only able to deliver one package at a time. They have to go back to base every time they need to deliver the next package.
Hundreds of requests are required for today’s websites: having more sophisticated themes means that the size of the websites and the number of resources grows. And so does the time it takes to load each resource. Remember our “deliveryman” has to go back to base every time, they are not able to transfer more than one file at a time.
Each connection is a heavy technical operation: Since hundreds of connections are required, it starts to accumulate serious overhead. With loading time being measured in milliseconds, the combined time required to create a connection for hundreds of resources starts to become very significant.
Many times web designers had to implement specific measures to reduce these inefficiencies. Workarounds such as CSS sprites, minification, and the combining of files are meant to overcome issues with loading web sites.
These are — in essence — workarounds rather than fixes.
HOW HTTP/2 SOLVES THE PROBLEMS OF HTTP1.X
HTTP/2 is designed and evolved from SPDY, a protocol designed at Google aimed at making the web 2x faster. It addresses HTTP problems in the following way
HTTP/2 is intended for consumption by machines (your web browser and your website’s web server) rather than humans. It is binary rather than text based making it inherently more efficient. Transfer and parsing of the data is faster using binary protocols.
Multiple files can be transferred simultaneously on the same connection. Fixes were implemented such that you can pipeline resources on the same connection. Rather than having to open a new connection each time (our deliveryman going back to base), all of the resources can be carried on the same connection (our deliveryman dumps everything in a van and takes everything in a single trip).
Server push to send files which will be required by browser. In HTTP1.x it is the web browser who asks the web server for the resources it requires. HTTP Server Push (implemented as part of HTTP/2) allows the server to start sending resources that it knows the web browser will need. For example, you can instruct the server not to wait for the browser to ask for the CSS, JS and other resources files which the browser is going to need anyway.
HTTP packet Header and other optimizations – these are technical improvements which are designed to improve the actual efficiency of transfers
WHAT IS REQUIRED TO ENABLE HTTP2?
By not supporting HTTP/2 over unencrypted connections, website owners are being strong armed into implementing HTTPs for their website.
Back at the very beginning of the article we said that not much effort is required from your end to enable HTTP/2. Enabling HTTP/2 is something which needs to be done at web server level. Most web servers such as Apache, Nginx, IIS, and other major web servers already have support for HTTP/2.
If you run your own web server, you just need to install and enable the HTTP/2 libraries. If your website is hosted with a hosting company, check with the company whether the web server is already enabled for HTTP/2.
THE CATCH.... SECURE CERTIFICATES
Maybe things were too good to be true. We have just discussed how web servers already fully support HTTP/2.
Most major web browsers also fully support HTTP/2. However, they have also chosen to only support HTTP/2 in encrypted mode. The reason for this is that there has been a strong movement to enable HTTPS (encryption) all over the web. Such initiatives as HTTPS Everywhere strongly push the need for HTTPS on all websites.
By not supporting HTTP/2 over unencrypted connections, website owners are being strong armed into implementing HTTPs for their website.
Of course this is not necessarily a bad thing. Implementing HTTPS has significant security and privacy advantages. With companies coming together to form a Certificate Authority called Let’s Encrypt to allow free secure certificates, the overall cost to actually acquire a certificate and implements HTTPS becomes much cheaper. This was relatively expensive up until some time ago.
Implementing HTTPS is not something you ought to do without give it the necessary due thought. You may probably want to discuss this with your trusted website developer or somebody with enough technical expertise. Most times, your hosting company should be able to guide you through this.
Of course, it’s strongly recommended that you implement HTTPS. Besides the additional security, you’re going to get the ability to enable HTTP/2 and make your website faster. That’s what we call a win-win situation.
ARE OTHER OPTIMIZATION TECHNIQUES STILL NECESSARY?
Certain optimizations aimed at reducing web requests become superfluous. If your site is incurring computation time to “combine” JS, CSS and other files, this has actually become an overhead cost. Any time “wasted” addressing the above mentioned inefficiencies is no longer necessary.
On the other hand such optimizations such as caching, reduction of the size of resources, delivering content over a CDN, choosing a great hosting server, and other optimizations which address different types of inefficiencies should stay in place.
The great thing about HTTP/2 is that not only does it make your website load faster, it’s also pushing you to make your website more secure. There’s no arguing that there are advantages to both of these. HTTP/2 is the next step in making all of the web faster. Let’s all be part of the it and make it happen.
+P and P Infotech : Web Solution, Web Design and development Indore
Reffered From: webdesignerdepot
HTTP/2 is intended for consumption by machines (your web browser and your website’s web server) rather than humans. It is binary rather than text based making it inherently more efficient. Transfer and parsing of the data is faster using binary protocols.
InfoArmor has published a timeline and history of the attack against Yahoo. The first offers to sell Yahoo-derived data appeared on April 3, 2016. According to InfoArmor’s analysis, the individuals attempting to sell the Yahoo data (and other major data sets for websites like Instagram, LinkedIn, Dropbox, MySpace, and Tumblr) are fronting the data sets for criminal groups, as opposed to acting directly on behalf of government agencies in foreign countries. It’s not always easy to tease these relationships apart, since criminal hackers sometimes sell data to nation-states, or could be hired to work directly on their behalf.
