Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prepare PL 3.8 Release #1796

Open
4 of 5 tasks
felixarntz opened this issue Jan 13, 2025 · 8 comments
Open
4 of 5 tasks

Prepare PL 3.8 Release #1796

felixarntz opened this issue Jan 13, 2025 · 8 comments
Assignees
Labels
[Plugin] Performance Lab Issue relates to work in the Performance Lab Plugin only

Comments

@felixarntz
Copy link
Member

felixarntz commented Jan 13, 2025

This issue is to track preparation of the upcoming 3.8.0 release up until publishing, which is due January 27, 2025.

  • Create release/3.8.0 branch closer to the release date
  • Finalize scope and punt unfinished pull requests to following release (Thursday, January 23, 2025)
  • Bump versions in milestones according to the scope (Thursday, January 23, 2025)
  • Smoke test (Friday, January 24, 2025)
  • Prepare the release (Monday, January 27, 2025)

Note: The release would normally happen on Monday January 20, but due to a US holiday several folks from the team that handle the releases are out, which is why the release is postponed to the day after.

Update: Due the holiday and the fact that several milestones are not yet cleared, the release has been postponed to the following Monday.

@felixarntz felixarntz added the [Plugin] Performance Lab Issue relates to work in the Performance Lab Plugin only label Jan 13, 2025
@felixarntz felixarntz added this to the performance-lab 3.8.0 milestone Jan 13, 2025
@github-project-automation github-project-automation bot moved this to Not Started/Backlog 📆 in WP Performance 2024 Jan 13, 2025
@westonruter
Copy link
Member

Release branch has been created: https://github.com/WordPress/performance/tree/release/3.8.0

@westonruter
Copy link
Member

Preparation PR: #1827

@westonruter
Copy link
Member

Performance Lab testing

  • Add Site Health check for Cache-Control: no-store page response header which disables bfcache. (1807)

See #1825 for an issue I found which I've submitted a fix for in #1826. With that fix present, when no Cache-Control: no-store is present, I get the following test:

Image

But when I add a plugin that does:

<?php
/**
 * Plugin Name: No-Store
 */

add_action(
	'send_headers',
	function () {
		header( 'Cache-Control: no-store' );
	}
);

Then I get as expected:

Image

  • Add Site Health test to verify that static assets are served with far-future expires. (1727)

Testing a site with LocalWP which does not have a far-future expires header results in the expected site health test:

Image

  • Enqueue scripts using plugins_url() instead of plugin_dir_url(). (1761)

The includes/admin/plugin-activate-ajax.js script is added to the Performance screen as expected.

@westonruter
Copy link
Member

westonruter commented Jan 25, 2025

Modern Image Formats testing

  • Switch to wp_content_img_tag filter for improved image handling. (1772)

Upon uploading an image, I was able to see AVIF file served on the frontend:

<figure class="wp-block-image size-large">
  <img
    fetchpriority="high"
    decoding="async"
    width="1024"
    height="668"
    src="http://localhost:10043/wp-content/uploads/2025/01/bison1-1024x668.avif"
    alt=""
    class="wp-image-10"
    srcset="
      http://localhost:10043/wp-content/uploads/2025/01/bison1-1024x668.avif  1024w,
      http://localhost:10043/wp-content/uploads/2025/01/bison1-300x196.avif    300w,
      http://localhost:10043/wp-content/uploads/2025/01/bison1-768x501.avif    768w,
      http://localhost:10043/wp-content/uploads/2025/01/bison1-1536x1002.avif 1536w,
      http://localhost:10043/wp-content/uploads/2025/01/bison1-2048x1336.avif 2048w
    "
    sizes="(max-width: 1024px) 100vw, 1024px"
  />
</figure>

@westonruter
Copy link
Member

Speculative Loading testing

  • Implement speculative loading considerations for safer behavior. (1784)

The speculationrules script is now omitted when logged-in. When logged-out, it is included and works as expected. When a link includes a query var, it is not speculatively loaded.

@westonruter
Copy link
Member

Embed Optimizer testing

  • Remove requirement for both mobile and desktop URL metrics to be collected for preconnect links to be added. (1764)

I added a YouTube video to the top of a post and visited the frontend on desktop to trigger collection of a URL Metric. Upon reloading, I then saw the page include the preconnect links just for desktop as expected:

<link data-od-added-tag rel="preconnect" href="https://i.ytimg.com/" media="(min-width: 783px)">
<link data-od-added-tag rel="preconnect" href="https://www.youtube.com/" media="(min-width: 783px)">

@westonruter
Copy link
Member

Image Prioritizer testing

  • Remove erroneous check for resource initiator type when considering whether to submit LCP background image. (1760)

I activated Twenty Thirteen and visited the homepage on desktop where the header (with a background-image) is the LCP element. This resulted in the expected lcpElementExternalBackgroundImage in the submitted URL Metric:

Image

@westonruter
Copy link
Member

westonruter commented Jan 26, 2025

Optimization Detective testing

  • Omit element node index in XPaths up to children of BODY. (1790)
  • Disambiguate XPaths for children of BODY with id, class, or role attributes. (1797)

With existing URL Metrics already collected which reference a YouTube embed at:

