Image loading is easy to bring layout jitter, lazy image loading is easy to highlight such layout changes. I recently had a hard time testing the image lazy loading feature for my blog. To shoot.

Figure source davidecalignano. It

Basic best practices

In the modern best practices presented in web.dev, developers should

  • Set unit-independent width and height for image elements in HTML.
  • Define the specific size of at least one dimension in CSS and set the unspecified dimension size value toauto;

Modern browsers automatically calculate aspect-ratio based on the width and height provided by the image element HTML, so by defining the specific size of a dimension in CSS, the browser will automatically calculate the size of an unvalued dimension. The effect is similar to:

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

In addition, before supporting the aspect-ratio CSS attribute, some browsers (such as Chrome 79-87) already used these two HTML attributes internally to calculate aspect ratios. Loading =”lazy” is used, for example, when an image fails to load. Loading =”lazy” does not reduce much layout jitter.

Best practices in HEXO

So how do we set the length and width of each image? Setting it manually seems impractical. I only have a dozen pictures on my blog right now, but I’m tired by the time I get to the third one. Markdown doesn’t have a universal syntax for setting image sizes, and setting them up is mostly unnecessary and cumbersome when writing.

After searching through existing Hexo documents and plugins, I didn’t find a plugin that would sniff the size of an image used in a blog and set it on the appropriate element. So I wrote a hexo-filter-probe-image-size and installed it via NPM.

After the installation is complete, turn it on in the HEXO configuration file. By default, the plug-in uses the size of the image of the same name in the website images/ directory as the size of the networked image, rather than sending a real network request.

# In _config.yml
probe_image_size:
  enable: true

Someone chose to specify a default size for all images because they were scattered all over the place. The same goes for me, with pictures scattered all over the place. To solve this problem, the proxies option is implemented to configure different locations of each image. This configuration item replaces the default behavior described in the previous paragraph.

Probe_image_size: enable: true proxies: # image named example.png # in D:/Writings/ -name: Element module docs match: ^.+/(? =example.png$) target: D:/Writings/example/ # Begin with pictures of Donates - or Donates # in E:/Documents/ Donates / -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 your site images.

Each match subsetting represents the regular expression for the path to match, and each target represents the path to be resolved to. Plug-in operation sniffer successful without original width and height attributes of the < img > element. For a more detailed explanation and examples, visit the repository’s README README documentation.

Because most of the image size information is in the file header; There are only 14 images on my blog, all of which correspond to local files. Plug-in parallel processing, the total sniffing time of these image sizes on the author’s computer was only about 41 ms. Each image adds about 1-2 ms of sniffing time, discarding the initial processing.

Now test my sliphua.work on PageSpeed Insights with a layout jitter of 0 when it loads. The overall rollout is also much faster, how much faster because I didn’t test it before, I don’t know. As long as it works.