Optimizing the artist's web site

The initial conversion of my wife’s web site to a Hugo-generated static site was complete, but the work was not done yet.

The old site had been ‘optimized’ for turn of the century web performance but that was all based on old wisdom - mostly poor resolution images, no responsive design considerations, hand tooled HTML headers, yuck.

Simply switching to Hugo and basing the initial layout on the somewhat canonical Ananke Gohugo Theme was, as the motto says - a solid starting place for Hugo sites with basic features and include best practices for performance, accessibility, and rapid development.

We had simply started using the best images of her work that we had available following the initial old site conversion. It was only when a couple of our early testers noted some slow rendering and other issues that I began to look a little deeper.


The first thing I noticed was that the site’s default featured image, that appears in the banner area, was over 2 MB. Yikes. We were probably eating a good portion of some of our visitors’ data budgets with some of the images we were using. Some ImageMagick manipulations and experimentation with quetzli got that down to 435K.

But that process was going to take way too long for her site’s hundreds of images. So at first I settled on a little scripted application of jpeg-recompress and that brought the overall image content down from 277MB to 138MB. Better but not ideal.

Next, many of her images were really big, resolution-wise. An application of ImageMagick’s mogrify brought the image content further down from 138MB to 84MB. I knew it still needed some responsive image work but better.

Tweaking the colors and layout

Early testing of the revised site by some fellow artists had also identified some other issues.

  • The theme’s default text color scheme used gray text - which looked nice and modern but some testers noted that it was a bit hard on their eyes. Out went the gray and in came near-black. It does not seem quite so pleasing to my eyes but I am not the one we are trying to please.

  • I’d been testing the responsive layouts in my browser but there is nothing quite like real users using their own devices. Some noted that on small handheld devices the text was a bit squashed against the sides of their devices. Since the theme is using Tachyons for its layout is was fairly simple to adjust the spacing for small devices.

  • I had initially gotten cute and made the entire project summaries, that appear on the landing page as well as in the categorized ‘galleries’, the featured images as well as the titles and summary text into active links. Little did I realize that on some mobile devices that meant all the text ended being displayed as blue, underlined links, despite trying to avoid that. I attempted adjusting the CSS a:*-any-link styles but that did not work reliably. In the end it was easier (and maybe a little clearer for users) to make just the image and the subject into links and add a “More »” button.

  • I came across GitHub’s advice for using system fonts and decided that would make for a more consistent look than simply specifying sans-serif as well as better than imposing a web font on users. Unfortunately on Android devices the lack of a specification to use their Roboto font led to a fallback to serif faces. I decided that the rare Linux user experiencing issues on GitHub were even less likely on her website and I’d rather cater to the far more numerous (I expect) Android and Chromebook crowd.

There are still more optimizations needed but for now that will have to do.