![]() It all sounded like an easy fix for my laziness. I could resize my images at build time while compressing them and changing the encoding quality. Skimming through the docs, it looked like there was something called Image Processing in Hugo, and that was supposed to help fix all my problems. There seemed to be a light at the end of this tunnel though. Hence the horrible performance score on Lighthouse. I couldn’t be bothered to resize images multiple times to do responsive images.I was too lazy to bother resizing all the images for the list layout, so most of them were quite big and loaded all at once on the home page.There were a few problems with this approach. ![]() I write them in markdown, so adding an image was just a matter of putting the right path in there: ![]() That meant using images in my articles was easy. I also had my images stored in the static/ folder, because that made sense? I mean images are not exactly content or assets, right? Turns out it’s wrong, but more on that later. Me being lazy, I considered that a win □♂️. I had my cover image in the post front matter, under the images list, because that was the Hugo way to automatically make that image a Twitter social card as well. Or if you look at my web.dev scores, not so little. Now that the “MVP” has been released for a few months, I keep finding small, little things to improve with it. Mine wasn’t a very complicated Hugo website, to begin with, so following in Hui Jing’s footsteps, we made it work without docs. They are geared towards helping you either develop a theme or change your theme to accomplish something new. She created all the custom CSS for it, with a fantastic Masonry layout.īut that meant from this point forward the Hugo docs were mostly useless. I didn’t want a stock theme, it’s my personal website after all, so it should be an expression of myself, right? Well, I was lucky enough to catch Hui Jing in a benevolently, slightly bored, mood. It all relies on the idea that you’ll install Hugo, create a new site, and then add a theme. But what didn’t work so well for me was the Hugo documentation. ![]() I got tons of improvements in build time. Perfect Google Lighthouse Score.I’ve recently moved my personal website to Hugo, and it’s been mostly a pleasant experience switching over from Jekyll. Website performance expert and I think this is a really big deal, especially when you want to get a It turns it into a JPG file with 50% compression and a width of maximum 1400 pixels, typically resulting in a <100kb image, which is often ten times smaller than the original. This means that a standard image in markdown, like this: !(/uploads/image.png) The file is called ‘/layouts/_default/_markup/render-image.html’ and contains the following code: This answer to a relatively unrelated question, I realized Hugo can resize standard markdown images through render hooks! I immediately browsed through the docs and created a hook to add to my most recent project… and it worked! Although shortcodes were a step in the right direction, ‘regular’ markdown editors (like my CMSĬms. is using) still created unresized images. The command to do so had to be written in a shortcode or a layout. When I switched to Hugo in June 2021 I was happy to find that Hugo could resize images ‘on build time’. However, images in my markdown were still not resized, often resulting in huge page loads. It resized your images on the fly and kept it in their cache for 30 days. When I switched to Jekyll in 2015 I found out that I could no longer resize images automatically. Before 2015 I was building WordPress websites.
0 Comments
Leave a Reply. |