♻️ Refactor: Move inline styles containing background-image: out of line

[servedsmart]

This has been tested for around half an hour locally, also with thumbAndBackground param and otherwise default exampleSite config. I'm pretty sure that all scenarios where changed html files are loaded were checked.

Purpose

This greatly reduces the number of inline styles in the project and enhances maintainability by avoiding a lot of duplicate code.

This also reduces the number of hashes required for a CSP since all previous background-image inline styles are now in main.css.

[netlify]

✅ Deploy Preview for snazzy-dango-efb2ec ready!

Name	Link
🔨 Latest commit	e3e90cf
🔍 Latest deploy log	https://app.netlify.com/projects/snazzy-dango-efb2ec/deploys/68589fdb14d6310008b7dd05
😎 Deploy Preview	https://deploy-preview-2268--snazzy-dango-efb2ec.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[ZhenShuo2021]

@servedsmart I appreciate the work you've put into this PR, but I've noticed several performance concerns that might impact the build process:

1. Page traversal complexity: The code loops through all site pages ({{ range .Site.Pages }}) during each page render, which could create O(N²) complexity for larger sites. While Hugo has aggressive caching mechanisms, I'm uncertain if these results are cached effectively.

2. Duplicate image processing: Images appear to be resized in head.html and then potentially resized again in article-link, leading to redundant processing.

3. Unfiltered duplicate images: The same image files aren't being deduplicated, which could cause performance overhead and generate multiple issues: increased build time, and potential memory usage spikes.

4. Changed resize behavior: Previously, background images were resized to 1200x and feature images to 600x. Now all images are processed twice with different dimensions, significantly increasing build time and very large and unnecessary CSS file size.

5. Missing optimization opportunities: Some of these issues could potentially be addressed using Hugo's partialCached function.

I may have missed some implementation details, so please feel free to correct me if I'm wrong about any of these points.

Since I'm not a collaborator or owner of this project, I won't be able to provide ongoing code review support. However, I'd suggest consulting with modern AI tools like ChatGPT or Claude - they're excellent at helping optimize Hugo templates and can provide detailed guidance on performance improvements.

Thanks for understanding!

[servedsmart]

@servedsmart I appreciate the work you've put into this PR, but I've noticed several performance concerns that might impact the build process:

1. **Page traversal complexity**: The code loops through all site pages (`{{ range .Site.Pages }}`) during each page render, which could create O(N²) complexity for larger sites. While Hugo has aggressive caching mechanisms, I'm uncertain if these results are cached effectively.

2. **Duplicate image processing**: Images appear to be resized in `head.html` and then potentially resized again in `article-link`, leading to redundant processing.

3. **Unfiltered duplicate images**: The same image files aren't being deduplicated, which could cause performance overhead and generate multiple issues: increased build time, and potential memory usage spikes.

4. **Changed resize behavior**: Previously, background images were resized to 1200x and feature images to 600x. Now all images are processed twice with different dimensions, significantly increasing build time and **very large and unnecessary CSS file size**.

5. **Missing optimization opportunities**: Some of these issues could potentially be addressed using Hugo's `partialCached` function.

I may have missed some implementation details, so please feel free to correct me if I'm wrong about any of these points.

Since I'm not a collaborator or owner of this project, I won't be able to provide ongoing code review support. However, I'd suggest consulting with modern AI tools like ChatGPT or Claude - they're excellent at helping optimize Hugo templates and can provide detailed guidance on performance improvements.

Thanks for understanding!

Thank you for the feedback. I didn't think that build time was such a big concern, therefore I didn't bother. In absolute terms this should not increase build time by a lot, but I do understand and think that this is a valid point.
Also css size can be optimized because there will be images in the css that are not used, but I also thought that this is (in absolute terms) quite minimal.

I see that you have already taken care of some of your concerns in #2318. Thank you very much! Also for the fix, I really didn't consider that scenario.

I will use functions to avoid code duplication in a new pr and address additional concerns of yours. Thank you for the again very valuable feedback!

[ZhenShuo2021]

Thanks for the reply.

I appreciate your response, though I did notice a few statements that seem based on assumptions rather than confirmed behavior. Phrases like “I didn't think...”, “should not increase...”, “I also thought...”, “quite minimal” come across as speculative, which can be risky when discussing performance and build behavior.

To help move this forward constructively, I'd suggest checking the actual impact using profiling tools, or reaching out to the Hugo maintainers to confirm whether this pattern leads to measurable performance issues. It's important that these decisions are based on tested behavior rather than assumptions.

Thanks again.

[ZhenShuo2021]

Also css size can be optimized because there will be images in the css that are not used, but I also thought that this is (in absolute terms) quite minimal.

I think there might be a misunderstanding about my CSS size concern. It's about your code generating dual resize CSS (1200x and 600x) for every image instead of distinguishing background from feature images.

Since you mentioned CSS optimization, could you clarify how exactly this would work? Also, the current approach seems to make bundle.min.css unable to cache because adding images changes the CSS file.

