WEBP? When? Please?

feature
1

Hi there benevolent developers and people with knowledge about the intricacies of image processing in hugo and golang: What is your view on implementing webp into the image processing functionality and what keeps you from doing it?

I know it must be a technical issue, because the browser threshold supporting this went over 87% recently, so it can be considered a usable format. I don’t want to incense a religious discussion about the pro and con’s of webp, but I think Hugo should be able to easily compile my ugly 5mb jpg into a nice fast loading 200kb webp image.

It’s time :slight_smile:

PS: Asking because the issues on Github about webp get more and more passive-agressive by the week.

PPS: It’s more or less not a “please come one and do it finally now or I will go back to WordPress” question but one of “what keeps you from doing it and what is the timeline (in months?) to have this feature running” question :wink:

2 Likes
2

By the way: I am doing webp manually at the moment. Google cwebp and (at least on an Ubuntu based system) all is well. So there are ways around. The question is if it makes sense to create hacks to get webp into our websites or if we can lean back and wait.

From an SEO point of view April/May is a threshold. At this date Google will start using it’s new three page speed indicators to rank websites and a huge part of that will be if images are small and “next generation formats” to load fast and improve user experience. So if Hugo is ready in April we all should be happy :wink:

1 Like
3

WEBP support used to be in past Hugo milestones, but it doesn’t seem to be in the current one.

The following quote is from this comment:

The main problem here is that there is no native Go webp encoder.

And the following quote is from the closed PR that intended to add WEBP support to Hugo by employing an external library:

I don’t think we have the bandwidth to implement this using C bindings.

It appears that this is an upstream issue.

P.S. Regarding the passive/aggressive comments simply do not pay attention. At some point WEBP support will come, however things cannot happen right away for the above reasons.

2 Likes
4

Funny to think Go (which is basically Googles self-invented Scripting Language) does not have a library for webp (which is basically Googles self-invented Image Format). It’s probably one of these “too many cooks” issues.

5 Likes
5

That.

2 Likes
6

Looking around there are several go libraries that support encoding webp images but I couldn’t find any that were pure go.

There’s one more but I can’t link more than twice and it hasn’t been worked on in 4 years.

7

OT: it’s exactly that in Google environment. Implementing requirements that they cannot met through their own resources. You don’t need to look too far. Implement Google AdSense and you see how impacted you are on PageSpeed. Crazy.

1 Like
8

they seem skeptical…

9

I am archiving this topic

We really cannot have a discussion in this forum about Go’s lack of development for a WebP Encoder or Google’s lack of support for its own file format, because it leads nowhere.

Whenever the encoder is developed upstream, I’m sure the Hugo maintainer will be notified through other channels.

Thank you for your understanding.

12

Commit gohugoio/hugo@33d5f80 by @bep added support for webp image encoding.

It will be available in the next Hugo release.

7 Likes
13

@bep bless your soul

14

I compiled the dev version (even with doing brew install webp).
But webp option is not recognized.
I guess I’m too impatient and will wait for the official build :slight_smile:

15

I also compiled the latest Dev version and got a console message that read like so: this feature is not available in your Hugo version along with a link to the Hugo FAQ.

WEBP files were generated under the resourceDir but they were empty files containing errors.

It seems that currently this feature is not ready.

I suppose that we’'ll see how WEBP support works in the next release.

16

Extended version works for me.

17

Right. Hence the console message about the Hugo version.

18

Nice work @bep. Thank you.

{{ $i := resources.Get "a.jpg" -}}

{{ $alt := "" }}
{{ with $i.Exif }}
  {{ $alt = .Tags.ImageDescription }}
{{ end }}

{{ $i = $i.Resize "x200" }}
{{ $i_webp := $i.Resize "x200 webp" }}

{{ if lt (len $i_webp.Content) (len $i.Content) }}
  {{ $i = $i_webp }}
{{ end }}

<img alt="{{ $alt }}" src="{{ $i.RelPermalink }}" width="{{ $i.Width }}" height="{{ $i.Height }}">
1 Like
19

@jmooring

Basically in the above conditional you are comparing the length of both the resized JPG and the WEBP files and if the WEBP is smaller then you choose to use that.

However, as far as I know, the WEBP file format is supposed to offer a smaller file than JPEG of the same photo.

So, I do not quite understand, why you would need to compare the generated file sizes…

Furthermore, since this topic is about the new WEBP feature then I suppose that it would be informative to emphasize the need to generate proper markup with the picture element that serves both the WEBP and JPEG file formats for all browsers.

For example a simplified version could look something like this:

<picture>
  <source type="image/svg+xml" srcset="pyramid.svg">
  <source type="image/webp" srcset="pyramid.webp">
  <img src="pyramid.png" alt="regular pyramid built from four equilateral triangles">
</picture>

ref:
MDN Doc on Responsive Images
StackOverflow: picture srcset with webp - how to implement sizes?

1 Like
20

That is probably true 99.9% of the time, but it depends on original and target quality. If you’re starting with a low quality JPG, and converting to WEPB at q=75 (Hugo’s default), the file might get bigger, but not by much.

In this contrived example, the resulting WEBP image is larger than the resulting JPG image:

git clone --single-branch -b hugo-forum-topic-30394 https://github.com/jmooring/hugo-testing hugo-forum-topic-30394
cd hugo-forum-topic-30394
hugo server

But the WEBP image is only 1% larger, so in practical terms the size comparison is pointless. Google posted a FAQ on this subject.

The <picture> element example is great. Browser support for WEBP is pretty good at this point, but it’s not perfect.

1 Like