PageSpeed Optimisations Changes (compression, caching, minify)

Hosting on Micro.blog
1

I’m looking at ways to increase the speed of already fast micro.blog websites.

Looking at the PageSpeed results of micro.blog sites such as news.micro.blog.

There’s a few easy wins that I think can be implemented to speed up everyone’s blogs and reduce overall bandwith for micro.blog.

First of all, enable gzip and brotli compression on the Caddy servers which server the blogs. This has been brought up before and is a pretty easy win.

Second, add cache TTL to static assets of 365 days or 31536000 seconds. The default themes already have cache busting static elements, so this shouldn’t casue any issues. Could take this a step further and update the default themes to serve webP images resized correctly. This has been suggested before but no one suggested a TTL — it should be 365 days. :slight_smile:

Third, add the build flag --minify to the Hugo build pipeline. Hugo has the annoying quality of creating lots of white space in the generated .html pages. Basically, whereever there is Go templating logic, this gets turned into whitespace newlines in the generated .html. Take a look at the .html source of your micro.blog. This is just wasted bytes and the --minify tag will strip this in the build step. Seperate to this, could we have the ability to add custom flags to the build step?

CleanShot 2024-07-17 at 18.58.17@2x
CleanShot 2024-07-17 at 18.58.17@2x1278×750 78.3 KB

I think these pretty simple changes will have a measurable impact on micro.blog websites and get people closer to a clean 100 Lighthouse score.

@manton can we get these implemented?

1 Like
2

Turns out you can add your own hugo.yaml file to control the build process of Micro.blog. So number 3 can be addressed by adding:

minify:
  minifyOutput: true

However, this causes a few other issues because it’s overwriting the default config for Hugo.

@manton: could you share what the default config for Hugo is for Micro.blog?

3

The defaults are here: theme-blank/config.json at master · microdotblog/theme-blank · GitHub.

When you edit your config, it does not mess with the defaults. Manton combines the files, using the default first, then overriding any values you specify inside your config (or adding them if they didn’t previously exist).

There is no need to edit or include any default you don’t intend to override.

For example, my theme config.json contains the following only:

{
  "markup": {
    "highlight": {
      "anchorLineNos": false,
      "codeFences": true,
      "guessSyntax": true,
      "hl_Lines": "",
      "lineAnchors": "",
      "lineNoStart": 1,
      "lineNos": true,
      "lineNumbersInTable": true,
      "noClasses": true,
      "style": "dracula",
      "tabWidth": 4
    },
    "goldmark": {
      "renderer": {
        "unsafe": true
      }
    }
  },
  "params": {
    "github_username": "jsonbecker",
    "instagram_username": "jsonbecker",
    "mastodon_url": "indieweb.social/@jsonbecker",
    "bookshop_affiliate_id": "9011",
    "menu": [
      {
        "name": "Books",
        "url": "/books"
      },
      {
        "name": "Now",
        "url": "/now"
      },
      {
        "name": "Archive",
        "url": "/archive"
      }
    ]
  }
}
4

Just to add to that, Micro.blog only merges the config files together for the JSON version, not YAML. Always best to use JSON configs.

5

Ah thanks for the tip about matching the format.

I’ve added the following as config.json in the theme editor, but it doesnt appear to be changing or merging with the original config.

{
  "security": {
    "enableInlineShortcodes": true
  },
  "minify": {
    "minifyOutput": true
  }
}

Any tips?

6

What makes you say that it’s not merging? I don’t think (other than maybe an export?) Micro.blog ever displays the merged configuration.

7

It’s not applying the configurations. My inline shortcode is not compiling and the output is not minimised. Both of those things happned with the .yaml file, but that overwrote the default config.

8

Sorry, I forgot to mention something: there is a hard-coded list of allowed config fields that can be overridden. security and minify aren’t allowed, but I can enable them.

9

Oh interesting. Yes could you’d up let those be overridden? The inline shortcodes like inline html is not dangerous if you own the content, and quite useful.

Could you let us know what are the list of configs that can be overridden?

10

Looks like the minify config is working, but still have some trouble with inline shortcodes. Has the security config been enabled?

11

I haven’t enabled security yet. There are some fields that we may not be able to allow — because security :slightly_smiling_face: — so I need to review each field individually. Can you explain more about how you’d like to use enableInlineShortcodes? I wasn’t familiar with it before now.