WordPress.org

Make WordPress Core

Tagged: performance Toggle Comment Threads | Keyboard Shortcuts

  • Joe McGill 3:46 pm on March 12, 2016 Permalink
    Tags: , , , , , performance   

    Performance improvements for images in WordPress 4.5 

    WordPress 4.5 includes a few performance enhancements for images.

    Increased image compression for custom sizes

    WordPress 4.5 increases the amount of compression applied to intermediate sizes by changing the default quality in WP_Image_Editor from 90 to 82. As noted in the proposal for this change, this results in a noticeable reduction in file sizes with little change in visual quality. Developers can override the default image quality value using the wp_editor_set_quality filter.

    Improved resizing settings for ImageMagick

    For sites making use of ImageMagick, we’ve reduced file sizes further by resizing images  more efficiently in WP_Image_Editor_Imagick and by stripping extraneous metadata using the new WP_Image_Editor_Imagick::strip_image() method.

    For now, ‘icc’ and ‘icm’ color profiles are retained, along with ‘exif’, ‘xmp’, and ‘iptc’ profiles, which can contain copyright and orientation data. Those who want to retain additional metadata can disable profile stripping by adding a callback function to the image_strip_meta hook that returns false.

    Note that the original full sized images uploaded to WordPress are unaffected by these changes.

    Introduction of wp_get_upload_dir()

    As Jeremy Felt mentioned in his post on Multisite changes, wp_upload_dir() received a major performance overhaul in this release. Those changes were pared with the addition of a new function, wp_get_upload_dir(), which can be used as a more performant way to display information about the uploads directory on the front end. This is particularly useful when building URLs for images in templates. (See #34359)

     
    • petermolnar 5:56 pm on March 12, 2016 Permalink | Log in to Reply

      I don’t welcome the default EXIF stripping. It’s not optimization, it’s removing information from a picture.

      • Joe McGill 6:43 pm on March 12, 2016 Permalink | Log in to Reply

        Hi Peter,

        Thanks for your comment. To be clear, Exif data is not being stripped by default at this time. Please reread the section about metadata stripping, which lists all the profiles that are retained. Sorry if that was unclear.

    • petermolnar 5:58 pm on March 12, 2016 Permalink | Log in to Reply

      • Destac 6:07 am on March 13, 2016 Permalink | Log in to Reply

        You should again reread that link the images are not having the data stripped but the resizing doesn’t carry the exif data over.

        WordPress strips EXIF data from the auto-resized versions of the images as a side effect. What it’s actually doing is creating new images from the original, and not copying that data.

        However, the original image is saved as-is, with all EXIF information included. The original image is not modified in any way.

        • Marko Heijnen 3:10 pm on March 14, 2016 Permalink | Log in to Reply

          That’s copy/pasting from the topic. I’m sure Peter can read. His first statement is still correct since WordPress by default with Imagick will strip information from a picture. Not the EXIF information but other related information.

          For GD I have played a bit to see what options we have and the only workable option is storing EXIF data as IPTC.

          • Destac 1:06 pm on March 15, 2016 Permalink | Log in to Reply

            Not true. His original statement says.

            I don’t welcome the default EXIF stripping. It’s not optimization, it’s removing information from a picture.

            So my statement as was Joe’s were still correct.

            On this separate matter i don’t see the value of this information vs stripping it which is recommended for
            performance

        • petermolnar 11:21 am on March 31, 2016 Permalink | Log in to Reply

          resizing does carry EXIF over. GD used to strip it, imagick does not.

    • Kochhase 2:10 pm on March 15, 2016 Permalink | Log in to Reply

      hello, “along with ‘exif’, ‘xmp’, and ‘iptc’ profiles, which can contain copyright and orientation data”. in germany the there is a § for that. http://dejure.org/gesetze/UrhG/95c.html. so wordpress does not authorized to remove this information.

    • FolioVision 10:34 pm on March 28, 2016 Permalink | Log in to Reply

      This is great work Joe. Wonderful to have better core support of ImageMagick (IM really does make a huge difference in quality). Any chance we could get a Setting screen in the backend to handle the Media Library and these settings. Making them command line only seems pretty user unfriendly. Even if one has to flick a switch to make them available (i.e. add Advanced Media Settings checkbox somewhere visible by default).

      Alec Kinnear

      • Joe McGill 11:59 am on March 31, 2016 Permalink | Log in to Reply

        Thanks Alec,

        While we aren’t planning to add a screen to control specific ImageMagick settings in core, I think it would be a wonderful plugin for those who are interesting in controlling the fine details.

        Joe

    • Bayu Angora 11:40 pm on April 13, 2016 Permalink | Log in to Reply

      So, we don’t need image compress plugin anymore?

      • Joe McGill 1:19 am on April 14, 2016 Permalink | Log in to Reply

        It’s likely that you still might get some benefit out of some compression plugins, but it shouldn’t be nearly as dramatic as it was before. Best thing to do is to evaluate the difference you’re seeing in quality and performance between WordPress defaults and what your compression plugin gives you and decide if it’s worth continuing to use a compression plugin in your particular use case.

    • ninjaunmatched 5:09 pm on April 15, 2016 Permalink | Log in to Reply

      Will the new compression be applied to existing images or only new uploads?

    • nekroido 8:28 pm on April 20, 2016 Permalink | Log in to Reply

      Are you planning on enhancing the resizer with focal points support? The feature is quite vital for custom themes and support for mobile apps.

    • Simon Pollard 3:39 pm on May 11, 2016 Permalink | Log in to Reply

      Apologies if this is a silly question – if a user uploads an image that is 1024 x 768 and I have a custom thumbnail size that is 1024 x 768 that I use in my code and request that version of the thumbnail. Will the image I get back be the original uncompressed image, or will I get an optimised one? If it is the original do I need to ask my user to upload images 1025 x 768 to enforce a compression? Hope that makes sense.

      • Simon Pollard 8:07 am on May 12, 2016 Permalink | Log in to Reply

        So it appears if the size of an image matches the size of a specified image size by add_image_size() it does not get created and thus not optimised. If I make the image 1px larger it will then create an optimised version. Is there any way to enforce optimisation on all images or enforce the creation of an optimised image size version?

    • Mikel King 3:48 pm on May 18, 2016 Permalink | Log in to Reply

      Is there a guide somewhere that explains how this works from the content creation to hydration process?

  • Joe McGill 12:51 pm on February 22, 2016 Permalink
    Tags: , , , performance   

    Proposal: Increase the default image compression in WordPress 

    Note: This proposal was merged to core in [36615]. Download the latest nightly build and give it a try!

    In order to improve page load performance, I propose that the default image compression setting be changed from 90 to 82 in WordPress. Let’s get into why.

    Background

    The default quality setting for resized images in WordPress has been 90 since the image_resize() function was shipped in version 2.5. This setting creates images with much larger file sizes than recommended by modern web best practices.

    Over the past several years, the importance of performance has been highlighted as users access the web globally on slower connections, and performance has even started being used by search engines to influence search results.

    Tools like Google PageSpeed Insights and WebPagetest will warn site owners if images aren’t sufficiently compressed. For example, the glossary at the bottom of the WebPagetest performance optimization page states:

    Within 10% of a photoshop quality 50 will pass, up to 50% larger will warn and anything larger than that will fail. The overall score is the percentage of image bytes that can be saved by re-compressing the images.

    Research

    With this in mind, web developer and performance advocate Dave Newton published recommendations for ImageMagick compression settings based on his research comparing various ImageMagick settings against Photoshop’s ‘high quality’ (60) setting for JPEGs. He found that an Imagick compression setting of 82 was closest to this using an objective measurement named DSSIM to compare the visual similarity between two images.

    We experimented with Dave’s settings in the RICG Responsive Images plugin during the 4.3 cycle and found that not all Dave’s suggestions can be easily applied by default in WordPress due to the memory required to process large images on shared hosts. However, changing the default image quality setting is a relatively small change that makes a big impact on file size without sacrificing much in the way of perceived image quality.

    In research released in 2014, compressed images with a DSSIM score of 0.015 were deemed acceptable to most people. In tests of several different images, I found that changing the default compression setting in WP_Image_Editor from 90 to 82 reduced image sizes by an average of ~25% with DSSIM scores ranging from 0.0014 to 0.0019 for ImageMagick and 0.0019 to 0.0023 for GD — both of which are drastically under the 0.015 threshold cited above.

    Proposal

    Given these results, I suggest making the change to 82 for the default image compression setting. You can follow the discussion on the related ticket (33642) and give feedback in the comments or in the #core-images channel on Slack.

    As a reminder, this setting only applies to the intermediate sizes that WordPress creates, and not the original files uploaded by users. For any users who need to maintain a higher image quality for intermediate sizes, the default quality can still be changed with the wp_editor_set_quality filter.

     
    • leehodson 1:26 pm on February 22, 2016 Permalink | Log in to Reply

      How about setting the default to 82 and providing an easy way for site admins to adjust the setting from within the upload screen at the time of upload and for site admins to set a default compression value in Settings > Media.

      Many site admins, editors and authors are unaware that images are compressed on upload and so few (even among developers) are aware of the wp_editor_set_quality filter; makes sense to provide a user friendly way for the quality setting to be adjusted both at time of upload and from within the media settings screen. I’d even go as far as to let those with media upload permission to rebuild their uploaded images from within the media library.

      What’s the general feeling toward this idea?

      • Eric Andrew Lewis 2:14 pm on February 22, 2016 Permalink | Log in to Reply

        I don’t think the typical end-user needs to worry about image compression levels.

        • leehodson 2:32 pm on February 22, 2016 Permalink | Log in to Reply

          They do when they can’t figure out why their beautiful high quality images of special events look fuzzy on their iPads when viewed within their websites.

          Really isn’t for us as web developers to tell people what they do and don’t need to worry about; it is for us to make it easy for people to control their websites. One extra slider in the media uploader won’t be huge distraction to authors but will make life easier for them and for site admins.

          • Samuel Wood (Otto) 4:18 pm on February 22, 2016 Permalink | Log in to Reply

            Really isn’t for us as web developers to tell people what they do and don’t need to worry about

            Actually, it is. That’s exactly your job. You don’t tell your mechanic the best way to fix your car, you don’t tell your plumber the best way to plumb. And you don’t tell your web developer the best way to develop for the web.

            “It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.” – https://wordpress.org/about/philosophy/

            • Jon Brown 4:56 pm on February 22, 2016 Permalink

              I don’t think anyone would suggest exposing the technical details to users.

              Images and image quality are deeply personal things for many bloggers and site owners though and ignoring those desires isn’t serving our users.

              IMHO, we should have always had an option for image quality vs speed, something like

              Image quality settings could be:
              [ ] High (Minimal compression/large file size, 90 old default)
              [ ] Medium (Optimized Compression/small file size, 82 new default)

              • Neither setting affects your originally uploaded image. Changing the setting will only affect newly generated thumbnails.

              Photographers could set things to “high”, everyone else would stop generating poorly compressed thumbnails.

              I find users are very strongly bipolar on this. Either they’re photo focus and want “100% quality JPEGs” or they’re speed focused and want “A’s on all the speed test suites”. Of course the first group actually wants both, but one can explain, or at least try, to explain why those are mutually exclusive options.

            • Ihor Vorotnov 5:14 pm on February 22, 2016 Permalink

              I totally agree that it’s our job develop properly. But WordPress is used by many non-devs, without dev assistance/hiring. It this case, a UI for setting this option would make sense. IMHO, it should be:

              • default option value is 82
              • a user can change this options in Settings – Media (simple input with instructional text would be sufficient)
              • a developer can override this value via `wp_editor_set_quality` filter
            • chrishoward 5:43 pm on February 22, 2016 Permalink

              There’s so many things in WP where we allow the user to make their own choice.

              The breadth of WP users goes well beyond those reliant on other developers. Many, many, many, many WP sites are one person shops, so the user is also the admin.

              They have to set things like permalinks, home page type (blog/static), use the theme customizer, post format types, widgets, menus, categories, tags, etc.

              People have had quality setting on their digital cameras for 20 years. Likewise photo editing software.

              Poor user is sitting their trying to decide if his post is an “Aside” or a “Quote” or a “Status”… so seeing an image quality option would be like seeing old friend!

              An image quality setting is not going to scare anyone – esp if you put it in words. i.e. Max, high, medium, low.

              Adding an option for image quality is hardly “a weight of technical choices”.

              “It’s our duty as developers to not treat users as idiots – even if they are.”

              The only I’d do different to Lee is I’d only have a control for it in the Media Settings.

            • Jeremy Clarke 6:01 pm on February 22, 2016 Permalink

              FWIW you guys should focus on accepting the fact that there will not be an option for this, and definitely don’t allow yourselves to waste cycles on feeling bad about it. Decisions v. Options is an ancient debate in WP and this particular setting will NOT be the one that breaks the trend.

              Opine on what you think the default should be and accept that changing it will involve either 4 lines of code or installing a tiny plugin.

            • leehodson 6:24 pm on February 22, 2016 Permalink

              The web developer’s duty is to build the site and make it as easy as possible for the site owner or his/her designated admins to use it to create and publish contenet. Control of the site belongs to the site’s owner, not me; I’m the experienced developer, not the inexperienced site owner: make it easy to use the site.

              To use the plumber example, I’d tell the plumber what I want done and give instruction on how I’d like the end product to look e.g. fit the new sink in the corner but please make sure there is enough room for me to move my elbows without hitting the wall and try to hide the pipes as best you can without leaving any pipes sticking out for me to trip over. I’m the householder, not the plumber, but I know what I want and what I don’t want: what I want is the plumber to do the work and leave me with a way to turn on the taps without need to call in a plumber each time I need to wash my hands.

              In any case, this belongs in a different discussion.

            • leehodson 6:26 pm on February 22, 2016 Permalink

              Jeremy, who says this feature isn’t up for discussion? It obviously is up for discussion. We’re looking at changing the way WordPress handles media files and we, as end users and developers, are making a reasonable suggestion. The discussion is still open.

            • Jeremy Clarke 6:37 pm on February 22, 2016 Permalink

              leehodson: What’s up for discussion is changing the default compression level. That’s what the OP was about and that’s what this conversation could potentially change.

              Nowhere in the OP did anyone ask whether there should be a setting and the reason is there won’t be. I say this as a fellow traveler who has wasted too much energy fighting for my own pet settings, and as someone with no influence over core WP and nothing to gain other than reducing the overall community drama.

            • leehodson 6:51 pm on February 22, 2016 Permalink

              Thinking about it, there is another solution: could be added to Jetpack as part of the gallery or carousel module.

              The problem with not providing a visible override setting in core is that those with image rich sites who are unknowingly accustomed to an image compression value of 90 may suddenly find their displayed images look low-res when compressed at 82. That will catch many users unaware and I can already see the headlines slating WordPress for making the change without providing a visible method to manually adjust the setting that doesn’t require a plugin (which so many equate with the mantra ‘too many plugins are bad’) or that doesn’t require a single line of code (which many users don’t expect to be forced to use).

              Really wouldn’t like to see some developers charging WP users high fees for adjusting the compression setting. We all know some will.

              The idea of changing the default compression value to 82 or between 82 and 90 is good and is one I like but without an easy way to adjust the setting I can’t see the idea being welcomed by regular end users.

        • Mike Schroder 10:32 pm on February 22, 2016 Permalink | Log in to Reply

          Completely agree. This is one of the areas where “Decisions, not Options” is pretty clear. It’s up to us to do the research (as @dnewton, @joemcgill, and more have) and make a decision that’s good for the majority of sites. Plugins can (and do) modify this value or present a UI as they would like.

      • Jon Brown 4:40 pm on February 22, 2016 Permalink | Log in to Reply

        +1 on this proposal and +10 on Lee’s additional suggestions.

        The current setting is awful for users and we should make this better all around.

        Witness the plethora of cloud based images compression services and plugins that have sprung up to do little more than fix this fundamental design flaw in WP media management. Setting up SmushIt, Krakken, EWWW, etc should be completely unnecessary and it’s become de rigeur.

        Over the years I can’t begin to count the number of users frustrated by WP’s handling on images. Granted a huge number of those don’t understand compression, image size or color space, but the frustration stems from poor defaults without transparency (ie. making it clear what compression is happening, what sizes are being created and used) and zero control over any of it.

        • Jeremy Clarke 6:07 pm on February 22, 2016 Permalink | Log in to Reply

          Adding a setting for image compression will solve pretty much none of those problems, which IMHO are related to featured images and custom sizes (which have never been well-expressed in the UI despite being critically important to authoring workflows). Compression doesn’t confused people, it’s just something people want once they learn the benefits. Turning it on by default is the solution. Once WP has aggressive compression by default a lot of those plugins will fade away as users see the diminishing returns offered by them.

          Unlike custom image sizes, which are editorially relevant (like most of the other decisions highlighted by people in these comments as examples of settings) compression levels are not relevant to how you publish posts. No one NEEDS a different compression level no matter how much they might believe they do, whereas having a custom image size that works properly as a thumbnail in X part of your theme is mandatory.

          • leehodson 6:16 pm on February 22, 2016 Permalink | Log in to Reply

            I need it. Countless others say they need it. Where do you get the idea that no one needs it? Evidence suggests otherwise.

            • Jeremy Clarke 6:25 pm on February 22, 2016 Permalink

              I don’t think you can prove you “need” it. You want it and that’s fine, lots of people feel they want it, but your site will continue to function and display correctly without it (unlike a site with messed up Custom Image Sizes).

              Also for those who “need” it 4 lines of code or a tiny plugin is not an unreasonable step. If you really need it you can install a plugin, that’s how WP works.

              It would be so boring to make a list of options in WP that people actually need but aren’t supported by core (about as interesting as the lists above of settings that ARE in core). For now I’ll leave you with this: Despite WP having a powerful and elaborate capability/role system which can be customized infinitely, there are no options to control it anywhere in core. You can’t add roles or modify the capabilities of roles at all without a plugin. You are stuck with 4 crappy roles that barely cover common use-cases of multi-author sites. Pretty much any site with more than a dozen users will need a plugin like Members or Capability Manager. This is not a bug, it’s a decision made by core to protect users from the extra complexity.

            • leehodson 6:31 pm on February 22, 2016 Permalink

              Role management is a reasonable point. WordPress core presently allows admins to perform tasks that editors, authors and subscribers can’t perform. Is there a reason that same method can’t be employed to control access to a compression value setting in Media Settings or within the media uploader? I can’t think of one.

            • Jeremy Clarke 6:40 pm on February 22, 2016 Permalink

              >Is there a reason that same method can’t be employed to control access to a compression value setting in Media Settings or within the media uploader? I can’t think of one.

              Sorry you missed my point. I wasn’t saying that role/capability management somehow complicates the question of a setting for image compress, I was just pointing out that even role/capability management has no option visibility in core, despite being a huge, complex feature set in place under the hood.

              If such an important (security/workflow/community) feature doesn’t get admin options, you can see why options like image compression are left as “plugin territory” too.

            • leehodson 6:55 pm on February 22, 2016 Permalink

              I read it a bit fast, maybe. Thanks for clearing that up. I do see what you mean though I don’t see it the same way. Might do after an internal debate with myself.

    • chrishoward 1:37 pm on February 22, 2016 Permalink | Log in to Reply

      What Lee said!

      Some sites want minimum compression, wanting their images to look their best.

      Most folks though can’t even tell.

      Looking at that owl, I reckon you can set the default much lower, and then like Lee said, provide an override in the Media settings.

    • Mark-k 1:49 pm on February 22, 2016 Permalink | Log in to Reply

      This doesn’t sound like a real research. I am not objecting but to actually test the usefulness of this change you will need actually web page to test against.

      For small images 25% reduction will not be felt by the user as the bigger factor is the latency.. Big images are many time used as the original image so there will be no change there.

      As for saving money argument, lets call it BS. I get 10GB/mo for 8$ which I can’t even get close to utilizing. I know that israel in this regard is an outliner, but still the price for byte/mo on desktop is virtually 0 and mobile is rapidly getting there all over the world.

      Again, no objection if people can not see the difference, but not sure that a surprise reduction in quality will be welcomed by site owners that will be able to notice it. If implemented this feature should be active only on new installs.

      • Ihor Vorotnov 5:27 pm on February 22, 2016 Permalink | Log in to Reply

        > and mobile is rapidly getting there all over the world

        If you’re talking about mobile traffic cost, you’re soooo wrong. I live in Ukraine, Turkey and Montenegro. All mentioned countries aren’t technical outsiders. In fact, regular internet in Ukraine is much, much, much better then in US. I have unlimited 100Mbps cable for $5/m. However, we just got 3G in 2015, it’s available only in large cities and it’s expensive. Same applies to Russia and Belarus. In Turkey, regular networks are bad and slow, but they have great 3G even in mountain villages. But still, it’s pretty expensive. In Montenegro, regular network is fine (not that good as in Ukraine, but pretty good), 3G is fine but not cheap too. Same applies to many other european countries. So, mobile bandwidth isn’t even close to being cheap. And I’m not even talking about less developed countries. Check India, for example, or Thailand, other asian countries (except China, that’s a different beast). I don’t know how things are going in Latin America, but somehow I’m sure it’s not better. All mentioned countries/regions combined are at least half of the world. So, yes, your Israeli experience is rather an exception.

        • Jeremy Clarke 6:12 pm on February 22, 2016 Permalink | Log in to Reply

          +1 What we know for sure is that decreasing bandwidth requirements has a meaningful impact in all contexts and on mobile the impact is very important for MANY users all over the place for all kinds of reasons.

        • Mark-k 11:51 am on February 23, 2016 Permalink | Log in to Reply

          You don’t design features for today, you should design features for tomorrow when they will actually be used. Changing the default in 4.5 will have no impact on images generated before that and it will take a long time for this feature to generate more then half of wordpress hoisted images on the web. So if you think that anyone around the world will be able to save any money from the introduction of the feature then I think you are very wrong.

      • Drivingralle 3:33 am on February 23, 2016 Permalink | Log in to Reply

        @Mark-k: Happy for you that you can get cheap mobile data. But even in Germany 1GB/mo can cost you around € 10,-. The networks are quite good there but still no reason to send big images.

        Right now I’m in Asia and bandwidth is a big concern here. Volume is cheap, but a lot of sites take ages to load.

        The combination of srcset and an increased compression for intermediate sizes would be a win for both cases/locations.
        In general the weight of most websites is way to high. Images are the biggest part of it. Working on that is a a really important thing.

        • Mark-k 12:01 pm on February 23, 2016 Permalink | Log in to Reply

          srcset **increases** the sizes of the images being send, it is the opposite of this feature in terms of bandwidth performance. srcset increases the size by a factor of 4 for retina displays. shaving 25% off it will end you in an increase of a factor of 3. Maybe a faster and better way to improve image bandwidth performance is to have an option to disable srcset in core so people in “developing world” (whatever that is) can out of the box help their users save bandwidth.

    • dsthedev 2:26 pm on February 22, 2016 Permalink | Log in to Reply

      This is a great idea. I think some people are missing the point here. A mere 8% reduction in quality level can yield ~25% smaller image sizes across the board (minus original) with almost no visual difference? That sounds like it would be good for everyone. Especially since adding an option in media settings would be easy enough and allow for a little more customization.

      I think it makes even more sense if you combine it with the responsive images feature recently added. Improving performance with practically no downsides?

    • Benjamin Pick 3:11 pm on February 22, 2016 Permalink | Log in to Reply

      While I support this proposal, we need to make sure that site editors/admins (!) can find out why their images become blurry. That’s why I like the idea of a media setting – this makes it clear that there is some subjective judgement involved.

      (For example, we had a client that complained that the PNGs become blurry already at the 90%-Level. This was because the typical image was technical drawings or product images with text on it, so it feels blurry much earlier than with photos. I also think of the PDF thumbnails that might get merged into core – please test if 82% would be appropriate there as well.)

      • Jeremy Clarke 6:17 pm on February 22, 2016 Permalink | Log in to Reply

        Benjamin you’re our only hope! Can you go find those images and see how they perform at 90 v. 82?

        I suspect the difference will be invisible as in the test above, and that if they get “blurred” (certainly not a description of the test above) then 90 v. 82 won’t be the reason.

        Either way, at this point it’s up to whoever thinks 82 is to low to show examples.

        • Mark-k 12:09 pm on February 23, 2016 Permalink | Log in to Reply

          Why? it is always the people that want to change things that need to justify it. 90% kinda works and maybe the difference between 90% and 82% is not big, but is it too much difference between the original and 82%? Wherever you have text it will become harder to identify, so maybe the nice owl in the example should be replace with an image of text and the difference should be tested on this kind of images.

          Then you will say that most images do not contain text, and I will agree but before a proper measurement and additional research is done you can not just say that the “difference is invisble” to everyone.

          • Helen Hou-Sandi 3:33 pm on February 23, 2016 Permalink | Log in to Reply

            The post very clearly lays out DSSIM as a proper objective measurement, existing outside research on a precise threshold, and a lot of work done by this team to quantify various outcomes as documented in a spreadsheet. The image set includes images with text, both JPG and PNG. If that is not “proper measurement and additional research”, I have a hard time believing you’re actually open to discussion.

    • jeffmcneill 3:23 pm on February 22, 2016 Permalink | Log in to Reply

      I strongly endorse this proposal. File size, besides number of files, is one of the biggest factors in a slow user experience. Yes indeed, “the biggest factor is latency” but it is latency for requests and responses, that is what is being requested is slow making it to the device, because it is big. Also, the idea that everyone has cheap bandwidth/throughput everywhere, all the time, is simply mistaken. We need ways of making WordPress more mobile-friendly (not to mention developing-country friendly), and this is an excellent proposal to do just that.

    • Aaron D. Campbell 3:46 pm on February 22, 2016 Permalink | Log in to Reply

      I’m all for this change. An average of 25% reduction in file size seems like an obvious win, especially since the visual difference between 90 and 82 is almost none.

      However, we do not need, and should not add, a setting for this. The vast majority of users not only won’t need the setting, but won’t understand it (What does an image quality of 90 vs 82 vs 60 vs 100 actually mean?). The filter (wp_editor_set_quality) is already in place for those that really want it, and a plugin could easily be created to add this setting for any users that want it.

      • dsthedev 4:26 pm on February 22, 2016 Permalink | Log in to Reply

        I don’t know, I feel like it would be pretty easy to write a simple 1 – 2 sentence description of what the setting does. Benjamin Pick provided a perfect example of somebody uploading technical drawing or images with text on them. If a user doesn’t understand the setting they will probably skip it entirely. I also don’t think we need yet another plugin for something that could be a very simple option in core. A great example of that is needing to download the “Disable Google Fonts” plugin on every site I create because wp-core forces Open Sans on everybody without providing a very simple checkbox option to not use it.

        • Aaron D. Campbell 6:06 pm on February 22, 2016 Permalink | Log in to Reply

          The problem here is two fold:

          1) If the majority of users will never use an option, then it shouldn’t be in core. We generally refer to this as the 80-20 rule of thumb. We want core to be what 80% of the people need, and plugins to cover the needs of the other 20%. I don’t even think 20% of users will need this option, much less 80%.

          2) Option overload is a real thing. Users freeze up when there are too many options, because they feel overwhelmed. Every option that goes into the WordPress admin needs to be carefully examined and an EXTREMELY good case needs to be made for it’s necessity. A single new option, then another int he next release, and another after that, and soon our options screens are overfilled and scary to an average user. “It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.” – https://wordpress.org/about/philosophy/

    • Stephane Daury (stephdau) 4:01 pm on February 22, 2016 Permalink | Log in to Reply

      Thanks for the time you put into this. I’m also in favor of looking deeper into this. Those not browsing on broadband, or those with bandwidth limits, will surely appreciate such savings, especially when thinking web scale, and WP as “25% of it”.

    • pix365 4:25 pm on February 22, 2016 Permalink | Log in to Reply

      LIke Aaron, I too am in favour of the change, Mobile data packages in Europe is quite expensive, so reducing the volume of data downloaded can only be a good move, I vote for a Option (& i am assuming it will be dropped to 82) inside the Media admin section to allow folks to override the new default with the Legacy setting (90)
      AND OR if you gave folks the ability to enter a custom value, i think most will use it responsibly, but you can bet some users will use 100%. for that reason alone a custom value field setting is probably not a good one, unless max setting was 90.

    • Aaron Jorbin 5:57 pm on February 22, 2016 Permalink | Log in to Reply

      Thanks for writing thus up.

      The proposal looks great. Let’s do it!

    • Helen Hou-Sandi 6:05 pm on February 22, 2016 Permalink | Log in to Reply

      I’m for this. Really great to see the numbers from objective measurements (DSSIM) included in this, always appreciate the thoroughness and thoughtfulness. Also really cool that this came from responsive images work, which while related, is not inherently coupled to this. Having API improvements come from feature work tends to work well for us.

      Regarding the comments here, no core UI settings for this, please. We don’t have one now and this change is, per the numbers, incredibly unlikely to be visually noticeable in the end results, so I don’t see why it requires further changes in the admin.

      Just so I’m clear on this point – this only applies to JPGs, yes? Are PNGs resized to PNGs or are they resized to JPGs? (There’s also a comment above with concerns about PNG quality loss.)

      • Joe McGill 6:37 pm on February 22, 2016 Permalink | Log in to Reply

        Good questions Helen.

        The quality setting affects both JPG and PNG files. PNGs will remain PNGs but compression in Imagick affects PNGs differently than JPGs so the file size differences aren’t as noticeable. There are a few tickets floating around track about better compression for PNGs specifically, which would be another nice addition to tackle.

    • Primoz Cigler 6:55 pm on February 22, 2016 Permalink | Log in to Reply

      Yes, do it. And no, no extra settings are needed. I even think you could set it to lower than 82, but I guess some other people here will kill me with fire 😀

      Are metadata and exif stripped also? I think it is a good idea they should be stripped by default as well. So called lossless compression.

    • Dave 7:10 pm on February 22, 2016 Permalink | Log in to Reply

      I’m all for this change, and appreciate Joe’s time in writing it up, and providing data to explain why.

      I agree with the last few comments about no UI settings in core (for all the same reasons that were already mentioned).

    • jteague 7:13 pm on February 22, 2016 Permalink | Log in to Reply

      +1 on this proposal. Our own recent tests came out at 84% optimal, but either compression percentage is fine.

    • Ansel Taft 7:53 pm on February 22, 2016 Permalink | Log in to Reply

      A great write-up, well reasoned, and an excellent tweak to WordPress. [/makeitso]

    • Gary Pendergast 11:20 pm on February 22, 2016 Permalink | Log in to Reply

      +1 on this change, nice writeup, Joe. 🙂

      -∞ on adding UI for an option, the existing filter is sufficient.

    • jtleathers 1:15 am on February 23, 2016 Permalink | Log in to Reply

      I’m all in favor of this change. It always bugs me when the current default creates smaller resolution images with larger file sizes than the original image. This change should definitely help.

    • M Asif Rahman 2:14 am on February 23, 2016 Permalink | Log in to Reply

      Agreed. Let’s do this.

      And for changing the value, we have a hook already.
      add_filter( 'jpeg_quality', create_function( '', 'return 80;' ) );

      Read more at – https://developer.wordpress.org/reference/hooks/jpeg_quality/

    • Drivingralle 3:45 am on February 23, 2016 Permalink | Log in to Reply

      +1 for this.

      I created a ticket in trac about giving developers a way to control image compression for costume image sizes per size to save even more file size. I think somehow related.
      https://core.trac.wordpress.org/ticket/29795

    • Mark Howells-Mead 8:42 am on February 23, 2016 Permalink | Log in to Reply

      +1 from me. When I make the effort to optimize content photos as precisely as possible before uploading them, WordPress’ processing always creates copies from them which are larger in file size than the originals.

      I doubt many editors or admins will take the time to pay attention to a setting in wp-admin: I think that a customization of the default setting should continue to be handled by the experienced developer, via a hook.

    • AllenAyres 8:02 pm on February 23, 2016 Permalink | Log in to Reply

      I understand I’m not a developer, but speaking for the thousands (millions?) of photographers using WP for their business-front end, it would be appreciated to give them a heads-up on the change and the way to undo it if they prefer.

      *You* may not care for image-quality vs download speed, but those who rely on the display of their work to be seen at its best do. Our life’s work is image quality, what may not be obvious to some is glaring to others.

      For those who are on slower/metered access, I’m ok if they bypass my site, it’s generally not for them in the first place.

      • Ipstenu (Mika Epstein) 12:45 am on February 24, 2016 Permalink | Log in to Reply

        I’m curious… Do you have people looking at the downsized images or the full sized? Because as I understand it, we’re only going to be changing compressions for the resized images.

        • Ryan Hellyer 8:25 am on February 24, 2016 Permalink | Log in to Reply

          I suspect it’s both. Even the “full sized” images shown on photography websites tend to be scaled down to a more reasonable number for display. And photographers tend to be very particular about their thumbnails in my experience too. I actually think the thumbnails can be even more important, as they tend to show up JPG compression more, due to their small size and people staring close at them.

          • Ipstenu (Mika Epstein) 7:55 pm on February 24, 2016 Permalink | Log in to Reply

            But isn’t the fullsized not scaled down by WP? If I upload a 3000×2000 image, it doesn’t get processed, it just gets copied.

            Thumbnails, yeah, I totally agree there. Not sure how to get the word out really.

      • Joe McGill 4:20 pm on February 24, 2016 Permalink | Log in to Reply

        Hi Allen,

        While the visual differences will be slight, I agree that we’ll want to let users with strong opinions about this sort of thing know. In fact, that’s the main reason for publicly publishing this proposal in the first place. Besides publishing information on this blog, I’d be curious to know where else you suggest we publicize this information?

        • AllenAyres 4:57 pm on February 24, 2016 Permalink | Log in to Reply

          Thank you Joe.

          To me, it would need to be published in the release notes so that those many photographers (and the developers a good percentage of the photographers pay to develop their site) would know before they update. On some hosts that update automatically it would be good to know what happened to their image quality.

          Again, what may appear slight to some is a huge change to others, and as Ryan mentioned, the resized images would be affected more (I spend a lot of time getting each image looking perfect, all the while optimizing for download speed, upload a 900×600 image, the theme resizes it to something a bit smaller to fit and then generates 1-2 thumbnails to display varying sizes throughout the site – the smaller the image the more compression affects perceived quality).

          Please don’t strip exif data either, our IP is carried in there via copyright notices, etc. I already strip out as much as possible but have seen many photographers track down theft of copyrighted images through the searches of the info they place within the exif.

          For professionals, we work/invest tremendously already to have the image display at its best, balancing that with download speed too, at least allow us a way to undo the changes made.

    • davidshq 2:02 am on February 26, 2016 Permalink | Log in to Reply

      I’m not a huge fan of this idea. I see too much deterioration in image quality. The owl looks great, but I see way too much degradation in numerous images I’ve utilized on sites in the past…

      What I would like to see is something akin to jpegMini’s technology, which reduces file size but maintains perceived image quality.

    • Todd Lahman 2:15 am on March 1, 2016 Permalink | Log in to Reply

      Not sure if this was mentioned, but this should also be applied to the jpeg_quality filter.

    • Mark Howells-Mead 8:42 am on March 31, 2016 Permalink | Log in to Reply

  • Matt Mullenweg 3:28 am on July 13, 2010 Permalink
    Tags: performance   

    Forcing GZIP: http://www.stevesouders.com/blog/2010/07/12/velocity-forcing-gzip-compression/

    This would make an excellent WordPress plugin.

     
    • Justin Shreve 9:38 am on July 13, 2010 Permalink | Log in to Reply

      I gave it a shot. I follow the method totally to spec. It worked on my personal tests but could probably use some additional testing.

      http://justin.wordpress.com/2010/07/13/force-gzip/
      http://justinshreve.com/force-gzip.zip

      Also nice easter egg hidden in the headers!

    • demetris 10:18 am on July 13, 2010 Permalink | Log in to Reply

      For the majority of WP users this is less relevant than we may first think, for a simple reason:

      Most WP users are on shared-hosting, and gzip support in shared-hosting setups is rare. (Really rare!)

      For the rest of the cases, where the server can send gzipped content, I am curious to know what would happen if one sent gzipped content unconditionally, that is, without regard for the Accept-Encoding header and without running any tests first.

      • Milan 11:37 am on July 13, 2010 Permalink | Log in to Reply

        gzip support in shared-hosting setups is rare. (Really rare!)

        What is your source for this? I can’t agree that it is rare. And do we talk about compression via Apache or via PHP?

        I am curious to know what would happen if one sent gzipped content unconditionally, that is, without regard for the Accept-Encoding header and without running any tests first.

        In article it is said that they check for cookies first.

      • Matt 12:39 pm on July 13, 2010 Permalink | Log in to Reply

        You can gzip in PHP with ob_start( 'ob_gzhandler' ).

        • demetris 1:19 pm on July 13, 2010 Permalink | Log in to Reply

          But that’s not a good option, which is why it is not in core anymore.

          Also, that option does nothing for static resources like JS and CSS files, for which great benefits can be expected from gzipping. Two examples: 1. The main CSS of Twenty Ten is 22kB uncompressed and 5kB compressed. 2. The latest, minified jQuery (1.4.2) is 71kB uncompressed and 25kb compressed.

          @Milan

          My source is checks that I do myself from time to time. Last time I checked a large number of hosting companies was in Spring 2009. For an indication, at that time none of the hosts recommended at the wp.org page supported gzip compression in their shared-hosting offerings.

          I would be interested to know if the situation has changed significantly since then, but I am not holding my breath, since that happens for a reason: gzip compression is expensive.

        • Peter Westwood 8:24 pm on July 13, 2010 Permalink | Log in to Reply

          But that’s not a good option, which is why it is not in core anymore.

          Actually it got removed solely becuase it was impossible to tell reliably if compression was already enabled at another level in the web server stack – either in the Web Server or for all php requests.

          That lead to alot of people suffering from double compression when it was enabled.

    • Milan 11:42 am on July 13, 2010 Permalink | Log in to Reply

      It would be excellent if it is made by good programmer, with very lightweight JavaScript and small cookie. And in any case only HTML will be compressed and not for new visits.

      This data shows that minification of CSS and JavaScript files should be more encouraged since it will make some savings when delivered uncompressed.

    • Otto 5:29 pm on July 13, 2010 Permalink | Log in to Reply

      The problem with compressing output to browsers is that you’re really making a tradeoff. Compression uses less bandwidth, but if you’re compressing on the fly then you’re using more CPU time. On shared hosting solutions, CPU time is generally more limited than bandwidth, so compression like this ain’t always a good thing.

      • Peter Westwood 8:26 pm on July 13, 2010 Permalink | Log in to Reply

        Indeed.

        Compression on the fly is only a benefit if your servers are Network I/O bound not CPU bound.

        You often do better to focus on one time compression of the things that you can and good caching of output (which could be compressed once)

        • Matt 9:08 pm on July 13, 2010 Permalink | Log in to Reply

          You’re thinking only from the server side — it’s a benefit from the client side by making things much faster.

        • Otto 9:29 pm on July 13, 2010 Permalink | Log in to Reply

          It’s a diminishing returns problem. Compressing 20k of HTML down to 4k will indeed be faster, but not if it takes you longer to compress than to send 16k down the pipe.

          On the other hand, if you also use a static caching solution to save the compressed stream for serving it up again later, then you can achieve enhancements all around, since you don’t incur a CPU time penalty for compressing every single time.

        • Matt 9:34 pm on July 13, 2010 Permalink | Log in to Reply

          I think you’re vastly overestimating the time it takes to compress something on the fly.

          Time for some ab, but I don’t have an unloaded box handy.

      • Milan 12:15 pm on July 14, 2010 Permalink | Log in to Reply

        @Matt: If anyone does some tests, they should test both Apache and PHP since some people in their articles recommend only PHP without mentioning Apache’s mod_deflate.

    • Matt 12:39 am on July 14, 2010 Permalink | Log in to Reply

      This is a pretty nice tool for testing if Gzip is on, and how much it would save if it was:

      http://www.whatsmyip.org/http_compression/

    • Steve Souders 3:54 pm on July 14, 2010 Permalink | Log in to Reply

      @Matt: It warms my heart to have you evangelizing performance this way. You made my day.

      Compression is nearly always a win if the payload is > 1 kB. My blog post yesterday has a chart ( http://stevesouders.com/images/roundtrips-per-kb.png ) that shows the number of roundtrips required for various payload sizes. Reducing roundtrips, esp. for JS and CSS, makes the page load much faster. Netflix found that turning on gzip compression made pages 13-25% faster ( http://assets.en.oreilly.com/1/event/7/Improving%20Netflix%20Performance%20Presentation.pdf ).

      For static JS and CSS files, it is a challenge if the WP user does not have access to their web server config. One alternative would be to have gzipped versions of these files (main.js.gz) and WP could dynamically determine which static file to include.

    • Robert Jakobson 10:53 am on July 23, 2010 Permalink | Log in to Reply

      Could anyone or the author himself explain and clarify whether CSS, Javascript is getting compressed as well with this plugin or is it only PHP/HTML markup?

      Need an answer quickly.

  • Ryan Boren 6:53 pm on June 18, 2008 Permalink
    Tags: , performance   

    Performance tweaking the hierarchy walke … 

    Performance tweaking the hierarchy walkers and eliminating taxonomy queries with DD32. Category listings are getting faster.

     
  • Ryan Boren 10:36 pm on April 18, 2008 Permalink
    Tags: performance   

    Eliminated a bunch of usermeta queries f … 

    Eliminated a bunch of usermeta queries from the Write Post page.

     
  • Ryan Boren 1:56 am on April 18, 2008 Permalink
    Tags: performance   

    Sped up the main query for the Manage Co … 

    Sped up the main query for the Manage Comments page. Shaved some time from wp_list_categories() and wp_dropdown_categories(). Working on the category dropdowns and checkboxes on the Write Post page next.

     
  • Ryan Boren 12:19 am on April 17, 2008 Permalink
    Tags: performance   

    Consolidated three comment count queries … 

    Consolidated three comment count queries on the Manage Comments page down to one.

     
  • Ryan Boren 6:03 am on April 16, 2008 Permalink
    Tags: performance   

    Eliminated a slow query in the Dashboard … 

    Eliminated a slow query in the Dashboard. Trying to consolidate some other Dashboard queries.

     
  • Ryan Boren 6:01 am on April 16, 2008 Permalink
    Tags: performance   

    Speeding up the Write Post page by loadi … 

    Speeding up the Write Post page by loading the full category list only once the “All Categories” tab is clicked. The much shorter “Most Used” categories list is displayed by default. If you have hundreds or thousands of categories this speeds up page load time nicely.

     
    • Viper007Bond 12:01 pm on April 16, 2008 Permalink | Log in to Reply

      Any way to reverse this via a plugin or something? I don’t have hundreds or thousands of categories and I much prefer the 2.5.0 arrangement.

    • Ryan 7:34 pm on April 17, 2008 Permalink | Log in to Reply

      We ended up reverting this to try another approach.

    • Daniel 7:36 pm on May 25, 2008 Permalink | Log in to Reply

      Sorry to hear about the reversion, this change would have been great from my perspective, what about an option in the settings so the user could choose which of ‘All Categories’ or ‘Most Used’ is displayed by default?

    • Lloyd Budd 10:18 pm on May 26, 2008 Permalink | Log in to Reply

      Daniel, options are bad.

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar