Хорошо поддаются оптимизации по скорости загрузки, снижают нагрузку на сервер, а страницы можно сделать удобными для пользователей с мобильными устройствами. К тому же есть возможность выбрать версию отображения. Поскольку это отдельный мобильный сайт, как правило, поддомен, то HTML, стили, URL одних структурных страниц будут разными. Необходимо настраивать HTTP- или JS-перенаправление пользователей с десктопов на мобильный сайт и наоборот. Помимо настройки перенаправлений, нужно связать десктопную и мобильную версию специальными атрибутами. Могут быть проблемы с дублированием контента.
Благодарю за труд. Взял на заметку👌
>На AMP-страницах нет возможности реализовать важные функциональные элементы: навигационное меню, внутренний поиск, блоки перелинковки, виджеты социальных сетей, дополнительная перелинковка в футере.
Вы не упомянули, что предоставляется набор готовых библиотек, позволяющий закрыть большинство базовых потребностей. Так же есть возможность использовать iframe для тех моментов где это критично, но на мой взгляд страницу нужно оставлять максимально легкой, а по необходимости - переводить пользователя на обычную страницу.
Конечно, в рамках amp предоставляется набор готовых контейнеров, и даже amp-iframe https://amp.dev/ru/documentation/components/amp-iframe/. Но есть ограничения и отличия от iframe на обычной странице сайта.
Я говорю про пользовательские js, неподдерживаемые html-теги и тд. С навигацией погорячилась, прошу прощения, ее можно реализовать с помощью amp-sidebar.
Один из самых простых способов ускорить адаптивный дизайн - отключить часть свистелок для загрузки на мобильных версиях (например, слайдера) - технически очень просто, в том числе на большинстве бесплатных cms.
Девушка, извините, не было целью вас обидеть. Вы просто проверьте ваше понимание заголовка Vary, в одном единственном месте - документе-стандарте, в котором описывается работа протокола HTTP, а потом заново посмотрите на ту статью в Google-справке - тему Vary. В Google for Developers - да, действительно отличная статья, но которая дополняет (а не заменяет) то, что описывается в документе-стандарте, по части - Vary.
У вас очень запутанные формулировки, например:
"сервер обращается к агенту пользователя через HTTP-запрос Vary"
1. Сервер здесь никуда не обращается. Сервер отдаёт (в HTTP-ответе).
2. HTTP-запрос Vary? Может имелось ввиду - HTTP-заголовок Vary? Если это так, то Vary относится к группе заголовков HTTP-ответа, а не HTTP-запроса.
***
"Vary сообщает серверу и браузеру о необходимости учесть агент пользователя"
1. Что вы имели ввиду под "сообщает серверу" ("браузеру" ладно, пока опустим)? Vary итак создаётся на сервере и покидает его. Vary с сервера - сообщает серверу?
***
Вот, что я имел ввиду, в своём первом комментарии - очень всё неочевидно и запутанно, по теме Vary.
Смотрите только первоисточник, сравнивая с ним - все остальные.
Помните, для кого-то вы будете гуру - после прочтения данной статьи. На вас будут ссылаться и цитировать. Держите марку!
>В мобильную выдачу с прогрессивным веб-приложением не попасть
Пожалуйста, поясните, что Вы имели ввиду
PWA - это история про быстрый доступ к сайту с рабочего стола смартфона или планшета, когда пользователь осознанно добвил это приложение к себе на экран. То есть из SERP не перейти на страницу PWA.
Это не про ранжирование в мобильной выдаче, поэтому не пронумерован пункт как оптимизация сайта для мобильных устройств. К тому же, чтобы использовать PWA, оптимизированная мобильная версия уже должна быть. Настройка прогрессивного веб-приложения не улучшает мобильные страницы сайта, а позволяет получить быстрый доступ к ним за счет кеширования.