You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
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.
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:
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:
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:
When I activate the Disable WP REST API plugin, I get:
And the expected warning appears in the plugin list table:
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:
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)
Activity
westonruter commentedon Jan 24, 2025
Release branch has been created: https://github.com/WordPress/performance/tree/release/3.8.0
westonruter commentedon Jan 25, 2025
Preparation PR: #1827
westonruter commentedon Jan 25, 2025
Performance Lab testing
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-storeis present, I get the following test:But when I add a plugin that does:
Then I get as expected:
Testing a site with LocalWP which does not have a far-future expires header results in the expected site health test:
The
includes/admin/plugin-activate-ajax.jsscript is added to the Performance screen as expected.westonruter commentedon Jan 25, 2025
Modern Image Formats testing
Upon uploading an image, I was able to see AVIF file served on the frontend:
westonruter commentedon Jan 25, 2025
Speculative Loading testing
The
speculationrulesscript 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 commentedon Jan 26, 2025
Embed Optimizer testing
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
preconnectlinks just for desktop as expected:westonruter commentedon Jan 26, 2025
Image Prioritizer testing
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 expectedlcpElementExternalBackgroundImagein the submitted URL Metric:westonruter commentedon Jan 26, 2025
Optimization Detective testing
With existing URL Metrics already collected which reference a YouTube embed at:
The optimizations still apply to add the
preconnectlink from #1796 (comment), even though theFIGUREnow has the XPath: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.
On a LocalWP site which has loopback request support, the Site Health test shows the expected result:
When I activate the Disable WP REST API plugin, I get:
And the expected warning appears in the plugin list table:
Optimizations are disabled on the frontend when this is the case and
WP_ENVIRONMENT_TYPEis notlocal.When loading the page I see the non-attribution build of web-vitals loaded by default:
When I activate a plugin that does this:
Then the page output changes as expected:
And URL Metrics are collected as expected.
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" }When accessing a search results page and I have
WP_DEBUGenabled, I see the console include the expected message:I added a
NOSCRIPTtag with a nestedIMGtag to a Custom HTML block. ThisIMGdid not get adata-od-xpathattribute added to it, while a previousIMGin an Image block did get the attribute as expected.I installed the Intrinsic Dimensions plugin with the westonruter/od-intrinsic-dimensions#1 PR checked out that leverages
track_tagand it resulted in the expected data being added to theVIDEOtag in the submitted URL Metric:It also resulted in the expected attributes being added to the
VIDEOtag: