Announcement

Collapse
No announcement yet.

Zstd 1.5.6 Released - Celebrating Google Chrome Support For Zstandard Encoding

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Zstd 1.5.6 Released - Celebrating Google Chrome Support For Zstandard Encoding

    Phoronix: Zstd 1.5.6 Released - Celebrating Google Chrome Support For Zstandard Encoding

    Meta's Yann Collet just released Zstd 1.5.6 as the newest version of this Zstandard compression implementation. This release is driven in part by Google Chrome 123 adding support for Zstd encoding for web traffic. Chrome now allows Zstandard (zstd) for the content-encoding to speed-up page load speeds and bandwidth savings...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    The release notes are dated 27. March 2024 - while the tag 1.5.6 is dated 21.03.2024 (https://github.com/facebook/zstd/tags/),
    so 6 days for creating the release notes? Interesting ...

    Comment


    • #3
      Why did Chrome decide that this is a good idea but Firefox decided against it?


      UNCONFIRMED (nobody) in Core - Networking: HTTP. Last updated 2024-03-07.


      Perhaps there will be more urgency now if web servers start to depend on this?

      EDIT: Actually, I now see: https://bugzilla.mozilla.org/show_bug.cgi?id=1884305 which is very new compared to the other bugs. Looks like they are aware.
      Last edited by ahrs; 27 March 2024, 08:29 AM.

      Comment


      • #4
        Originally posted by ahrs View Post
        Why did Chrome decide that this is a good idea but Firefox decided against it?
        Because it's lead by mozilla? There is probably an important icon that needs to be forced into the GUI with no option to remove it, that has a much higher priority!

        Comment


        • #5
          Originally posted by Anux View Post
          Because it's lead by mozilla? There is probably an important icon that needs to be forced into the GUI with no option to remove it, that has a much higher priority!
          You're joking but I find it funny that those two bugs I linked were opened 8 years ago and now that Google's done it there's sudden sporadic activity again. I miss the times where Mozilla was bold enough to make decisions on their own. There's still no JXL support in Firefox for example (outside of Nightly).

          Comment


          • #6
            Originally posted by ahrs View Post

            You're joking but I find it funny that those two bugs I linked were opened 8 years ago and now that Google's done it there's sudden sporadic activity again. I miss the times where Mozilla was bold enough to make decisions on their own. There's still no JXL support in Firefox for example (outside of Nightly).
            Damned if they do, damned if they don't. Their market share is so small that one tiny feature won't be the thing that gets all their old users back and Chrome has enough manpower that they can implement any tiny feature that Firefox tries to one-up them with.

            Comment


            • #7
              Best feature Firefox could get now would be to announce all Rust code converted back to C++ or even C.

              Comment


              • #8
                Chrome needs as much speed as Google can build into it. All user data is being uploaded to google servers in real time, Chrome is aggressively pre-fetching data from numerous links on each page a user visits, and on top of it Google is caching and proxying much of the internet through its servers. The speed difference is noticeable, but not really necessary. Waiting 1-2 seconds for a website to load vs milliseconds isn't a significant enough difference to make the privacy tradeoff worthwhile.

                Comment


                • #9
                  While Chrome embracing Zstd encoding is great, at this time there is limited web server support for Zstd encoding.
                  How is this different to JXL? The reason given for not supporting JXL is "...limited web server support".

                  Looks like double standards.

                  Comment


                  • #10
                    Been waiting for this.
                    If everyone serving HTTP content using gzip switched to zstd ASAP, it would save countless gigawatt hours per year.
                    I've been using zstd for internal services for 8 years now and other companies probably are doing it too, but this allows switching the end-user facing parts of the system too.​
                    Last edited by david-nk; 27 March 2024, 02:55 PM.

                    Comment

                    Working...
                    X