TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

WebP: The WebPage Compression Format

552 点作者 Kubuxu8 个月前

35 条评论

BugsJustFindMe8 个月前
&gt; <i>the longest post on my site, takes 92 KiB instead of 37 KiB. This amounts to an unnecessary 2.5x increase in load time</i><p>Sure, if you ignore latency. In reality it&#x27;s an unnecessary 0.001% increase in load time because that size increase isn&#x27;t enough to matter vs the round trip time. And the time you save transmitting 55 fewer KiB is probably less than the time lost to decompression. :p<p>While fun, I would expect this specific scenario to actually be worse for the user experience not better. Speed will be a complete wash and compatibility will be worse.
评论 #41476428 未加载
评论 #41477484 未加载
评论 #41475879 未加载
评论 #41475574 未加载
评论 #41476515 未加载
评论 #41475649 未加载
评论 #41477138 未加载
评论 #41483284 未加载
评论 #41475628 未加载
评论 #41475683 未加载
评论 #41476756 未加载
gkbrk8 个月前
&gt; Why readPixels is not subject to anti-fingerprinting is beyond me. It does not sprinkle hardly visible typos all over the page, so that works for me.<p>&gt; keep the styling and the top of the page (about 8 KiB uncompressed) in the gzipped HTML and only compress the content below the viewport with WebP<p>Ah, that explains why the article suddenly cut off after a random sentence, with an empty page that follows. I&#x27;m using LibreWolf which disables WebGL, and I use Chromium for random web games that need WebGL. The article worked just fine with WebGL enabled, neat technique to be honest.
评论 #41477004 未加载
lifthrasiir8 个月前
It is actually possible to use Brotli directly in the web browser... with caveats of course. I believe my 2022 submission to JS1024 [1] is the first ever demonstration of this concept, and I also have a proof-of-concept code for the arbitrary compression (which sadly didn&#x27;t work for the original size-coding purpose though). The main caveat is that you are effectively limited to the ASCII character, and that it is highly sensitive to the rendering stack for the obvious reason---it no longer seems to function in Firefox right now.<p>[1] <a href="https:&#x2F;&#x2F;js1024.fun&#x2F;demos&#x2F;2022&#x2F;18&#x2F;readme" rel="nofollow">https:&#x2F;&#x2F;js1024.fun&#x2F;demos&#x2F;2022&#x2F;18&#x2F;readme</a><p>[2] <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;lifthrasiir&#x2F;1c7f9c5a421ad39c1af19a9c4f060743" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;lifthrasiir&#x2F;1c7f9c5a421ad39c1af19a9c...</a>
评论 #41480400 未加载
评论 #41480602 未加载
评论 #41478964 未加载
raggi8 个月前
Chromies got in the way of it for a very long time, but zstd is now coming to the web too, as it’s finally landed in chrome - now we’ve gotta get safari onboard
评论 #41476217 未加载
评论 #41475848 未加载
jfoster8 个月前
I work on Batch Compress (<a href="https:&#x2F;&#x2F;batchcompress.com&#x2F;en" rel="nofollow">https:&#x2F;&#x2F;batchcompress.com&#x2F;en</a>) and recently added WebP support, then made it the default soon after.<p>As far as I know, it was already making the smallest JPEGs out of any of the web compression tools, but WebP was coming out only ~50% of the size of the JPEGs. It was an easy decision to make WebP the default not too long after adding support for it.<p>Quite a lot of people use the site, so I was anticipating some complaints after making WebP the default, but it&#x27;s been about a month and so far there has been only one complaint&#x2F;enquiry about WebP. It seems that almost all tools &amp; browsers now support WebP. I&#x27;ve only encountered one website recently where uploading a WebP image wasn&#x27;t handled correctly and blocked the next step. Almost everything supports it well these days.
评论 #41482429 未加载
评论 #41486910 未加载
984690568 个月前
While peeking at the source, I noticed that the doctype declaration is missing a space. It currently reads &lt;!doctypehtml&gt;, but it should be &lt;!doctype html&gt;
评论 #41478560 未加载
评论 #41482575 未加载
评论 #41477596 未加载
Retr0id8 个月前
I&#x27;ve used this trick before! Oddly enough I can&#x27;t remember <i>what</i> I used it for (perhaps just to see if I could), and I commented on it here: <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;gasman&#x2F;2560551?permalink_comment_id=4431196#gistcomment-4431196" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;gasman&#x2F;2560551?permalink_comment_id=...</a><p>Edit: I found my prototype from way back, I guess I was just testing heh: <a href="https:&#x2F;&#x2F;retr0.id&#x2F;stuff&#x2F;bee_movie.webp.html" rel="nofollow">https:&#x2F;&#x2F;retr0.id&#x2F;stuff&#x2F;bee_movie.webp.html</a>
评论 #41476819 未加载
评论 #41477962 未加载
butz8 个月前
Dropping google fonts should improve page load time a bit too, considering those are loaded from remote server that requires additional handshake.
评论 #41476433 未加载
niutech8 个月前
This page is broken at least on Sailfish OS browser, there is a long empty space after the paragraph:<p>&gt; Alright, so we’re dealing with 92 KiB for gzip vs 37 + 71 KiB for Brotli. Umm…<p>That said, the overhead of gzip vs brotli HTML compression is nothing compared with amount of JS&#x2F;images&#x2F;video current websites use.
评论 #41476358 未加载
评论 #41480689 未加载
michaelbrave8 个月前
I personally don&#x27;t much care for the format, if I save an image and it ends up WebP then I have to convert it before I can edit or use it in any meaningful way since it&#x27;s not supported in anything other than web browsers. It&#x27;s just giving me extra steps to have to do.
评论 #41483269 未加载
评论 #41482926 未加载
gildas8 个月前
In the same vein, you can package HTML pages as self-extracting ZIP files with SingleFile [1]. You can even include a PNG image to produce files compatible with HTML, ZIP and PNG [2], and for example display the PNG image in the HTML page [3].<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;gildas-lormeau&#x2F;SingleFile?tab=readme-ov-file#file-format-comparison">https:&#x2F;&#x2F;github.com&#x2F;gildas-lormeau&#x2F;SingleFile?tab=readme-ov-f...</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;gildas-lormeau&#x2F;Polyglot-HTML-ZIP-PNG">https:&#x2F;&#x2F;github.com&#x2F;gildas-lormeau&#x2F;Polyglot-HTML-ZIP-PNG</a><p>[3] <a href="https:&#x2F;&#x2F;github.com&#x2F;gildas-lormeau&#x2F;Polyglot-HTML-ZIP-PNG&#x2F;raw&#x2F;main&#x2F;demo.png.zip.html">https:&#x2F;&#x2F;github.com&#x2F;gildas-lormeau&#x2F;Polyglot-HTML-ZIP-PNG&#x2F;raw&#x2F;...</a>
divbzero8 个月前
&gt; <i>Typically, Brotli is better than gzip, and gzip is better than nothing. gzip is so cheap everyone enables it by default, but Brotli is way slower.</i><p>Note that <i>way slower</i> applies to speed of compression, not decompression. So Brotli is a good bet if you can precompress.<p>&gt; <i>Annoyingly, I host my blog on GitHub pages, which doesn’t support Brotli.</i><p>If your users all use modern browsers and you host static pages through a service like Cloudflare or CloudFront that supports custom HTTP headers, you can implement your own Brotli support by precompressing the static files with Brotli and adding a <i>Content-Encoding: br</i> HTTP header. This is kind of cheating because you are ignoring proper content negotiation with <i>Accept-Encoding</i>, but I’ve done it successfully for sites with targeted user bases.
phh8 个月前
&gt; A real-world web page compressed with WebP? Oh, how about the one you’re reading right now? Unless you use an old browser or have JavaScript turned off, WebP compresses this page starting from the “Fool me twice” section. If you haven’t noticed this, I’m happy the trick is working :-)<p>Well it didn&#x27;t work in Materialistic (I guess their webview disable js), and the failure mode is really not comfortable.
next_xibalba8 个月前
If only we hadn&#x27;t lost Jan Sloot&#x27;s Digital Coding System [1], we&#x27;d be able to transmit GB in milliseconds across the web!<p>[1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Sloot_Digital_Coding_System" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Sloot_Digital_Coding_System</a>
评论 #41476504 未加载
评论 #41475452 未加载
评论 #41476362 未加载
评论 #41476152 未加载
评论 #41475810 未加载
rrrix18 个月前
I very much enjoyed reading this. Quite clever!<p>But...<p>&gt; Annoyingly, I host my blog on GitHub pages, which doesn’t support Brotli.<p>Is the <i>glaringly</i> obvious solution to this not as obvious as I think it is?<p>TFA went through a lot of round-about work to get (some) Brotli compression. Very impressive Yak Shave!<p>If you&#x27;re married to the idea of a Git-based automatically published web site, you could <i>at least</i> replicate your code and site to Gitlab Pages, which has supported precompressed Brotli since 2019. Or use one of Cloudflare&#x27;s free tier services. There&#x27;s a variety of ways to solve this problem before the first byte is sent to the client.<p>Far too much of the world&#x27;s source code already depends exclusively on Github. I find it distasteful to also have the small web do the same while blindly accepting an inferior experience and worse technology.
评论 #41481645 未加载
somishere8 个月前
Lots of nice tricks in here, definitely fun! Only minor nitpick is that it departs fairly rapidly from the lede ... which espouses the dual virtues of an accessible and js-optional reading experience ;)
lxgr8 个月前
From the linked Github issue giving the rationale why Brotli is not available in the CompressionStream API:<p>&gt; As far as I know, browsers are only shipping the decompression dictionary. Brotli has a separate dictionary needed for compression, which would significantly increase the size of the browser.<p>How can the decompression dictionary be smaller than the compression one? Does the latter contain something like a space-time tradeoff in the form of precalculated most efficient representations of given input substrings or something similar?
评论 #41477984 未加载
评论 #41477341 未加载
Dibby0538 个月前
I didn&#x27;t know canvas anti-fingerprinting was so rudimentary. I don&#x27;t think it increases uniqueness (the noise is different every run) but bypassing it seems trivial: run the thing n times and take the mode. With so little noise, 4 or 5 times should be more than enough.
评论 #41476340 未加载
Pesthuf8 个月前
It&#x27;s impressive how close this is to Brotli even though brotli has this massive pre-shared dictionary. Is the actual compression algorithm used by it just worse, or does the dictionary just matter much less than I think?
评论 #41477993 未加载
TacticalCoder8 个月前
I <i>loved</i> that (encoding stuff in <i>webp</i>) but my takeaway from the figures in the article is this: brotli is so good I&#x27;ll host from somewhere where I can serve brotli (when and if the client supports brotli ofc).
kardos8 个月前
On the fingerprinting noise: this sounds like a job for FEC [1]. It would increase the size but allow using the Canvas API. I don&#x27;t know if this would solve the flicker though (not a front end expert here)<p>Also, it&#x27;s a long shot, but could the combo of FEC (+size) and lossy compression (-size) be a net win?<p>[1] <a href="https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Error_correction_code" rel="nofollow">https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Error_correction_code</a>
astrostl8 个月前
Things I seek in an image format:<p>(1) compatibility<p>(2) features<p>WebP still seems far behind on (1) to me so I don&#x27;t care about the rest. I hope it gets there, though, because folks like this seem pretty enthusiastic about (2).
评论 #41478305 未加载
评论 #41477380 未加载
bogzz8 个月前
Still waiting on a webp encoder to be added to the Go stdlib...
ajsnigrutin8 个月前
So... 60kB less of transfer... and how much slower is it on an eg. galaxy s8 phone my mom has, because of all the shenanigans done to save those 60kB?
butz8 个月前
I wonder what is the difference in CPU usage on client side for WebP variant vs standard HTML? Are you causing more battery drain on visitor devices?
评论 #41476860 未加载
csjh8 个月前
I think the most surprising part here is the gzipped-base64&#x27;d-compressed data almost entirely removes the base64 overhead.
评论 #41477402 未加载
评论 #41477395 未加载
ranger_danger8 个月前
&gt;ensure it works without JavaScript enabled<p>&gt;manually decompress it in JavaScript<p>&gt;Brotli decompressor in WASM<p>the irony seems lost
评论 #41478992 未加载
Jamie99128 个月前
Why don&#x27;t they make zstd images surely that would beat webp
评论 #41479239 未加载
galaxyLogic8 个月前
Is there a tool or some other way to easily encode a JPG image so it can be embedded into HTML? I know there is something like that, but is it easy? Could it be made easier?
评论 #41475931 未加载
DaleCurtis8 个月前
What a fun excursion :) You can also use the ImageDecoder API: <a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;ImageDecoder" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;ImageDecode...</a> and VideoFrame.copyTo: <a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;VideoFrame&#x2F;copyTo" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;VideoFrame&#x2F;...</a> to skip canvas entirely.
评论 #41481637 未加载
toddmorey8 个月前
&quot;I hope you see where I’m going with this and are yelling &#x27;Oh why the fuck&#x27; right now.&quot;<p>I love reading blogpost like these.
cobbal8 个月前
I would love to try reading the lossy version.
bawolff8 个月前
They did all this and didn&#x27;t even measure time to first paint?<p>What is the point of doing this sort of thing if you dont even test how much faster or slower it made the page to load?
评论 #41476940 未加载
kopirgan8 个月前
19 year old and look at the list of stuff she&#x27;s done! Perhaps started coding in the womb?! Amazing.
niceguy48 个月前
Not to side track the conversation but to side track the conversation, has there been many other major WebP exploits like the serious one in the past?
评论 #41475387 未加载