Thanks to visit codestin.com
Credit goes to github.com

Skip to content

feat: upgrade to rum v2 #81

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.

Sign up for GitHub

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

Jump to bottom
Merged
auniverseaway merged 4 commits into from
Sep 10, 2025
Merged

feat: upgrade to rum v2 #81

auniverseaway merged 4 commits into from
Sep 10, 2025

Conversation

@kptdobe
Copy link
Contributor

@kptdobe kptdobe commented Sep 9, 2025 •
edited
Loading

Upgrade to RUM v2.

We'll be tracking clicks in webcomponents and many other good things like better source handling.

Not sure how to provide a URL for testing...

@aem-code-sync
Copy link

aem-code-sync bot commented Sep 9, 2025 •
edited
Loading

Hello, I'm the AEM Code Sync Bot and I will run some actions to deploy your branch and validate page speed.
In case there are problems, just click a checkbox below to rerun the respective action.

  • Re-run PSI checks
  • Re-sync branch
Commits

auniverseaway
auniverseaway reviewed Sep 9, 2025
View reviewed changes
nx/scripts/nexter.js Outdated
@@ -1,10 +1,10 @@
import { sampleRUM } from '../deps/rum.js';
Copy link
Member

@auniverseaway auniverseaway Sep 9, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would make all of DA slower as it would put rum in the critical path of showing pixels.

Please find a way to use rum without getting in front of LCP (which is the previous behavior).

auniverseaway
auniverseaway reviewed Sep 9, 2025
View reviewed changes
nx/scripts/nexter.js Outdated
el.autoBlocks = decorateLinks(el);
el.blocks = [...el.querySelectorAll(':scope > div[class]')];
decorateDefaults(el);
if (i === 0 && sampleRUM.enhance) {
Copy link
Member

@auniverseaway auniverseaway Sep 9, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does sampleRUM.enhance do? We should not have a dependency on rum for basic decorating. Rum does not provide value to the person trying to view the page and should be not be executing / required in the path to LCP.

Copy link
Contributor Author

@kptdobe kptdobe Sep 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

enhance is an optimization to load the enhancer only after the first section is loaded, i.e. load the enhancer post LCP.

Copy link
Contributor Author

@kptdobe kptdobe Sep 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we lazy load sampleRUM, this would not be necessary.

auniverseaway
auniverseaway reviewed Sep 9, 2025
View reviewed changes
nx/scripts/postlcp.js Outdated
import { sampleRUM } from '../deps/rum.js';

(async function loadPostLCP() {
window.hlx = window.hlx || {};
Copy link
Member

@auniverseaway auniverseaway Sep 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These should be moved to rum.js as they are part of the rum feature. We want to keep these things encapsulated to their own area of concern.

auniverseaway
auniverseaway requested changes Sep 9, 2025
View reviewed changes
Copy link
Member

@auniverseaway auniverseaway left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've always had a complicated relationship with RUM because it provides the site owner value, it provides Adobe value, but it does not provide any value to the visitor.

In simple Edge Delivery implementations with a lot of LCP headroom, it's totally fine to put RUM in front of LCP. That's the way boilerplate is. This is not something I'm willing to accept on DA.

If we cannot get the RUM data we need without putting bytes in front of LCP, I think we have an architectural problem with RUM. Historically, we have been able to defer without any noticeable impacts to reporting (at least to my knowledge), and I don't want to change this.

If you look at it differently: if AWS / Cloudflare / etc said we had to run their code before we can do our work, we would tell them to fly a kite. We should treat our customers (da.live in this case) with the same amount of respect.

@kptdobe
Copy link
Contributor Author

kptdobe commented Sep 10, 2025 •
edited
Loading

but it does not provide any value to the visitor.

It does provide value to the visitor: if we can track what happens when a page loads, we can detect when page is slow or if something is broken and then, we can work hard to make it better to the visitor.

if AWS / Cloudflare / etc said we had to run their code before we can do our work

Yes and this is the case for almost all projects. Then it is a question of tradeoff: do you accept to lose x% of performance for the benefits of the given feature...

The sampleRUM function is adding some bytes in front of the LCP. That's true and nothing we can do about it because we want to capture things as early possible (see tradeoff value for visitors above). It has a measured impact of 15 to 30ms. For a LCP at 2800ms, this is irrelevant and largely in the error margin.
When we talk with Akamai which is adding scripts on the way to LCP, we are talking about 2 to 3... seconds!

Is another site than da.live using this repo as a foundation ? Because in the current state and for da.live, the LCP argument is irrelevant.

  • for the explorer, you have to load the list of folder's children, that's all what really matters. The LCP event comes really late anyway, just because there is nothing really "large". 95 resources are loaded before the LCP, you can move the rum.js resource wherever you want, it will not change anything
image
  • for the editor, the LCP will most likely be the hero image of the page being edited. It is the last thing loaded on the page (by nature of the editor). If we want to fine tune, we should question why the whole da-library or so much stuff is loaded before... lit 9k, da-y-wrapper 120k, da-assets.js4k... hard to argue that the rum method is such a problem in this environment.
image

Finally, by deferring the load of rum.js, you lose visibility of everything that happens before (early checkpoints, resource loaded (or not), potential JS errors...).

@kptdobe
Copy link
Contributor Author

kptdobe commented Sep 10, 2025

ok... rethinking about all of this... da.live is more an app than a site anyway. Performance monitoring and tracking are slightly different.

I revisited the PR. If we trigger sampleRUM in lazy.js, we'll lose:

  • the early error tracking - which I assume is fine, the site is not really content driven, only 2 or 3 page types (homepage, explorer and editor), early errors are pretty visible and under control
  • top checkpoint is late which will have an impact on page views (might be less than reality) but we do not really care here about people visiting a page and leaving before the page is loaded because it is slow.

All the rest is computed based on Performance API which keeps track of the everything from the beginning anyway.

@auniverseaway auniverseaway merged commit 09e2402 into main Sep 10, 2025
3 of 4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@auniverseaway auniverseaway auniverseaway approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@kptdobe @auniverseaway