Sure @schlessera, I will test this soon and get back to you.
Hi @schlessera, I’m getting an error from the AMP_Options_Manager line of code:
PHP Fatal error: Uncaught Error: Class 'Option' not found
I know you guys are probably busy, but it would be much better for me to debug this by chatting with you so we can fix this ASAP. I don’t like having these AMP pages run with a high request time in production since Google nowadays has the habit of penalizing anything that seems slow.
-
This reply was modified 2 years, 1 month ago by
janvitos.
@janvitos I’m sorry, the command should have been the following:
AMP_Options_Manager::update_option( 'amp_css_transient_monitor_disable_caching', true );
Once you’ve tried this and could confirm the change on the Site Health page, please observe the latency. If the performance didn’t improve, please roll back to v1.4.4 for now. I’ll see if I can contact you to schedule a call tomorrow then.
Note: We’re working on a fix that should be pushed soon as v1.5.2, but that assumes we’ve correctly identified the issue, which is not fully confirmed yet.
So @schlessera, even after adding the proper command to my functions.php file (and not getting an error anymore), I’m still seeing this in Site Health:
amp_css_transient_caching_disabled: true
So as you suggested, I will be reverting back to 1.4.4 for now.
-
This reply was modified 2 years, 1 month ago by janvitos.
-
This reply was modified 2 years, 1 month ago by janvitos.
-
This reply was modified 2 years, 1 month ago by janvitos.
@janvitos I think the boolean was wrong for the command. Please try this:
AMP_Options_Manager::update_option( 'amp_css_transient_monitor_disable_caching', false );
It should be false because we want to turn off disabling the caching. A bit of double-negative confusion going on here I suspect.
Thank you very much for testing and helping us work through this!
Also, here is a pre-release v1.5.2-alpha ZIP build of a fix to the plugin which does the above for you: https://github.com/ampproject/amp-wp/pull/4513#issuecomment-608056374
This also includes some other fixes we’re going to release later today: https://github.com/ampproject/amp-wp/milestone/30?closed=1
Alright, amp_css_transient_caching_disabled is now set to false.
I will get back to you very soon with the request time results.
-
This reply was modified 2 years, 1 month ago by janvitos.
-
This reply was modified 2 years, 1 month ago by janvitos.
So after 20 minutes, amp_css_transient_caching_disabled is still false and request time is now back to normal at 70ms with v1.5.1.
OK, great. Thank you for confirming that. If you wanted to go the extra mile and try the above 1.5.2-alpha build, that would give added more confidence the 1.5.2 release will fix the issue for others as well.
Just to let you know @schlessera and @westonruter, after a little longer, amp_css_transient_caching_disabled was set to true again and the request time went back up to 170ms.
amp_css_transient_monitoring_threshold was set to 1000, so I have now set it to 5000 to see what will happen.
-
This reply was modified 2 years, 1 month ago by janvitos.
-
This reply was modified 2 years, 1 month ago by janvitos.
Could you provide us with a dump of the parsed CSS transients? Here’s the WP-CLI command to do that:
wp option list --search='_transient_amp-parsed-stylesheet-*' --transients --format=json
Sharing it in a Gist or DM in WordPress Slack would probably be best.
Here’s the link to the dump of the parsed CSS transients: https://gist.github.com/janvitos/9f2343d807d705045934e45b120c1a95
-
This reply was modified 2 years, 1 month ago by janvitos.
Thank you. I want to analyze them to see if I can find the source for the variability you’re experiencing.
Alright. I will be waiting to hear from you.
By the way, since setting amp_css_transient_monitoring_threshold to 5000, amp_css_transient_caching_disabled was never triggered and was never changed to true.
-
This reply was modified 2 years, 1 month ago by janvitos.