[servedsmart]

notice a few statements that seem based on assumptions rather than confirmed behavior. Phrases like “I didn't think...”, “should not increase...”, “I also tho

I know what you mean and I should have probably made it more clear.

• It is unlikely that added css will be a big burden. I have checked every added class and compared it to the actual used classes in exampleSite. This would of course become more the more images matching the pattern are added, but it is not that big of a difference in absolute terms, as I have said.
• Build times with hugo are quite short and I never thought that anyone would care if a large site doesn't even take 1min to build since it is only build time, not run time that is affected. I will add a profile with hyperfine just to prove my point, previous observations were not assumptions, they were observations from me having built exampleSite 10s of times during development. But as I have said before, your points are valid, this is just to answer your questions.

I btw just wanted to point out why I did what I did, not say that my approach was not flawed in some ways.

hyperfine profile

System details (fastfetch):

OS: Arch Linux x86_64
Host: 20Y7003XGE (ThinkPad E14 Gen 3)
Kernel: Linux 6.12.36-1-lts
[...]
CPU: AMD Ryzen 7 5700U (16) @ 4.37 GHz
GPU: AMD Lucienne [Integrated]
Memory: 9.11 GiB / 22.30 GiB (41%)
Swap: 0 B / 22.30 GiB (0%)
[...]

dev (0999dc2)

Benchmark 1: rm -rf ~/src/blowfish/exampleSite/{resources,public} ~/.cache/hugo_cache && hugo --minify -s ~/src/blowfish/exampleSite --themesDir ~/src -d ~/src/blowfish/exampleSite/public --baseURL http://localhost/
  Time (mean ± σ):     29.998 s ±  0.792 s    [User: 221.873 s, System: 7.523 s]
  Range (min … max):   28.904 s … 30.953 s    12 runs

Before pr - hotfix/revert-2268 (ZhenShuo2021@9e5a7f9)

Benchmark 1: rm -rf ~/src/blowfish/exampleSite/{resources,public} ~/.cache/hugo_cache && hugo --minify -s ~/src/blowfish/exampleSite --themesDir ~/src -d ~/src/blowfish/exampleSite/public --baseURL http://localhost/
  Time (mean ± σ):     12.742 s ±  0.420 s    [User: 54.338 s, System: 3.166 s]
  Range (min … max):   12.359 s … 13.598 s    12 runs

So even though building with this PR takes ~235% of the time, it is still only 17.25s per build of exampleSite in absolute terms. That's why I didn't really noteice it when building myself and therefore didn't think it would be worth investigating further. That this would have an impact was known to me. As I've said before, I'm just trying to answer your concerns/questions, this isn't meant to say that what I did was perfect/good enough/whatever.

[servedsmart]

Also css size can be optimized because there will be images in the css that are not used, but I also thought that this is (in absolute terms) quite minimal.

I think there might be a misunderstanding about my CSS size concern. It's about your code generating dual resize CSS (1200x and 600x) for every image instead of distinguishing background from feature images.

Since you mentioned CSS optimization, could you clarify how exactly this would work? Also, the current approach seems to make bundle.min.css unable to cache because adding images changes the CSS file.

I said the following:

Also css size can be optimized because there will be images in the css that are not used, but I also thought that this is (in absolute terms) quite minimal.

by that I mean exactly what you have just stated: additional classes that are added to css even though they are not used in html. I hope you can now understand what I was trying to say.

To avoid this caching issue, I could use a separate CSS file.

Also how the resize can be handled is getting the background-images from the files that use them. I think you have already done that in #2318

Btw, as I have stated previously I am quite new to hugo/web development and it is not that easy to know how or even if you can do these things with hugo's go templates. Your changes and suggestions have helped me a lot and I hope that you can at least somewhat understand my point of view.

[servedsmart]

@ZhenShuo2021 I will eventually resubmit this pr and try to address your concerns and also add profiles to the new pr. I am sorry that my testing didn't cover the config parameters not being set.

[ZhenShuo2021]

The main concern is long-term maintainability and performance. While strict CSP can be valuable in some cases, for a static blog theme like this, the real-world benefit is quite limited, and the added complexity may cause more issues than it solves. No one can guarantee they’ll maintain their code indefinitely. If that happens, the cost of complexity becomes technical debt others will need to handle.

I encourage you to use AI tools to help review your code or even ask LLM to point out issues. LLM has become very powerful recently. To be transparent, I am also using AI to translate this message because English is not my native language.

You’re welcome to resubmit anytime. Just note that I’m not the repo owner, please tag @nunocoracao for final decisions.

[ZhenShuo2021]

For context, the changes led to a 300% increase in build time on my M1 MacBook.

[ZhenShuo2021]

by that I mean exactly what you have just stated: additional classes that are added to css even though they are not used in html. I hope you can now understand what I was trying to say.

This is not acceptable. Small issues like this add up and become real problems over time.