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

Page experience issue #37268

Open
thiagoenge opened this issue Dec 27, 2021 · 8 comments
Open

Page experience issue #37268

thiagoenge opened this issue Dec 27, 2021 · 8 comments
Labels
P3: When Possible Stale Inactive for one year or more Type: Page experience AMP page fails page experience criteria

Comments

@thiagoenge
Copy link

thiagoenge commented Dec 27, 2021

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?

@jshamble jshamble added P3: When Possible WG: caching Type: Page experience AMP page fails page experience criteria labels Jan 11, 2022
@twifkak
Copy link
Member

twifkak commented Jan 19, 2022

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
Copy link
Contributor

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:

Screenshot 2022-01-19 at 08 29 27

@thiagoenge
Copy link
Author

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
Copy link
Member

twifkak commented Jan 19, 2022

@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
Copy link
Member

twifkak commented Jan 19, 2022

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
Copy link
Member

twifkak commented Jan 24, 2022

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
Copy link
Author

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

Screenshot from 2022-01-28 13-50-17

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?
Screenshot from 2022-01-28 13-49-26

@stale
Copy link

stale bot commented Jan 22, 2023

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.

@stale stale bot added the Stale Inactive for one year or more label Jan 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P3: When Possible Stale Inactive for one year or more Type: Page experience AMP page fails page experience criteria
Projects
None yet
Development

No branches or pull requests

5 participants