From nothin’ to gzip - HTTP 203
Вставка
- Опубліковано 7 чер 2021
- You know GZIP right? It’s everywhere on the web to reduce the number of bytes going over the wire. In this episode, Surma is giving you a quickstart on how it works.
DEFLATE spec (RFC 1951) → goo.gle/3x5FZMl
Compressor Head → goo.gle/3pvVESJ
More videos in the HTTP 203 series → goo.gle/HTTP203
Subscribe to Google Chrome Developers here → goo.gle/ChromeDevs
Also, if you enjoyed this, you might like the HTTP203 podcast → goo.gle/HTTP203Podcast
#HTTP203 #ChromeDeveloper #WebDev - Наука та технологія
"Let's talk about GZIP. GZIP is Deflate. We're done."
The best show on the best channel! Keep going!
I concur
Diving right into something I thought I'd never check out fully. Love it!
It's interesting to learn more about GZIP in this video. Thanks for sharing great content!
Thank you for being informative and entertaining :)
I implemented a Huffman encoding algorithm for fun after watching a Tom Scott video. On a few novels from Projects Gutenburg, it seemed to average about 57% of the original file size and that included sending the tree.
Very well explained 👍
Sweet baby gzip!
Amiga got a mention!
Brilliant! Now do VP9 😉
yes!!! I have always to not only learn and understands this subject if these video's were going to take hour or just hit on the bare minimum, but explain enough o that the nedt videos i watch practice and attempt to retain, i habe been a mechanic for 14 years and there thing. im watching reading and trying to self teach myself before choosing the the most report
so let's write a script that makes our code more redundante in production, to get a smaller result in gzip
OCR is my form of Text Compression in Images i simply remove text from the image and then insert it from binary after the image is rendered.
Lossy text compression is real - when you are compressing a source you first minimise it, which is discarding part of the data which the target browser doesn't need in order to make use of it, which is comparable to how jpeg discards part of the image we don't need to make use of it. JPEG's pre-processed data is then passed to a lossless compression method (huffman or arithmetic) the same way sources are pre-processed and then passed to lossless gzip.
Code minimisation is an optional preprocessing step that you can run before sending the code over the wire, but it's not part of text compression itself.
Lossy text compression has its own name already (minimization)
I think they dont mean minify, cause all the functions like new WebSocket is not minified. This instead would be like "Hello my name is Andrew" -> "Hlo my nme is Andrw" and your brain would fill in the missing letters.
Mr. Surma, do you know there's a beautiful river named Surma in Bangladesh? Luckily it flows beside my village house
What does it mean "Surma" in Bangladashian language ?
@@hobbyturystaSEO Its just a name & I don't think there is a specific meaning of that😅
@@krtirtho each name has a source, history which has specific meaning not in English
@@hobbyturystaSEO Oh, I found it...This name derived from the Arabic word "Surma". In Arabic, surma is a cosmetic that is used to darken and thicken the eye lashes
#collected
@@krtirtho Surma means expert in urdu/hindi
With huffman there is no need to limit to bytes, characters, or even blocks of a predefined length. Words, phrases, etc are all totally possible. If you have well defined expectations of your data, e.g. a JSON packet with well known,yet verbose, keys (and perhaps even the values), you can use a static table, omit that table from the output, and then get truely incredible compression ratios without going anywhere near lz.
:-) yes, see messagePack (msgpack.org/) but your point re intelligently structuring the data is just plain good design. ie sending:
{keys:["first","last","title","email"],rows: [["Jane","Doe","HRH","jd@example.com"],["More","Contacts","Some","mc@example.com"],...]}
is more efficient than sending:
[{"first":"Jane","last":"Doe","title":"HRH","email":"jd@example.com"}, {""first":"More","last":"Contacts","title":"Some","email":"mc@example.com"},...]
@@linuxgeex that's actually not at all what I was saying.
Rather you can retain the json in a more readable structure but use huffman coding to virtually eliminate the well known keys. Message pack doesn't achieve that, though it does gain efficiencies in other areas, e.g. Numbers.
If your data is well structured and you're OK with binary formats, then you can't get more efficient than a custom binary format that has no need for keys due to well known offsets. But for readable structures like json and XML that have a lot of verbosity - huffman really shines
@@LeeSmith-cf1vo Ah you mean supplying app-specific custom huffman tables. The article mentioned that already, which is why I didn't think that's what you were talking about.... it sounded like you meant to raise a new concept.
@@linuxgeex app specific predefined tables, but also not just for bytes but large chunks of variable length text thus reducing verbose keys to a handful of bits
@@linuxgeex all the concepts were mentioned, but not in combination and some so briefly that many may have missed them
No laughs, laughs. Lol.
19:00 How does the length of the bit sequence re-construct the Huffman tree?
RFC 1951 has an algorithm to construct _a_ huffman tree from the code lengths,
you could then simply use the same huffman tree when encoding and decoding.
thank you for your work you put into these videos. is this kind of conversation you have when you are going out for a beer?
It’s not a pub crawl without a PowerPoint deck.
@@dassurma These conversations remind me of the shop-talk chitchat we’d have over lunch with the other developers when I was on a larger team. Miss those days!
So should minifiers have an option to optimize for certain types of text compression? I feel like lighthouse reports will ding you if you don't minify even if that results in a larger amount of bytes sent.
I believe this is already something minifiers take into account when they generate identifiers. It's why they often end up with things like "Jq" instead of "a"
@1:30 I assume he means inference
😢😢😢
Do symbols convey more information then words? ;)
Lazyloading css pls
Aren't all sentences just words 😉
oh wow, I just watched a video on new media queries that so far work only in firefox, lol, obviously, everything always arrives to firefox first, it's the bleeding age, and that video made me think how I haven't seen these two in a long time. and here they are >
Hii
Does this mean the same deflate algorithm is the best to compress images in lossless manner than moz-jpeg or others? Or it has adverse effect on binary format?
PNG uses Deflate and performs well on some images, but not very good photographic imagery as things _look_ similar but don’t really repeat. Image compression is a whole different beast.
@@dassurma Will deflate work well on high res texual images keeping the redability intact but compressing it to well proportion. Just curious to know your opinion. I will try quantPNG and optiPNG both with some text image meanwhile.
website
11:57 looks like it says length >= 6
dammit
It says length >= 3 now.
I didn't know it was possible to reupload a video that's already published.
Isn’t code minification considered a lossy text compression?
Yes, technically lossy, but semantically it’s lossless. That is, for example, you’re losing some meaning in the white space, but if only a machine will be reading it and parsing it, then it hasn’t lost any meaning at all to the parser (so in that context, it’s lossless).
What about brokolni