Improperly sized images

[kmogged]

URL

https://www.jupiterbroadcasting.com/

On what type of device(s) did you see this bug?

Desktop

On which browser(s) are you seeing the problem?

Firefox

Other Browser

No response

Summary

There is a noticeable lag when initially loading images on the pages. This is due to improperly sized images. Using a fast CDN would improve load time, but shrinking the amount of bits down the pipe is even simpler/better first step. Also using webp would help speed, but you would need to use picture tags for supporting Safari.

It's good to use CSS to enforce the sizes, but the image file's maximum width typically should be the width required for mobile devices. These following images are quite extreme.

Homepage Logo:
https://www.jupiterbroadcasting.com/images/logo_narrow.png 1481 x 518 px

Show "Tiles":
https://www.jupiterbroadcasting.com/images/shows/linux-action-news.png 1280 x 720 px
https://www.jupiterbroadcasting.com/images/shows/coder-radio.png 1280 x 720 px
https://www.jupiterbroadcasting.com/images/shows/linux-unplugged.png 1280 x 720 px
https://www.jupiterbroadcasting.com/images/shows/self-hosted.png 1280 x 720 px
https://www.jupiterbroadcasting.com/images/shows/office-hours.png 1280 x 720 px
https://www.jupiterbroadcasting.com/images/shows/jupiter-extras.png 1280 x 720 px

Host "Bubbles":
https://www.jupiterbroadcasting.com/images/people/chris.jpg 600 x 600 px
https://www.jupiterbroadcasting.com/images/people/wes.jpg 600 x 600 px
https://www.jupiterbroadcasting.com/images/people/*

[gerbrent]

nice observations and advice @kmogged !

Would you be interested in helping craft the solution by chance?

[kmogged]

@gerbrent I'm not opposed. I would require some understanding of how these images are populated. Looks like they were initially scraped at one time. Perhaps, these should be retained somewhere as the "source images". Feels like these shouldn't be in the docker container to begin with. Again, this is a good candidate for object storage.

Otherwise...

1. It seems like I would pull this docker container.
2. Copy the originals to a "source folder"
3. Run a tool to resize and save the images to the expected folder...viola

[gerbrent]

Here, I can help w #1 and #2! ; )

https://github.com/JupiterBroadcasting/jupiterbroadcasting.com/tree/develop/static/images

[gerbrent]

I suppose there is a simplicity to hosting these images via the docker container vs distinct object storage, despite it's other advantages.

[kmogged]

Docker definitely has some strengths of making development easier and portable.

Looks like the scraper has the potential to overwrite these files Scraper Save Avatar so I would say what is in the repo now should be considered sources of the images. This is sort of a pickle, since there would need to be a resize event/build for new hosts, guests, or any images scraped.

I think it would be wise to have a format like:
Alex.jpg (original)
Alex-thumb.jpg (for episode pages)
Alex-max.jpg (for the people pages)
and so on

This event could occur during the scrape in the python code, which makes sense if the images come from the feed someday.
Otherwise, it could happen with the docker up sequence if images are manually added to git.

I'm just learning what is going on here. I typically live in the shell with git, and use Bitbucket, Gitlab. So, Github I'm rusty with. Also fun learning Hugo, which uses familiar Jinja templates, but still new to me.

[kmogged]

or would be better to created resized images with filenames like alex-60x60.jpg, etc.
Since, I don't know what the dimensions of a thumbnail are!(could be anything..)

[kmogged]

@gerbrent forgive me. I'm verbose 🤣 I am also learning Hugo.
Seems Hugo has some nifty image processing built in. https://gohugo.io/content-management/image-processing/#resampling-filter

We should just let Hugo create create what it needs by specifying the shortcode. Then we can ignore the source images, etc.

[kmogged]

Small update: I did dig into this, but it's not so straight forward. It appears the site is more or less a traditional website using paths to images. Which I'm more used to, but there is the Hugo way where the image assets are part of a resource bundle. This is not how it's setup. I get it, since the site is young.

Once the assets are put into these resource bundles. Hugo can access the images and do the nifty image manipulation when it builds.

The resource bundle would have the best high quality images possible. Hugo could build the right size images depending on the markdown in the templates.

[kmogged]

I have the solution to this, but it will require the images be moved out of the /static directory and into a newly created /assets directory. I'm sure their are other solutions with bundles, etc. This just seemed easy and works.

For whatever reason Hugo is very picky on its file structure and won't pull from the /static directory. Here is a nice image reference which states this https://www.markusantonwolf.com/blog/guide-for-different-ways-to-access-your-image-resources/

My code can be deployed before this change and will fall back to the previous image location if the image is not in the "global" folder.

[gerbrent]

lovely @kmogged ! Thanks for the detailed investigations..

also: verbose is good! documenting your process here is a nice way for the rest of us to learn alongside you, and great reference for when we come back here looking for other answers in the future.

I don't believe moving the images away from /static would be too consequential, given the benefits in your proposed solution, so don't let that get in your way. Your fallback strategy is a sound one too.

Anyone have any objections to continuing on this path??

[ozcoder]

Please don't forget the related issue #326