Enhancing image preview: core proposal

For many years search engine results have shown various images size publicly made available by site owners. Last year (September 2019), some extra controls over the content preview was introduced to Google Search followed by Bing who announced similar capabilities for their Search Engine earlier this year (April 2020).

In practice, this means that many sites do not get the benefit of large image previews, and may be losing out on traffic. Today, WordPress sites do not opt-in to large image previews by default even when “Search Engine Visibility” setting is turned on.

Below is an example comparison of Discover content for small image preview vs large image preview:

Proposed Solution 

This proposal is to opt-in to large image previews by default when “Search Engine Visibility” setting is turned on allowing search engines to display large images resulting in an enhanced user experience and CTR (click-through rate).

Theoretically, this is as simple as conditionally injecting <meta name="robots" content="max-image-preview:large"> in the HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. head of all pages.

WordPress may already inject a “robots” metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) into a page, for example when a site is set to disallow search engines from indexing it. To facilitate large image previews as well as exposing a central management layer for the “robots” meta tag, a new function wp_robots() should be introduced. The function would include a filterable list of values to include in the “robots” meta tag and render the meta tag only if necessary. Having this centralized layer will streamline robots management and interoperability between plugins.

By default, the list would cover the following values:

  • noindex, to be included when search engines are disallowed from indexing the page or due to certain other circumstances
  • nofollow, to be included when noindex is provided when search engines are disallowed from indexing the page
  • follow, to be included when noindex is provided due to certain other circumstances
  • max-image-preview: large, to be included when search engines are allowed to index the page, and when large preview images may be used for the page

This would only be the default behavior and could be expanded or modified by plugins, for example to add additional robots tag directives.

The function would be hooked into wp_head and other relevant actions, and it would essentially supersede the existing noindex() and wp_no_robots() functions.

What’s next?

Your thoughts on this proposal would be greatly valued. Please share your feedback, questions or interest in collaboration by commenting on this post. After that we can create a tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. and kick start development.

#images, #proposal, #seo

Media Weekly Update (Oct 7)

This post serves to jump-start discussion before the weekly check in, which takes place in #core-images on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. The next meeting is Friday, October 14 at 17:00 UTC and agenda for these meetings includes moving priority tasks forward, providing feedback on issues of interest, and reviewing media focused tickets on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..

Summary from last week

The last meeting was Friday, October 7 at 17:00 UTC. You can read the entire chat log in the #core-images channel on Slack.

