Page experience issue

[thiagoenge]

Hi guys, i'm getting this message from AMP Page Experience Guide:

Your AMP page from origin has a good page experience, but the cached AMP page needs work. Don't fret, we have some recommendations to help you improve! However, it's rare that we see a cached AMP page fail page experience. Please file a GitHub issue so that we can take a look and see how AMP can help.

url: https://me.ahazou.com/startnetvpn

Anyone can help to understand?

[twifkak]

Hi @thiagoenge, thanks for filing.

@sebastianbenz Do you know who to assign PX Guide bugs? Trying to understand what this error message means, what its impact is, and whether it's a bug in the cache or the guide. Looks similar to #37390.

[sebastianbenz]

What happens here is that the PX guide runs PSI against the origin URL and the cached URL. If the cache performs worth than the origin, this error message get reported. I don't see any obvious reason though, why cache seems to perform worse in this case. A quick WPT run also doesn't reveal any significant differences.

left origin PSI / right cache PSI:

[thiagoenge]

Hi guys, thanks for explanation. We deploy several improvements in order to achieve the performance in left screenshot in last days. But, the indicators on search console dont move up, any thougths?

[twifkak]

@thiagoenge The slowness being indicated is on the cdn.ampproject.org domain, which is maintained by Google. At first glance, I don't believe you can deploy any changes that will improve the TTFB on that domain significantly, but I'll let you know if I think of anything. As far as Search Console, I'm not very familiar with the report, I'm sorry. I believe most CWV-related metrics are lagging indicators (e.g. 28-day averages), but since this report is 23 days old, I'm skeptical that waiting any longer would change it significantly.

@sebastianbenz Thanks for the explanation. The only significant difference in the waterfalls I see is the "ssl" time for the first request. I'm not experienced in diagnosing TLS handshake performance, but here goes:

I don't see a relevant difference in server capabilities between cache and origin.

When I run curl -sv on both URLs, the number of steps is the same, but the number of bytes in one step is ~4K larger on the cache side.

When I run openssl s_client -connect for both domains and capture the server certs, it is clear that the reason for the larger cert is is a very large SAN section with a lot of domains.

I don't know that this is the cause of the difference in TLS handshake latency; just a theory.

[twifkak]

We're looking into whether we can address this. That said, it's worth noting that the raw network performance of the cache server is offset by the ability to prefetch from referrers like Google Search; the PSI metrics shown above are not necessarily reflective of real-world performance as observed by users.

[twifkak]

Looks like I may have overestimated the impact of the cert bytes, but I'm not sure by how much. Looking at the waterfalls again, I see a significant difference in TTFB after the TLS negotiation stage. I suspect that is a function of which cache tier hit.

As some anecdotal evidence of that, here's 3 runs of the same comparison in sequence:

run 1 - origin TTFB = 721 ms; cache TTFB = 775 ms
run 2 - origin TTFB = 743 ms; cache TTFB = 779 ms
run 3 - origin TTFB = 720 ms; cache TTFB = 740 ms

It could be that the 3rd set of requests are after closer cache tiers are populated. That said, it's possible that all that's being observed is varying performance characteristics of some different replicas being chosen along the request path.

[thiagoenge]

Hi guys, i would like to share another stranger message on page experience tool, i think that is related to this discussion

Why the message said that a poor page experience if i have all metrics green?

Below there are some actions appointed, the first one, about meta viewport, the current tag is: <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1"> which is injected by framework that we use (NextJs), the question is, this issue is really a problem or once all metrics are green is more an warning than error?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.