Connect with us

SEO

WordPress Considers Historic Development Change

Published

on

WordPress Considers Historic Development Change

Matt Mullenweg, developer of WordPress and CEO of Autommatic, proposed no longer adding new features to the WordPress, pivoting instead to a plugin-first policy.

This new approach to the future of WordPress has already resulted in a new feature intended for the next version of WordPress to be dropped entirely.

Canonical plugins are said to offer a way to keep improving WordPress on a faster schedule.

But some WordPress core contributors expressed the opinion that publisher user experience may suffer.

Canonical Plugins

First discussed in 2009, canonical plugins is a way to develop new features in the form of plugins.

The goal of this approach is to keep the WordPress core fast and lean while also encouraging development of experimental features in the form of plugins.

The original 2009 proposal described it like this:

“Canonical plugins would be plugins that are community developed (multiple developers, not just one person) and address the most popular functionality requests with superlative execution.

…There would be a very strong relationship between core and these plugins that ensured that a) the plugin code would be secure and the best possible example of coding standards, and b) that new versions of WordPress would be tested against these plugins prior to release to ensure compatibility.”

This approach to features and options is also referred to as Plugin First, to emphasize how features will first appear in the form of plugins.

These plugins are called canonical because they are developed by the WordPress core development team as opposed to non-canonical plugins that are created by third parties that might limit features in order to encourage purchase of a pro-version.

Integration of canonical plugins into the WordPress core itself would be considered once the plugin technology has proven itself to be popular and essential to the majority of users.

The benefit of this new approach to WordPress would be to avoid adding new features that might not be needed by the majority of users.

Plugin-first could be seen to be in keeping with the WordPress philosophy called Decisions, Not Options, which seeks to avoid burdening users with layers of technical options.

By offloading different features and functionalities to plugins, a user won’t have to wade through enabling or disabling functionalities they need, don’t need or don’t understand.

The WordPress design philosophy states:

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

Canonical Plugins the Future?

Matt Mullenweg published a post titled, Canonical Plugins Revisited, in which he made the case that this is the way that WordPress should be developed moving forward.

He wrote:

“We are reaching a point where core needs to be more editorial and say “no” to features coming in as ad hoc as they sometimes do, and my hope is that more Make teams use this as an opportunity to influence the future of WordPress through a plugin-first approach that gives them the luxury of faster development and release cycles (instead of three times per year), less review overhead, and and path to come into core if the plugin becomes a runaway success.”

The first casualty of this new approach is the cancellation of integrating WebP image conversion into the next version of WordPress, WordPress 6.1, currently scheduled for November 2022.

Plugin-First is Controversial

The shift to a plugin-first development process was subjected to debate in the comments section.

Some developers, such as core contributor Jon Brown, expressed reservations about the proposal to switch to developing with canonical plugins.

They commented:

“The problem remains that there are too many complicated plugins standing in for what would be a simple optional feature.

Plugins are _not_ a user-friendly option to core settings. First users have to discover there is a plugin, then they have negotiated yet another settings screen and updates and maintenance of that plugin.”

The commenter used the example of a commenting functionality that is currently served by mutliple bloated plugins as a less than ideal user experience.

They noted that having one canonical plugin to solve a problem is preferable to the current state where desirable options can only be found on bloated third party plugins.

But they also said that having a settings option within core, without the need for a plugin, could present a better user experience.

They continued:

“Now, I do think Canonical plugins are a better situation than 6+ bloated plugins like exist here, but so would a single checkbox added to the settings page in core to do this. Which would further improve the UX and discovery issues inherent in plugins.”

Ultimately, the commenter expressed the idea that the concept of canonical plugins seemed like a way to shut down discussions about features that should be considered, so that the conversation never happens.

“Canonical plugins” seems like a weaponized tool to derail discussions the same way “decisions not options” has become for years.”

That last statement is a reference to frustrations felt by some core contributors with the inability to add options for features because of the “decisions, not options” philosophy.

Others also disagreed with the plugin-first approach:

“Canonical plugin sounds grand but it will further increase maintenance burden on maintainers.

In my opinion, it’s no go.

It will be much more better to include some basic features in core itself instead of further saying – It’s a good place for plugin.”

Someone else pointed out a flaw in plugin-first in that collecting user feedback might not be easy. If that’s the case then there might not be a good way to improve plugins in a way that meets user needs if those needs are unknown.

They wrote:

“How can we better capture feedback from users?

Unless site owners are knowledgeable enough to report issues on GitHub or Trac (let’s be honest, no one reports plugin issues on Trac), there’s really no way to gather feedback from users to improve these recommended/official plugins. “

Canonical Plugins

WordPress development is evolving to make improvements faster. Core contributor comments indicate that there are many unresolved questions on how well this system will work for users.

An early indicator will be in what happens with the cancelled WebP feature that was previously intended to be integrated into the core and will now become a plugin.


Featured image by Shutterstock/Studio Romantic

Source link

SEO

How To Optimize The Largest Contentful Paint & Rank Higher

Published

on

How To Optimize The Largest Contentful Paint & Rank Higher

How To Measure The Largest Contentful Paint Of Your Website

Run a free website speed test to find out. Your LCP speed will be displayed immediately.

The results of your speed test will tell you if:

  • The LCP threshold is met.
  • You need to optimize any other Core Web Vital.

How Is The Largest Contentful Paint Calculated?

Google looks at the 75th percentile of experiences – that means 25% of real website visitors experience LCP load times of 3.09 seconds or higher, while for 75% of users the LCP is below 3.09 seconds.

In this example, the real-user LCP is shown as 3.09 seconds.

