Changes to team member images / processing to improve page load time on the about.gitlab.com landing page.

At the moment https://about.gitlab.com is a bit of a behemoth of page load time.

Five seconds is an Internet eternity! And in some cases I've seen over six seconds. Even on LTE on a mobile device, this would be a very sad experience. 😢📱

There's a couple reasons for this:

• Everything that happens in home.js causes a network request per # of team members with pictures. (Note that the class title js-landing-communityis a bit inaccurate here since it's pulling from Gitlab team members not avatars of people who have committed to Gitlab)
• The version of Nginx being used is either not enabled or not up to date enough to use http2.
• All the member images are of varying sizes and quality
• Blog post featurettes at the bottom use the full size image as the background which is not necessary.

I was able to get this number to down below two seconds (served from my local machine mind you, results on the open internet my vary)

To do this I did the following:

• I've rewritten the index.html.haml to create a shuffled list of team member images when the site is built versus happening in the browser during "page runtime".
• I've resized all the team member images to 200x200 pixels. In my responsive sizing tests I didn't see them go above this resolution even on a resolution larger than 1440p.
• I used Caddyserver's built in http2, gzip, and minification directives. I'm not too familiar with Middleman but it looks like minification is already happening in the build process and gzip is enabled in the Nginx conf based on the response headers. The key thing here is enabling http2 which allows for parallelized, not sequential, downloads of resources (i.e. the many little team member images happen super quick).
• On Nginx enabling http2 is just a matter of ensuring you have a version >= 1.9.5 and then adding http2 to the listen directives on port 443 (since it only available when using TLS) like so:

  server_name about.gitlab.com;
  listen 443 ssl http2;
  listen [::]:443 ssl http2;

• The bg image for "Feature Preview: Introducing Cycle Analytics" is a giant unsplash photo that was being fully loaded (a 1275x750 image) then resized to something in the 350px range. I shrunk it. On the actual blog post page, the image is blurred and the resolution decrease is unnoticeable.
• Enable gzip compression with nginx like so:

server {
   ...
   gzip on;
   ...
} 

• Adding proper caching headers to assets, 1 day is a good amount without having to worry about interference between old cached content and new expired cache content. The main thing here is that between page reloads it doesn't yet again make a request for the same file. The site nginx.conf should include these lines:

server {
   ...
   # Media: images, icons, video, audio, HTC
   location ~* \.(?:jpg|jpeg|gif|png|ico|cur|gz|svg|svgz|mp4|ogg|ogv|webm|htc)$ {
     expires 1d;
     access_log off;
     add_header Cache-Control "public";
   }

   # CSS and Javascript
   location ~* \.(?:css|js)$ {
     expires 1d;
     access_log off;
     add_header Cache-Control "public";
   }
   ...
}

• Removed highlight.css which wasn't being used anywhere (.highlight) as far as I could grep.

TODO:

• It would probably be better to include in the build process a process which given a healthy sized image it creates both a smaller image for the blog post preview divs and maintains the larger one for the actual blog post background.

EDIT: I just realized I also have the commit from !3232 (closed) here as well since I didn't initially have that in a feature branch in my fork. Let me know and I can fix this or if it also looks acceptable to merge, it can be done all at once here.

EDIT2: I've since improved my original page load even further, with the proper caching and on a reload after a full page load has occurred, the total transferred is only ~200kb. This is why you see so many 304s which indicate the asset has not changed since it was last requested. Shown here: