The documentation of this event is sparse:
https://chromedevtools.github.io/devtools-protocol/tot/Page#event-frameNavigated
Page.frameNavigated:
Fired once navigation of the frame has completed. Frame is now associated with the new loader.

Chromium implementation:
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/inspector/inspector_page_agent.cc?dr=CSs&g=0&l=891-896

But from what I can see when running Wordpress test suite, this event seems to be sent earlier than what the documentation suggests.

And by looking at Puppeteer usage of it:
https://github.com/GoogleChrome/puppeteer/blob/0c8ace2fab4ec7c7f8add21313760ca4c438d256/lib/FrameManager.js#L224-L234
You can see that it has to fire the earliest, so that the Frame instance created on line 232 is registered in the global Map on line 234.

So that later, we have the Frame instance for the given frameId available when we receive all the other events.
For example here, on lify cycle events:
https://github.com/GoogleChrome/puppeteer/blob/0c8ace2fab4ec7c7f8add21313760ca4c438d256/lib/FrameManager.js#L134-L138

I would say that Page.frameNavigated has to be fired the earliest it can, as soon as we can compute the frameId of a frame. The location will most likely be invalid and still refer to the previous origin, but I imagine some other event is going to update the location. Like Frame.navigatedWithinDocument.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=92c077bff4508ffb76ab439764d83482e4fd7848

https://hg.mozilla.org/mozilla-central/rev/063f7a6e6362
https://hg.mozilla.org/mozilla-central/rev/022cef1ce6b9