feat: add data-nuxt-img and data-nuxt-pic attrs #747
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit adds data attributes to usages of nuxt/image and nuxt/picture. This will allow us to compare performance results (in aggregate) for apps that use the components against apps that use normal <img> or <picture> tags. Currently, it isn't possible because there isn't a good way to distinguish the two in HTTP Archive. Doing such a perf comparison allows us to: - ensure that these components actually improve performance - catch and fix performance regressions quickly
✅ Deploy Preview for nuxt-image-v1 canceled.
|
|
Thanks for pull request @kara! Since last time we discussed, adding
Would be happy to discuss if you think still are merits to always include attrs to all components. |
|
@pi0 After the last meeting, I did some digging in HTTPArchive and saw that the average number of images per page is ~20 images. Given that 13 chars * 20 is only ~260 bytes, it seemed like a reasonable trade-off for being friendlier to integration with dev tooling for users. That said, we can do analysis on DOM properties as well, it's just a bit more work for us in HTTPArchive, so if you prefer client-side only, happy to update the PR. |
kara
force-pushed
the
label
branch
3 times, most recently
from
c7742b8
to
9f8a301
Compare
|
@pi0 Thought about it more and realized that we can always switch to "data-" attributes if/when we decide to integrate with dev tooling, so we might as well do the slimmer, client-side option now. Just updated the PR to make it client-side only. |
danielroe
approved these changes
Mar 3, 2023
pi0
approved these changes
Mar 6, 2023
Merged
kara
added a commit
to kara/image
that referenced
this pull request
Jan 26, 2024
Feature detection was added in nuxt#747 to allow performance analysis for nuxt/image uses in aggregate. Since that time, Javascript-based feature markers have been standardized in the W3C group around the User Timing API: https://www.w3.org/TR/user-timing/#dfn-mark_feature_usage This commit updates the feature tracking to use the new standard, which is designed to be performance-neutral. The previous mechanism (the data- attributes) will be removed in a future PR, once we can confirm it works as expected end-to-end.
kara
added a commit
to kara/image
that referenced
this pull request
Jan 26, 2024
Feature detection was added in nuxt#747 to allow performance analysis for nuxt/image uses in aggregate. Since that time, Javascript-based feature markers have been standardized in the W3C group around the User Timing API: https://www.w3.org/TR/user-timing/#dfn-mark_feature_usage This commit updates the feature tracking to use the new standard, which is designed to be performance-neutral. The previous mechanism (the data- attributes) will be removed in a future PR, once we can confirm it works as expected end-to-end.
kara
added a commit
to kara/image
that referenced
this pull request
Jan 31, 2024
Feature detection was added in nuxt#747 to allow performance analysis for nuxt/image uses in aggregate. Since that time, Javascript-based feature markers have been standardized in the W3C group around the User Timing API: https://www.w3.org/TR/user-timing/#dfn-mark_feature_usage This commit updates the feature tracking to use the new standard, which is designed to be performance-neutral. The previous mechanism (the data- attributes) will be removed in a future PR, once we can confirm it works as expected end-to-end.
kara
added a commit
to kara/image
that referenced
this pull request
Jan 31, 2024
Feature detection was added in nuxt#747 to allow performance analysis for nuxt/image uses in aggregate. Since that time, Javascript-based feature markers have been standardized in the W3C group around the User Timing API: https://www.w3.org/TR/user-timing/#dfn-mark_feature_usage This commit updates the feature tracking to use the new standard, which is designed to be performance-neutral. The previous mechanism (the data- attributes) will be removed in a future PR, once we can confirm it works as expected end-to-end.
kara
added a commit
to kara/image
that referenced
this pull request
Jan 31, 2024
Feature detection was added in nuxt#747 to allow performance analysis for nuxt/image uses in aggregate. Since that time, Javascript-based feature markers have been standardized in the W3C group around the User Timing API: https://www.w3.org/TR/user-timing/#dfn-mark_feature_usage This commit updates the feature tracking to use the new standard, which is designed to be performance-neutral. The previous mechanism (the data- attributes) will be removed in a future PR, once we can confirm it works as expected end-to-end.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit adds data attributes to usages of nuxt/image and nuxt/picture. This will allow us to compare performance results (in aggregate) for apps that use the components against apps that use normal
<img>or<picture>tags. Currently, it isn't possible because there isn't a good way to distinguish the two in HTTP Archive.Doing such a perf comparison allows us to: