Веб-упаковка | Перспектива некоммерческого издателя | Дэн Йорк

Оглавление

Предпосылка
Случаи применения
Доступность — Мобильное кэширование / предварительная выборка
Доступность — среда с низкой пропускной способностью / высокой задержкой
Доступность — Экстремальный пример
Обнаруживаемость — результаты мобильного поиска
Выбор консолидации или сложности
Ищу Стандарты
Вопросы, которые я бы хотел обсудить
Личные предпосылки

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

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

Однако существует опасность, что, если не сделать это в качестве открытого стандарта, который будет широко распространен, общий формат веб-упаковки может укрепить текущую консолидацию на уровне контента в Интернете.

Мы должны обеспечить, чтобы любой распространенный формат веб-упаковки не закреплял «привратников» контента, а скорее способствовал бы открытому Интернету, в котором могут участвовать все голоса.

Предпосылка

Internet Society (ISOC) — это глобальная некоммерческая организация, которая напрямую управляет коллекцией из более чем 20 веб-сайтов. Эти сайты в основном используют WordPress в качестве системы управления контентом (CMS). Большинство сайтов в настоящее время размещаются у поставщика управляемого хостинга, сервис которого основан на серверах Amazon Web Services (AWS). Большинство сайтов используют сеть доставки контента Amazon Cloudfront (CDN).

Кроме того, в Internet Society насчитывается более 130 глав и специальных групп интересов (SIGs — Special Interest Groups). Это отдельные юридические организации, которые самостоятельно управляют своими индивидуальными веб-сайтами. Они разделяют многие из тех же целей и вариантов использования глобальной организации, и потенциально могут реализовать многие из тех же преимуществ открытого стандарта для веб-упаковки.

Примечание: автор является сотрудником интернет-сообщества, но этот документ не отражает позицию интернет-сообщества. Этот фон предоставляется для контекста.

Случаи применения

С видением «Интернет для всех», часть нашего мандата в команде стратегических коммуникаций Internet Society заключается в следующем:

  • Убедитесь, что наш контент ИМЕЕТСЯ В НАЛИЧИИ (available) для всех и везде.
  • Убедитесь, что наш контент ОБНАРУЖИВАЕТСЯ (discoverable) для всех и везде.

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

Доступность — Мобильное кэширование / предварительная выборка

Основной вариант использования заключается в обеспечении лучшего пользовательского опыта для мобильных пользователей за счет повышения производительности мобильных веб-страниц с помощью систем кэширования и предварительной выборки. В нашей аналитике мы видим постоянный рост числа мобильных пользователей. Благодаря своему опыту работы с пользователями я видел увеличение скорости за счет посещения сайтов с использованием ускоренных мобильных страниц Google (AMP), мгновенных статей Facebook или новостей Apple. Сайты кажутся почти сразу видимыми, в отличие от ожидания загрузки обычного веб-сайта.

Доступность — среда с низкой пропускной способностью / высокой задержкой

Значительная часть нашей работы связана с охватом людей, которые живут в тех частях света, где подключение к Интернету ограничено. В некоторых местах людям приходится приносить свои смартфоны или ноутбуки в локальные сети с Wi-Fi и загружать контент через это соединение. Было бы идеально иметь возможность предоставить им пакет соответствующих страниц, которые они могли бы загрузить на свое устройство, находясь в точке доступа Wi-Fi, а затем иметь возможность читать и использовать их позже, находясь в автономном режиме.

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

Содержание может быть:

  • информация о грантовых программах, которые могли бы помочь увеличить связь
  • информация о том, как сделать свои локальные системы более безопасными
  • многостраничное руководство или руководство по безопасности маршрутизации
  • набор последних сообщений в блоге, чтобы помочь человеку оставаться в курсе того, что делает организация
  • документация о том, как начать главу или стать участником
  • или много других наборов контента.

В настоящее время мы используем CDN для оптимизации доставки нашего контента в такие места, как это. Но мы можем увидеть выгоду в некоторой форме упаковки, которая может быть доставлена CDN от нашего имени.

Важно отметить, что следует соблюдать осторожность, чтобы «пакет» не был настолько большим, чтобы его загрузка в среде с низкой пропускной способностью и высокой задержкой заняла много времени. Эта проблема должна быть учтена при размышлении о том, как создать пакет.

Среда с низкой пропускной способностью — это место, где, как я вижу, работа «с подписью», предложенная как часть текущего предложения по веб-упаковке, может быть полезной. Я мог видеть случай, когда кто-то мог загрузить пакет содержимого из точки доступа WiFi на устройство, а затем поделиться этим пакетом с кем-то еще через другое соединение локальной сети (например, соединение Bluetooth между устройствами). Второму получателю было бы очень полезно знать наверняка, что пакет произошел с наших сайтов в его текущей форме.

Доступность — Экстремальный пример

Чтобы быть более конкретным, давайте рассмотрим более крайний случай. Один из наших сайтов, Фонд интернет-общества, предоставит гранты для различных проектов, в том числе для расширения связей в различных регионах мира. В настоящее время мы финансируем несколько проектов, создающих «общественные сети» в разных частях мира.

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