Screenshot of a Core Web Vitals data of DebugBear.com, November 2022

What Are The Lab Test Results On My Core Web Vitals Data?

With this specific web speed test, you’ll also see lab metrics that were collected in a controlled test environment. While these metrics don’t directly impact Google rankings, there are two advantages of this data:

  1. The metrics update as soon as you improve your website, while Google’s real-time data will take 28 days to fully update.
  2. You get detailed reports in addition to the metrics, which can help you optimize your website.

Additionally, PageSpeed Insights also provides lab data, but keep in mind that the data it reports can sometimes be misleading due to the simulated throttling it uses to emulate a slower network connection.

How Do You Find Your Largest Contentful Paint Element?

When you run a page speed test with DebugBear, the LCP element is highlighted in the test result.

Sometimes, the LCP element may be a large image, and other times, it could be a large portion of text.

Regardless of whether your LCP element is an image or a piece of text, the LCP content won’t appear until your page starts rendering.

For example, on the page below, a background image is responsible for the largest paint.

How To Optimize The Largest Contentful Paint & Rank Higher In GoogleScreenshot of DebugBear.com, November 2022

In contrast, this page’s LCP is a paragraph of text.

How To Optimize The Largest Contentful Paint & Rank Higher In GoogleScreenshot of DebugBear.com, November 2022

To improve the Largest Contentful Paint (LCP) of your website you need to ensure that the HTML element responsible for the LCP appears quickly.

How To Improve The Largest Contentful Paint

To improve the LCP you need to:

  1. Find out what resources are necessary to make the LCP element appear.
  2. See how you can load those resources faster (or not at all).

For example, if the LCP element is a photo, you could reduce the file size of the image.

After running a DebugBear speed test, you can click on each performance metric to view more information on how it could be optimized.

How To Optimize The Largest Contentful Paint & Rank Higher In GoogleScreenshot of a detailed Largest Contentful Paint analysis in DebugBear.com, November 2022

Common resources that affect the LCP are:

  • Render-blocking resources.
  • Images that are not optimized.
  • Outdated image formats.
  • Fonts that are not optimized.

How To Reduce Render-Blocking Resources

Render-blocking resources are files that need to be downloaded before the browser can start drawing page content on the screen. CSS stylesheets are typically render-blocking, as are many script tags.

To reduce the performance impact of render-blocking resources you can:

  1. Identify what resources are render-blocking.
  2. Review if the resource is necessary.
  3. Review if the resource needs to block rendering.
  4. See if the resource can be loaded more quickly up, for example using compression.

The Easy Way: In the DebugBear request waterfall, requests for render-blocking resources are marked with a “Blocking” tag.

How To Optimize The Largest Contentful Paint & Rank Higher In GoogleScreenshot of DebugBear.com, November 2022

How To Prioritize & Speed Up LCP Image Requests

For this section, we’re going to leverage the new “fetchpriority” attribute on images to help your visitor’s browsers quickly identify what image should load first.

Use this attribute on your LCP element.

Why?

When just looking at the HTML, browsers often can’t immediately tell what images are important. One image might end up being a large background image, while another one might be a small part of the website footer.

Accordingly, all images are initially considered low priority, until the page has been rendered and the browser knows where the image appears.

However, that can mean that the browser only starts downloading the LCP image fairly late.

The new Priority Hints web standard allows website owners to provide more information to help browsers prioritize images and other resources.

In the example below, we can see that the browser spends a lot of time waiting, as indicated by the gray bar.

How To Optimize The Largest Contentful Paint & Rank Higher In GoogleScreenshot of a low-priority LCP image on DebugBear.com, November 2022

We would choose this LCP image to add the “fetchpriority” attribute to.

How To Add The “FetchPriority” Attribute To Images

Simply adding the fetchpriority=”high” attribute to an HTML img tag will the browser will prioritize downloading that image as quickly as possible.

<img src="https://www.searchenginejournal.com/optimize-largest-contentful-paint-debugbear-spcs/471883/photo.jpg" fetchpriority="high" />

How To Use Modern Image Formats & Size Images Appropriately

High-resolution images can often have a large file size, which means they take a long time to download.

In the speed test result below you can see that by looking at the dark blue shaded areas. Each line indicates a chunk of the image arriving in the browser.

How To Optimize The Largest Contentful Paint &#038; Rank Higher In GoogleScreenshot of a large LCP image on DebugBear.com, November 2022

There are two approaches to reducing image sizes:

  1. Ensure the image resolution is as low as possible. Consider serving images at different resolutions depending on the size of the user’s device.
  2. Use a modern image format like WebP, which can store images of the same quality at a lower file size.

How To Optimize Font Loading Times

If the LCP element is an HTML heading or paragraph, then it’s important to load the font for this chunk of text quickly.

One way to achieve this would be to use preload tags that can tell the browser to load the fonts early.

The font-display: swap CSS rule can also ensure sped-up rendering, as the browser will immediately render the text with a default font before switching to the web font later on.

How To Optimize The Largest Contentful Paint &#038; Rank Higher In GoogleScreenshot of web fonts delaying the LCP on DebugBear.com, November 2022

Monitor Your Website To Keep The LCP Fast

Continuously monitoring your website not only lets you verify that your LCP optimizations are working, but also makes sure you get alerted if your LCP gets worse.

DebugBear can monitor the Core Web Vitals and other site speed metrics over time. In addition to running in-depth lab-based tests, the product also keeps track of the real-user metrics from Google.

Try DebugBear with a free 14-day trial.

How To Optimize The Largest Contentful Paint &#038; Rank Higher In GoogleScreenshot of site speed monitoring data on DebugBear.com, November 2022



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