Amphtml: ${pageLoadTime} variable is not resolved after default pageview trigger

[sap1ens]

Short description of your issue:

${pageLoadTime} variable is not resolved after default pageview ("on": "visible") is triggered. It's resolved later though.

Other similar variables (like ${contentLoadTime}) are resolved fine.

How do we reproduce the issue?

Check https://amp.mobify.net/lancome/http://www.lancome-usa.com/makeup

You'll see that one of the requests to engagement-collector.mobify.net fails - it's supposed to have ${pageLoadTime} defined.

Currently if I use this trigger:

"pageload": {
    "on": "timer",
    "timerSpec": {
        "interval": 5,
        "maxTimerLength": 600
    },
    "request": "pageload"
}

The first request has undefined ${pageLoadTime}, but only the first one. All consequent requests are fine. Originally I had this issue with another trigger (it's deployed on the page mentioned above):

"pageload": {
    "on": "visible",
    "request": "pageload"
}

What browsers are affected?

Chrome 56

Which AMP version is affected?

1486153081489

[dvoytenko]

/to @lannka

[zhouyx]

After looked into it a little bit, ${pageLoadTime} is only resolved when loadEventStart returns a value greater than 0.

loadEventStart returns 0 until the load event was sent for the current document.

The two config for the request could happen before loadEventStart event, thus ${pageLoadTime} is undefined.

[lannka]

Agree, seems like working as intended. We can't wait till the full page load to send the ping, otherwise you'll lose many pings.

[drewzboto]

@lannka I don't think this is working as intended, or at worst has changed behavior from prior releases. Several other existing analytics vendor plugins are broken based on the exact same configuration.

If this isn't the intention, what is the trigger to use that does guarantee page load time being resolved?

[drewzboto]

For context, one of the main value props for AMP we're trying to measure and prove to our customers is that load times in AMP are way lower than their origin pages. The analytics docs aren't very clear on when the page load time is resolved when trying to measure it

[zhouyx]

I agree on: visible is somewhat confusing. It's easy for people to assume that page should have loaded by that time. Maybe we should provide another on: load trigger event, but then when should we trigger it? @lannka WDYT?

[dvoytenko]

@sap1ens Could you please clarify what you mean by "pageLoadTime not resolved"? Are you receiving no values at all, or 0, or empty string, or actually "undefined" string?

From what I can tell, the code, at least, attempts to wait for page's load before trying to calculate this value. So, if you are seeing an empty value, I believe this is a regression. Seeing that this value arrives for subsequent requests makes me think that there's a risk condition. I don't see any recent changes in that part, but it could feasibly be a change in browser behavior as well.

[sap1ens]

@dvoytenko I meant no value at all. You can check this URL - https://amp.mobify.net/lancome/http://www.lancome-usa.com/makeup, find a request failing with 400 and see the request data:

^ notice the value for the value field.

[dvoytenko]

@sap1ens @lannka @zhouyx This certainly looks like a risk condition to me. Let's take a look.

[dvoytenko]

Given the regression, I'm upping this to P1.

[lannka]

It's indeed a race condition. But I don't think it ever worked [as expected]. pageLoadTime is reported as window load event time. It fails when the analytics trigger gets fired before window load. In other words, amp-analytics gets laid out before window load hence blocked window load.

Solution 1:
Let amp-analytics layout wait for window load. However, we should not do that, because window load can potentially wait slow image load for long time, and cause missing analytics pings.

Solution 2:
Re-define pageLoadTime. On an AMP page, window load time is actually not a reliable metric at all. There is huge randomness in it. Because AMP controls all resource scheduling, window load can fire very early if the browser's event loop gets cleaned up before AMP runtime laying out any elements.
On the other hand, if an amp-img gets laid out right before that, it will block window load, the so image loading time will be counted into window load.

@dvoytenko , I suggest we re-define pageLoadTime to your document ini-load concept (when all elements in first viewport gets laid out). In that case, user should be using the ini-load trigger to collect such a metric, not visible trigger.

[lannka]

To not introduce regression in pub's dashboard, we can introduce a new metric initLoadTime.

[dvoytenko]

@lannka ini-load is good for many cases, but $pageLoadTime also makes sense. From the code I see that it's supposed to wait until the window.onload arrives. Is that not the case? Was there a recent regression for that part of code?

[drewzboto]

Many thanks @dvoytenko!

[luby1]

Did anyone manage to get $pageLoadTime into Google Analytics? I can't determine if this is not working again in amp-analytics or Google Analytics is ignoring the values. I get pageviews into Google Analytics, but no $pageLoadTime.

I tried the example above:

"pageload":{
    "on":"visible",
     "request":"pageload"
    }

And also with extraUrlParameters:
"extraUrlParams":{
"plt":"${pageLoadTime}"
}

And page load speed recorded in the Google Analytics is always 0, despite seemingly valid JSON request. I also tried custom metrics instead using page load time metrics (cm1), and no luck there either.

Am I missing something? I read every document I could find online about amp-analytics and Google Analytics and there is not a single document detailing how to get ${pageLoadTime} reported.

[avimehta]

@luby1 plt is a reserved parameter for Google Analytics and should be using only when hit type is set to timing. By default AMP sends page load time for 1% sample rate and you should be seeing the numbers for that. If you would like to use a higher sample rate, see the code below and adapt it for the rate you would like:

{
  "triggers": {
    "performanceTiming": {
      "sampleSpec": {
        "threshold": 1,
      }
    }
}

If the code above does not work, do you mind opening a new issue and cc'ing me on it so that I can investigate this?

Unfortunately, because of the way reporting works for Google Analytics, custom metrics, sending this value in custom metrics will just sum it up and the resulting value will be meaningless.

[luby1]

Hi Avi, thank you for your reply. I've tried your suggestion, and no result.

I opened new issue: https://github.com/ampproject/amphtml/issues/19463 . Didn't know how to copy you from the issue itself; I apologise if there is a better way to do it.