Теперь представьте, что вы находитесь в отдаленной деревне инуитов в Арктике, которая, возможно, имеет доступ к Интернету только через одну из различных спутниковых систем, которые обеспечивают периодическое подключение. Ваш доступ в Интернет ограничен временем, когда один из спутников проходит над головой. Во время одного прохода вы можете узнать о грантах Фонда или каким-то образом оказаться на сайте Фонда. Может быть, вы можете прочитать первую страницу или около того … но затем спутник выходит за пределы диапазона. Теперь вам нужно дождаться следующего прохождения спутника, чтобы получить следующую страницу (и) информации. И, может быть, вы получите всю информацию на следующем проходе … или, может быть, вам не нужно ждать следующего прохода … или, может быть, вы сдаетесь.

Мне кажется, что гораздо лучше было бы иметь какой-то способ упаковать набор страниц, чтобы, если кто-то заходит, скажем, на страницу «Средние и крупные гранты», он на самом деле получает пакет всех различных страниц. необходимо подать заявку на грант. Человек в удаленном сообществе может снять весь этот пакет за один проход. Затем они могли читать всю необходимую им информацию, не дожидаясь следующего спутникового прохода.

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

Хотя это может быть крайним примером, во всем мире существует много удаленных сообществ с такими проблемами подключения.

Обнаруживаемость — результаты мобильного поиска

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

В текущих платформах мы видим, что в результатах мобильного поиска приоритет отдается контенту, использующему формат упаковки этой платформы. Мобильный поиск Google поддерживает сайты, предлагающие контент AMP. Результаты Facebook одобряют сайты, предлагающие мгновенные статьи Apple News будет показывать только сайты, использующие его формат.

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

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

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

Выбор консолидации или сложности

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

Как и многие некоммерческие организации, мы не располагаем ресурсами для поддержки пользовательских разработок. Вместо этого мы полагаемся на «плагины», встроенные в большую экосистему разработчиков WordPress. Прямо сейчас, чтобы поддерживать различные форматы / системы упаковки, мы должны установить разные плагины для каждой платформы. Это добавляет сложности к нашему сайту. По мере установки дополнительных плагинов, вы:

  • увеличиваете вероятность конфликтов между плагинами;
  • снижаете безопасность сайта, так как вы добавляете больше кода от внешних поставщиков;
  • увеличиваете административные потери в плане обновлений;
  • увеличиваете общий размер сайта для резервных копий;
  • увеличиваете нагрузку на систему, что может привести к снижению производительности; а также
  • увеличиваете проблемы при устранении любых проблем на сайте.

По этим причинам мы стараемся не добавлять на сайт слишком много дополнительных плагинов. Уровень сложности для поддержки всех существующих систем упаковки — это больше, чем мы хотим добавить на наши сайты.

Однако, если мы решим поддерживать только одну мобильную систему кэширования / предварительной выборки, мы затем блокируем себя обнаруживаемость — мобильные Результаты поиска, выбирающие консолидацию — или сложность в этой одной платформе. Мы также подпитываем продолжающуюся консолидацию, которую я вижу в пространстве интернет-контента.

Ищу Стандарты

В моем идеальном мире была бы одна форма веб-упаковки, которую мы могли бы генерировать на наших сайтах, которая затем могла бы использоваться несколькими различными системами кэширования / предварительной выборки. Это позволило бы нам, например, установить только один плагин и создать один канал.

Вопросы, которые я бы хотел обсудить

На семинаре ESCAPE, помимо обсуждения того, как стандартизированная спецификация веб-упаковки может соответствовать описанным выше вариантам использования, некоторые из моих дополнительных вопросов включают в себя:

  • Если спецификация веб-упаковки может быть стандартизирована через IETF или другие органы по стандартизации, какое обязательство мы можем увидеть на основных платформах для принятия и продвижения этого стандарта?
  • Каковы условия, при которых стандартизированная спецификация веб-упаковки может помочь обеспечить, чтобы контент в Интернете оставался открытым и не все больше находился под контролем больших платформ?
  • В каких условиях такой стандарт может привести к централизации / консолидации?
  • Как мы можем войти в процесс стандартизации таким образом, чтобы избежать условий, ведущих к централизации?
  • Как веб-упаковка может привести к сценариям, которые помогают децентрализации?
  • Как можно создать веб-упаковку таким образом, чтобы в Интернете можно было также просматривать голоса некоммерческих организаций, частных лиц и других небольших организаций?

Личные предпосылки

В настоящее время я работаю в Internet Society в качестве директора по веб-стратегии (Director of Web Strategy), управляющего небольшой командой, отвечающей за публикацию контента на наших различных сайтах, а также за разработку многих аспектов сайтов. Моя роль также включает поисковую оптимизацию (SEO — search engine optimization), поисковый маркетинг (SEM — search engine marketing) и все аспекты аналитики на наших сайтах. Я работал с Интернетом с середины 1980-х годов и с Интернетом с первых дней в начале 1990-х годов. С тех пор я создавал веб-сайты, используя широкий спектр систем, фреймворков и CMS, уделяя особое внимание WordPress с 2005 года. В мои обязанности входили команды, управляющие веб-сайтами как для коммерческих/для получения прибыли, так и для некоммерческих работодателей, и я принимал участие стратегические/политические/деловые и тактические/исполнительные аспекты.

В рамках IETF я принимаю участие в списке рассылки WPACK и встречах с глазу на глаз со времени первого побочного совещания на IETF 101.

Как отмечалось ранее, этот документ представляет собой личное представление и не представляет позицию интернет-общества.

Ссылка на оригинал публикации

https://www.iab.org/wp-content/IAB-uploads/2019/06/dan-york.pdf

Дата публикации оригинала

7 июня 2019 г.

Поделись записью