Re-Design Reprise: Theme Tweaks

I've made an effort to reduce the size of the static assets of my theme to speed up the page loading on mobile platforms; my target was a normal G2 connection, so 300 ms of latency and 250 Kb/s of downstream bandwidth.

The elephant in the room was the JQuery library required by Bootstrap, in my case was used only for the collapsible navigation bar, so it was the first thing I tried to tackle. I looked to compile only the required module, but the gain was minimal. Next I tried automatic tools for dead code elimination and "three shaking" but they didn't produced a gain either. Fortunately before I started to write a solution by my own, I've found an actively developed library created to replaced JQuery as a drop in replacement, so with the bootstrap.native library it passed from 120 KByte uncompressed to less than 3.5 KByte uncompressed.¹

I slightly modified the Javascript to not be completely broken on IE8, still some glitches remain, and arranged the theme to not be completely unusable if Javascript is disabled.

Jinja templates

I used the occasion to fix an ugly bit that was present in the previous iteration. The current wisdom is to put all the Javascript functions at the end of a page to speed up the rendering, but with my theme, when an images gallery was added to an article, a Javascript function necessary to initialize the gallery unfortunately ended in the middle of the index page, as I couldn't find a way with Jinja to pass a value from a child template to a parent template if the value was defined inside an include.

I was stuck forever with this and I suspect a bug as it's supposed to work according to Jinja's documentation. I ended up using a workaround abusing the global context:

{% set _ = gallery_required.append(gallery_name) %}

It's not a clean approach and it risks to not work in a future version, but I couldn't find a better solution. When I have some time I need to isolate a test case and report it upstream.

Unfortunately the current stable version (2.9) fixed a bug that enforce the scoping of variables modified inside code blocks and it broke the rendering of my archives.html page. Considering the design's decisions, I'm starting to doubt that Jinja is flexible enough for a static site generator.

Anyway I rearranged the archives code without values passed using variables and now should be fixed for the foreseeable future:

{% for year, articles in dates| groupby('date.year')| reverse %}
    {{ year }}
    {% for article in articles %}
        {{ article.date.strftime("%d %B") }} - {{ article.title }}
    {% endfor %}
{% endfor %}

Playing with Fonts

I've experimented with WebFonts in the theme, i.e. if the primary font choice wasn't installed in the system, a webfont was used as a secondary choice². I've verified that Firefox doesn't show glitches but testing it with Chrome there was an ugly FOIT when loading the index page, so for the platforms that don't have Georgia installed I'm sorry, you have to use your system version of a serif font.

Critical

Another thing that I've played with is what is called "critical CSS".

There is a Google developer page where it's suggested to inline in the page's header tag only the portion of CSS necessary to style the elements displayed on the view-port³, defer the loading of the full CSS file as one of the last operations and finally inject it in the page when the file is downloaded.

I've implemented the thing, but considering that the full CSS when minified it's only about 20 KByte, I've toyed with the idea to put all my CSS inline.

Things That Need Fixing

There's still a thing that's broken: Bootstrap doesn't do anything special with the abbr HTML tag⁴, so on devices with touchscreen, abbreviations don't work. It's in the to do list.

Conclusions

The final tuning was to enable HTTP/2, gzip compression and cache expiration for the static assets and moving the page encoding from the HTML to the web server headers.

I haven't extensively bench-marked the page loading, but throttling the network parameters to simulate a regular 2G connection, the process of loading and displaying an index page with a cold cache is completed in less than two seconds, the painting of the view-port above the fold happens after less than 700 ms. On a desktop it's near a half second, not bad considering that the server I'm using is now in the East of North America.