1.5.1 slow, causes high request time

Humm. Can you try with the AMP Optimizer disabled? Here’s a plugin to disable the Optimizer: https://gist.github.com/westonruter/8d52c0b807e6dfbbdf2219622d0f4a7e

/cc @schlessera

I’m curious if the slowness is due to a remote request being made, or if something about the Optimizer is slowing it down.

Do you have any remote stylesheets by chance?

@janvitos I’d like to investigate this further and would love to have more details about your site.

If you can, please provide the URL to an example page that is affected, details about your server environment and anything else that could help us detect a possible cause for the slowdown.

For the server environment information, the easiest way is to go to Tools / Site Health in your admin backend, and copy the information from the “Info” screen. There should be a “Copy site information to clipboard” button on that page.

Try check the autoload options for the plugin in the DB.

Backup the DB and run this SQL.
delete from wp_options where option_name like "transient_amp_remote_request_%

Hi,

Thanks for all of your answers. I can certainly try with the AMP Optimizer disabled.

I do not have any remote stylesheets.

So let me try with AMP Optimizer disabled and I will get back to you before proceeding with further troubleshooting.

• This reply was modified 4 years, 7 months ago by janvitos.

Alright, I just tried with AMP Optimizer disabled (loaded amp-disable-optimizer.php in my functions.php file), and the problem remains in 1.5.1.

I will now try running the SQL query mentioned by @someonefrompagely and get back with the results.

Edit: got this when simulating the query: Matched rows: 0. So I guess that doesn’t exist in my DB.

• This reply was modified 4 years, 7 months ago by janvitos.
• This reply was modified 4 years, 7 months ago by janvitos.

As for @schlessera, here’s a URL you can use: https://www.ipnoze.com/photos-vieux-arbres-beth-moon/amp/

But be aware that once the URL is accessed the first time, it will then be cached and will run much faster. But I gave you a an old URL that should at least hit PHP on the first try and show the request time issue.

As for server environment, here it is:

### wp-core ###

version: 5.4
site_language: fr_FR
user_language: en_US
timezone: America/Toronto
permalink: /%postname%/
https_status: true
user_registration: 0
default_comment_status: closed
multisite: false
user_count: 1
dotorg_communication: true

### wp-active-theme ###

name: ipnoze (ipnoze)
version: 1.0.0
author: ipnoze
author_website: https://www.ipnoze.com/
parent_theme: none
theme_features: widgets, post-thumbnails, title-tag

### wp-themes-inactive (2) ###

Twenty Nineteen: version: 1.5, author: the WordPress team
Twenty Twenty: version: 1.2, author: the WordPress team

### wp-plugins-active (17) ###

Ad Inserter: version: 2.6.6, author: Igor Funa
AMP: version: 1.5.1, author: AMP Project Contributors
Classic Editor: version: 1.5, author: WordPress Contributors
Cloudflare: version: 3.4.1, author: John Wineman, Furkan Yilmaz, Junade Ali (Cloudflare Team)
Disable Emojis (GDPR friendly): version: 1.7.2, author: Ryan Hellyer
JSM's Non-Breaking Space for French Content: version: 1.9.0, author: JS Morisset
Lazy Load by WP Rocket: version: 2.3.2, author: WP Rocket
Media Cleaner: version: 5.6.2, author: Jordy Meow
Media Credit: version: 4.0.4, author: Peter Putzer
Nginx Cache: version: 1.0.4, author: Till Krüss
OneSignal Push Notifications: version: 2.1.1, author: OneSignal
Schema: version: 1.7.8.1, author: Hesham
The SEO Framework: version: 4.0.5, author: The SEO Framework Team
WebSub/PubSubHubbub: version: 3.0.3, author: Matthias Pfefferle
WP Mail SMTP: version: 1.9.0, author: WPForms
WP Native Articles: version: 1.5.3, author: OzTheGreat (WPArtisan)
XML Sitemap & Google News: version: 5.2.7, author: RavanH

### wp-plugins-inactive (3) ###

Open Graph and Twitter Card Tags: version: 2.2.7.2, author: Webdados
Public Post Preview: version: 2.9.0, author: Dominik Schilling
Query Monitor: version: 3.5.2, author: John Blackbourn

### wp-media ###

image_editor: WP_Image_Editor_Imagick
imagick_module_version: 1690
imagemagick_version: ImageMagick 6.9.10-86 Q16 x86_64 2020-01-13 https://imagemagick.org
imagick_limits: 
	imagick::RESOURCETYPE_AREA: 7 GB
	imagick::RESOURCETYPE_DISK: 9.2233720368548E+18
	imagick::RESOURCETYPE_FILE: 768
	imagick::RESOURCETYPE_MAP: 7 GB
	imagick::RESOURCETYPE_MEMORY: 4 GB
	imagick::RESOURCETYPE_THREAD: 1
gd_version: 2.2.5
ghostscript_version: not available

### wp-server ###

server_architecture: Linux 4.18.0-147.5.1.el8_1.x86_64 x86_64
httpd_software: nginx/1.17.9
php_version: 7.4.4 64bit
php_sapi: fpm-fcgi
max_input_variables: 1000
time_limit: 300
memory_limit: 256M
max_input_time: 60
upload_max_size: 50M
php_post_max_size: 50M
curl_version: 7.61.1 OpenSSL/1.1.1c
suhosin: false
imagick_availability: true

