Reduce image loading layout jitter and best practices in Hexo

Image loading is prone to layout jitter, and lazy loading of images can easily highlight such layout changes. When I recently tested the lazy image loading function for my blog, I was deeply disturbed. Want to die.

Image source davidecalignano.it

Basic best practices

In modern best practices web.dev given , developers should

• Set the width and height without unit for the picture element in HTML;
• Define the specific size of at least one dimension in CSS, and set the size of the unspecified dimension to auto ;

aspect-ratio according to the width and height provided by the HTML of the image element, so you only need to define the specific size of a dimension in CSS, and the browser will automatically calculate the size of the indefinite dimension. The effect is similar to:

img {
  aspect-ratio: attr(width) / attr(height);
}

In addition, before supporting the aspect-ratio CSS property, some browsers (such as Chrome 79-87) already used these two HTML properties to calculate the aspect ratio internally. However, the effect is poor, and it often fails when the image fails to load or when loading="lazy" is used, which can not reduce the layout jitter.

Best practices in Hexo

So how should we set the length and width for each picture? manual setting seems unrealistic. Although the author's blog currently has only a dozen pictures, when I set it to the third one, I'm already tired. Markdown does not have a unified and extensive image size setting grammar, and setting these when writing is mostly unnecessary and very troublesome.

After searching existing Hexo documents and plug-ins, I did not find such a plug-in. You can go to sniff the size of the pictures used in the blog and set it on the corresponding <img> element . So I wrote a hexo-filter-probe-image-size and installed it through npm.

After the installation is complete, turn it on in the Hexo configuration file. By default, this plugin uses the size of the image with the same name in the images/ , and does not send a real network request.

# In _config.yml
probe_image_size:
  enable: true

Someone chose to specify a default size for all pictures because the pictures are scattered everywhere. The author is the same, the pictures are scattered everywhere. To solve this problem, the proxies option implemented to configure the different positions of each picture . This configuration item will replace the default behavior described in the previous paragraph.

probe_image_size:
  enable: true
  proxies:
    # 名为 example.png 的图片
    # 在 D:/Writings/example/ 里
    - name: Element module docs
      match: ^.+/(?=example.png$)
      target: D:/Writings/example/

    # 开头是 Donate- 或 Donates 的图片
    # 在 E:/Documents/Donate/ 里
    - name: Donates
      match: ^.+/(?=Donate[s-][^/]+$)
      target: E:/Documents/Donate/

    # 网络图片都映射到 D:/CDN/img/
    - name: HTTP to local
      match: ^(https?:)?//.+/
      target: D:/CDN/img/

This is also a good time to organize website pictures.

Each match sub-setting item represents the regular expression of the path to be matched, and each target represents the path that should be resolved. It turns out that the plug-in operation sniffing successfully does not have <img> elements with width and height attributes. A more detailed explanation and examples please visit the warehouse the README README document.

Because most of the picture size information is located in the file header; the author’s blog has only 14 pictures, which can correspond to the local file; the plug-in is processed in parallel, and the total sniffing time of these picture sizes on the author’s computer is only about 41 ms. Throw away the initial processing time, and add about 1-2 ms of sniffing time to each picture.

Now test the author's blog sliphua.work PageSpeed Insights . The overall first content display is also much faster, how much faster because it has not been tested before, I don’t know. It just works.