I've made some more small changes to the site design. * The list items in the post list are now columns using CSS flexbox. Previously the date and title were just separated by [white space](https://developer.mozilla.org/en-US/docs/Web/CSS/white-space). Now the title wraps properly on mobile displays, it should appear more 'visually consistent'. * Added navigation pointers to the bottom of each post. 👈 * A sitemap is now generated on every build, but I haven't rewritten the script to copy it into the site root. * Article text is now justified, with [some hyphenation](http://clagnut.com/blog/2395/) to balance out the spacing between words. This feels like a good compromise, but I always wonder if I'm sacrificing legibility for aesthetics? _Edit July 2020:_ Commented out this justification/hyphenation code for the moment. It still [looks beautiful](/blog/media/2020/06/site_changes/lynx_screenshot_2.png) in Lynx. ![lynx screenshot](/blog/media/2020/06/site_changes/lynx_screenshot_1.png) Looking at the site stats, the majority of requests are not referred from elsewhere. I suspect that means whoever checks this blog (people check this blog?) typically goes directly to the main index. It might be helpful if the index loaded faster, so I rewrote the site to inline all the CSS in the header of the main page, following [this tutorial](https://www.sitepoint.com/inline-css-in-jekyll/). The CSS is all copied and compressed during site generation, so I don't need to worry about keeping the inline code up to date. The idea behind serving everything in one file is that it cuts down on HTTP round-trips. One file, one request, faster page loads! The limit for one HTTP trip is about [14kB](https://simonhearne.com/2017/optimising-css-image-sprites/#keep-it-under-14kb), while at the moment the main blog page is 7.9kB, well under the limit. The HTML is [compressed](/blog/2020/04/05/jekyll_build_server/) too. Is this still necessary? 5G towers are going up in most cities around Britain. Oxford doesn't have any yet, but it's only a matter of time. We can count on mobile internet getting faster every year, and the page already loads reliably in under half a second. I made a similar optimisation to my contact page last year, and only really noticed the difference when I was in Venezuela on an extremely slow network. There's another argument that you should really be [relying on the cache](https://www.tunetheweb.com/blog/inlining-css-is-not-for-me/) instead, that's where the [real savings](https://twitter.com/mattround/status/1250412984830222336) are. Without going into (more) aggressive caching, I think the site is as fast as it can possibly be at the moment.