Print images really big, slowing down hugo

1

hi i have a little conundrum, my client wants to have photo documentation of their projects on their website. now i have both print-quality photos and downsized web-appropriate photos.

the print photos are massive, and because of them hugo takes upto 5 seconds to update each time i make a change

i realise this is not a problem with hugo, but with my personal needs.

is there any way i can get best of both worlds? keep my client happy and yet get maximum performance out of hugo?

how are you storing massive images/files? how do you deal with git? do you store in on long term glacial storage on aws or somesuch?

is there a common solution for this situation? please advise me

2

The resized images should be cached after the initial resize. Are you running hugo server with any additional flags?

3

for my panoramas

  • images are not a part of hugo - speeds up!
  • use shortcodes to link to image directories
  • build tiles and use OpenSeadragon to present it

search here for image responsive to find a solution for you

4

i usually do: hugo server -w --disableFastRender --ignoreCache

should i not be adding those flags?

5

I have no idea how your site looks, but --ignoreCache is a really bad idea of you do image processing with Hugo.

6

i dont do any image processing. i just have two folders, one with big images, and one with web-optimised resolutions.

also, @ju52, what is this technique of shortcodes to image folders? please share

7

In any case, I would recommend doing hugo server for the fastest experience.

8

@bep, not hugo server -w?

9

What @bep said.

4 Likes
10

Also, are the print quality photos actually used in the site? If not, make sure they don’t live under static that way hugo isn’t wasting time copying over unused photos

11

ok. thank you. i think we can close this thread now.

12

Personally I do not recommend using shortcodes for images.

It may be convenient but it does come with a long term cost for image heavy websites.

For single pages that do not have many images I prefer to call them directly from the template like so:

  • Use the method resources.Get to fetch the images from the /assets/ folder
  • Combine the above with a Hugo Archetype so that when the command hugo new is executed the image resources are outputed as plain front matter parameters.

Obviously the above requires some planning but it also has the benefit that one can use a high-res image under /assets/ for Hugo to use and at the same time keep it out of version control so that the repo’s size is reasonable.

Finally for single pages that require a lot of images I have found that Page Bundles and plain Markdown syntax images work the best.

13

Am curious, are you keeping high-res images out of version control by having a symbolic link to assets?

14

No. That is just plain broken since Hugo 0.50. Even with disableBrowserError set the console is polluted by this ERROR. Hopefully someone will look into Consider allowing symlinks below /assets in project · Issue #5374 · gohugoio/hugo · GitHub at some point.

I am doing something else to keep large images out of version control. My /assets/ folder resides in my Dropbox account and I have created a Zapier integration to trigger a new deploy on Netlify whenever a file is added in that directory.

15

Oh interesting. Thanks for sharing.

16

@alexandros @zwbetz but why would you wanna take big photos out of version control?

17

As I said above to keep the Git repo size down.

Also by using the above Dropbox + Netlify integration these images are safely stored in the cloud.

18

i see. could you please link to how you do this exactly?

20

There is no link. I will try to give a step-by-step here:

  • The local Hugo project directory resides in my Dropbox.
  • The /assets/ directory is excluded from version control with .gitignore
  • Then I configured the Zapier integration that I linked to above so that a Netlify deploy is triggered when a new file is added under /assets/

That’s pretty much it. It’s a pretty low-tech solution and it suits me fine.

There are also more involved ways of doing the same like this one for Jekyll:

21

I use a shortcode to build image lists with descriptions (not yet optimized)

<div class="flex flex-column">
{{ $images := .Page.Resources.ByType "image" }}
{{ $mask := printf "**/%s.*" (.Get 0)}}
{{ $original := $images.GetMatch $mask }}
{{ with $original -}}{{$orig := .}}{{ $.Scratch.Set "image" ($orig.Fit "480x360") }}{{ $img := $.Scratch.Get "image" }}
<div class=flex-l>
	<div class="pa2 mt2 w50">
		<a class="dim b--white"  data-fancybox=gallery href="{{$orig.RelPermalink | relURL}}" >
			<img class="ba bw1 b--dark-blue contain" src="{{ $img.RelPermalink | relURL  }}"  alt="{{ .Name }}" />
		</a>
	</div>
	<div class="tl pa2 pl4-l pt4-l measure">
		{{ $.Inner | markdownify }}
	</div>
</div>
{{- end}}
</div>

MD-File (German - no need to translate here)

{{% imagelist dsc03298    %}} Aufnahme **-2 EV**, Belichtungszeit {{< frac 1 250 >}}<br/>Äußere Strukturen sind zu gut erkennen.{{% /imagelist %}}
{{% imagelist dsc03299    %}} Aufnahme  **0 EV**, Belichtungszeit {{% frac 125%}}<br/>Die Decke und die Erker auf der unteren linken Seite sid abgesoffen, durch die Fenster sind äußere Strukturen kaum zu erkennen.{{% /imagelist %}}
{{% imagelist dsc03300    %}} Aufnahme **+2 EV**, Belichtungszeit {{% frac 60%}}<br/>Äußere Strukturen sind zu fast unsichtbar, die Fenster verlieren an Struktur, der Innenraum ist sehr gut abgebildet.{{% /imagelist %}}