Что в интересного в URL AMP-страниц?

В Интернете много различных типов URL-адресов. Они прямо и косвенно указывают на содержание интернет-страниц. Когда вы открываете новую статью на сайте New York Times, быстрый взгляд на URL-адрес позволяет узнать, что нового рассказывает солидное издание с многолетним опытом серьёзных публикаций. Инновационные продукты в мобильных приложениях и недавний запуск AMP в Google Search изменили понятие и содержание URL-адресов. Новые технические решения требуют раскрыть смысл различных видов URL-адресов для AMP-страниц и объяснить суть изменений, которые нужны для решения проблем вокруг URL.

В 2017 году все AMP-документы имеют три различных вида URL-адресов:

• Оригинальный URL – документ издателя записан в формате AMP.

• URL AMP-кэш – документ загружается через AMP Cache (например, все AMP страницы из поиска Google выдаются из кэша Google AMP). Большинство пользователей никогда не увидят этот URL.

• Google AMP просмотр URL — документ отображается в инструментах для просмотра AMP-сайтов (например, на странице результатов поисковой выдачи Гугл).

Несмотря на то обстоятельство, что одновременно имеются три вида URL-адреса различного происхождения на один и тот же контент, которые могут сбивать с толку веб-мастеров, существует две основные причины, из-за которых разработаны URL-адреса различного вида: это кэширование и предварительная визуализация AMP-страниц. Обе причины вносят свой вклад в развитие ускоренных AMP-страниц, но требуют новых URL-адресов.

Почему необходимы изменённые URL-адреса? Ответ на этот вопрос связан с принципами дизайна AMP-страниц: создать быстрозагружаемые страницы, легкие и понятные для восприятия. AMP-формат пытается решить некоторые проблемы всего мобильного веба, поэтому его компоненты должны быть простыми и понятными для всех.

AMP кэш предоставляет различные преимущества. Например, для небольшого веб-сайта, который не имеет достаточных ресурсов или собственных DNS-записей, чтобы представить пользовательский контент через сложные API-интерфейсы. Или веб-ресурс, который не может оплатить доставку контента через специальные сети доставки контента.

По этой причине, Google AMP Cache использует простое преобразование URL-адреса. Веб-мастер делает доступным контент сайта через конкретный URL-адрес, Google AMP Cache кэширует и обслуживать контент через всемирную инфраструктуру Google. С помощью новых URL создаются зеркала страниц и преобразуется оригинальное содержание веб-сайта.

Это так просто, использовать кэш Гугл для оригинальных URL. В противном случае, веб-мастеру потребуются свои DNS-записи или придётся перенастраивать свои сервера. Некоторые сайты поступают именно так. Однако для подавляющего большинства веб-ресурсов подход с изменением URL гораздо проще в использовании.

В предыдущем разделе подробно рассматривались URL-адреса типа Google AMP Cache - URL, которые указывают на кэшированную версию документа в формате-AMP. Но как быть с адресами типа:

Почему они нужны? Это «AMP Viewer» – URL-адреса для предварительной визуализации ускоренных страниц. Встроенная поддержка AMP сберегает ресурсы пользователей (память и мощность процессора) и позволяет обойтись без кодирования страницы. Эта технология работает для мобильных приложений и мобильных веб-страниц. Потребность в новых URL-адресах связана реализацией мобильных веб-решений.

Когда пользователь задаёт запрос в SEPR, Google мгновенно загружает AMP-страницы, созданные на основе оригинального контента обычных страниц. Визуализация осуществляется при помощи скрытых IFRAME на вложенных AMP-страницах (в результате поиска Гугл). Дополнительный параметр, который указывает, что AMP-документ был предварительно обработан – это компонент JavaScript. Он обрабатывает жизненный цикл этих фреймов и называется «AMP Viewer».

Браузер пользователя загружает документ из выдачи и начинает отображать контент AMP-страницы. На этом этапе не загружаются другие объекты, такие как изображения и вставки, которые управляются AMP. Некоторые объекты могут загружаться, но это делается с учетом имеющихся ресурсов и других ограничений. Когда пользователь нажимает на результат, все, что должен сделать AMP Viewer, это показать iframe, который браузер уже отобразил.

