Add performance.mark for next/third-parties for feature measurement#57439
Add performance.mark for next/third-parties for feature measurement#57439kodiakhq[bot] merged 12 commits intovercel:canaryfrom
Conversation
| }: ScriptEmbed) { | ||
| useEffect(() => { | ||
| // Useful for feature detection and measurement | ||
| performance.mark('next-third-parties', { |
There was a problem hiding this comment.
We have to use the special mark_use_counter name so it's picked up by Chrome tooling. The unique name should be in the details field.
performance.mark('mark_use_counter',
{'detail': {
'feature': 'next-third-parties'
}
}
);
|
|
||
| useEffect(() => { | ||
| // Useful for feature detection and measurement | ||
| performance.mark('next-third-parties', { |
There was a problem hiding this comment.
Same here - though I like that we're doing a separate name for GTM. WIll help us track diff components and compare
Tests Passed |
| performance.mark('mark_use_counter', { | ||
| detail: { | ||
| feature: 'next-third-parties', | ||
| type: dataNtpc, |
There was a problem hiding this comment.
Instead of using 'type', can we append the dataNtpc to the main feature name if it exists? e.g. next-third-parties-${dataNtpc}
janicklas-ralph
requested review from
feedthejim,
huozhi,
ijjk,
shuding,
timneutkens,
wyattjoh and
ztanner
as code owners
Stats from current PRDefault BuildGeneral
Client Bundles (main, webpack)
Legacy Client Bundles (polyfills)
Client Pages
Client Build Manifests
Rendered Page Sizes
Edge SSR bundle Size
Middleware size
Next Runtimes
|
gnoff
left a comment
gnoff
left a comment
There was a problem hiding this comment.
Can you write up a description that explains how this provides an ability to measure adoption and perf wins? I'm used to using these in dev to debug perf but it seems this would be live in Prod too. I assume this is meant to be low-overhead but would be nice to understand what we're getting for adding this to the production path.
We’re working with the Chrome Speed Metrics team to develop an API to better identify specific features used by frameworks and/or CMS platforms. Instead of a entirely new API surface, we've agreed to use In the past, we've used HTML attributes for Next which have been helpful, but this will improve the accuracy of our feature detection. In this instance, this will better help us analyze and compare sites that use It's worth noting that this metric will have a public arm, but we're starting to incorporate its usage now to gather early data. |
| // Useful for feature detection and measurement | ||
| performance.mark('mark_use_counter', { | ||
| detail: { | ||
| feature: `next-third-parties-${dataNtpc}`, |
There was a problem hiding this comment.
if dataNtpc is not provided the feature will be next-third-parties-. Should we provide a more descriptive placeholder value? Also if the implementor doesn't provide a dataNtpc value should we even do the attribution? If it's actually required then maybe we should warn if Dev if missing.
There was a problem hiding this comment.
That's a good point. I don't think we need to fire attribution if we don't receive dataNtpc, since it won't be helpful
| const gtmPreview = preview ? `>m_preview=${preview}>m_cookies_win=x` : '' | ||
|
|
||
| useEffect(() => { | ||
| // Useful for feature detection and measurement |
There was a problem hiding this comment.
| // Useful for feature detection and measurement | |
| // performance.mark is being used as a feature use signal. While it is traditionally used for performance | |
| // benchmarking it is low overhead and thus considered safe to use in production and it is a widely available | |
| // existing API. |
There was a problem hiding this comment.
maybe update both comments. I interpretted feature detection as being related to whether the enviornment provides a feature and measurement as this being related to preformance measurement given the APIs used. Clarifying should help us keep track of why this code is in here when we rediscover this later :)
|
@housseindjirdeh @janicklas-ralph ready to approve but for the question on |
|
I've made the changes for |
| // performance.mark is being used as a feature use signal. While it is traditionally used for performance | ||
| // benchmarking it is low overhead and thus considered safe to use in production and it is a widely available | ||
| // existing API. | ||
| performance.mark('mark_use_counter', { |
There was a problem hiding this comment.
Working group changed their mind on naming:
| performance.mark('mark_use_counter', { | |
| performance.mark('mark_feature_usage', { |
| // benchmarking it is low overhead and thus considered safe to use in production and it is a widely available | ||
| // existing API. | ||
|
|
||
| performance.mark('mark_use_counter', { |
There was a problem hiding this comment.
| performance.mark('mark_use_counter', { | |
| performance.mark('mark_feature_usage', { |
timneutkens
left a comment
timneutkens
left a comment
There was a problem hiding this comment.
A PR description is missing
| import React from 'react' | ||
| 'use client' | ||
|
|
||
| import React, { useEffect } from 'react' |
There was a problem hiding this comment.
| import React, { useEffect } from 'react' | |
| import type { ReactElement } from 'react' | |
| import { useEffect } from 'react' |
There was a problem hiding this comment.
probably better not to pull in the entire entrypoint as a good practice. not a blocker though
6 participants
What?
Adding a
performance.markfor next/third-parties for feature measurementWhy?
We’re working with the Chrome Speed Metrics team to develop an API to better identify specific features used by frameworks and/or CMS platforms. Instead of a entirely new API surface, we've agreed to use
performance.markas the signal along with mark_use_counter as a signature.In the past, we've used HTML attributes for Next which have been helpful, but this will improve the accuracy of our feature detection. In this instance, this will better help us analyze and compare sites that use
@next/third-partiesversus those that don't, and to see if our efforts are actually improving performance.It's worth noting that this metric will have a public arm, but we're starting to incorporate its usage now to gather early data. performance.mark calls are indeed low-overhead and shouldn't affect loading/rendering performance whatsoever.