Представляем вам набор рекомендаций, следуя которым вы сможете с самого начала улучшить производительность вашего веб-приложения.
Когда вы только начинаете создавать современное веб-приложение, одна их первых вещей, которые будто бьют вас кирпичом по голове, — осознание факта, что не только большинство телефонов намного медленнее, чем ваш компьютер, но и 3G/4G соединения у большинства пользователей строго говоря нельзя назвать потрясающими.
Фактически, разница между работой на локальном хосте и настоящем производственном сервере может быть настолько драматичной, что если вы не предпримете несколько мер предосторожности, то сразу после выпуска вашего приложения вы поймете, что у большинства пользователей ваш продукт работает крайне плохо и они, вероятно, ненавидят вас за это.
Чтобы это предотвратить, мы создали набор рекомендаций с наиболее эффективными мерами, которые вы можете предпринять чтобы изначально улучшить производительность вашего веб-приложения. Также эти шаги помогут вам предупредить падение производительности при появлении новых функций уже после выхода прекрасного первого релиза.
1. Установите бюджет производительности и придерживайтесь его
Бюджет производительности это четкая задача, выражающая, насколько быстрым должно быть ваше приложение. Цель — не дать вашей команде превратить продукт в беспорядок из слежавшихся функций, который требует вечности для загрузки, что в значительной степени неизбежно для долгосрочных проектов. Как вы можете предположить, в этой стратегии есть два главных компонента:
- установить бюджет производительности сам по себе;
- следовать ему в процессе работы (вот тут-то все и оступаются).
Лучший способ внедрить это — позволить собственнику продукта четко установить приоритет для производительности. Это заставить команду (дизайнеров и разработчиков) сфокусироваться на мобильной версии, для которой скорость является одной из самых важных черт.
Когда это сделано, следующим шагом будет вставить в ваш CI Pipeline правило, которое будет блокировать все запросы на принятие изменений, не отвечающих всем требованиям. И — нет, вы не можете делать исключений (в этом смысл правила CI).
Вот два главных правила, которые мы применяем в Aerolab. Можете их скопировать:
У вас есть не больше 1 секунды чтобы показать пользователю то, что он хочет увидеть.
(1 секунда времени для первого имеющего значение изображения при хорошем WiFi на нашем стандартном экземпляре Macbook Pros).
Через 1,5 секунды приложение должно стать интерактивным.
(1,5 секунды времени для интерактивности при хорошем WiFi на нашем стандартном экземпляре Macbook Pros).
Наличие четкой задачи по производительности затрагивает все в вашем стэке, от дизайна и выбранных вами Javascript-библиотек до того, как будут настроены ваши сервера.
Внедрение бюджета производительности — и его соблюдение! — это отличный способ заставить всю вашу команду совместно трудиться над тем, чтобы сделать продукт быстрым.
Когда каждый поймет, как его работа влияет на этот параметр, вы сможете остановить снижение производительности, а это значит, что вы сможете сохранить отличную скорость от самого первоначального релиза и на протяжении всей жизни продукта.
2. Сохраняйте ваше ядро настолько легким, насколько это возможно
Одна из вещей, который вы должны иметь в виду, когда начинаете новый проект, следующая.
Основные фреймворки и библиотеки, которые вы выбираете для построения вашего продукта, обычно остаются в нем навсегда, что делает эти решения в достаточной мере необратимыми.
Поэтому, если вы выбрали невероятно большой промышленный фреймворк, который каким-либо образом нуждается в запуске виртуальной машины Linux в браузере, вы можете попрощаться с производительностью вашего продукта до следующего большого рефакторинга. Которого, конечно, никогда не будет, потому что удаление вещей обходится намного, намного, намного дороже, чем их добавление.
Лучший совет, который я могу вам дать: вы должны выбрать самое легкое из возможных решений, которое поможет вам справиться с задачей. Если вы строите продукт, который очень близок к тому, что браузер может делать самостоятельно (например, новостной сайт, блог, электронная торговля или что угодно, в основном показывающее текст, изображения и видео), вам обычно нужен самый минимум, помогающий вам в создании организованной базы кода и попытках сохранять порядок при принятии запросов на внедрение изменений.
Здесь нужен ваш профессиональный взгляд. Если вы создаете продукт для миллионов мобильных пользователей, выбор ужасно тяжелого промышленного стека может быть катастрофическим как в отношении UX, так и с точки зрения доходов. Если вместо этого вы работаете над некоторым внутрикорпоративным приложением, которое несколько человек используют один раз в год (или если вы просто хотите опробовать новый фреймворк), – можете просто закинуть туда все, что хотите, потому что это никого не будет волновать.
Если вам нужны какие-то ссылки, наши готовые библиотеки для веб-разработки это Preact (полностью совместимый клон React в 3kb) и фреймворк Next.JS, который обеспечивает рендеринг на стороне сервера, офлайн-поддержку, предварительную выборку, отличную документацию и фантастическое сообщество.
Это попадание «в яблочко» для большинства проектов. К тому же поверх этой крошечной базы кода очень легко добавлять функции. Объединив этот подход со следующим советом, мы сможем загружать наши последние веб-приложения меньше чем за секунду, что является фантастическим с точки зрения UX.
3. Спроектируйте стратегию загрузки
Если вы работаете в этой сфере некоторое время, вы знаете, что со временем вам придется запихивать невероятно тяжелый компонент в ваш продукт, уничтожая все достижения в плане производительности, которые были в первом релизе. И что хуже, это будет демотивировать вашу команду, так как они почувствуют, что все их усилия сделать продукт быстрым были бессмысленны.
Но не отчаивайтесь! Когда такое случится, есть возможность сжульничать, и она называется «Проектированием загрузочной стратегии», что разделяет усилия между дизайнерами и разработчиками.
Главный принцип, стоящий за хорошей Загрузочной Стратегией, – никогда не позволять пользователям узнать, когда происходит загрузка приложения. А если этого нельзя избежать (например, при первоначальной загрузке), – сделать процесс настолько быстрым и приятным насколько возможно, загружая важные вещи в первую очередь, а все остальное – позже или никогда.
Лучший способ это испытать — выбрать самый тяжелый компонент в вашем приложении (вы знаете, тот, который требует тонну JS, хотя используется всего дважды на весь сайт) и разбить процесс загрузки на два субкомпонента:
- «Плейсхолдер»-версию компонента, которая требует самого минимального количества кода, однако прекрасно вписывается на странице и выглядит совсем как нечто настоящее. Например, если компонент это сложный видео плеер, который подгружает десятки дополнений, вам обычно нужно показать только миниатюру и кнопку «проигрывать». Это именно то, что вы покажете пользователю при первичной загрузке веб-приложения. Вы получите дополнительные «плюсики», если они будут выглядеть так, будто и правда работают.
- Настоящую версию компонента, которую вы загрузите сразу после того как будет должным образом загружено все самое важное на сайте. Лучший способ сделать это – отложить загрузку зависимостей этого компонента и все остальное до события загрузки окна, и когда вы наконец получите весь этот код, то сможете открыто заменить субкомпонент-«плейсхолдер» на настоящий, работающий.
Один из самых популярных примеров этой техники это эффект прогрессивной загрузки изображения, используемый Medium, Quartz и некоторыми другими, встраивающий картинку с очень низким разрешением с помощью HTML (в качестве плейсхолдера), а затем, после загрузки, переходящий к полному изображению:
Если вы выполнили оба шага правильно, этот новый тяжелый компонент не повлияет на ваше изначальное время загрузки (позволяя пользователям приступать к использованию продукта так же быстро как раньше). Все по-прежнему будет загружаться и правильно функционировать, а этот компонент загрузится на несколько десятых долей секунды позже всего остального веб-приложения. Если переход к рабочему компоненту правдоподобен, ваши пользователи вообще ничего не заметят, что является золотым стандартом для производительности.
Имейте в виду, что даже с продуманной загрузочной стратегией загрузка больших JS-библиотек все равно будет приводить к некоторым заметным заминкам на большинстве телефонов. Так что даже имея самую разумную загрузочную стратегию во всем мире стоит пытаться загружать как можно меньше кода.
4. Занимайтесь разработкой на среднем телефоне
Одна из лучших вещей, которые вы можете сделать как разработчик, – писать код на таком же устройстве, какое будет у большинства ваших пользователей.
Вы можете писать ваш код на топовой линейке Macbook Pro, но вам стоит приобрести дешевый б/у Nexus 5X или Moto G4 просто чтобы посмотреть как ваш код будет себя вести на девайсе средней руки. Если вы хотите действительно последовать этому совету, вы можете также ограничить соединение для этого телефона чтобы имитировать достаточно приличное 3G-соединение. Использование Chrome с удаленным дебаггингом сделает этот опыт почти таким же хорошим, как разработка на вашем компьютере.
Это откроет вам глаза на то, как на самом деле большинство людей используют ваше приложение в реальном мире, а также даст вам четкое понимание того насколько маленькие CPU и RAM доступны настоящим пользователям. В тот момент, когда вы начнете раздражаться из-за того что перезагрузка занимает слишком много времени на вашем телефоне, вы поймете, что поставляете гораздо больше кода, чем следует.
Различия между устройствами и платформами могут быть значительными. Для начала, согласно большинству тестов, айфоны обычно в два раза быстрее, чем лучшие Android-телефоны.
Просто, чтобы дать вам представление о том, насколько на самом деле медленны большинство телефонов, Эдди Османи написал отличную статью о JS Startup Performance. Один из наборов данных, которые он показывает, – это сколько времени требуется для анализа и выполнения 1 МВ Javascript на разных устройствах:
Согласно этим показателям, iPhone 7 примерно в 8 раз быстрее чем Nexus 5X (или в 14 раз быстрее чем более средний Moto G4). Так что, если вы разрабатываете веб-приложение, интенсивно использующее javascript, при помощи последнего iPhone или Macbook, у вас будет очень искаженное представление о производительности вашего кода на среднем телефоне.
Тестирование на разных устройствах нужно не только для исправления каких-то разночтений CSS. Это необходимость в силу того факта, что больше 60% веб-пользователей используют для этого мобильные устройства (а около 80% пользователей приходится на развивающиеся страны), и очень мало этих пользователей имеют супердорогие последние телефоны с неограниченным тарифным планом.
Если ваше приложение плохо работает на среднем телефоне с обычным соединением, оно будет плохо работать у подавляющего большинства ваших пользователей.
5. Используйте рендеринг на стороне сервера
Лучший способ убедиться, что весь JS, стоящий за вашим приложением, не затрагивает ваш продукт, это просто избавиться от него. Пуристы скажут вам писать только чистый HTML (что, кстати, является неплохой идеей). Однако работа с современными фреймворками, такими как React, принесет вам очень впечатляющую производительность, инструментарий и удобство командной работы, которых сложнее достичь с более старым стэком.
Простой способ сделать это — воспользоваться преимуществом рендеринга на стороне сервера, который будет рендерить ваш сайт на сервере (включая выполнение всех этих досадных сетевых запросов), так что вы сможете поставлять простой HTML как пользователям так и ботам. Большинство хороших микрофреймворков (Next.JS, Create React App, Preact CLI и несколько других) сделают это за вас, а в крайнем случае решение легко найти с помощью нескольких поисковых запросов Google.
Поскольку отображение HTML – основная функция браузера в последние несколько десятилетий, это поможет очень быстро отображать ваш важнейший контент, не заставляя ваших пользователей ожидать несколько лишних путешествий на сервер для доставки массивного груза Javascript и связки API-запросов. Более того, поскольку HTML очень легко кэшировать, вам не придется постоянно забивать фронтенд-серверы для рендеринга, и это может помочь выиграть несколько миллисекунд из вашего первоначального времени загрузки.
Вы также получите некоторые преимущества в SEO и распространении, поскольку простой HTML может быть проанализирован простым curl-запросом вместо необходимости запускать headless-браузер. Пока главные поисковики будут исполнять и индексировать отягощенные Javascript сайты, вы сможете воспользоваться дополнительными преимуществами. Вы получите лучшую совместимость с некоторыми другими сервисами (такими как Twitter, Linkedin, Pocket и многими другими), а еще эта часть продукта станет более предсказуемой и менее подверженной ошибкам.
6. Сначала подумайте про офлайн
У мобильных пользователей очень непредсказуемое сетевое соединение, разные скорости и уровни потерь пакетов. Мое любимое слово – Lie-Fi (Lie – «ложь»). Это когда ваш телефон говорит, что вы в сети, а на самом деле это не так или соединение ужасно медленное. В сочетании с тем фактом что большинство мобильных пользователей обычно спешат и очень нетерпеливы, это не добавит вашему продукту новых юзеров.
Для большинства современных продуктов критически важно использование преимуществ, которые дают офлайн-функции (такие, как Service Workers) или простое кэширование всего на свете. Большинство фреймворков помогут вам справиться со сложными проблемами, такими как недействительность кеша или обновление ресурсов. Но воспользуетесь ли вы преимуществом этих функций и получат ли ваши новые и старые верные пользователи совершенно потрясающее время загрузки, зависит только от вас как от разработчика.
Самое лучшее в этом – наличие таких библиотек как Workbox, которые упрощают настройку Service Workers, так что вы можете легко добавить его в свой продукт и получить очень хорошую функцию, работающую без особых проблем.
Обеспечение хорошей работы вашего приложения в режиме офлайн является одной из ключевых особенностей построения продуктов в первую очередь для мобильных устройств. Делая ваш сайт более доступным при плохой связи (например, во время поездок в метро, если вы живете в большом городе) или просто пользуясь преимуществом кеша, благодаря чему все загружается почти мгновенно при повторных посещениях, это помогает вам сделать работу вашего сайта более сходной с работой приложений.
Заключительные слова
Я знаю, что фокусировка на производительности обычно не так привлекательна, как добавление связки новых функций, но делая ваш продукт быстрым вы получите совершенно потрясающие результаты когда дело дойдет до прибыли, просто потому что людям нравятся быстрые продукты, и статистика хороших PWA по большей части поддерживает этот вывод.
Если вы правда хотите построить впечатляющие продукты, каждый должен держать в уме производительность. Наличие целой команды, работающей над тем чтобы сделать приложение быстрым и легковесным, является одним из самых важных аспектов для построения продуктов, которые в самом деле понравятся людям.
***
Подписывайтесь на наш канал в Telegram!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
