RFC: Web optimizations for VA.gov

[asg5704]

RFC

I did some preliminary analysis of possible improvements that can be implemented to ensure assets are loaded efficiently on VA.gov. I am requesting comments, feedback, questions, etc of if these implementations can be implemented on our AWS S3 bucket using an nginx proxy.

Use Brotli compression to further reduce file sizes sent over the network on Amazon S3 buckets.

Why? Better file size compression. Brotli compression compared to GZIP:

The current sizes of bundled JS assets on the AWS S3 bucket are (102Kb, 102Kb, 299Kb, and 194Kb) respectively. Using Brotli these could become (87.7Kb, 87.7Kb, 257Kb, and 166.8Kb) respectively. 697Kb of data down to 599Kb (~100Kb)

Pros

• Better compression ratio
• Reduction in file-sizes
• Latency improvements
• Relatively easy to implement on nginx (module provided by Google)

Cons

• Potentially slower compression speed
• Brotli is not supported in <IE11 browsers (see https://caniuse.com/?search=brotli)
• Would need a fallback to GZIP for unsupported browsers

// Example of nginx.conf
brotli on;
brotli_comp_level 10;
brotli_static on;
brotli_types text/plain text/css application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript image/x-icon image/vnd.microsoft.icon image/bmp image/svg+xml;

gzip on;
gzip_disable "MSIE [1-6]\.(?!.*SV1)";
gzip_vary on;
gzip_proxied any;
gzip_comp_level 9;
gzip_types text/plain text/css application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript image/x-icon image/vnd.microsoft.icon image/bmp image/svg+xml;

Upgrade to HTTP/2 protocol

Why? Could drastically improve server latency for requests

Assets request from the AWS S3 bucket are currently served over HTTP 1.1, which only allows 6 TCP connections per origin. If there are more than 6 connections it places the requested files in a Queue to be resolved at a later time which why there is a lot of latency. By upgrading to the HTTP/2 protocol, we could benefit from its multiplexing capabilities (on a single TCP connection 🤯 ), compression, and prioritization it uses to reduce web page latency.

Pros

• Not limited to 6 TCP connections 🥳 per origin (aka using multiplexing)
• Better compression (using HBASE to compress headers metadata)
• Priority in streaming

Cons

• Many browsers that use HTTP/2 require HTTPS
• Only partial support for IE11 (only Windows 10 users have support, Windows 7 and below have no support
• Would require a fallback to HTTP/1.1 for non-supported browsers (see https://caniuse.com/http2)

[f1337]

Excellent analysis @AGarcia-Clarity, thank you!!!

With the caveat that I have no idea what effort is involved, I think HTTP/2 is something we should do anyway.

If we add brotli compression support, I'm guessing we're going to increase build times. I'd like to see us quantify what that difference is, for the brotli change alone. Because our build times are atrocious right now, and we are actively trying to reduce them.

[asg5704]

Thank you @f1337. I would have to do more research but from my readings:

HTTP/2

Mentioned that HTTP/2 could be a larger fix if we already have HTTP 1.1 optimizations in place. The beauty of HTTP/2 is that we do not have to get rid of HTTP/1.1 at all (because it will be around for at least another decade). Instead we could allow HTTP/1.1 to create an upgrade request via Upgrade headers if the browser supports it.

Brotli compression

It could increase build times depending on how we do the Brotli compression. There are two options Static compression (using webpack) and Dynamic compression which each have their pros & cons.

1. Static compression

We would have to compress assets ahead of time during the build process and then they are uploaded to the S3 bucket. This option would increase build times however assets would be loaded quicker (latency reduced)

2. Dynamic compression

Compressing assets on-the-fly when they are requested from the browser. This option would NOT increase build times because creating & updating compressed versions of these assets doesn't need to be done. However the latency could take a hit if we set compression levels too high.

[asg5704]

TBD at a later date.