Do you have an external object caching plugin installed, like WP Redis? This will help. After this, make sure you have a page caching plugin installed, like WP Super Cache, if you don’t have a caching layer already in your stack (like Varnish). AMP requires additional processing time to generate pages and so to ensure a low TTFB you need to have page caching. This is actually a best practice for any WordPress site.
That being said, 8 seconds is far too long for normal page generation without caching.
What does your Site Health information say in your admin?
Heya Weston,
I am having the same issue as @gustavors, with a long TTFB/server-pause before webpage rendering starts. (In my case it’s a 2.5 second TTFB and non-amp pages have a 400ms to TTFB.)
We have WProcket to assist with caching and the AMP plugin is in Transitional mode. This has helped with then troubleshooting of any given page when searching slow elements.
Would use of the serverside-rendering AMP protocol help @gustavors and I with speeding up any uncached elements?
On that note, shouldn’t our AMP pages already be cached by the AMP cache system and the slowdown potentially related to the building/sanitizing of the AMP page by the plugin?
Thank you again for your awesome work and insight to this project.
-
This reply was modified 6 years, 8 months ago by
macksq.
Would use of the serverside-rendering AMP protocol
I’m not sure what you are referring to here.
On that note, shouldn’t our AMP pages already be cached by the AMP cache system and the slowdown potentially related to the building/sanitizing of the AMP page by the plugin?
Yes, valid AMP pages will be served by AMP Caches when encountered on search and other platforms. However, this doesn’t mean it’s not important to have AMP pages served quickly. When accessing an AMP page via Twitter, an AMP Cache is not used and Twitter sends the user directly to the AMP page on your origin server. In any case, when in Standard mode then the AMP version is served to all users, including desktop visitors.
And yes, the slowdown is likely due to some performance issue during the sanitization/processing phase to generate a valid AMP page. We are currently working on improving performance, for example: https://github.com/ampproject/amp-wp/pull/3319
In order to identify why your sites are slow to generate AMP pages, we’d need to have access to all the Site Health information, including the active themes and plugins, as well as the site URL.
My apologies to @gustavors if my follow up question hi-jacks the thread at all!
The reference to a server-side AMP protocol in my previous question is based off mention of the AMP Optimizer found on the AMP.dev site under the server-side rendering tutorial.
Below is a snippet from the tutorial:
Server-side-rendering is a technique that AMP caches use to even further speed up loading time. With server-side-rendering it’s possible to remove the AMP boilerplate so that the AMP document can be painted without running the AMP runtime JavaScript. For example, the server-side rendered version of the AMP Boilerplate Generator renders twice as fast as the normal AMP version!
I would assume this suggestion is exactly what the WP AMP plugin accomplishes! Although there are calls to the needed javascript by the plugin.
@macksq The AMP plugin will be supporting Optimized/Transformed AMP https://github.com/ampproject/amp-wp/issues/958
But this won’t improve the server response time (TTFB), as it will add a bit more processing time.