Attendees: @karmatosed, @joemcgill, @mikeschroder, @swissspidy, @flixos90, @desrosj, @azaozz, @paaljoachim, @markoheijnen, @adamsilverstein, @jorbin, @designsimply

  • Media organization improvements:
    • @joemcgill opened up conversation about a feature project to start work on this, explaining that we have the chance to take a UIUI User interface/UXUX User experience first approach.
    • @karmatosed is going to head up the UI/UX side of things.
    • @joemcgill thinks the likely first step is exploration of base taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. support, and a review on how it is currently broken with media.
    • @karmatosed asked all those interested in working on this to create sketches of their ideal media categorization flow for review by next week.
  • Add new coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. media widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. (#32417)@joemcgill noted that the runway for 4.7 is ending, but work can continue for a future release. @designsimply to refresh the current patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. on the ticketticket Created for both bug reports and feature development on the bug tracker. by Monday (October 10), and may target images specifically as a first step (this is still missing a refreshed patch).
  • Rotate Full Size Images on Upload (#14459)@mikeschroder profiled this and found that while the clock time for checking and setting orientation is minimal, it took ~230ms for an iPhone 7-sized image to be rotated (total 5.6s resize time) on a shared test server. He thinks total resize time should be reduced before this is added, and that #37140 is a better step for 4.7. After discussion with @markoheijnen and @azaozz, consensus seems to be that benchmarking of upload vs manual rotation should be done to prove the UX case for #37140 over #14459.
  • Accents in attachment filenames should be sanitized (#22363)@joemcgill pointed out the new patch here from @gitlost, which looks promising. @swissspidy to take a look over the weekend (feedback is on ticket now, but could use more eyes).
  • Better PDF Upload Management (#31050) – Everyone likes this, but time running out for 4.6. @markoheijnen to target next patch by Wednesday (Oct 12) (this was moved out of the milestone, as it’s currently missing a refreshed patch).
  • Responsive images (srcset) can include images larger than the full size (#36477)@mikeschroder didn’t have time to performance test the patch. To do so shortly and post feedback on the ticket (feedback is on ticket now).

Agenda for the next meeting

This week, discussion will continue on priority projects for the 4.7 release. If you have specific tickets that you want to have discussed, feel free to leave a comment on this post or reach out on Slack in the #core-images channel.

Edit: Updated post per status on Wednesday, Oct 12.

#4-7, #images, #media

Media Weekly Update (Sept 30)

This post serves to jump-start discussion before the weekly check in, which takes place in #core-images on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. The next meeting is Friday, October 7 at 17:00 UTC and agenda for these meetings includes moving priority tasks forward, providing feedback on issues of interest, and reviewing media focused tickets on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..

Summary from last week

The last meeting was Friday, September 30 at 17:00 UTC. You can read the entire chat log in the #core-images channel on Slack.

Attendees: @joemcgill, @mikeschroder, @swissspidy, @flixos90, @azaozz

  • Unexpected change to media title behavior in WP 4.6.1 (#37989)@joemcgill noted that @sergey found a fix for the remaining UTF-8 issues and it has been committed to trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision., but needs to be backported still. @joemcgill working on getting this done. Test please!
  • Downscale to only smaller images with srcset (#36477) – It looks like a true fix is not likely to land in 4.7, since this would have likely been part of changing the way WordPress handles full size images. @mikeschroder and @joemcgill to test the current patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. for performance and SSIM.
  • Better PDF thumbnails (#31050)@markoheijnen was not able to attend, but previously noted that he is continuing work on this for a week or two to try to make 4.7.
  • WordPress image’s title is not alt (#34635)@joemcgill chatted with the AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) team about this, and the suggestion is that WordPress should no longer guess at an appropriate alt if the user hasn’t explicitly added one. He notes that this shouldn’t be that difficult to patch, but the change will need to be well communicated.
  • image_send_to_editor filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. is not fired when an Image is edited or replaced in TinyMCE (#34823) – Based on @adamsilverstein‘s feedback, it looks like the ticketticket Created for both bug reports and feature development on the bug tracker. should be closed, as there’s a different filter intended for this purpose.
  • Usage of image_size_names_choose breaks JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. attachment model attributes (#34981) – Chatted about a bit of background. @azaozz took a look and posted a new patch for review.
  • Sanitize accents in attachment filenames (#22363) – From @gitlost’s comments, it looks like there are fixes in remove_accents() necessary that should happen first, and would likely fix the base bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. here. His work on it is mostly in #24661. @mikeschroder to dig into the progress of Safari’s support of these filenames. Feedback from those who have strong knowledge in UTF/character encodings would be appreciated.
  • Rotate Full Size Images on Upload (#14459 and #37140) – Would rather not destroy EXIF/IPTC in full size images (with GD), so may be better to fix this in Imagick first. Needs performance testing. Comment left on ticket.
  • Add new coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. media widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. (#32417) – No updates here. May not be 4.7 at this point, but @joemcgill reaching out to @designsimply for status.
  • Media organization improvements:
    • Make media library searchable by filename (#22744) – @joemcgill added a patch to fix a JOIN issue found by @flixos90. Please continue testing this, especially with large media libraries.
    • @flixos90 opened a GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ repo to work on media taxonomies/UIUI User interface, and is organizing a feature project around it. @joemcgill suggests an initial meeting with @karmatosed for high level direction, followed by changes in the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, or core directly where appropriate.

Agenda for the next meeting

This week, discussion will continue on priority projects for the 4.7 release. If you have specific tickets that you want to have discussed, feel free to leave a comment on this post or reach out on Slack in the #core-images channel.

#4-7, #images, #media

Media Chat

In the regular #core-images chat this Friday, 15 April, 19:00 UTC we are planning to discuss enhancements for 4.6. So far there are four items on the agenda:

  • We are planning to add responsive images to the editor and discuss different implementation methods, e.g. saving srcset and sizes attributes to the database versus generating them on the front end. See #36475.
  • The makers of TinyMCE recently released JavaScript image tools for editing images in the browser which could replace the current server based image editor. The new editor would be quite faster, allowing you to edit and resize images before uploading them, and it would be easier to include in other scripts. This may well be a feature project over a few releases.
  • PDF preview images. See #31050.
  • Continue to improve mixed content issues on HTTPSHTTPS HTTPS is an acronym for Hyper Text Transfer Protocol Secure. HTTPS is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted. This is especially helpful for protecting sensitive data like banking information. sites. See #34945.

If you have more ideas or tickets to discuss regarding media, please join us or leave a comment here. 🙂

#4-6, #image-editor, #images, #media, #respimg

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 filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output..

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)

#4-5, #dev-notes, #images, #media, #optimization, #performance

Proposal: Increase the default image compression in WordPress

Note: This proposal was merged to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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.

#image-editor, #images, #media, #performance

Image header cropping now uses Jcrop.

Image headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. cropping now uses Jcrop.

#images, #javascript