Connect with us

SEO

WordPress Reconsiders WebP By Default Proposal

Published

on

WordPress Reconsiders WebP By Default Proposal


WordPress announced that it is reconsidering its proposal to roll out automatic WebP image generation because of the passionate opposition received for the new feature. The announcement noted that they will formally research the suggestions put forth by the WordPress community in order to make a better decision for the next steps.

Enabling WebP by Default

WordPress initially announced a proposal for adding a feature that would automatically generate multiple versions of every image used on a website as well as WebP versions of those images.

The purpose of the new feature was to make it easy for publishers to upload images to WordPress and allow WordPress to output optimized WebP versions. The new WebP format would help reduce file size and increase the performance of every WordPress website.

Concerns quickly arose about the new WebP feature because many determined that some sites would quickly run out of disk space for archiving as much as a million additional images.

Some in the WordPress ecosystem suggested that the feature not be shipped as an automatically turned on feature. They said it would be preferable for the feature to be turned off by default.

Clash With WordPress Design Goals

The suggestion of shipping the new WebP feature in a default off state ran counter to the WordPress philosophy known as Decisions, not Options, which is a design goal of shipping product that works out of the box with minimal configuration.

WordPress outlines five major design goals in their formal philosophical statement

Advertisement

They are paraphrased below:

  1. Functional Out of the Box
  2. Designed for the Majority of Users
  3. Decisions, Not Options (Developers Make Decisions on Behalf of Users)
  4. WordPress Core Features Must be Needed by 80% of Users
  5. Simplify All Tasks

The Decisions, Not Options philosophy was specifically cited by WordPress to justify making the WebP feature default to “on” and to not ship with a user interface for turning it off.

This is what that design philosophy states:

“When making decisions these are the users we consider first. A great example of this consideration is software options.

Every time you give a user an option, you are asking them to make a decision. When a user doesn’t care or understand the option this ultimately leads to frustration.

As developers we sometimes feel that providing options for everything is a good thing, you can never have too many choices, right? Ultimately these choices end up being technical ones, choices that the average end user has no interest in.

It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.”

The prospect of shipping a disruptive feature with no easy way to turn it off set off alarm bells throughout the WordPress ecosystem.

Adam Silverstein, the Google software developer who works on WordPress is the one who cited the Decisions, Not Options goal for the new WebP functionality that was announced on March 28, 2022 (Enabling WebP by Default).

The tenet states that it’s better for the developers to make the decisions about options on behalf of users because creating a product with multiple options is burdensome.

Advertisement

That design goal fits into the overall philosophy of making every WordPress installation work out of the box and be functional for the majority of users.

Opposition from the WordPress Community

In an exceptionally passionate comment section to the proposal, the majority of commenters were alarmed by the possibility of publishers running out of the disk space and experiencing non-functional websites at worst and significantly higher expenses due to having to purchase more disk space from their web host.

WordPress Announces it is Reassessing WebP Feature Deployment

In today’s announcement Adam Silverstein, the WordPress core developer, acknowledged the concerns of the WordPress community and pledged that the next step would be to reaasses the proposal and return with more agreeable options.

He wrote:

“The performance team has heard the feedback and takes the community’s concerns seriously.

With the help of the community, we will work on conducting additional data-driven research. Based on our findings, we will reassess our proposed approach to enabling WebP by default.”

The statement said that they would be researching the disk storage impact from creating additional WebP images and a separate concern regarding compatibility of WebP with other functions such as email clients, RSS readers and lazy loading.

The GitHub repository for researching the impact of the WebP feature on disk storage states:

“This issue is for research and analysis related to the concern about the new Enabling WebP by default feature creating too many files.

Many users were concerned about the proposed doubling of the number of image files resulting in increased hosting costs, running out of disk space (or “inodes”), or failed backup.”

Advertisement

After the above research is finished, WordPress pledged to reassess having the WebP feature on or off by default as well as to consider a user interface that will make it easy to turn the feature on or off.

WordPress Community Response

The WordPress community greeted the news of these with overwhelmingly positive comments.

A typical comment:

“Thanks for the update @adamsilverstein, as always you’ve handled the feedback from the prior post most graciously and I look forward to what the Performance team learns in this additional testing and research and appreciate all the efforts to ensure WordPress is forward-thinking and competitive in the CMS space.”

Overall it looks like the WordPress ecosystem worked fantastically to reach a good decision to reassess the impact of the WebP proposal and to not rush hastily into a decision that might have had a detrimental impact on publishers.

Citation

Read the Official WordPress Announcement

Follow-up on WebP by Default Proposal

