WHAT'S NEW INHTTP/2

BY DAWN PARZYCH

The front end optimization (FEO) movement was a result of the inefficiencies of HTTP/1.1. The availability of HTTP/2 may
mean more work for companies that have already spent countless hours and hundreds of thousands of dollars
implementing FEO strategies; and a decline in companies and offerings focused on FEO as HTTP/2 will erode the benefits.
There has already been a shift in the FEO space with Google shutting down its PageSpeed Service in August. While the
official reason is that they saw more interest in the offering through partners than through their service, part of me thinks it
has to do with the release of HTTP/2. The deprecation announcement came out on May 5, 2015 less than 2 weeks before
HTTP/2 was published as RFC7450.
This post in our HTTP/2 series will explore four key components of HTTP/2 - header compression, multiplexing &
concurrency, priorities & dependencies, and server push - and what that means for developers and companies that have
previously implemented various FEO strategies.

HEADER COMPRESSION
HTTP is highly repetitive and a stateless protocol, this requires the conversation between a client and a server to contain
many identical pieces of information. A typical HTTP/1.1 request header contains the following information:

GET / HTTP/1.1
Host: instartlogic.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/45.0.2454.85 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Cookie:

During a typical browsing session there is certain information here that will not change such as the User-Agent, Language
preference, ability to accept compressed content and the types of content the browser can accept; but this information is
communicated on each and every request. Previously there has been no way to compress header content and reduce the
unnecessary transmission of identical data until SPDY and HTTP/2. Header compression is handled by the
HPACK standard or RFC 7541. HPACK eliminates the redundancy and reduces the size of headers helping to reduce page
weight.

Given the growth in the number of resources on a page reducing the size of headers is a much needed functionality. Prior to
SPDY, there has previously been no work arounds or options to reduce the size of headers, this is a net new win the
performance optimization space. Earlier this year the team at HttpWatch ran some tests comparing the
performance of HTTPS to SPDY to HTTP/2; for an object that returned no content (204 response code) the request and
response sizes are listed below:

Protocol

Request Header Size

Response Header
Size

Total Header Size

HTTPS

602

235

837

SPDY/3.1

659

59

718

15%

HTTP/2

259

28

287

66%

Percentage bytes saved

Overall header size can be reduced by 66% with HTTP/2 header compression, for pages with hundreds of resources those
savings can add up quickly.

MULTIPLEXING AND CONCURRENCY

One of the biggest inefficiencies of HTTP/1.1 was the ability to only send one request per TCP connection. This led to
multiple work arounds being implemented from registry hacks to force browsers to open more TCP connections or FEO
techniques like domain sharding, concatenation and image sprites. In the early days of HTTP browsers only opened up two
connections per domain, when the maximum connection speed was 56K this seemed reasonable. As connection speeds
increased along with the number of resources per page this became a bottleneck.
Domain sharding arose to work around this issue. Domain sharding is the process of splitting content across domains to
trick the browser into opening up additional connections to a web site. For example if your domain is www.example.com a
browser would open two connections to download all content from that domain. With domain sharding you could create
additional DNS entries and host content on www.example.com, images.example.com, and scripts.example.com this way the
browser went from opening two connections to six connections; making more effective use of available bandwidth. The
downside of this is additional DNS entries and TCP connections add additional time. As domain sharding became more
popular browsers quickly moved from only allowing 2 connections to up to 6 connections or more per domain, yet domain
sharding still exists which means up to 18 connections to a web application.

Other popular FEO techniques to mitigate the effects of

having to wait for a connection to be freed prior to requesting
the next object include image sprites and content in-lining.
The goal of both of these is to eliminate the number of round
trips needed to fully download a page. An image sprite is a
collection of all the images on a page into a single image
reducing the number of image requests from 60 to 1 can
greatly reduce the amount of time spent waiting for a web
page to load.
Along the same lines content in-lining was designed to
reduce the number of round trips by taking external resources
such as JavaScript and Cascading Style Sheets and
embedding the content in the HTML.
These are both great at reducing the number of round trips
for first time visitors the side effect is negatively impacting the
performance for repeat visitors. Image sprites and content inlining make it harder for content to be served from cache on a
repeat visit. If an image sprite contains 60 images and 1
image changes, all 60 images in the sprite need to be redownloaded as opposed to only the 1 image that changed.

Along the same lines if external resources are embedded in the HTML which isnt cached then those files are redownloaded on each and every request causing.
HTTP/2 provides an easy solution by allowing concurrency on a single TCP connection. There is no longer a need to create
multiple DNS entries for resources, create sprites or in-line content. Continuing to shard content over multiple domains will
actually negatively impact performance as additional DNS lookups and TCP connections are set up unnecessarily.
Eliminating sprites and content in-lining will improve performance for repeat visitors with no negative performance hit for first
time visitors.

PRIORITIES AND DEPENDENCIES