Заметим, эта операция невероятно дешевая: нет сетевой активности или перенаправления пользователя на новую страницу. Это приводит к почти мгновенной загрузке результатов поисковой выдачи.

Вышеперечисленные операции происходят в то время, когда пользователь все еще находится на исходной странице (например, страница с результатами органического поиска). Иначе говоря, до тех пор, пока пользователь не перешел на другую страницу; Пользователь просмотрел содержимое страницы, созданное при помощи IFRAME на той же странице. Поэтому браузер не изменяет URL.

Но Google по-прежнему хочет, чтобы URL-адрес в браузере показывал на страницу, отображаемую на экране, тем самым упрощая связь с пользователями. Когда пользователи нажимают кнопку «Обновить» в своем браузере, они ожидают, что будет отображаться этот же документ, а не страница из результатов поиска. Таким образом, AMP Viewer должен самостоятельно обновить этот URL. Это происходит с помощью History API. Этот API позволяет программе AMP Viewer обновлять URL-адрес браузера без необходимости жесткой навигации.

Вопрос заключается в том, какой URL-адрес должен обновлять браузер. В идеальном случае это будет URL-адрес самого результата (например, www.example.com/amp/doc.html) или URL-адрес кэш-памяти AMP (например, www-example-com.cdn.ampproject.org/www.example.com/amp/doc.html).

Но, к сожалению, ни один из них не подходит. Основное ограничение History API – новый URL-адрес должен быть в том же источнике, что и исходный URL-адрес (ссылка). Это обеспечивается браузерами исходя из соображений безопасности, но это также означает, что в поиске Google (www.google.com) этот URL-адрес должен быть оригинальным.

В предыдущем разделе объяснялись ограничения для URL-адресов, которые должен обрабатывать AMP Viewer. Однако, эти URL-адреса могут вводить в заблуждение пользователей и представлять опасность, связанную с фишинговыми атаками (подмена адресов). Если страница AMP показала страницу входа, которая похожа на Google, а на панели URL-адресов указано www.google.com, как пользователь узнает, что эта страница не имеет отношение к Google? Вот здесь и возникает потребность в дополнительной атрибуции. Чтобы обеспечить надлежащее установление происхождения контента, каждый AMP Viewer должен показать пользователям, откуда загружается контент, который они просматривают. Один из способов атрибуции – добавить заголовок в Header Bar. Он отображает «истинное» происхождение оригинальной страницы.

В предыдущих разделах читатели узнали, почему существуют различные URL-адреса и почему в каждом AMP viewer должен быть собственный заголовок. Но что будет дальше? Как вы знаете, Google делает всё возможное, чтобы гарантировать скорость и производительность страниц AMP-формата.

В феврале 2016 года AMP-страницы запущены в поиске Google. За это время сделано следующее:

• Все URL-адреса Google (например, URL Google AMP Cache и Google AMP Viewer URL) наилучшим образом отображают оригинальный источник контента.
• Когда пользователи прокручивают страницу вниз, чтобы прочитать весь документ, скрывается панель заголовка (Header Bar). Это увеличивает видимую часть экрана.
• Когда пользователи просматривают страницу через платформу, где недоступен Google AMP viewer URL, Гугл перенаправляет их на каноническую страницу документа.

В дополнение к вышесказанному, многие пользователи запросили способ доступа, копирования и совместного использования канонического URL-адреса документа. Сегодня добавляется поддержка этой функции в виде кнопки, находящейся в заголовке AMP Viewer в Google Search. Эта функция улучшит функциональность пользовательских браузеров.

В ближайшие недели Android-приложение будет использовать исходный URL-адрес документа, когда пользователь нажимает кнопку для общего доступа. Эта функциональность уже доступна в приложении Google для iOS.

Наконец, ведутся работы над внедрением API-интерфейсов веб-платформы, которые позволяют еще больше улучшить эту функциональность. Один из таких API – это API общего доступа (Web Share API) к веб-ресурсам, который позволит при просмотре AMP-страниц вызывать собственный поток совместного доступа к платформе с исходным URL-адресом, а не URL-адресом для просмотра AMP.

© WaterMillSky 2012-2021