Re: What is the good place to hook the beginning of a new page?

[Kouhei Ueno]

+navigation-dev

On Wed, Aug 25, 2021 at 2:43 PM Koji Ishii <ko...@chromium.org> wrote:

Hi,

I'm trying to accumulate time consumed in font functions.

Currently, we reset the accumulated time on FCP. In the next step, I'd like to measure this for 1) before FCP and 2) before DOM content load.

To do this, I'm thinking to change this to:

1. Reset on the beginning of a new page.
2. Report "before FCP" accumulated value at FCP.
3. Report "before DOM content load" accumulated value at DOM content load.

Could you advise what is the best place to hook 1?

I'd like to reset this even when we reuse the same renderer process. Set a break point at FrameLoader::StartNavigation but it looks like we don't call this for Refresh. Any pointers are greatly appreciated in advance.

--
You received this message because you are subscribed to the Google Groups "loading-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAHe_1dKd363j5r0uj%3DzdQ96f5fkF5uMzXNFmc9OEXjC%3DNOERyw%40mail.gmail.com.

--

kouhei

[Kentaro Hara]

What about around DocumentLoader::DidCommitNavigation()? It's called just after the commit navigation IPC.

You received this message because you are subscribed to the Google Groups "navigation-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to navigation-de...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/navigation-dev/CAPVAxLUNiN_fEpsto66V7Y4pi%2B_37W7W_wrEg8WewYptNx-atg%40mail.gmail.com.

--

Kentaro Hara, Tokyo

[Kenichi Ishibashi]

What's the purpose of these TimeDeltas? If your purpose is to measure some metrics related to page load timing, it might be worth taking a look at PageLoadMetricsObserver.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CABg10jwtSZV0m6Eq9etBPfcNTrON6enVfvLPQXFKqUxfD0jofA%40mail.gmail.com.

[Rakina Zata Amni]

Note that DidCommitNavigation() won't be fired for bfcache restore/prerender activation etc because the page is not freshly loaded/committed. So if you want to reset during those times as well, you'd probably also need to listen to PageLifecycleState changes (or maybe there are better ways to detect activation?).

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/navigation-dev/CABg10jwtSZV0m6Eq9etBPfcNTrON6enVfvLPQXFKqUxfD0jofA%40mail.gmail.com.

[Kouhei Ueno]

Can this be part of PerformanceTiming [cs] and piggy back on the reset logic there?

I find it a bit unfortunate to have the FontPerformance counters [cs] be a process-wide state.

--

kouhei

[Kentaro Hara]

Note that DidCommitNavigation() won't be fired for bfcache restore/prerender activation etc because the page is not freshly loaded/committed. So if you want to reset during those times as well, you'd probably also need to listen to PageLifecycleState changes (or maybe there are better ways to detect activation?).

My understanding is that Koji-san is interested in understanding how much time is spent on the synchronous font access during a fresh page load. So I think we want to add a logic to NOT record the metrics on FCP and DOMContentLoaded when it's not a fresh page load. I think this can be achieved by 1) reset the metrics in DidCommitNavigation(), 2) record the metrics on the first FCP and the first DOMContentLoaded.

--

Kentaro Hara, Tokyo

[Alexander Timin]

If we are talking about Blink, then unlike the browser process, we already have objects there with the right lifetime — DOMWindow / ExecutionContext.

I wonder if it would be possible to attach the necessary data to them which would remove the need for us to worry about LocalFrames being reused for another document? 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/navigation-dev/CABg10jzhiR1LeP62sie4Y5RJ0eF7N%2BLTnSJOYhbvSj77yndXBg%40mail.gmail.com.

[Koji Ishii]

Thank you all for the replies.

The tricky part is that we want to measure time spent in the platform code while core is loading the page. Attaching to DOMWindow means the platform needs to know which DOMWindow the renderer process is currently working on. This is still at an early stage of the investigation, so if anyone has better ideas how to handle this, including not to make it per-process global, happy to discuss more.

Re. bfcache, haraken is right, if we're not firing FCP/DOMContentLoaded, we don't need to reset.

Sounds like DidCommitNavitation is the one, unless anyone has better ideas to handle performance counters in the platform code?

[Alexander Timin]

On Thu, 26 Aug 2021 at 05:58, Koji Ishii <ko...@chromium.org> wrote:

Thank you all for the replies.

The tricky part is that we want to measure time spent in the platform code while core is loading the page. Attaching to DOMWindow means the platform needs to know which DOMWindow the renderer process is currently working on. This is still at an early stage of the investigation, so if anyone has better ideas how to handle this, including not to make it per-process global, happy to discuss more.

Re. bfcache, haraken is right, if we're not firing FCP/DOMContentLoaded, we don't need to reset.

Sounds like DidCommitNavitation is the one, unless anyone has better ideas to handle performance counters in the platform code?

If we want to tie these metrics to FCP / DOMContentLoaded, I would strongly recommend to avoid making them process-global as it would be very hard to reason about them when we have multiple (main) documents hosted in the same process.

It might be hard to do if the font caches are tied to a process rather than execution context / page, but then an alternative might be to maintain a global always-increasing counter of total time spent in the font-related logic and just query it from a per-document struct (so the result will be the difference in sampled values when Window is created and when FCP / DomContentLoaded is reached).  

[Koji Ishii]

Thanks

Right, currently, FontCache is process-global, we'll need to change that to make the metrics not global.

IIUC your suggestion, copy the values at DidCommitNavitation, then compute the diff at FCP/DomContentLoaded? Good point, it can work when we have multiple documents per process. Thanks for the suggestion!

[Alexander Timin]

On Fri, 27 Aug 2021 at 07:12, Koji Ishii <ko...@chromium.org> wrote:

Thanks

Right, currently, FontCache is process-global, we'll need to change that to make the metrics not global.

IIUC your suggestion, copy the values at DidCommitNavitation, then compute the diff at FCP/DomContentLoaded? Good point, it can work when we have multiple documents per process. Thanks for the suggestion!

Yes, but I think that there is no need to copy them in DidCommitNavigation specifically — DOMWindow or ExecutionContext's constructors (or equivalents) should work as well.