Hi all. I’m a Python developer, moving 15 years of family website across to Hugo with some basic questions.
The old site is a homegrown static generator with a Python script; once I get things right, I will write a Python script to walk the tree and create the Hugo posts and images for the old stuff, then use it henceforth.
I like to keep everything in a private GitHub repo for safety and portability. The images are not a problem - having hundreds in the GitHub repo won’t hit any limits in my lifetime, as long as I commit sensibly-sized ones and not my original photos (which live in iCloud/Mac Photos)
I plan to publish either with GitHub pages, or possibly a GitHub action into an S3 bucket configured as a website
Is there any benefit to ‘building on a server’, or is it easiest just run locally and ‘git add’ the generated site markup?
Images: again is there a benefit to making the images (typically 5-20 200k images, all 640px wide, per post) PageResources and “processing” them, or just making subfolders under assets/ and referencing them? I do not intend to keep the multi-megabyte masters in the repo.
How good are go and hugo at resizing photos? Over the years I found that the Mac Preview seems to do a much nicer job than either Python Imaging Library or ImageMagick; it’s hard to pinpoint why but they just seem to lose colour somehow.
Transfer time. 100 images in content. Then build. Now 100 images in content and another 100 images in public.
I find it much easier to keep markdown and images together in a page bundle. When working a piece of content, I know where everything is. And just because an image is a page resource doesn’t mean you have to “process” it.
This is a subjective question. You should experiment using different resampling filters. The default is Box.
I call “just” a trigger word. Because if in your specific case you “just” add all built files you might end up with artefacts from a previous build or might end up with a ballooning repo size with tens of image sizes per image or any other given obstacle. Those are just the ones that come to mind right now. It’s of course easy to just add the local build. If it’s a “one developer” website then you do what fits your workflow.
I do keep the multi-megabyte masters in the repo, because I started developing for the web in the last century. Back then we had small monitors. Now some people come with 2800 pixel wide monitors on my sites and just don’t deserve to spend thousands of their preferred currency on hardware just to see a blurry image. So I keep a large “original” (actually just a resized image, but resized to 2000 pixel wide) and let the generator create image sizes I prefer. When I change my layout or the design of my site then the generator creates the images sizes I prefer THEN. No loss. Lossless
From an SEO point of view (speed of your site) you don’t want to serve “one image size fits all purpose” images to your visitors. It’s 2021.
And again… if in your case it’s a website you do for your family to share photos of your pet then this might all be overkill again. But if you have a business you need to do what leads to your business being found and selected by potential customers. With maybe overly large monitors.
I am with @jmooring about the page bundles. Keep everything for a page in its own folder.
Go and GoHugo are not reinventing resizing algorithms. They implement them. You can configure how GoHugo resizes images and what algorithm to use. Take a look at the following part of the docs about “resampling filters”:
All in all the answer to your question is: There are no rules or guidelines, mostly because a lot is possible and it always depends on your user case. I am not a photographer, so I just put a large image somewhere, thought about how to transform it into the required outputs once, implemented that and forget about it The MAC preview “thinks” for you. Imagick or Python libraries are as good as what you tell them to do.
One thing to keep in mind: Higher (or “visually better perceived”) quality means longer processing.
That is not a future-proof idea I’m afraid, as Google and other platforms are in the habit of changing the permissons to static assets (like photos) that are hosted on their servers without warning.
In the past week, I have observed a 403 Forbidden error when trying to access items from Google Photos with resources.GetRemote.
Your option may work on your end today, but tomorrow who knows.
A liitle more involved to set up, but potentially well worth the effort, would be to roll-your-own images-as-a-service. Serve advanced image formats, manipulate images and serve them from a separate bucket and/or domain. Fast, cheap, effective.
I’ve recenty worked on a very large Hugo site, which is deployed to an S3 bucket and which uses Serverless Sharp in an AWS Lamba instance to replicate Imgix functionality, with github.com/theNewDynamic/hugo-module-tnd-imgix to get images into Hugo.
Images do not need to be in the same bucket as your Hugo site, and do not need to be version controlled, keeping Github happy.
The MAC preview “thinks” for you. Imagick or Python libraries are as good as what you tell them to do.