HTTP 1.1/2 optimization

Tech
, ,

Major features of HTTP/1.1 and HTTP/2

HTTP/1.1 and HTTP/2

General optimization

These common rules can be applied to HTTP/1.1 and HTTP/2.

  • Reduce DNS lookups and latency

  • Make fewer HTTP requests

    Concatenate CSS, JS files and use image sprites properly;

  • Reuse TCP connections

  • Parallelize requests and responses

  • Add cache-related headers

  • Reduce transferred data

    Minify HTML, JS, CSS files, compress other text-based assets;

    Compress images, such as removing unnecessary metadata, reducing the numbers of colors, using SVG or Icon Font;

    Use proper image dimensions. different scenarios, different images;

    Use right image format, such as WebP, BPG;

    Lazy loading some modules or images/videos/audio, users may not scroll to these parts, also could consider media queries;

  • Inline resource properly

    such as JS/CSS code, images

  • Use CDN or self-built cache system

    Caching every cacheable resource;

  • Avoid HTTP redirects

  • Eliminate cookies partially or entirely

See also:
Web performance optimization on the Google Developer website

HTTP/1.1 optimization

  • HTTP Pipelining

    The default of a HTTP/1.1 connection is persistent, but it implies a strict FIFO queue, have head-of-line blocking problems;

    Pipelining is complex to implement correctly, buggy proxies are still common;

    Use it very carefully.

  • Multiple TCP Connections

    Most modern browsers support opening up to six connections per origin(host name + port) usually;

  • Domain Sharding

  • Concatenation and Spriting

    JS/CSS file concatenation and image sprites are so popular in HTTP/1.1 scenario;

    Pros: fewer HTTP requests; fewer transferred HTTP header data; eliminating extra network latency;

    Cons: extra application complexity (preprocessing, deployment, code); expensive cache invalidations; larger JS/CSS files need more parsing, rendering time; Bigger images need more resident memeory on the browser side; more complex update policy;

    Don’t combine unnecessary resources for the current page;

    Seperate resources into several bundles according to different purposes, don’t bundling independent resources;

    Seperate and deliver first-paint critical JS, CSS bundles;

    Apply them carefully, measure the results, figure out the proper file size, no ideal size;

  • Resource inlining

    This technique is also popular, mostly embed JS, CSS code and images into a page;

    Don’t inline resources that being used by multiple pages;

    Inlining resources that are small, and limited to specific pages. In practice, under 1-2KB are small, resources below this often incur higher HTTP overhead than itself;

    Don’t inline frequently updated resources;

    Don’t inline frequently accessed resources, then can use CDN and cache;

    Base64 encoding has byte expansion as compared with the original resource, increased decoding time;

See also:
Connection management in HTTP/1.x
Akamai HTTP 1.1/2 Demo

HTTP/2 optimization

  • TCP, TLS Optimizations

    Minimum requirements for the HTTP/2 server:

    Server should start with a TCP cwnd(Congestion window size) of 10 segments;

    Server should support TLS with ALPN negotiation;

    Server should support TLS resumption to minimize handshake latency;

  • Remove HTTP/1.1 workarounds

    No need Pipelining, Multiple TCP connections, Domain Sharding, put resources under a same origin;

    Concatenation and Spriting are still useful, small files are bad for disk IO, can cache them? take care of your cache system, make it work like you think! don’t remove them aggressively;

    Resource inlining can be replaced by server push, to improve cache performance, especially in mobile network environment, it have high-cost roundtrips. Sometimes static assets are in CDN, how to push? it is awkward! Only support GET, HEAD methods; No URL fuzzy matching for the Node.js http2stream.pushStream() function at this moment; Don’t support window.fetch(), use XMLHttpRequest; May push already cached resources; don’t remove it aggressively also;

Browser optimization

  • DNS prefetch

    <link rel="dns-prefetch"  href="//example.com">

    It is a hint to the browser, but Chrome always perform it.

  • TCP preconnect

    <link rel="preconnect" href="//example.com">

    A hint to the browser that it open a connection to the linked web site in advance, also perform DNS lookups.

  • prefetch

    <link rel="prefetch" href="//other-site.com/images/big.jpeg">

    Suggest the browser to fetch the linked resources that will be used in the next navigation/page load;

    Will generally cause the cookies of the prefetched site to be accessed;

    No same-origin restriction;

    Has a lower priority than preload, preload is for the current navigation/page load;

  • preload

    <link rel="preload" href="sample.mp4" as="video" type="video/mp4">

    Tells the browser to download a resource because this resource will be needed later during the current navigation;

    It is not a suggestion to the browser, is a MUST;

  • prerender

    <link rel="prerender" href="/next-page.html">

    Suggests that the browser fetch the linked resource in advance, and that it also render the prefetched content offscreen so it can be quickly presented to the user once needed.