Среда, 9 ноября 2016 г.
Progressive Web Apps
(PWA) используют новые технологии, чтобы предоставить пользователям лучшее от мобильных сайтов и нативных приложений — и это одна из самых захватывающих новых идей в Интернете. Но чтобы они действительно приносили пользу, важно, чтобы они были индексируемыми и на них можно было ссылаться. Каждая рекомендация, представленная в этой статье, является существующей передовой практикой для индексации — независимо от того, создаете ли вы Progressive Web App или простой статический веб-сайт. Тем не менее, мы собрали эти передовые практики, чтобы предоставить вам контрольный список для руководства:
Сделайте ваш контент доступным для сканирования
Почему? Исторически сложилось так, что веб-сайты всегда генерировали или отображали свой HTML на сервере, что является самым простым способом гарантировать, что ваш контент можно напрямую связать ссылкой. Веб-приложения популяризировали концепцию клиентского рендеринга, при котором контент динамически обновляется на странице по мере навигации пользователя без необходимости перезагрузки страницы.
Современный подход — это гибридный рендеринг, при котором серверный рендеринг используется, когда пользователь переходит непосредственно по URL, а клиентский рендеринг используется после первоначальной загрузки страницы для последующей навигации и асинхронных запросов.
Наш
пример серверного PWA
демонстрирует чистый серверный рендеринг, в то время как наш
пример гибридного PWA
демонстрирует комбинированный подход.
Если вы не знакомы с терминологией серверного и клиентского рендеринга,
ознакомьтесь с этими статьями оклиентском и серверном рендеринге
, а также
серверном рендеринге в react и node.js.
Передовые практики:
Используйте серверный или гибридный рендеринг, чтобы пользователи получали контент при первоначальной загрузке своего веб-запроса.
Всегда следите за тем, чтобы ваши URL-адреса были доступны независимо:
Вышеуказанное должно содержать глубокую ссылку на этот конкретный ресурс.
Если вы не можете поддерживать серверный или гибридный рендеринг для своего Progressive Web App и решили использовать клиентский рендеринг, мы рекомендуем использовать инструмент “Fetch as Google” в Google Search Console, чтобы убедиться, что ваш контент успешно отображается для нашего поискового робота.
Не перенаправляйте пользователей, переходящих по глубоким ссылкам, обратно на домашнюю страницу вашего веб-приложения.
Кроме того, следует избегать показа пользователям страницы ошибки вместо глубокой ссылки.
Предоставляйте чистые URL-адреса Почему?Идентификаторы фрагментов ( #user/24601/ или#!user/24601/
) были эффективным обходным путем для браузеров, позволяющим получать новый контент с сервера через AJAX без перезагрузки страницы. Этот дизайн известен как клиентский рендеринг. Однако синтаксис идентификатора фрагмента несовместим с некоторыми веб-инструментами, фреймворками и протоколами, такими как.
протокол Open Graph от Facebook History API позволяет нам обновлять URL без идентификаторов фрагментов, при этом получая ресурсы асинхронно и, следовательно, избегая перезагрузок страницы — это лучшее из обоих миров. Схема сканирования AJAX #! (с ее
#! URL-адресами с экранированными фрагментами) имела смысл в свое время, но сейчас больше не рекомендуется. Наши
примеры гибридного PWA и клиентского PWA
демонстрируют работу History API.
Передовые практики:# Предоставляйте чистые URL-адреса без идентификаторов фрагментов ( #!или
) например:
Если вы используете клиентский или гибридный рендеринг, обязательно поддерживайте навигацию в браузере с помощью History API.
Избегайте: #! Использования
структуры URL для управления уникальными URL-адресами не рекомендуется: # Она была введена как обходной путь до появления History API. Это считается шаблоном,
отличным от чистого URL-структуры. # Использование ! структуры URL без сопутствующего
символа не поддерживается:
https://www.example.com/#product/25/
Эта структура URL уже является концепцией в Интернете и относится к глубоким ссылкам на контент на определенной странице.
Указывайте канонические URL-адреса Почему?
Лучший способ устранить путаницу при индексации, когда один и тот же контент доступен по нескольким URL-адресам (будь то одни и те же или разные домены), — это пометить одну страницу как каноническую и сделать так, чтобы все остальные страницы, дублирующие этот контент, ссылались на нее.
Передовые практики:
Включите следующий тег на всех страницах, дублирующих определенный фрагмент контента:
Если вы поддерживаете Accelerated Mobile Pages, обязательно правильно используйте его аналог rel=”amphtml”
инструкцию.
Избегайте:
Избегайте намеренного дублирования контента по нескольким URL-адресам и неиспользования rel=”canonical”
элемента ссылки. Например, rel=”canonical”
элемент ссылки может уменьшить двусмысленность для URL-адресов с параметрами отслеживания.
Избегайте создания противоречивых канонических ссылок между вашими страницами.
Дизайн для нескольких устройств Почему?
Важно, чтобы все ваши пользователи получали наилучшие впечатления при просмотре вашего веб-сайта, независимо от их устройства. Сделайте ваш сайт
в его дизайне
—шрифты, поля, отступы, кнопки и общий дизайн вашего сайта должны динамически масштабироваться в зависимости от разрешения экрана и области просмотра устройства.
Маленькие изображения, масштабированные для настольных компьютеров или планшетов, создают плохое впечатление. И наоборот, изображения со сверхвысоким разрешением долго загружаются на мобильных телефонах и могут повлиять на производительность прокрутки на мобильных устройствах.
Подробнее о
UX для PWA.
Рекомендации:
Используйте
атрибут srcset
для получения изображений с разным разрешением для экранов с разной плотностью, чтобы избежать загрузки изображений, размер которых превышает возможности экрана устройства.
Масштабируйте размер шрифта и высоту строки, чтобы текст оставался читабельным независимо от размера устройства. Аналогичным образом убедитесь, что отступы и поля элементов также масштабируются разумно.
Протестируйте
различные разрешения экрана
используя
функцию режима устройства в инструментах разработчика Chrome
и
инструмент проверки удобства для мобильных устройств.
Не показывайте пользователям контент, отличный от того, который вы показываете Google. Если вы используете
перенаправления или определение агента пользователя
(также известное как определение браузера или
динамическая подача) для изменения дизайна вашего сайта для разных устройств, важно, чтобы сам контент оставался прежним.
Используйте инструмент “Просмотреть как Google” в Search Console, чтобы убедиться, что контент, полученный Google, соответствует контенту, который видит пользователь.
Из соображений удобства использования избегайте использования шрифтов фиксированного размера.
Разрабатывайте итеративно
Почему? Один из самых безопасных путей при добавлении функций в веб-приложение — вносить изменения итеративно. Если вы добавляете функции по одной, вы можете наблюдать влияние каждого отдельного изменения.
Альтернативно, многие разработчики предпочитают рассматривать свое прогрессивное веб-приложение как возможность обновить свой мобильный сайт одним махом — разрабатывая новое веб-приложение в изолированной среде и заменяя им существующий мобильный сайт, как только оно будет готово.
При итеративной разработке функций старайтесь разбивать изменения на отдельные части. Например, если вы намерены перейти от рендеринга на стороне сервера к гибридному рендерингу, решайте это как отдельную итерацию, а не в сочетании с другими функциями.
Оба подхода имеют свои плюсы и минусы. Итерация снижает сложность работы с индексируемостью поиска, поскольку переход является непрерывным. Однако итерация может привести к более медленному процессу разработки и, возможно, к менее инновационному обновлению, если разработка не начинается с нуля.
В любом случае, наиболее чувствительными областями, за которыми следует следить, являются ваши канонические URL-адреса и конфигурация robots.txt вашего сайта.
Рекомендации:
Итерируйте свой веб-сайт постепенно, добавляя новые функции по частям.
Например, если вы еще не поддерживаете HTTPS, начните с миграции на безопасный сайт.
Избегайте:
Если вы разработали свое прогрессивное веб-приложение в изолированной среде, избегайте его запуска, не проверив, правильно ли настроены ссылки rel-canonical и robots.txt.
Убедитесь, что ваши ссылки rel-canonical указывают на реальный сайт и что ваша конфигурация robots.txt позволяет поисковым роботам сканировать ваш новый сайт.
Логично запретить поисковым роботам индексировать ваш сайт, находящийся в разработке, до запуска, но не забудьте разблокировать доступ роботов к вашему новому сайту при запуске.
Используйте прогрессивное улучшение
Почему? По возможности важно обнаруживать функции браузера перед их использованием. Обнаружение функций также лучше, чем тестирование браузеров, которые, по вашему мнению, поддерживают данную функцию.
Распространенной плохой практикой в прошлом было включение или отключение функций путем тестирования того, какой браузер у пользователя. Однако, поскольку браузеры постоянно развиваются, эта техника настоятельно не рекомендуется.
Service Worker — это относительно новая технология, и важно не нарушать совместимость в погоне за прогрессом — это идеальный пример того, когда следует использовать прогрессивное улучшение.
Рекомендации:
Перед регистрацией Service Worker проверьте доступность его API:
Используйте метод обнаружения для каждого API для всех функций вашего веб-сайта.
Никогда не используйте агент пользователя браузера для включения или отключения функций в вашем веб-приложении. Всегда проверяйте, доступен ли API функции, и корректно деградируйте, если он недоступен.
Избегайте обновления или запуска вашего сайта без тестирования в нескольких браузерах! Проверьте аналитику вашего сайта, чтобы узнать, какие браузеры наиболее популярны среди вашей базы пользователей.
Тестируйте с помощью Search Console
Почему? Важно понимать, как Google Search видит контент вашего сайта. Вы можете использовать
Search Console чтобы
получать отдельные URL-адреса с вашего сайта
и видеть, как Google Search видит их, используя функцию “Сканирование > Просмотреть как Google”. Search Console обработает ваш JavaScript и отрендерит страницу, если выбрана эта опция; в противном случае отображается только необработанный HTML-ответ.
Google Search Console также анализирует контент на вашей странице различными способами, включая обнаружение наличия структурированных данных, Rich Cards, ссылок на сайты и ускоренных мобильных страниц.
Рекомендации:
Контролируйте свой сайт с помощью Search Console и изучайте его функции, включая “Просмотреть как Google”.
Предоставьте карту сайта через Search Console Сканирование > Карты сайта. Это может быть эффективным способом убедиться, что Google Search знает обо всех страницах вашего сайта.
Аннотируйте с помощью структурированных данных Schema.org
Почему? Schema.org структурированные данные — это гибкий словарь для обобщения наиболее важных частей вашей страницы как данных, обрабатываемых машиной. Это может быть как общим, например, просто сказать, что страница является NewsArticleтак и конкретным, например, детализация местоположения, названия группы, места проведения и продавца билетов для гастролирующей группы, или обобщение ингредиентов и шагов для рецепта.
Использование этих метаданных может не иметь смысла для каждой страницы вашего веб-приложения, но рекомендуется там, где это целесообразно. Google извлекает их после рендеринга страницы.
Существует множество типов данных, включая NewsArticle, Recipeи
Product и это лишь некоторые из них. Вы также можете изучить все
поддерживаемые типы данных здесь.
Рекомендации:
Убедитесь, что ваши метаданные Schema.org верны, используя
инструмент тестирования структурированных данных.
от Google. Проверьте, отображаются ли предоставленные вами данные и нет ли ошибок. Избегайте использования типа данных, который не соответствует фактическому контенту вашей страницы. Например, не используйте
fr
Рецепт для футболки, которую вы продаете—используйте Продукт вместо этого.
Аннотируйте с помощью Open Graph и Twitter Cards
Почему? В дополнение к метаданным Schema.org может быть полезно добавить поддержку протокола Open Graph от Facebook и Twitter rich cards.
Эти форматы метаданных улучшают пользовательский опыт, когда ваш контент распространяется в соответствующих социальных сетях.
Если ваш существующий сайт или веб-приложение использует эти форматы, важно убедиться, что они также включены в ваше progressive web application для оптимальной виральности.
Лучшие практики:
Протестируйте свою разметку Open Graph с помощью
Facebook Object Debugger Tool.
Ознакомьтесь с
форматом метаданных Twitter.
Не забудьте включить эти форматы, если ваш существующий сайт их поддерживает.
Тестируйте в нескольких браузерах
Почему? Очевидно, что с точки зрения пользователя важно, чтобы веб-сайт вел себя одинаково во всех браузерах. Хотя опыт может адаптироваться к разным размерам экрана, мы все ожидаем, что мобильный сайт будет работать одинаково на устройствах схожего размера, будь то iPhone или мобильный телефон на Android.
Хотя веб может восприниматься как фрагментированный из-за количества браузеров, используемых по всему миру, это разнообразие и конкуренция являются частью того, что делает веб такой инновационной платформой. К счастью, веб-стандарты никогда не были такими зрелыми, как сейчас, и современные инструменты позволяют разработчикам с уверенностью создавать насыщенные, кроссбраузерные совместимые веб-сайты.
Лучшие практики:
Используйте инструменты кроссбраузерного тестирования, такие как
BrowserStack.com,
Browserling.com или
BrowserShots.org чтобы убедиться, что ваше PWA
кроссбраузерно
совместимо. Измеряйте производительность загрузки страницы
Почему?
Чем быстрее веб-сайт загружается для пользователя, тем лучше будет его пользовательский опыт. Оптимизация скорости страницы уже является хорошо известным направлением в веб-разработке, но иногда при разработке новой версии сайта необходимые оптимизации не считаются приоритетными.
При разработке progressive web application мы рекомендуем измерять производительность скорости загрузки вашей страницы и оптимизировать ее перед запуском сайта для достижения наилучших результатов.
Лучшие практики: Используйте такие инструменты, как
Page Speed Insights
и
Web Page Test
для измерения производительности загрузки страниц вашего сайта. Хотя у Googlebot немного больше терпения при рендеринге,
исследования показали,
что 40% потребителей покинут страницу, загрузка которой занимает более трех секунд..
Узнайте больше о наших рекомендациях по производительности веб-страниц и
критическом пути рендеринга здесь
Избегайте откладывания оптимизации на этап после запуска. Если контент вашего веб-сайта загружается быстро до миграции на новое progressive web application, важно не допустить регресса в ваших оптимизациях.
Мы надеемся, что приведенный выше контрольный список полезен и предоставляет правильное руководство, которое поможет вам разрабатывать ваши Progressive Web Applications с учетом индексируемости.
Когда вы начнете, обязательно ознакомьтесь с нашими
примерами индексируемости Progressive Web App.
Как мы это применяем
We archive Search Central announcements because client questions often trace back to a change that was announced years ago. Reading the original is faster than reconstructing it from second-hand summaries.
Связанные услуги