Hi AMP devs,
We have noticed that the CSS sanitizing of AMP is taking almost 10 seconds in our site. Checking through New Relic shows AMP_Style_Sanitizer::process_link_element is called 7 times. Do we have ways to optimized this?
- This topic was modified 2 years, 7 months ago by Danilo Parra Jr..
The page I need help with: [log in to see the link]
Are all 7 calls to that
process_link_elementtaking roughly the same amount of time? Or is one taking longer than the others? Do you have an external stylesheet loaded from another domain, for example?
Can you share a screenshot of the “Stylesheets” metabox on a validated URL screen?
Ideally expand the stylesheets for each
<link>so we can see the URLs for the external stylesheets.
Alternatively, put your site into Transitional mode so we can see what the external stylesheets are.
Please see the screenshot for the top 3 slowest
The list below are all the CSS files the page loads.
Thank you for these details, and apologies for the delay in getting back to you. We’re discussing this further with our team and will have an update soon.
I have submitted our site health information in the form, please check.
With regards to the stylesheet I manage to dequeue fontawesone and dashicons from the plugin calls, and optimize theme stylesheet by removing the unused styles we have in the site. Although that help in the site performance, AMP is still parsing the stylesheet slow. It is worth noting also that we don’t have Persistent object caching enable in our site because of Memberpress (our membership plugin) have issues with it.
Thanks for the update, I was wondering if you have any dynamic CSS implementation on your site, which includes dynamically-generated style rules with selectors referring to user IDs or elements being given randomized background colors. etc. it may invalidate the previous transient version and requires regeneration which may affect your performance.
Also, performance may degrade in terms of the number of CSS files, as you mentioned removing unused CSS is a good way to tackle it.
Alternatively, please check server timing log for
?amp_verbose_server_timing=1while being logged in as Administrator. as shown in the screenshot it should be 0 meaning it’s being served from transient.
let me know if this helps.
I checked the live site and
amp_parse_cssis not set to zero which concludes that the site it not serving from transient. Please know that the live site does not have object caching enable because of memberpress recommendation. Is there any way around this if we can’t use object caching?
thanks for the update, Using Object caching is recommended in such cases but given you can’t use object caching because of member press, I will recommend checking with member press plugin support.
memeberpress have this guide check if that’s helpful.
Alternatively, you can disable the AMP on pages that serve dynamic content.
Is there dynamic content though? All of the stylesheets being linked to seem to be static files. Are all of the external stylesheet URLs the same with each page load? Or are you adding a current timestamp as the version for any of them, causing them to change with each page load?
Thank you for your suggestion, but I already implemented WP Rocket through the Memberpress guide you mentioned. I also disable AMP on memberpress pages.
There is a dynamic content but it is not changing every time a page is loaded so it is pretty much the same e.g. theme color settings.
## Are you adding a current timestamp as the version for any of them, causing them to change with each page load?
I’m not using current timestamp to version any of them.
I am finding variable content.
I did two requests to that URL and then pretty printed the HTML pages. Then I obtained a diff: https://gist.github.com/westonruter/9bfb597bd8bc2e5492b309f7b020ff97
The inline styles in particular may be causing the CSS parser to run. Nevertheless, these wouldn’t be involving
You may want to switch to Transitional mode temporarily to compare the AMP and non-AMP more easily to identify the change.
Ads are only showing for logged out users. I have checked
amp_parse_csswhile logged in so ads that is adding inline styles won’t be present in the page. Also I have test a dev site where object caching is enable and it does show
amp_parse_cssis set to zero which means it is using the transient while in the staging and live site that have object caching disabled shows that
amp_parse_cssis not set to zero even on multiple page request.
0even when you are not using an external object cache. If not using an external object cache, then it uses transients. If the value is non-zero, then this indicates a cache miss with each request, or else that parsed CSS caching is disabled.
falseif using an external object cache (if
object-cache.phpdrop-in is present), or if the AMP plugin has disabled transient caching due to there being highly-variable CSS. In that case, the
amp_css_transient_caching_disabledflag in the Site Health info would say
true, but it is
falsefor you so that doesn’t seem to be the case.
Perhaps you have a misconfigured object cache? Perhaps a
wp-content/object-cache.phpthat is empty or not working?
Object caching is working in the dev site which is just a copy of the live site. I have checked
wp-content/object-cache.phpand it’s not empty or misconfigured.
In order to further investigate the issue, I disabled plugins, change themes, and found out that the main theme CSS is not being cache by AMP. This file
https://www.superguide.com.au/wp-content/themes/genesis-superguide/style.css?ver=4.1.0is being parsed multiple times on every page load.
In order to get the logs of all not cached files I added an error_log here
You can see the debug.log content here – https://gist.github.com/daniloparrajr/c5e59d24a5ff7a3e3881da137e61e9dc
This is all the logs generated when the homepage is loaded.
- The topic ‘AMP CSS parsing taking too long to finish’ is closed to new replies.