### wp-database ###

extension: mysqli
server_version: 10.4.12-MariaDB
client_version: mysqlnd 7.4.4

### wp-constants ###

WP_HOME: undefined
WP_SITEURL: undefined
WP_MAX_MEMORY_LIMIT: 256M
WP_DEBUG: false
WP_DEBUG_DISPLAY: true
WP_DEBUG_LOG: false
SCRIPT_DEBUG: false
WP_CACHE: false
CONCATENATE_SCRIPTS: undefined
COMPRESS_SCRIPTS: undefined
COMPRESS_CSS: undefined
WP_LOCAL_DEV: undefined
DB_CHARSET: utf8
DB_COLLATE: undefined

### wp-filesystem ###

wordpress: writable
wp-content: writable
uploads: writable
plugins: writable
themes: writable
mu-plugins: writable

### wp_mail_smtp ###

version: 1.9.0
license_key_type: lite
debug: No debug notices found.

### amp_wp ###

amp_mode_enabled: reader
amp_templates_enabled: post
amp_serve_all_templates: This option does not apply to Reader mode.
amp_css_transient_caching_disabled: true
amp_css_transient_caching_threshold: 50 transients per day
amp_css_transient_caching_sampling_range: 14 days
amp_css_transient_caching_transient_count: 172

I normally use Query Monitor to trace such performance issues, but unfortunately, it seems like it’s not compatible with the AMP plugin.

• This reply was modified 4 years, 7 months ago by janvitos.
• This reply was modified 4 years, 7 months ago by janvitos.
• This reply was modified 4 years, 7 months ago by janvitos.

Can you try run this query and adjust the wp_ as appropriate for your setting in wp-config.php

select count(*), sum(length(option_value)) as size from wp_options where option_name like '%transient_amp_remote_request_%';

Hi @someonefrompagely, so I changed the first query you gave me and wrote it like this:

delete from wp_options where option_name like '%transient_amp_remote_request_%';

I am now getting Matched rows: 2 for the simulated query. I will proceed with running the query and see if it helps.

Edit: I ran the query and deleted the 2 rows. After, I ran the query again and there were still 2 rows, as if they were recreated.

• This reply was modified 4 years, 7 months ago by janvitos.
• This reply was modified 4 years, 7 months ago by janvitos.
• This reply was modified 4 years, 7 months ago by janvitos.
• This reply was modified 4 years, 7 months ago by janvitos.

So the issue persists even after running the query.

I just digged in a bit further and found one of the two transients point to this remote request: https://cdn.ampproject.org/rtv/012004012158290/v0.css

After looking at the Chrome waterfall, it seems like this file is loaded first and is adding roughly 100ms to the quest, which could explain the hike.

I’m guessing since it’s a CSS file, the file is loaded synchronously (and NOT asynchronously) and is blocking all the other requests while it downloads.

I won’t be available for testing for a few hours and will revert to 1.4.4 in the meantime, but I’m pretty sure we found the culprit.

• This reply was modified 4 years, 7 months ago by janvitos.
• This reply was modified 4 years, 7 months ago by janvitos.
• This reply was modified 4 years, 7 months ago by janvitos.
• This reply was modified 4 years, 7 months ago by janvitos.

After reverting back to 1.4.4, running the delete query a second time after running it the first time returns no results, as if there are no remote requests in 1.4.4.

• This reply was modified 4 years, 7 months ago by janvitos.
• This reply was modified 4 years, 7 months ago by janvitos.

If you guys need anything else, please let me know. I will be available for testing on and off today.

@janvitos Thanks for all the additional information, that really helps get a better picture of the issue.

From the Site Health debug information, I can see the following:

amp_css_transient_caching_disabled: true
amp_css_transient_caching_threshold: 50 transients per day
amp_css_transient_caching_sampling_range: 14 days
amp_css_transient_caching_transient_count: 172

With the new plugin release, we added a mechanism to detect when the CSS stylesheet cache we have is too volatile, to avoid filling up users’ database with thousands of transients when they don’t serve any use. This can happen when the CSS contains randomized or generated data, so that each new request has slightly different CSS than the one before.

In the above debug log, amp_css_transient_caching_disabled is true, meaning that this detection was actually triggered on your site, and that hence the CSS stylesheet caching was disabled.

The added latency for your site with this version could come from the fact that this caching is disabled and all stylesheets have to be reparsed on every single page request.

However, as we don’t yet have much real-world data about what values to expect, it could well be that our threshold is too low right now.

I would be very grateful if you could try the following to get some confirmation.

Can you please set the threshold to a high value for now, by adding the following code to a plugin or your theme’s functions.php file:

add_filter( 'amp_css_transient_monitoring_threshold', 1000 );

And then reset the disabling of the CSS stylesheet cache by running the following code once:

AMP_Options_Manager::update_option( Option::DISABLE_CSS_TRANSIENT_CACHING, true );

You can do this for example with WP-CLI’s wp shell command, or by pasting it into a plugin or your theme’s functions.php file and removing it again.

After this, when you go back to the Tools -> Site Health screen, the Info page should display these changes at the bottom, with amp_css_transient_caching_disabled showing false and amp_css_transient_caching_threshold showing 1000 transients per day.

Please let me know if you don’t know where to do the above, and I’ll prepare a separate plugin to install instead.

Thank you very much!