fbq('init', '1321385257908563');

fbq('track', 'PageView');

fbq('trackSingle', '1321385257908563', 'ViewContent', { content_name: 'wordpress-reconsiders-webp-by-default-proposal', content_category: 'news wp ' });





Source link

SEO

Google On How To Simplify Hreflang Implementation

Published

on

Google On How To Simplify Hreflang Implementation

Google’s Search Advocate John Mueller says hreflang implementation doesn’t have to be as complicated as people think.

Hreflang is one of the more confusing aspects of technical SEO and among the most important for international businesses and publishers.

In reply to a thread on Reddit, Mueller outlines a simplified approach for publishers to follow.

Hreflang: The Problem

Hreflang is a link attribute that informs Google of the language used on a page. With that information, Google can show the page version corresponding to the language a person is searching in.

Without the hreflang attribute, Google may serve pages in a language the searcher doesn’t speak or pages specific to a country the searcher doesn’t reside.

In the r/TechSEO forum on Reddit, a user is seeking advice regarding the use of hreflang for websites in multiple countries.

They ask if they can get by with a partial implementation of hreflang. For example, they are setting up hreflang for versions of the website in the same language, such as Germany and Switzerland.

Advertisement

The alternative is linking all versions of all pages with hreflang, which is a considerable amount of work.

Mueller says that’s the best solution, but not exactly practical:

“In an idea [sic] world, you’d link all versions of all pages with hreflang. It would be the clean approach, however, sometimes it’s just a ton of work, and maintaining it if the sites are run individually is … good luck with that.”

Although linking every page with hreflang is the ideal solution, Mueller says it doesn’t have to be so complicated.

Hreflang: The Solution

First, Mueller suggests figuring out what needs fixing.

Identify whether a problem exists with searchers landing on the wrong site version.

If that isn’t happening, you may not need to implement hreflang.

Mueller states:

“In practice, you can simplify the problem. Where do you actually see issues with regards to people coming to the wrong country / language site? That’s where you should minimally implement hreflang (and, of course, a JS country/language recognizer / popupper to catch any direct visits). Probably a lot of that will be limited to same-language / different-country situations, so Switzerland / Germany in German may be the right place to start. Nothing breaks if you set up hreflang for 2 versions and have 4 unrelated versions.

If you already have these sites running, I’d check your analytics setup for traffic from Search, and compare the country where they come from vs the country that they end up on (pick one country, filter for the traffic from search, and compare the domains they end up on). If you don’t find a big mismatch there, most likely you don’t need to do a lot (or anything) for hreflang. There is no bonus for hreflang, it’s only about showing the most-fitting page in search for users in a specific country / language.”

Advertisement

Next, look at which pages searchers are landing on. One of the most likely mistakes Google can make is serving the wrong version of a website’s homepage.

Since brand names aren’t localized, Google doesn’t always know which version of a homepage to serve if that’s all a user types into the search box.

If you find searchers are landing on the wrong homepage, but there are no issues with other pages, you can get by with a partial implementation of hreflang.

Mueller states:

“When checking, focus on the most likely mistakes first: same-language / different-country sites is one, but there’s also homepage traffic. Often times a brand name is not localized, so when people search for it, it’s unclear to search engines what the expectation is. If you find a lot of mismatches on the homepage but not elsewhere in the site, you can also just do hreflang across the homepages (that’s often easier than all pages in a site). Or you could do a combination, of course, all homepages + all German-language pages. Hreflang is on a per-page basis, so the beauty (and curse) is that you can pick & choose.”

Lastly, Mueller reiterates that it’s possible to save a lot of time with hreflang by checking to see if there’s a genuine problem.

Google may serve the correct versions of pages all on its own, in which case you don’t gain anything by adding hreflang.

“In any case, before you rush off and work on this for a year, double-check that it’s an actual problem first, and if so, check where the problem is. Maybe there are super-simple solutions (maybe you just need a country/language popup and don’t even need the rest?), and you can spend your time more wisely elsewhere.”

Think of hreflang as a tool to utilize when needed. You can prioritize other tasks if there’s no need for it.


Source: Reddit

Advertisement

Featured Image: patpitchaya/Shutterstock

fbq('track', 'PageView');

fbq('trackSingle', '1321385257908563', 'ViewContent', { content_name: 'google-on-how-to-simplify-hreflang-implementation', content_category: 'news seo' }); } });



Source link

Continue Reading

DON'T MISS ANY IMPORTANT NEWS!
Subscribe To our Newsletter
We promise not to spam you. Unsubscribe at any time.
Invalid email address

Trending

en_USEnglish