Certain content is needed for a browser to begin to render a page, other information can be deferred until later in the
process. Most people dislike staring at a blank white screen, which led to the birth of the FEO best practice of putting style
sheets at the top and JavaScript (JS) at the bottom. With JS at the bottom of the page, it wouldnt block the download of
other content, but sometimes the loading of images of other resources is dependent on a certain JS file.
HTTP/2 provides the ability to set priorities and dependencies on resources, if a set of images depend on a given JS file
being downloaded first that can be specified and the images will not be downloaded until the JS has been delivered. If a
page contains a hero image that can be given a high priority to ensure that users receive that immediately after the HTML
reducing the amount of time a user is staring at a blank white screen.

Lazy loading is a FEO technique used to delay the loading of images that are at the bottom of the page or not in the
viewport. Images are not loaded until a user scrolls to them or at a predefined time. The downside of this optimization is the
additional JS code that is necessary to implement this. Each line of code adds additional weight to a page which can impact
overall performance. With HTTP/2 images that are below the fold can have a lower priority set and the additional lines of
code for lazy loading can be removed, making your pages load even faster.
Setting priorities and dependencies is not a requirement to upgrade an application to HTTP/2, they are optional. These will
require additional effort on the part of application developers to test and implement. If this is functionality you are looking to
implement, check with the vendor as some implementations may not support in their initial HTTP/2 releases. As a result, I
would not expect to see wide adoption of these features in the short term.

SERVER PUSH
Web site analytics can reveal trends of users after landing on the home page click on the login page or when viewing a
photo album most users view the next image in the album after viewing the first image. Knowing this it is possible to send
data that a user may want before they even ask for it. HTML5 defined the ability to prefetch content that the browser may
need in the future. The catch is that the content is only downloaded when the browser is idle and given the vagueness in the
specification browser implementations can vary widely.
Server push in HTTP/2 allows the server to proactively send resources to the client it knows or predicts will be needed
without waiting for the client to request them, for the browser to be idle and without adding additional page weight to a page.
As with priorities I expect to see server push be implemented at a future date - Nginx

WHERE DO I GO FROM HERE

HTTP/2 is eliminating the need for many FEO techniques that have previously been used to speed up web pages. Below is a
table highlighting which techniques will no longer be applicable and which ones should be removed if implemented due to
potential negative consequences. Many web performance optimizations such as image optimization, minification, caching,
and use of a CDN are still relevant in an HTTP/2 world and will continue to help improve the performance of web
applications. Take a look at what you have implemented and determine what changes need to be made to your applications
either by eliminating FEO techniques in use or adding new optimizations.
Method

Benefit

Downside

Avoid Redirects

Reduces unnecessary
requests.

Still applicable.

Enable compression

Reduces size of content and

overall page weight.

Still applicable.

Inline CSS & JS

Eliminates HTTP Requests.

Leverage browser caching

Improves performance for

repeat visitors by reducing
content validation requests.

Difficulty caching content for

repeat viewers.

HTTP/2 compatibility

Concurrency functionality
makes this unnecessary.
Still applicable.

Minify Resources

Eliminates whitespace and

comments making overall
page weight smaller.

Still applicable.

Optimize images

Maintain quality of image

while reducing the size.

Still applicable.

Optimize CSS delivery

Placing CSS at the top of a

page improves page render
times.

Remove render blocking JS

Placing JS towards the

bottom of the page improves
page render and load times.

Use a CDN

Places content closer to

users.

Image Sprites

Reduces requests by
sending images as a single
file.

Re-ordering content may

cause pages to not load
properly.

Ability to set priority makes

this unnecessary.

Re-ordering content may

cause pages to not load
properly.

Setting priorities and

dependencies makes this
unnecessary and eliminates
the downside of reordering
content.
Still applicable.

Can break caching as a

change to one image results
in all images being redownloaded.

Concurrency functionality
makes this unnecessary.

Concatenate files

Reduces requests by
sending JS and CSS as
single files.

Can break caching as a

change to one file results in
all being re-downloaded. ReConcurrency functionality
sources may be remakes this unnecessary.
downloaded on multiple
pages based on the
combination of files.

Prefetch resources

Proactively send resources

not yet requested.

Variability in browser
implementations.

Server push replaces this.

Lazy load images

Delay loading of images not

in the viewport to prioritize
loading of content in
viewport.

Requires additional JS code

increasing page weight. Can
cause some pages to not
load properly.

Ability to set priority makes

this unnecessary.

Domain Sharding

Increase browser
concurrency by opening
additional connections.

Additional overhead of DNS

And TCP connections. Not
an efficient use of TCP.

Concurrency functionality
makes this unnecessary.
Maintaining it may negatively
impact performance.

For additional information on HTTP/2 vs HTTP/1.1 check out Ilya Grigoriks HTTP/2 anti-patterns presentation.
Read Previous post

Visit our Blog to know more