During 2016 I decided that I wanted to blog again. This website long ago was a wordpress install that had my front page, some blog content, and my portfolio for my Library Science masters. I did not use the website much and paid for a mysql database for no real reason except that wordpress needed it. I was able to get to the point that I could tweak some settings though it was a challenge at the time. I did not have much to say then.

I did bring my website back and it stayed a static single page for most of its current iteration. Just my contact details and a short biography and not much else. I liked the idea of a static site generator but learning how the system works for a specific generator stayed on the back burner for a while. I ended up choosing pelican a python static site generator but ultimately it could have been any provided I did not mind maintaining it. Until recently it was not so common to have node, ruby, php, and python all on the same cheap no support webhost. Now I can keep all my content on the server and describe a publishing pipeline.

Once I started to write blogs again I chose a theme and set it up. I began to look at performance. I recently removed the bootstrap js and jquery to lighten the load but I probably broke some mobile functionality with that. I used Google’s Page Speed Insights to measure the site and its performance and started to tweak things so it would load faster.

At the beginning of this year I found this amazing article about performance. I want all of my future projects to take this into serious consideration. Performance and security are a tough balance against developer productivity. At this time I can see that most web technologies are chosen for developer productivity and shininess and not always for the users best interests. Online news and magazines have shown how far this can go. Many people have reported janky experiences reading a simple news article with a lot of analytics tracking, external libraries that monitor everything and add a lot of extra ads and content on the page. Along with extra modals nagging us to add/subscribe/sign up.

There are some technical challenges and tradeoffs with aiming for performance. Ideally a lot of the measures in the checklist can be taken on their own and not require doing everything up front.

First look at your webserver and make sure you are returning responses quickly. There might need to be a lot of troubleshooting and debugging to find out why responses are slow. Does your page query the database a lot to render one page? Can caching be used at all?

It is ok to send a lot of assets to the user especially if they are expecting it such as a marketing website for products. However, what can be done for that that initial paint? According to the checklist having an initial paint of less than 1250 milliseconds is a big goal for desktop and 3 seconds for mobile. The ideal experience would be the end user begins to see the content quickly and can do some basic interaction while all the nice stuff loads in over time. This might not be an easy task for an existing website.

The next step is to use build time steps to do some of these performance considerations. For Page Speed Insights common complaints are on using correct cache-control and expires headers for resources. Minifying css, html, and JavaScript. If you are serving content over HTTPS and have a login page you may need to turn off compression due to BREACH vulnerabilites allowing one to brute force private keys from compression caused issues.

For my own website I stuck with a automated build pipeline to do the minifying for me. My site doesn’t tend to need any JavaScript but minifying the css and HTML comes in handy. UglifyJS has a lot of information on what types of things can be stripped and how safe it is to do so. These are the settings that I have found to be safe for minifying HTML.

removeAttributeQuotes: true,
removeRedundantAttributes: true,
removeComments: true,
removeCommentsFromCDATA: true,
removeCDATASectionsFromCDATA: true,
collapseBooleanAttributes: true,
removeRedundantAttributes: true,
useShortDoctype: true,

I still need to redo my theme so I can remove the dependencies on bootstrap and any JavaScript. There really is no need on my website to have anything JavaScript I even removed Google Analytics because I have never found much need. It’s nice to know about traffic but otherwise I was not getting much utility out of it.

I will be using this performance checklist in my future applications but I wouldn’t expect every project to adopt every single item.

Contact me

Let’s Start a Project