/*[1][self::HTML]/*[2][self::BODY]/*[1][self::DIV]/*[2][self::DIV]/*[1][self::DIV]/*[1][self::DIV]/*[1][self::ARTICLE]/*[2][self::DIV]/*[1][self::FIGURE]/*[1][self::DIV]

The optimizations still apply to add the preconnect link from #1796 (comment), even though the FIGURE now has the XPath:

/HTML/BODY/DIV[@id='page']/*[2][self::DIV]/*[1][self::DIV]/*[1][self::DIV]/*[1][self::ARTICLE]/*[2][self::DIV]/*[1][self::FIGURE]/*[1][self::DIV]
  • Eliminate varying URL Metrics by logged-in state and discontinue disabling optimization by default for admins. (1788)

I visited a page while being logged-in as an administrator and a URL Metric was collected. Additionally, when looking at the collected URL Metrics there is now only one post type for a given URL whereas before there would be two, one for unauthenticated visitors and another for authenticated ones.

  • Add site health check to detect blocked REST API and short-circuit optimization when unavailable. (1762)

On a LocalWP site which has loopback request support, the Site Health test shows the expected result:

Image

When I activate the Disable WP REST API plugin, I get:

Image

And the expected warning appears in the plugin list table:

Image

Image

Optimizations are disabled on the frontend when this is the case and WP_ENVIRONMENT_TYPE is not local.

  • Allow extensions to opt in to using the web-vitals attribution build via the od_use_web_vitals_attribution_build filter. (1759)

When loading the page I see the non-attribution build of web-vitals loaded by default:

"webVitalsLibrarySrc":"http:\/\/localhost:10043\/wp-content\/plugins\/optimization-detective\/build\/web-vitals.js?ver=4.2.4"

When I activate a plugin that does this:

add_filter( 'od_use_web_vitals_attribution_build', '__return_true' );

Then the page output changes as expected:

"webVitalsLibrarySrc":"http:\/\/localhost:10043\/wp-content\/plugins\/optimization-detective\/build\/web-vitals-attribution.js?ver=4.2.4"

And URL Metrics are collected as expected.

  • Skip visiting tags in the Admin Bar when optimizing a page. (1816)

While being logged-in and the Image Prioritizer plugin is active, I do not seen any items from the admin bar in the collected URL Metric:

{
    "url": "http://localhost:10043/modern-image/",
    "viewport": {
        "width": 3201,
        "height": 1632
    },
    "elements": [
        {
            "isLCP": false,
            "isLCPCandidate": false,
            "xpath": "/HTML/BODY/DIV[@id='page']/*[2][self::DIV]/*[1][self::DIV]/*[1][self::DIV]/*[1][self::ARTICLE]/*[2][self::DIV]/*[1][self::FIGURE]/*[1][self::IMG]",
            "intersectionRatio": 1,
            "intersectionRect": {
                "x": 1140.4166259765625,
                "y": 465.36456298828125,
                "width": 604.0103759765625,
                "height": 394.01040649414062,
                "top": 465.36456298828125,
                "right": 1744.427001953125,
                "bottom": 859.37496948242188,
                "left": 1140.4166259765625
            },
            "boundingClientRect": {
                "x": 1140.4166259765625,
                "y": 465.36456298828125,
                "width": 604.0103759765625,
                "height": 394.01040649414062,
                "top": 465.36456298828125,
                "right": 1744.427001953125,
                "bottom": 859.37496948242188,
                "left": 1140.4166259765625
            }
        }
    ],
    "lcpElementExternalBackgroundImage": {
        "url": "http://localhost:10043/wp-content/themes/twentythirteen/images/headers/circle.png",
        "tag": "HEADER",
        "id": "masthead",
        "class": "site-header"
    },
    "timestamp": 1737855427.484776,
    "uuid": "70296c9f-780a-4ba7-b7d7-f183def683a4",
    "etag": "461f62c29dd8c1b925a0ee5a2b14ce7b"
}
  • Ensure optimization is performed in the wp-env local environment and log debug messages to console when disabled. (1822)

When accessing a search results page and I have WP_DEBUG enabled, I see the console include the expected message:

[Optimization Detective] Page is not optimized because od_can_optimize_response() returned false. This can be overridden with the od_can_optimize_response filter.
  • Skip visiting any tags inside of NOSCRIPT elements. (1783)

I added a NOSCRIPT tag with a nested IMG tag to a Custom HTML block. This IMG did not get a data-od-xpath attribute added to it, while a previous IMG in an Image block did get the attribute as expected.

  • Introduce OD_Tag_Visitor_Context::track_tag() method as alternative for returning true in tag visitor callback. (1821)

I installed the Intrinsic Dimensions plugin with the westonruter/od-intrinsic-dimensions#1 PR checked out that leverages track_tag and it resulted in the expected data being added to the VIDEO tag in the submitted URL Metric:

Image

It also resulted in the expected attributes being added to the VIDEO tag:

<video
  data-od-added-height
  data-od-added-style
  data-od-added-width
  data-od-intrinsic-dimensions-src-hash="4fb7e0d643f1bf97dd7ac7ac4772a7cc"
  data-od-xpath="/HTML/BODY/DIV[@id='page']/*[2][self::DIV]/*[1][self::DIV]/*[1][self::DIV]/*[1][self::ARTICLE]/*[2][self::DIV]/*[1][self::FIGURE]/*[1][self::VIDEO]"
  height="1920"
  style="height: auto; width: 100%; aspect-ratio: 1080 / 1920"
  width="1080"
  controls
  src="http://localhost:10043/wp-content/uploads/2025/01/goat-18139442-hd_1080_1920_30fps.mp4"
></video>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Plugin] Performance Lab Issue relates to work in the Performance Lab Plugin only
Projects
Status: Not Started/Backlog 📆
Development

No branches or pull requests

2 participants