Slashdot Mirror

← Back to Stories (view on slashdot.org)

Firefox To Support Google's WebP Image Format For a Faster Web (cnet.com)

Posted by msmash on from the marching-forward dept.

Firefox has joined Google's WebP party, another endorsement for the internet giant's effort to speed up the web with a better image format. From a report: Google revealed WebP eight years ago and since then has built it into its Chrome web browser, Android phone software and many of its online properties in an effort to put websites on a diet and cut network data usage. But Google had trouble encouraging rival browser makers to embrace it. Mozilla initially rejected WebP as not offering enough of an improvement over more widely used image formats, JPEG and PNG. It seriously evaluated WebP but chose to try to squeeze more out of JPEG. But now Mozilla -- like Microsoft with its Edge browser earlier this week -- has had a change of heart. "Mozilla is moving forward with implementing support for WebP," the nonprofit organization said. WebP will work in versions of Firefox based on its Gecko browser engine, Firefox for personal computers and Android but not for iOS.

53 comments

  1. 8 years ago? by Anonymous Coward · · Score: 0

    Created when Google wasn't fully evil/solely out for their own interests.

    1. Re:8 years ago? by bobstreo · · Score: 1

      Created when Google wasn't fully evil/solely out for their own interests.

      Maybe they're concerned about charge-backs from ISP services in states that haven't passed Network Neutrality edicts.

    2. Re:8 years ago? by arglebargle_xiv · · Score: 1

      Newsflash: Chromefox decides to copy what Google is doing. In other breaking news, water is still wet, the sun still rises every day, and Windows 10 still sucks. Film at 11.

  2. Still don't get it by Anonymous Coward · · Score: 3, Insightful

    What makes the web slow is unnecessary javascript. The "problems" with JPEG and PNG are miniscule compared to the problems with bloated javascript, and downright negligable if you actually take the time to optimally compress your images.

    1. Re:Still don't get it by Desler · · Score: 1

      Yep the 5 MB of minified and compressed Javascript is far more the problem then a 100 KB jpeg.

    2. Re:Still don't get it by jellomizer · · Score: 2

      You mean downloading Megs of jQuery just so I can do a couple of $("#content").html("Text") is slowing things down? How could that be document.getElementById("content").innerHTML = "Text" is much longer to write.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    3. Re:Still don't get it by Anonymous Coward · · Score: 0

      I'll head off the next anticipated counterpoint: "But it's cached so it only matters for the first page load."
      Not so: huge javascript libraries incur a noticeable, measurable slowdown even when being loaded from your local cache.

      Software bloat in both space and time expand to fill their "containers," not just the hardware average people use, but also what users will tolerate. User experience studies indicate that many people will leave a site if it takes just a few seconds to respond.

      User time is more important than developer time. If extra developer time is required to -not- use garbage bloated code, but saves years of user-hours and improves customer retention, it should be seen as money well-spent.

    4. Re:Still don't get it by cascadingstylesheet · · Score: 2

      You mean downloading Megs of jQuery just so I can do a couple of $("#content").html("Text") is slowing things down? How could that be document.getElementById("content").innerHTML = "Text" is much longer to write.

      If that were all that jQuery did, you'd have a point.

      jQuery abstracts away browser bugs and differences, just for one (huge) thing.

      It also makes things easy that are a huge PITA to implement in JavaScript.

      Yes, nothing you can do with jQuery can't be done with plain JavaScript - after all, jQuery is written in plain JavaScript. But you could just as well say that nothing you can do in C can't be done in assembly.

    5. Re:Still don't get it by Joce640k · · Score: 1

      I could quip that jQuery might be used for something else on the page that would take a LOT more code that in Javascript and, given that jQuery is already loaded, I might as well do "$("#content").html("Text")" for convenience.

      Sure, I could roll my own optimized libraries for the other things that jQuery does but they'd be slower to load than an already-cached copy of jQuery and you'd still complain about them.

      PS: Yes, there are web pages that only do "$("#content").html("Text")". They'll go under eventually.

      --
      No sig today...
    6. Re:Still don't get it by jellomizer · · Score: 1

      I am not dissing jQuery, I tend to use it often. However the problem is, it is a Big library, with a lot of features, rarely having even most of them being utilized on a page. So you are downloading megs of data for only a few kilobytes of actual executed code.

      Perhaps Major browsers should have a built in store of jQuery and AngluarJS vs having to download it every time. (Yes there is a way to link to it directly, without downloading the JS files, and it would be better cached in your browser) But still we are having an external library that is commonly being used managed outside the browser.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    7. Re:Still don't get it by SurenEnfiajyan · · Score: 1

      Webassembly? It's usually much faster and it allows you to use a language other than JS, such as C/C++, Rust, etc.

    8. Re:Still don't get it by sexconker · · Score: 1

      You mean downloading Megs of jQuery just so I can do a couple of $("#content").html("Text") is slowing things down? How could that be document.getElementById("content").innerHTML = "Text" is much longer to write.

      I rarely do Javascript, but when I do I always typo getElementById as getElementByID the first time.

    9. Re: Still don't get it by Anonymous Coward · · Score: 0

      How about, instead of pushing work on to browsers, you just apply some instrumentation and figure out what are all the lines of jquery (and any other library) that you really use and deploy a subset of it? Pay only for what you use. You are in control of that.

    10. Re:Still don't get it by jrumney · · Score: 1

      However the problem is, it is a Big library, with a lot of features, rarely having even most of them being utilized on a page.

      Which is why you should use a common CDN hosted copy of jquery, and not download and serve it from your own site. At least then, the same file is shared with other sites, and more likely to stay in the browser's cache.

    11. Re: Still don't get it by Anonymous Coward · · Score: 1

      if you like your users being spied on by 3rd parties or maybe even the NSA, sure - great idea!

    12. Re:Still don't get it by squiggleslash · · Score: 2

      The regular jquery.min.js file is currently 85k, it's not megabytes by a long shot. Yes, you might also use add-ons, but the thing by itself is usually enough for most web developers, and even includes a lot of non-DOM stuff like AJAX.

      The reason jQuery causes websites that use it to bloat has nothing to do with the size of the library, and it doesn't cause megabytes of data to be loaded. jQuery's main flaw is that it relies heavily on closures, which are extremely hard to garbage collect (in Javascript a closure can refer to the scope of the code that created it, which means all or most of that data has to left in memory until the closure itself is destroyed.) Add in the possibility of a closure using eval() (making it impossible for a JS interpreter/compiler to determine what data might get referenced) and you realize JS closures are horribly flawed.

      Not that I'm knocking jQuery for using closures, as a heavy jQuery user I can understand why, and it makes AJAX calls so much cleaner. This is a JS problem, and one that's probably too late to do anything about.

      --
      You are not alone. This is not normal. None of this is normal.
  3. Image formats aren't the bottleneck. by RyanFenton · · Score: 4, Interesting

    Compression levels and file size aren't the current limitations on 'web speed' as such.

    The limits are REALLY, REALLY easy to detect, if you try any sizable set of major websites with and without various levels of ad blocking and script blocking.

    The limitation is servers placed in between users and the content they want, by marketing company servers that demand to be parsed before loading.

    And marketing companies don't place much priority on 100% minimal load times, compared to showing greater statistics on what makes them money.

    That's what kills the traffic flow - like a small number of bad actors can slow any traffic system. When those actors are left in front of the others, with no way to get around them, all the traffic is slowed.

    This is a fix - but it's very much not a general fix for what most affects people's experience online.

    Adblock and script blocking are that for now - but bypassing a >1ms marketing server delay would be the more proper fix if you wanted ads to keep paying for things.

    Have marketing companies absolutely lose their chance to show ads for any, ANY delay would fix their priorities, and fix the web for those that want to keep it an ad-loaded experience.

    Ad/script blocking works for everyone else.

    Ryan Fenton

    1. Re:Image formats aren't the bottleneck. by Anonymous Coward · · Score: 0

      This already happens. What takes place is a mini-auction. The ad server gets queried and it holds a little auction for the slot and anything that can't respond quick enough is dropped on the floor. It's seriously crazy how it's like high frequency trading where the fastest responders are making the most money.

      And I do apologize for my involvement in all of this.

    2. Re:Image formats aren't the bottleneck. by Anonymous Coward · · Score: 0

      And I do apologize for my involvement in all of this.

      How do you sleep at night?
      "On top of a pile of money with many beautiful ladies."

    3. Re:Image formats aren't the bottleneck. by UnknownSoldier · · Score: 2

      Part of the problem is you that you have morons claiming "ad blocking is unethical.

      *facepalm*

      So closing my eyes is fine but if I use technology to do the same thing all of it sudden it becomes "ethical" ??? WTF !

      I use ad-blocking to SPEED up MY browsing experience and not load images + cookies from 30+ different websites.

    4. Re: Image formats aren't the bottleneck. by Anonymous Coward · · Score: 0

      I hope you meant 1s and not 1ms. Nothing is reachable over the internet in 1ms. Thereâ(TM)s probably something like 10ms between you and the nearest city.

      Anyway, the easiest way to make it fast and reliable would be the server side loading it to a cache periodically and presenting to the client directly.

      Obviously we donâ(TM)t want it fast.

    5. Re: Image formats aren't the bottleneck. by RyanFenton · · Score: 1

      Sure - 1ms.

      How?

      Server side page composition. Have the ad data queued to add to pages, throw them together on your server, send the composed page to the user.

      Minimize scripting needed on client side, and ensure minimal delay.

      Any marketing company that can't queue up their data to you, and has any ad take more than 1ms to add server-side is rejected as too slow.

      The user waiting for anything should be considered broken. If you are pushing ads, it has to be a better experience than without ads - otherwise, you're inherently asking to be bypassed as time goes on.

      Ryan Fenton

    6. Re:Image formats aren't the bottleneck. by commodore64_love · · Score: 2

      Being on dialup when I travel (yes really) I have a slightly different view. If I load the page straight-up, it's extremely slow (over a minute). However my dialup also has a compression algorithm and "Disable flash" that I can turn on.

      - The page looks like crap (2 color GIFs and JPEGs are not pretty), but it loads in less than 10 seconds.

      - And of course turning-off Flash means the annoying animated videos don't load.

      From my point of view Images and Flash are the main culprits for making webpages bloated and slow to load.

      --
      "I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
    7. Re:Image formats aren't the bottleneck. by Quince+alPillan · · Score: 1

      The limitation is servers placed in between users and the content they want, by marketing company servers that demand to be parsed before loading.

      Generally, this isn't true. Most marketing scripts are loaded asynchronously and will load in the background while your main content loads.

      Additionally, if you're a major website, you can demand network performance improvements from the marketing vendors before you'll put their pixel on your site.

      From my experience, cpu time processing javascript, loading large javascript libraries, and recalculating the dom is the biggest bottleneck. Those marketing scripts you mention? Most of them come with a jQuery library several versions old. If you load more than one or two on your site, you're loading multiple versions of jQuery (which is a huge library compared to what the scripts actually do). On top of that, they're usually inserting elements into the dom, such as 1x1 gifs or other scripts. This forces the browser to recalculate what the page is supposed to look like, which takes even more load time.

      Check out Chrome's built in performance monitoring tool. It'll show you what the site is trying to load and how long it's taking to parse javascript, css, etc.

      Ultimately, you're correct that it's the marketing scripts that are likely causing the issue, but it's not the issue that you think it is.

    8. Re:Image formats aren't the bottleneck. by MrL0G1C · · Score: 1

      Lol, and how ethical is spying on people and selling that information!?!?

      I've read 1984 and in many ways what we have today is worse, most of the population is brain-washed and the majority can't think beyond their genetic programming, hell the majority don't want to think, they find it too hard and want other people to think for them.

      --
      Waterfox - a Firefox fork with legacy extension support, security updates and better privacy by default.
    9. Re:Image formats aren't the bottleneck. by DontBeAMoran · · Score: 1

      http://explosm.net/comics/3709...

      --
      #DeleteFacebook
    10. Re: Image formats aren't the bottleneck. by Anonymous Coward · · Score: 0

      Three major CDNs are about 0.2ms(ISP) from me, and another 6 are 2-3ms(ISP's transit datacenter) away, and the rest are 300 mile away in Chicago with a 6ms RTT. Over 100 major datacenters within 9ms, including Google, and several internet exchanges.

  4. Image file sizes aren’t usually the real iss by 93+Escort+Wagon · · Score: 1

    But I suppose we can’t expect Google to attack the real speed killer - the calling and loading of sometimes dozens of third-party trackers and advertisements on a web page.

    --
    #DeleteChrome
  5. Re:Google is gay by Anonymous Coward · · Score: 0

    Gay is a-okay!!

  6. Can't wait for this to show up on 4chan by Anonymous Coward · · Score: 0

    They did WebM first after all. PNGs are a plague on humanity.

    1. Re:Can't wait for this to show up on 4chan by Anonymous Coward · · Score: 0

      Your mom gave muh dik the plague.

    2. Re:Can't wait for this to show up on 4chan by jellomizer · · Score: 1

      What makes PNG so bad?

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    3. Re: Can't wait for this to show up on 4chan by Anonymous Coward · · Score: 0

      People are using them for everything. 3 to 5 MB 1000+x1000+ PNGs regularly feature on the site and mock us poor mobile-only plebs.

    4. Re:Can't wait for this to show up on 4chan by Anonymous Coward · · Score: 3, Funny

      In an age where Americans have degenerated to the level of stupidity where they take high-fidelity audio and video, then down-scale resolution frame-rate and color-depth, mute it, and subtitle it, just so they can repost it as GIF on reddit.com imgur.com and other retarded web sites, you decide to complain about... PNG?

    5. Re: Can't wait for this to show up on 4chan by jellomizer · · Score: 1

      How is WebP going to fix misuse of an image format? What I would expect would be 3-5 MB 1100+x1100+ WebP files. To still mock the poor mobile-only plebs (who for some reason have that much slower of a network connection)

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    6. Re: Can't wait for this to show up on 4chan by Anonymous Coward · · Score: 0

      I just went there and there's both a 48KB png and a 297KB jpeg, both very roughly around 1000x1000 size. Both are some kind of MS Paint art and the jpeg looks worse. There will always be dumbfucks that don't watch their file size e.g. someone posted a useless 1.53MB jpeg.
      I have to say that while the content is full of some hot garbage; the pictures file sizes are shown above the thumbnails and that's impressive and unusual.

    7. Re: Can't wait for this to show up on 4chan by Anonymous Coward · · Score: 0

      It's not about the speed of a mobile connection, it's the data limit; I only have 2 GB per month and more than that costs more money (either in overage fees or upgrading my data plan). But otherwise you are correct, WebP will do nothing to correct developers who misuse image formats; PNG is pretty decent, and I don't see supporting new formats an issue but I doubt an incremental improvement in images will do anything noticeable to improve speed when things such as ads and inclusion of far too many javascript libraries appears to be making a far more noticeable impact than image compression.

    8. Re:Can't wait for this to show up on 4chan by Anonymous Coward · · Score: 1

      PNGs are huge because they are lossless. JPGs are old tech and we can do way better now.

  7. Googzilla EdgeFox by Anonymous Coward · · Score: 0

    No thanks, see you in the water (fox) instead.

  8. still no flif support? by Anonymous Coward · · Score: 1

    https://flif.info/

  9. Re:Google is gay by Anonymous Coward · · Score: 0

    Yes, Google is an anus dripping and leaking buckets of cum gay.

  10. Re:Image file sizes aren’t usually the real by bobmagicii · · Score: 1

    png4life. i actually do literally rage when i drag an image from my browser to the desktop and it ends up being webp. was so sure that shit would have died by now :(

  11. I hate WebP by Waccoon · · Score: 2

    WebP is another one of those things as Google that was thrown together as a test vehicle for a compression algorithm. It sucks as a format and comes in multiple inconstant flavors (versions) that make it a PITA to support. Just getting the image dimensions requires a lot of low-level bit shifting and twiddling for no damn reason, and how that's done depends on how the chunks are organized. It's a mess. It's no surprise to me why it didn't catch on. After trying to add support for it on my image board, I just gave up. Retrieving image information is too difficult as there's too many gotchas.

    Of course, Google would prefer that you just use their huge, complex WebP library, so you don't have to worry about how to unwind that horrible mess.

  12. AMINATION CONTROL by markdavis · · Score: 2

    Please, Mozilla, if you are going to support WebP images make absolutely sure Firefox complies with the image.animation_mode setting so any WebP animation can be controlled or disabled by the user!

  13. I get better compression rates... by Anonymous Coward · · Score: 0

    By adblocking all the shit that comes on a typical commercial website. Scripts, images etc. Easily cuts 30-50% of the download not to mention saving phone battery.

  14. Webp supports animation, unlike PNG by Anonymous Coward · · Score: 0

    Wikipedia states that Webp does animation.
    PNG doesn't do animation, so in one major criteria, PNG is inferior to GIF.

    1. Re:Webp supports animation, unlike PNG by blackpig · · Score: 1

      PNG does indeed do animations through the Animated Portable Network Graphics (APNG) file format and is supported by all modern browsers.

    2. Re:Webp supports animation, unlike PNG by Anonymous Coward · · Score: 0

      Criterion, please. Criteria is plural.

  15. Format isn't the problem by CanadianMacFan · · Score: 1

    Many of the times the large file size isn't due to the format but because the person creating the image didn't bother to optimize the picture. It's not unusual to be able to get an image in which you can shave 90% off of the size without compromising quality. Usually it's more like 30%-60% but I have seen 90%. I used to optimize my images when I had my own site. I do it now and again with a slow loading site just to see what I can do.

    When you have all of these sites and applications that lets anyone build a site without knowing what to do of course you are going to get bloated images. Never mind that the same image is going to be used for all environments. So that bloated image that's meant for the desktop that I could shave 90% off is also being sent to people who are using their mobile. It could be cut by another 3/4 by making a smaller version just for a mobile version of the site.

    It's not just the people up above that don't optimize their images. I was in a federal Canadian department and they didn't optimize the graphics either. What I hated is that the graphics for the Java web applications were included with the .jar files and being server from the application server because it was easier to deploy. If they served the graphics from the web server, which passed the requests to the application server, then the graphics would have been more responsive and the load on the application server would have been lessened because it was busy serving graphics (one page could have 20 small graphics).

    You don't need new image formats or even to replace HTTP(S) to get faster responses. Optimize your files and server configuration.

    1. Re:Format isn't the problem by ShoulderOfOrion · · Score: 1

      You're right, of course. Unfortunately, stupid and lazy is the default setting of the human race, hence the need to code up solutions that don't depend on humans actually thinking.

  16. Money? by Anonymous Coward · · Score: 0

    How much did Google pay Firefox to do this?