Знаменитая страничка Airbnb на 800Kb. Я ожидал бы большей заботы о производительности от 900+ разработчиков со средней зарплатой 290 000 долларов в год. Даже SublimeText в какой-то момент перестает выделять эту чушь.
В сети появилась тенденция к появлению новых «революционных» методов, которые позволяют делать вещи, которые были возможны десятилетия назад.
AMP
Во-первых, AMP (ускоренные мобильные страницы). Подумайте вот о чем: в целом Интернет не может быть быстрым, поэтому Google изобретает параллельный Интернет, в котором вам просто не разрешают использовать JavaScript. Ах да, и они позволяют вам использовать пару одобренных Google компонентов AMP JS. Но подождите, может ли обычный Интернет работать без JavaScript? Конечно может. Может ли обычный Интернет включать пользовательские компоненты JS? Не сомневайтесь. Это может быть быстро? Netflix недавно обнаружил, что если они удалят 500 КБ JavaScript со статической (!!!) веб-страницы, она будет загружаться НАМНОГО быстрее, и пользователи в целом будут счастливее. Кто бы мог подумать, правда?
Так зачем был нужен AMP? Ну, в основном Google нужно было заблокировать поставщиков контента, которые будут обслуживаться через поиск Google. Но для этого им нужна была хорошая легенда. И они решили продвигать его как решение для повышения производительности.
Дело в том, что веб-разработчики не верят в производительность. Они говорят, что верят, но на самом деле это не так. Они верят в ажиотаж. Поэтому, если вы рекламируете старые трюки под новым именем, разработчики могут сказать: «Теперь, наконец, я могу начать писать быстрые приложения. Спасибо, Google! ». Например, если бы Google когда-либо мешал вам делать это заранее.
«Но AMP новый! <amp-img> делает гораздо больше, чем ! »
Возможно, но что мешает Google, если он действительно намеревается помочь, выпустить его как обычную JS-библиотеку?
Итак, шумиха сработала, многие разработчики купили обложку и поспешили создать параллельную версию каждой веб-страницы, которую они обслуживают, с повышением производительности с поддержкой AMP.
До этого:
«Привет, босс, давайте перепишем наш веб-сайт, чтобы он загружался быстрее!»
«Отвали!»
«Но исследования показывают, что каждая секунда загрузки…»
«Я сказал, отвали!»
Сейчас:
«Привет, босс, давайте перепишем наш сайт с помощью AMP. Это новая технология от Google ..."
«Брось все! Вот возьми $$$ »
«Это также может улучшить…»
«Мне все равно. Начни это СЕЙЧАС! »
Я не говорю, что методы, продвигаемые AMP, плохие или бесполезные. Это хорошие практики. Но ничто не мешает вам следить за ними в обычной сети. Ничто никогда не мешало вам писать эффективные страницы с самого зарождения Интернета. Google почти не изобрел CDN и загрузку асинхронных скриптов. Но никого это не волновало, потому что старые технологии и передовой опыт никогда не были столь заманчивыми, как что-то, называемое «новым».
PWA
Войдите в PWA. Прогрессивные веб-приложения. Или приложения. Прогрессивные веб-приложения. Что бы это ни было.
Итак, идея заключалась в том, чтобы иметь возможность создать нативный опыт, но с веб-стеком. Чего не хватало сети? Установки приложений. Автономного режима. Уведомления (Ew). Работы в фоновом режиме. Да, в основном все. Это все.
Опять же, я не собираюсь говорить, что это неправильно. 1. Это не так. Если вы хотите создать нативное приложение с использованием веб-технологий, вам придется использовать что-то подобное. И это имеет смысл для приложений, таких как список покупок или, я не знаю, будильник?
Проблема с PWA в том, что есть две проблемы.
Во-первых, большинство приложений было бы лучше использовать в качестве веб-сайтов, чем приложений. Веб-сайты загружают каждый ресурс постепенно по мере необходимости, в отличие от приложений, которые должны получать все при установке (поэтому размеры пакетов приложений обычно намного больше, чем у веб-сайтов). Сайты более эффективны, но вы не можете использовать их в автономном режиме.
Но большинство «приложений» сегодня в любом случае доступны только в сети! Вы не можете позвонить в Uber, находясь в офлайн-режиме. Иначе зачем вам открывать приложение Uber? Tinder бесполезен в автономном режиме. Вы не можете встречаться с пустыми экранами чата. Вы не можете присоединиться к встрече на Meetup.com без подключения к сети. Вы не можете выбрать или забронировать отель, вы не можете перевести деньги или проверить баланс своего счета в автономном режиме. И никто не хочет перечитывать старые кешированные твиты из Twitter или вчерашние фотографии из Instagram. В этом нет никакого смысла.
Так что да, я бы предпочел, чтобы эти «приложения» были просто веб-сайтами. Вы не поверите, но в этом есть свои преимущества. Мне нравится меньший размер загружаемых файлов, особенно если я иногда захожу на сайт просто для того, чтобы быстро его просмотреть. Мне нравится, что веб-сайты не потребляют мои ресурсы в фоновом режиме. 2. Когда я закрываю его, он выгружается и не загружает постоянно новые версии собственных библиотек, которые разработчикам часто необходимо развертывать. Ради этого я более чем готов пожертвовать офлайн-режимом.
Вторая проблема с PWA, более актуальная для нашей темы, заключается в том, что она каким-то образом связана с производительностью.
Дело в том, что это не имеет отношения к производительности. То есть ничего нового. Вы всегда могли кэшировать ресурсы, чтобы быстро перемещаться между страницами, и браузеры неплохо справляются с этим. С помощью HTTP/2 вы можете эффективно извлекать ресурсы в большом количестве и даже отправлять ресурсы с сервера для «более мгновенного» взаимодействия.
Поэтому самостоятельное управление кешем ресурсов в ServiceWorker кажется скорее обузой, чем благословением. HTTP-кеширование также декларативно, хорошо протестировано и хорошо изучено на данный момент, иными словами, его трудно испортить. Чего вы не можете сказать о своем ServiceWorker. Кэширование — одна из двух самых сложных вещей в компьютерных науках. У меня лично был плохой опыт работы с Meetup.com PWA, когда из-за ошибки в их коде кеша весь сайт стал непригодным для использования до такой степени, что не открывались страницы встреч. И, в отличие от HTTP, его не так просто сбросить. Нет, обновление не помогло.
Но было бы нормально, если бы ServiceWorker был компромиссом: вы платите за сложность, но получаете новые захватывающие возможности. За исключением того, что вы этого не получите. Нет ничего полезного, что вы можете сделать с ServiceWorker, чего вы не сможете сделать с HTTP-кешем / AJAX / REST / локальным хранилищем. Это просто дыра сложности, в которую вы потратите бесчисленное количество рабочих часов.
PWA, как и AMP, даже не гарантирует, что ваш веб-сайт будет хоть сколько-нибудь «быстрым» или «мгновенным». Забавно, как в тематическом исследовании Tinder показано, что экран входа в систему (один ввод текста, одна кнопка, один логотип SVG и фоновый градиент) загружается через 4G-соединение за 5 секунд! Я имею в виду, что им пришлось добавить загрузчик на 2-5 секунд, чтобы пользователи сразу не закрывали эту херню. И они называют это быстро.
Настолько это быстро:
Как они это делают? Чертовски заботясь о производительности. Так просто.
О, также не обслуживают миллионы пакетов JavaScript и не выполняют рендеринг на клиенте с React, обслуживаемым через GraphQL с помощью fetch polyfill. Это, вероятно, тоже помогло.
ServiceWorker или AMP, если ваша целевая страница содержит 170+ запросов на 3,1 Мб для изображения и четырех полей формы, она не может загружаться быстро, независимо от того, сколько новых фреймворков вы добавите в нее.
Вердикт
Так какой вердикт? Чтобы писать быстрые веб-сайты с помощью AMP и PWA, вам все равно нужно глубоко разбираться в оптимизации производительности. Без этого единственный выбор, который у вас есть, — это гнаться за ажиотажем.
Но помните, что ни AMP, ни PWA волшебным образом не сделают ваш сайт быстрее, чем, скажем, обычная перезапись.
Однако, как только вы разберетесь с производительностью, вы заметите, что вам не нужны ни AMP, ни PWA. Просто перестаньте заниматься ерундой, и Интернет внезапно начнет работать мгновенно. AMP не изобрела CDN и . PWA не изобрела кеширование. Статическая сеть по-прежнему вращается вокруг любой современной широко разрекламированной среды.
«Но пользователи! Им нужна наша модная интерактивность. Они ТРЕБУЮТ анимации!»
Скажу одно. Никто не любит смотреть на экран загрузки 5 секунд. Анимированный загрузчик не имеет значения. Если вы не можете дать производительность, по крайней мере, не притворяйтесь, что это некая особенность.
________________________________
- Хотя я не думаю, что нам нужно больше уведомлений в нашей жизни. Особенно со случайных посещаемых нами веб-страниц. Даже не из собственных приложений — я держу свой телефон в постоянном режиме «Не беспокоить» с коротким списком приложений, которые могут отправлять уведомления.
- Кстати, с тех пор, как вы впервые открыли эту статью, мой ServiceWorker в фоновом режиме загрузил 0 Кб бесполезных данных. Надеюсь, у вас есть WiFi :)
