Building a better static page

In an effort to gain a better understand of the full stack in web development I tasked myself with improving my static pages. While I am concurrently learning web application development, I thought it would be beneficial to try and solve and better understand a static page. What follows are the simple tricks and tools that you can use to improve your site and its delivery.

Target and Budget

I sought to better improve my resume site which is only a few separate HTML files, a single style sheet, and a handful of png’s. This is what most would call a relatively small, static site and a perfect toy for these experiments. This blog is also static (Jekyll), and falls on the same domain name, but lets keep it separate for simplicity. I seek to keep costs low on this project while trying to eek out the best performance. Obviously, the game changes as budget and page-views increases.

Metrics

Page load speed

You can’t trust how snappy your page loads on your development machine. You probably have cached copies of pictures and fonts that deceptively make your page appear to load instantaneously. Further, you can’t really gauge if a site is getting better without a solid external metric. To this end, I recommend

• webpagetest.org
• Google’s page speed

Both of these give load times and suggestions for improving speed. I’ll cover how to implement a lot of these suggestions.

Responsiveness (other devices)

Similar to page speed, it is often tough to determine how a page will look on other devices. You can resize your window but this is a bit of a crude process. If you want to go this route, you can use browser extensions such as Window Resizer for Chrome. This gives you preset sizes that match device resolutions. I ran in to a hiccup where I couldn’t resize bellow 400px with which is much greater than many phone widths. So, I turned to this excellent free tool:

• Screenfly

Increasing page speed

There are many improvements that you can make to improve page speed, and the two tools I mentioned above will help identify them. However, lets touch on the low hanging fruit.

Compressing static assets

One of the best way to reduce the transferred amount is to compress assets before sending them. Without getting into too much detail, assets are either compressed in advance, or compressed on-the-fly by the server. The latter option is a lot lower maintaince if you are running nginx or apache. If you are running an S3 bucket site, you will likely have to do the former. Gzip is the standard for compression, so google that for your specific configuration. The general rule here is to compress any text asset that is static: static pages, css files, javascript. I was running on a server that uses nginx, and found that addding this to the site file, inside the server, section got gzip working for me:

gzip on;
gzip_http_version 1.0;
gzip_comp_level 6;
gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;
gzip_disable "MSIE [1-6]\.(?!.*SV1)";
gzip_proxied any;

Line 2 is a value that allows gzip to work with cloudfront. Line 3 specifies compression level, line 4 specifies the type of assets that will be compressed. Line 5 is a work around for internet explorer which can’t uncompress in early versions. The final line allows for serving when requests are proxied.