Great perfomance

Thanks a lot!

To be clear, using the AMP version for mobile is is done via Transitional template mode, correct? And for desktop too you mean switching Standard template mode, correct? Standard mode is AMP-first meaning desktop and mobile visitors both get the same fast AMP experience: AMP is canonical. The Transitional (and Reader) template modes are paired AMP schemes, where there is an AMP-speciifc URL that differs from the corresponding canonical URLs.

Hi @westonruter,

Yes, on a few sites we use directly the standard mode, providing AMP first experience for both desktop and mobile.

But for some, we use the amp first experience only on mobile, using a small code tweak, which proven to be helpful:

add_filter( 'option_amp-options', function ( $value ) {

	if ( wp_is_mobile() ) {
		$value['theme_support'] = 'standard';
	}

	return $value;
}, 99999 );

Because the hosting does the page caching per device ( mobile/tablet/desktop ) the wp_is_mobile is working fine in this context.

Interesting approach. We’re actually implementing support for this in the plugin, but in a different way. In particular, when a site is in Reader/Transitional mode, as a user on a mobile device visits the canonical non-AMP version then it will redirect them to the non-AMP verison.

PR: https://github.com/ampproject/amp-wp/pull/4796
Issue: https://github.com/ampproject/amp-wp/issues/4479

Serving the AMP version as the mobile version is tricky especially given various server stacks. You mentioned your hosting already varies caches by device, so it’s not a problem for you.

But in general, consider a site that has a caching layer that doesn’t properly segment by user agent in the same way that wp_is_mobile() does. If such a site used your approach, then it could result in a desktop user getting served the AMP version, or a mobile user getting the non-AMP version. For this reason, the AMP plugin by default is going to use JavaScript to redirect mobile users visiting visiting the canonical URL to rather go to the AMP version. For sites that have caching layers which support it, we’ll also support a filter to opt-in to doing PHP-based redirects instead, which will be much faster of course.

I briefly considered your approach of actually serving different versions of the site on the same URL based on the user agent, but I settled on using redirects instead. I suppose in practice this is no different than doing a redirection. But there could be some unintended side effects with how you’ve implemented it…

Consider Googlebot doing mobile-first indexing. When it lands on your site, it will be treated as a mobile visitor and will get served AMP in standard mode. In this mode, there will not be any amphtml link to advertise a separate AMP version, since as far as it knows the AMP version is the canonical version. I don’t suppose that would be a problem in and of itself.

But let’s say Googlebot uses desktop-first indexing, and indexes a page on your site. It will have the amphtml link since it’s not standard mode; it will then at some point later index the AMP version. The Googlebot which indexes AMP pages will use the mobile user agent, as far as I understand. So when it tries doing so it will end up getting redirected from /?amp to /?amp since the plugin thinks it is actually in Standard mode. This could end up making Googlebot very confused and your pages may not get indexed as AMP and thus they won’t be able to be served with the AMP badge and served with prerendering.

There is also special guidance from Google on how to make sure that Googlebot will know that different versions of the site depend on the User-Agent which I believe you’ll need to include in your snippet above (if your host isn’t doing it already): https://developers.google.com/search/mobile-sites/mobile-seo/dynamic-serving

Let’s continue the discussion here on the GitHub issue where I’ve cited our converation here.