Skip to content
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.

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

Initial load analytics event #7312

Merged
merged 2 commits into from
Feb 17, 2017
Merged

Conversation

dvoytenko
Copy link
Contributor

@dvoytenko dvoytenko commented Feb 2, 2017

Closes #7452, #6413, #7522.

ini-load event is triggered for a document or an embed when the contents positioned within the first window have been loaded. This event is useful on its own and also will be eventually used for visibility events.

*/
whenReadyToRetrieveResources_() {
return this.whenReadyToRetrieveResourcesPromise_;
const rect = layoutRectLtwh(
Copy link
Member

Choose a reason for hiding this comment

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

Can this use the signal?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In this case it could. But in general, I wanted to avoid creating this signal by default. E.g. without analytics and CSI reporting, this signal is not needed, but it's currently somewhat expensive. WDYT?

Copy link
Member

Choose a reason for hiding this comment

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

Makes sense.

@dvoytenko dvoytenko changed the title WORK IN PROGRESS: First-viewport-load analytics event WORK IN PROGRESS: First-win-load analytics event Feb 2, 2017
@dvoytenko dvoytenko changed the title WORK IN PROGRESS: First-win-load analytics event WORK IN PROGRESS: Initial load analytics event Feb 10, 2017
@dvoytenko dvoytenko changed the title WORK IN PROGRESS: Initial load analytics event Initial load analytics event Feb 16, 2017
@dvoytenko
Copy link
Contributor Author

@lannka PTAL. Ready for review.

The trigger for an embed or an AMP element has to include `selector` that points to the element:
```javascript
"triggers": {
"renderStart": {
Copy link
Contributor

Choose a reason for hiding this comment

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

initLoad?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

```

#### Initial load trigger (`"on": "ini-load"`)
This event is triggered when initial contents of an element or a document have been loaded.
Copy link
Contributor

Choose a reason for hiding this comment

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

i guess it's not supported for all elements right? shall we list the ones that support this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

All elements support this. Although for some it's somewhat weird. E.g. amp-pixel. But for most - it's a good signal and very meaningful.

Copy link
Contributor

Choose a reason for hiding this comment

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

OK, still, I guess it's only for AMP elements, and AMP docs?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Got it. Correct. Fixed.

);
this.visibilityStateMachine_.setState(this.viewer_.getVisibilityState());
if (firstPassAfterDocumentReady) {
this.ampdoc.signals().signal('ready-scan');
Copy link
Contributor

Choose a reason for hiding this comment

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

can you document a bit about what this signal is?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

@@ -166,6 +166,7 @@ export const LIFECYCLE_STAGES = {
layoutAdPromiseDelay: '18',
signatureVerifySuccess: '19',
networkError: '20',
friendlyIframeIniLoad: '21',
Copy link
Contributor

Choose a reason for hiding this comment

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

@tdrl FYI

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I discussed this with @keithwrightbos, I believe. Though it could have been @tdrl :)

// the initially parsed elements.
// TODO(jridgewell): this path should be switched to use a future
// "layer has been measured" signal.
return this.ampdoc.signals().whenSignal('ready-scan').then(() => {
Copy link
Contributor

Choose a reason for hiding this comment

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

shall we put all signals into an enum and have a centralized place for documentation?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good ideal. Will do. But this signal is a bit weird, so I'll keep it out. This one is just waiting for layers system to take over. I'd rather not invite its reuse.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

@dvoytenko
Copy link
Contributor Author

@lannka All done. PTAL.

Copy link
Contributor

@lannka lannka left a comment

Choose a reason for hiding this comment

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

one comment

```

#### Initial load trigger (`"on": "ini-load"`)
This event is triggered when initial contents of an element or a document have been loaded.
Copy link
Contributor

Choose a reason for hiding this comment

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

OK, still, I guess it's only for AMP elements, and AMP docs?

return true;

// First, wait for the `ready-scan` signal. Waiting for each element
// individually is too expensive and `ready-scan` will cover most of
Copy link
Contributor

Choose a reason for hiding this comment

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

Waiting for each element individually is too expensive

@dvoytenko Why is that? do you mean the cost of creating many Promise instances?

I came across this code and wondered if we can get rid of ready-scan (which has a weird / unclear definition itself).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This method was initially exclusively meant to cover performance measurement and thus tried to be as lightweight as possible. But I can't quite recollect how exactly this signal optimizes this. TBH, I'd think a bigger issue here is to wait for elements to be actually there to do this measurement at all. Otherwise it's very possible to make this call before any AMP elements have been parsed/added.

Copy link
Contributor

Choose a reason for hiding this comment

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

I see. So you meant that we are actually relying on the side effect of this code (waiting for documentReady_, ampInitialized_ & first pass) to wait for resources additions.

If that's the case, what do you think about switching to:

whenFirstPass() {}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That'd make sense to me. But not sure how much delta between them in practice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants