У вас могут быть лучшие в мире функции, но они ничего не значат, если какой-либо экран вашего приложения загружается даже немного медленно. В этом посте рассказывается, как не расстраивать пользователей своим приложением, и раскрываются некоторые новые технологии.
В первой части книги« Что вам следует делать в веб-разработке, о которой вам не говорят » я писал о передовых методах разработки. Это были самые важные вещи. Теперь мы можем перейти к менее убедительным, но также полезным примерам.
1. Используйте веб-пакет для объединения файлов
Я помню время, когда почти никто не объединял свои файлы, но сейчас это стандарт. В большинстве случаев мы должны отправлять код в одном связанном файле (разделение кода см. В пункте 9). Почему? Это быстрее. Передача одного большого файла происходит быстрее, чем отправка большого количества небольших запросов (однако в будущем это может измениться, см. Следующий пункт). Мы можем использовать такие инструменты, как webpack, чтобы сделать это за нас, и в течение минуты сделать конфигурацию для нашего проекта, которая может объединять файлы, минимизировать код, удалять комментарии, оптимизировать стили и добавлять необходимые префиксы и транспилировать код для расширения поддержки браузера.
Вот простой пример того, как это выглядит:
Чтобы помочь вам понять, как это работает, я рекомендую вам прочитать этот пост: Как работает webpack на примерах.
Если вам нужно что-то более продвинутое, с максимальной оптимизацией, вы можете проверить нашу Конфигурацию веб-пакета SwingDev. Он поддерживает .env файлы, Typescript, различные конфигурации для каждой среды и многое другое!
2. Разумеется, используйте Gzip.
Вы можете сэкономить много килобайт, просто убедившись, что на вашем сервере включена кодировка gzip. Вы можете проверить, использует ли ваш сервер gzip на этом веб-сайте Checkgzipcompression.com, или вы можете проверить это самостоятельно с помощью Google Chrome DevTools.
Перейдите на вкладку Network, выберите любой файл _3 _ / _ 4_ и найдите заголовок Content-Encoding. Если он там есть, вы используете gzip 🎉
Если вы ищете что-то еще лучше, вы можете исследовать Бротли. Я рекомендую вам прочитать Понимание потенциала Бротлиса. Это покажет вам, почему это стоит проверить.
3. По возможности используйте кеш
Запросы. Часто нет необходимости повторно получать данные из API, если мы знаем, что они вряд ли изменились в течение указанного периода. Не получая данные, мы дружим с пользователями мобильных данных, ограничиваем ненужные вызовы API и сводим к минимуму повторные отрисовки приложений из-за обновлений состояния.
Ресурсы. Механизм кеширования браузера - ваш друг. Во время разработки это может привести к очень неприятным ситуациям, но действительно помогает улучшить производительность вашего сайта. Каждый браузер кэширует такой контент, как изображения, JavaScript или CSS. В настоящее время мы можем вывести это на другой уровень. Используя Service Workers, мы можем получить автономный доступ к нашим ресурсам.
Кеширование файлов с помощью сервис-воркера
Не забывайте уважать эту мощную функцию. Из-за слишком большого объема кеширования легко потеряться, поэтому держите руку на пульсе и внимательно все проверяйте, прежде чем запускать в рабочую среду.
4. Размещайте изображения правильного размера
Часто мы используем одни и те же изображения для разных частей нашего приложения. Возьмем для примера интернет-магазин. У каждого товара в магазине есть свое обзорное изображение. Мы отображаем его на странице сведений о продукте, странице со списком продуктов с двумя вариантами макета: списком и сеткой, а также на странице с изображением в исходном размере.
Нам нужно как минимум четыре разных размера изображения. Почему нельзя использовать только одно изображение? Представьте, что исходное изображение имеет размер 1 МБ, и мы отображаем десять товаров на странице. Пользователь загрузит 10 МБ только фотографий, а это не то, что нам нужно. Если вы можете, попробуйте создать разные изображения для разных частей вашего сайта, это сэкономит вашим пользователям много килобайт. Также следует учитывать текущее разрешение экрана. Например, если кто-то открывает ваш сайт на своем мобильном телефоне, нет необходимости отображать гигантское изображение заголовка, которое вы обычно используете. Возможно, вам также понадобится другое изображение для четкого дисплея iPad Pro и другое для бюджетного устройства Android с низким разрешением.
Вы можете использовать HTML-тег <source/>, который можно использовать внутри HTML5 <picture/>, чтобы определить, какие изображения следует использовать в веб-браузере в зависимости от ширины или высоты экрана. Документы
Или используйте CSS медиа-запросы
5. Отправлять только дельту обновлений
Мы можем минимизировать полезную нагрузку, разгрузить наш бэкэнд и увеличить скорость запроса, отправляя только те изменения, которые пользователь внес в запросы на обновление. Может показаться сложным извлекать изменения в самом вложенном объекте, но кто сказал, что мы должны писать его самостоятельно?
Для глубоких дельт мы можем использовать следующий пример:
Помните, что запросы PUT и PATCH создаются для разных целей. Метод PUT описан в RFC 5789 следующим образом:
Некоторым приложениям, расширяющим протокол передачи гипертекста (HTTP), требуется функция для частичного изменения ресурсов. Существующий метод HTTP PUT позволяет только полную замену документа. Это предложение добавляет новый метод HTTP, PATCH, для изменения существующего ресурса HTTP.
Таким образом, PUT следует использовать только в том случае, если вы полностью заменяете ресурс, а не когда вы просто обновляете некоторые его части.
6. Покажите значок, что пользователь потерял подключение к Интернету
Ваши пользователи теряют подключение к Интернету чаще, чем вы думаете. Хорошая практика - сообщить им, что наше приложение потеряло соединение с Интернетом и его нельзя будет использовать, пока оно не вернется. Поддержка постановки в очередь действий и запросов пользователей, когда вы не в сети, - это тема для отдельной статьи, но я думаю, вам не придется ее реализовывать, если вы не работаете в крупном проекте, который должен поддерживать такие ситуации. Для большинства приложений достаточно показать на экране индикатор того, что ваше приложение пытается восстановить соединение с Интернетом.
7. Использовать HTTP-2
Это позволяет серверам проактивно проталкивать ответы в клиентские кеши вместо ожидания нового запроса для каждого ресурса. Он использует новое расширение ALPN, которое обеспечивает более быстрое шифрование соединений, поскольку протокол приложения определяется во время первоначального соединения. Смотрите также другие преимущества использования HTTP / 2.
Еще один ресурс, который я могу порекомендовать вам, чтобы узнать о преимуществах этого протокола, - это презентация Патрика Хаманна на JSConf EU 2018.
8. Разделение кода
Наиболее информативное определение разделения кода, которое я знаю, взято из документации по React:
Объединение - это здорово, но по мере роста вашего приложения будет расти и ваш пакет. Особенно, если вы включаете большие сторонние библиотеки. Вам нужно следить за кодом, который вы включаете в свой пакет, чтобы случайно не сделать его настолько большим, что вашему приложению потребуется много времени для загрузки.
Чтобы не получить большой пакет, хорошо бы опередить проблему и начать разбивать пакет. Разделение кода - это функция, поддерживаемая такими сборщиками, как Webpack и Browserify (через factor-bundle), которые могут создавать несколько пакетов, которые могут динамически загружаться во время выполнения.
Разделение кода вашего приложения может помочь вам «отложить загрузку» только тех вещей, которые в данный момент необходимы пользователю, что может значительно улучшить производительность вашего приложения. Хотя вы не уменьшили общий объем кода в своем приложении, вы избежали загрузки кода, который может никогда не понадобиться пользователю, и уменьшили количество кода, необходимого во время начальной загрузки.
Подробнее о разделении кода в React
Анализ разбиения кода на размер пакета в приложении create response
Как видите, есть много областей, в которых мы можем улучшить производительность нашего приложения.
Если вам нужно больше примеров и решений, вы можете посмотреть Руководство разработчика Frontend SwingDev. Мы приложили массу усилий, чтобы сделать это, но оно того стоило, убедитесь сами.
Как всегда, я более чем счастлив услышать ваши мысли по этой теме, что еще можно оптимизировать, и были ли вы уже осведомлены об этом или нет. Дай мне знать в комментариях!
Счастливого кодирования и оптимизации! 🦄
Нравится? Нажмите кнопку 👏! Спасибо!
Вы можете найти меня на GitHub.
