Блог·6 февраля 2017

Роль URL адресов в AMP

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

В чём значение адреса? В интернете оно весьма велико — URL-адреса и домены во многом являются гарантией доверия к контенту и обозначают собственность на него. Если вы читаете статью с New York Times, взгляда на URL достаточно, чтобы создать веру в то, что открытый вами документ представляет голос уважаемого издания. Кто автор материала, чей это бренд, и кто владелец прав на статью — ответы на все эти вопросы очевидны.

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

Итак, начнём. В документах AMP есть три разновидности URL-адресов:

  • Оригинальный URL: документ издателя, записанный в формате AMP
    http://www.example.com/amp/doc.html
  • URL кэша AMP. Документ, отправленный через кэш AMP (к примеру, все предоставляемые поиском Google страницы AMP подаются через Google AMP Cache). Большинство пользователей никогда не видит эти URL.
    https://www-example-com.cdn.ampproject.org/c/www.example.com/amp/doc.html
  • URL в инструменте Google для просмотра страниц AMP. Это документ, который отображается пользователю (например, при загрузке со страницы результатов поиска).
    https://www.google.com/amp/www.example.com/amp.doc.html
amp url

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

URL-адреса кеша AMP

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

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

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

URL-адреса в инструменте просмотра AMP

В предыдущем разделе мы узнали о принципах работы URL-адресов в кэше AMP – они направляют пользователя на кэшированный вариант документа в AMP. Но что насчёт адресов, начинающихся с http://www.google.com/amp, для чего нужны они? Это адреса «инструмента просмотра AMP», которые помогают обеспечивать предзагрузку.

В AMP встроены технологии предварительной загрузки, которая сохраняет вашу приватность и бережёт ресурсы, но об этом редко говорят, а когда говорят – не всегда правильно понимают. Документы AMP проходят предварительную обработку без необходимости загрузить каскад дополнительных ресурсов, без перегрузки процессора на устройстве пользователя, без запуска нарушающего приватность кода. И эти принципы работают независимо от того, осуществляется ли переход на AMP с мобильной веб-страницы или с установленного на устройстве приложения.

Как работает предварительная загрузка?

Когда пользователь осуществляет поиск в Google, получая результаты с поддержкой AMP, часть из них заранее подвергается предварительной загрузке. Поэтому при нажатии на одну из таких ссылок страница отображается мгновенно.

Предварительная обработка работает за счёт того, что на странице, с которой осуществляется переход, осуществляется загрузка скрытого фрейма с содержимым страницы в AMP и дополнительного параметра, устанавливающего, что для AMP-документа производится только предварительная загрузка. Компонент JavaScript, обеспечивающий работу этих фреймов, называется “AMP Viewer”, то есть инструмент просмотра AMP.

amp url

Инструмент просмотра AMP осуществляет предварительную загрузку документа AMP с помощью скрытого фрейма.

Браузер пользователя загружает документ и среду выполнения AMP, после чего начинает загрузку страницы AMP. Поскольку именно эта среда управляет всеми прочими ресурсами, включая изображения и встроенные приложения, на этом этапе не загружается ничего лишнего. Иногда среда выполнения AMP может решить загрузить те или иные ресурсы, но это будет сделано с учётом интересов экономии и приватности.

При нажатии на результат поиска инструменту просмотра AMP нужно только продемонстрировать уже загруженный браузером фрейм и сообщить среде выполнения о том, что теперь AMP-документ должен отображаться.

Это очень простая и дешёвая операция – никакой загрузки сети или прямого перенаправления на новую страницу. В результате получаем почти мгновенную загрузку нужных результатов.

Откуда берутся адреса, начинающиеся с google.com/amp?

Описанные выше процессы происходят, пока пользователь ещё находится на стандартной странице (в нашем примере – странице с результатами поиска). Иными словами, пользователь не перешёл на другую страницу, а просто просмотрел фрейм, выполненный на той же странице, поэтому браузер не поменял адрес.

Но нам всё равно хочется, чтобы адрес в браузере отражал страницу, на которой мы в данный момент находимся, и чтобы было легко делиться ссылкой на любые сайты. Когда пользователи обновляют страницу, в итоге они ожидают увидеть документ, который они ранее просматривали, а не страницу с результатами, поэтому инструменту просмотра AMP приходится вручную обновлять адрес. Для этого используется History API, позволяющая инструменту просмотра обновить адресную строку браузера без реального перехода на другую страницу.

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

Зачем мы отображаем верхнюю строку

Выше я объяснил, какие ограничения на URL-адреса приходится вводить в инструменте просмотра AMP. Но эти адреса могут сбить с толку, более того, они могут использоваться для фишинга. Если AMP покажет страницу входа в учётную запись, которая выглядит как страница Google, а в адресной строке будет написано http://www.google.com, как пользователю понять, что это ненастоящая страница Google? Именно поэтому нужна дополнительная атрибуция.

Чтобы произвести правильную атрибуцию, любой инструмент просмотра AMP должен дать понять пользователю происхождение контента, который он просматривает. Один из способов сделать это – добавить верхнюю строку, которая отобразит «реальный» домен страницы.

amp url

Верхняя строка в инструменте просмотра AMP

Что дальше?

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

С момента запуска технологии AMP в поиске Google в феврале 2016 г. мы предприняли следующие шаги:

  • URL-адреса Google (например, адреса кэша AMP Google или адреса в инструменте просмотра AMP от Google) максимально ясно отображают первоисточник контента:
    www.google.com/amp/www.example.com/amp/doc.html
  • Когда пользователи прокручивают страницу при чтении документа, верхняя строчка инструмента просмотра скрывается, освобождая тем самым ценное место на экране.
  • Если пользователи переходят по ссылке из инструмента просмотра AMP от Google на платформе, не поддерживающей этот инструмент, мы просто перенаправляем их на оригинальную страницу документа.

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

amp url

В ближайшие недели приложение Google для Android начнёт отправлять ссылку на изначальный адрес документа при нажатии на кнопку «Поделиться» в приложении. Эта функция уже доступна в приложении Google для iOS.

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

Мы в Google всячески хотим сделать взаимодействие с AMP максимально удобным как для пользователей, так и для издателей. Для нас очень важно успешное функционирование всей экосистемы, а ключевыми элементами этой экосистемы являются атрибуция, доверие пользователей и обеспечение прав собственности. Надеюсь, что этот пост поможет понять, зачем в AMP три разных типа адресов, какую роль они играют в ускорении работы технологии и как мы работаем над тем, чтобы сделать работу AMP в поиске Google ещё более удобной. Наконец, без вашего участия экосистема не сможет успешно развиваться, поэтому присылайте свои отзывы и включайтесь в работу над AMP.