Что Google AMP означает для JavaScript сообщества

Перевод статьи What Google AMP means for the JavaScript community от Mathias Schäfer

Не думая о производительности веба, сообщество JavaScript ненамеренно проложило путь для AMP.

Проект Google Accelerated Mobile Pages (AMP) фокусирует текущие противоречия в Интернете как линза: мобильную революцию, надежную и устойчивую журналистику, монетизацию и рекламу контента, стандартизацию сети, производительность сети и монополию в области технологий.

Много сказано об AMP. В этом посте я не буду объяснять, что такое AMP, и я не буду повторять всю критику, которую он вызвал. Пожалуйста, ознакомьтесь с этими вводными статьями:

• Everything You Need To Know About AMP (Все, что вам нужно знать о AMP)
• In AMP we trust (Мы верим в AMP)
• Need to Catch Up on the AMP Debate? (Нужно ли наладить обсуждение на AMP?)
• AMP conf 2017: Fireside chat: AMP and the web (AMP conf 2017: чат укамина: AMP и интернет)

Я хотел бы поговорить об одной детали всей картины AMP проекта: это использование JavaScript и его позиция по использованию JavaScript.

Проблема JavaScript

Поскольку я связался с JavaScript, я размышлял о возможных, разумных и полезных применениях JavaScript. С тех пор как JavaScript набрал силу в интернете, он был неправильно и чрезмерно использован. Раздражающие всплывающие окна. Нарушение взаимодействия с пользователем. Хрупкий, зависящий от конкретного браузера, недоступный код. Использование JavaScript, когда более надежная технология, расположенная ниже в стеке, была бы лучшим инструментом.

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

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

Пользователь мобильного веба испытывает разочарование, и JavaScript, по крайней мере, частично виноват. К сожалению, проблема производительности JavaScript сложна. Вот неполный обзор:

• Множество скриптов грузится с нескольких серверов. На некоторых сайтах скрипты сторонных сервисов преобладают и выходят из-под контроля.
• Скрипты большие. Они генерируют сетевой трафик и тратят деньги пользователей.
• Код сценариев, особенно код библиотеки и фреймворков, в основном не используется на странице. Одинаковый код загружается несколько раз.
• Загрузка, анализ и выполнение скриптов блокирует загрузку и отрисовку самого важного контента.
• Сценарии загружают контент отложенно, поэтому страница постепенно наполняется. Контент перескакивает, что ломает интерактивность пользователя и сажает батарею.
• Выполнение скрипта использует ЦП, препятствуя взаимодействию с пользователем и истощая батарею.
• Скрипты нарушают цикл рендеринга браузера, вызывая рывки и прерывания.
• Скрипты по-прежнему нестабильны из-за сбоя сети, разных браузерных рантаймов и проблем совместимости.
• Скрипты рекламы и аналитики собирают данные об устройстве, создают профиль пользователя и сохраняют его в локальном хранилище, нарушая конфиденциальность пользователя.

Важно понимать, что проблема JavaScript лежит в основе жалкого состояния производительности веба.

Оптимизация производительности отстаёт

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

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

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

Google показывает свою рыночную силу

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

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

Два шага необходимы, чтобы разрубить гордиев узел веб-производительности:

• Экспертиза и средства для создания жизнеспособного решения.
• Ресурсы использовать и продвигать это решение.

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

Кроме Google.

Авторитарное решение

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

Смелый шаг, который капиталисты из Силиконовой долины наверняка похвалили бы как «разрушительный», Google решил убрать весь беспорядочный код JavaScript, который замедляет работу в интернете. Так появились ускоренные мобильные страницы (AMP).

Создание жизнеспособного решения — это лишь половина работы. Распространить его на весь веб — другая. Поэтому Google даёт преимущество страницам AMP в мобильном поиске Google. Страницы AMP отображаются в «новостной карусели» вверху и отмечены символом молнии. Они загружаются «встроенно», поэтому навигация между списком результатов поиска и сайта кажется мгновенной.

Один JavaScript, чтоб править всеми

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

С AMP вам нужен только один JavaScript, так называемый AMP runtime. Это JavaScript с открытым исходным кодом, разработанный Google. Это не библиотека, которую вы можете использовать в своем собственном JavaScript. На самом деле, вы больше не должны писать JavaScript. Вместо этого вы объявляете пользовательские элементы в своем HTML и AMP JavaScript превращает их в интерактивные компоненты.

Загрузка стороннего кода JavaScript для рекламы, видеоконтента и виджето соцсетей возможна, но она контролируется и становится безвредной при помощи AMP. Сторонний код больше не мешает загрузке основного контента.

JavaScript AMP не особенно мал и не написан революционно новым способом. Инфраструктура скрипта и его компоненты просто придерживаются установленных принципов, которые в конечном итоге приводят к высокой производительности. В этом, AMP — отличный пример инженерной работы, который устанавливает новый стандарт для веб-интерактивности.

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

Сообщество Open Web должно признать поражение

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

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

В частности, сообществу JavaScript не удалось устранить необузданное злоупотребление JavaScript и негативное влияние JavaScript на производительность веб-сайта. Средний сайт в настоящее время загружает 23 скрипта общим объемом 426 кбайт сжатого кода JavaScript. Сегодня легко настроить проект с помощью React, Angular или даже jQuery, добавить некоторые распространенные сторонние скрипты и в конечном итоге закончить с мегабайтами блокирующего кода JavaScript, грузящегося с нескольких серверов.

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

Демократизируя производительность веба

Неудивительно, что одностороннее, авторитарное решение более эффективно, чем разбросанные усилия экспертов по JavaScript и веб-производительности. Но не желательно и не устойчиво создавать «вторую паутину», в первую очередь для поиска Google для мобильных устройств. Запрет всего существующего JavaScript и переписывание его с нуля — не жизнеспособное решение. Таким образом, влияние AMP на большую сеть пока неясно.

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