1

Full site being migrating to AMP. I want to integrate admin functionality to AMP pages, like simple links for deleting content, and huge forms(not mobile friendly) for editing content. It will be visible after login, and non mobile content will be in iframes(to not broke AMP, as incompatible). In other words I want single, same pages for user and admin front-end - AMP pages what will work on any device for user, and same AMP pages for admin what will require desktop screen, where admin actions performed in pop-up windows(iframes in lightbox). What should I do, to make this correctly:

  1. password protect admin version of page - in other words page will be different depending on session cookie,
  2. make absolute links to admin items, not relative, full url including my domain, to avoid hit cached content? Do Google change relative links when caching AMP or not touch it at all?
  3. Make different headers, allowing cache page by headers with user content(and login form), and disables cache by http headers for logged in admin? Is it really needed?

Something I miss? Will it work as expected? Is it a good way, in case separate admin area not worth developing, and not desirable?

Will Google do cache pages in AMP cache even with preventing cache-control headers? Are different cache-control headers needed for default page and for 'logged in' page?

2
  • I wouldn't use AMP unless you fully understand how it will be cached. Oct 19, 2018 at 11:50
  • @StephenOstermiller Good point, but I realize what all I can broke is search organic results, cause all other ways user receive page is from server, not cached. And admin items on pages completely closed from Google for sure. There are benefits by using admin area in amp, cause one can login, edit meta information on a page, and text without changing browser location or go trough many clicks to do so. Above question is also about not loosing benefits of amp cache, that's requires understanding how cache works.
    – LeonidMew
    Oct 20, 2018 at 9:13

1 Answer 1

1

Admin UI pages, and pages what must not be stored in cache just don't have ⚡ or amp attribute in html tag, while still use amp javascripts and markup. Anyway, that pages may be password protected, and hidden from crawler and amp cache. Dynamic UI must not be cached. That's different from sending cache-control headers, cause page what already have expired cache-control headers still may be served from amp cache.

"[the cache] uses the origin's caching headers, such as Max-Age, as hints in deciding whether a particular document or resource is stale. When a user makes a request for something that is stale, that request causes a new copy to be fetched, so that the next user gets fresh content"

The cache is allowed to serve stale content independent of HTTP caching headers. It must make reasonable efforts to keep the cache contents fresh and must revalidate content after serving stale responses.

Removing ⚡ makes amp not valid, but still use few benefits from it. However static or not-so-often changed pages should be in cache, causing many benefits from it, like pre-rendering, images scaled for different devices, minified html/js/css.

Reference: https://github.com/ampproject/amphtml/blob/master/spec/amp-cache-guidelines.md

Update: AMP cache replaces all outbound links, so, for example: link to cached image or page will point to cache CDN, however link, for example, to not cached login page will be full url to site domain, not CDN - even login link/form come from cache CDN.

Same pages can't be both regular version and non cached admin version, cause regular version can settle in amp cache, browser cache, and logged-in admin will see page from cache, instead of his non cached version. However, its possible to add some prefix to pages, like "/admin_" by mod_rewrite, pointing to same code, but this code will return page for cache or non cacheable page with admin UI addons depending on prefix.
Seems it also possible to use admin cookie, instead of prefix, under the following rules: login redirect to site url, not cdn. Scripts returns non cacheable version with admin UI depending on cookie, same scripts returns cacheable version if no cookie is present. Cache-control headers make browser to revalidate cached version each time. Seems loosing some benefits of cache, comparing to version with "admin" prefix.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.