предисловие
Тема производительности переднего плана никогда не прекращалась. Потому что эта вещь не самая лучшая, только лучше. И часто именно сложность бизнеса определяет степень оптимизации. Как фронтенд-разработчик, производительность — это метрика, о которой мы заботимся. Это напрямую влияет на наших пользователей, но также и на сам продукт. С момента разработки внешнего интерфейса было применено множество методов оптимизации, в том числе военные правила Yahoo. Они сложны и часто легко забываются. Поэтому в этой статье кратко изложены эти часто используемые методы оптимизации, возможно, она не является исчерпывающей, извините. Если вам понравилась моя статья, добро пожаловать в комментарии, добро пожаловать в Star~. Добро пожаловать, чтобы следовать за мнойблог на гитхабе
текст
Фронтенд-оптимизация появляется одна за другой, и теперь, когда мобильный терминал очень популярен, можно сказать, что если мобильный терминал будет оптимизирован, ПК-терминал тоже будет лучше. Поэтому мы можем объединить следующие картинки для некоторого анализа, как показано на рисунке:
На рисунке сделаны некоторые обобщения производительности интерфейса. Но на самом деле, я думаю, мы можем сделать это обобщение более точным, кратким и насыщенным. Поэтому я резюмирую производительность внешнего интерфейса с трех аспектов: сеть, манипуляции с DOM и рендеринг, а также данные.
сеть
Для веб-приложений всегда будет часть времени, потраченного на сетевые подключения и загрузку ресурсов. Часто для установления сетевого соединения требуется время. А количество сетевых запросов, отправляемых браузером одновременно, ограничено. Поэтому оптимизацию на этом уровне можно начать с «уменьшения количества запросов»:
-
уменьшить http-запросы: Это также упоминается в правилах YUI35, в основном для оптимизации трех аспектов ресурсов js, css и изображений, потому что нет никакого способа избежать html. Таким образом, мы можем выполнить следующие операции:
- Объединить js-файлы
- Объединить css-файлы
- Использование спрайтовых изображений (css sprite)
-
Используйте base64 для представления простых изображений
Для вышеуказанных четырех методов первые два можно упаковать с помощью инструментов упаковки, таких как webpack; для изображений спрайтов также есть специальные инструменты производства; кодировка изображений — base64, поэтому для некоторых простых изображений, таких как пустые изображения и т. , вы можете использовать base64 для записи непосредственно в html.
Возвращаясь к предыдущей проблеме сетевого уровня, помимо уменьшения количества запросов для ускорения загрузки сети, объем всего ресурса часто одинаков, на что мы обычно обращаем внимание.
-
Уменьшить размер ресурса: Это может быть реализовано следующими способами:
- gzip-сжатие
- обфускация js
- css-сжатие
-
Сжатие изображения
Сжатие Gzip в основном предназначено для html-файлов, оно может упаковывать повторяющиеся части в html и повторно использовать их несколько раз. Обфускация js может включать простое сжатие (удаление пробельных символов), искажение (метод уродства заключается в сжатии некоторых переменных) или php может использоваться для обфускации и шифрования js. Сжатие CSS — это простое сжатие. Сжатие изображений в основном предназначено для уменьшения объема.Исходя из того, что это не влияет на внешний вид, попробуйте сжать изображения, используйте png и другие форматы изображений, а также сократите использование векторной графики и изображений высокой четкости. Такой подход позволяет не только ускорить отображение веб-страниц, но и снизить потери трафика.
В дополнение к операциям двух вышеперечисленных частей нам также необходимо хорошо поработать с кэшированием на сетевом уровне. С точки зрения реальной оптимизации производительности кэширование является наиболее эффективным, и оно часто больше всего сокращает время загрузки.
-
тайник: можно описать следующими аспектами:
- Кэш DNS
- Развертывание CDN и кэширование
-
http-кэш
Поскольку браузер будет потреблять определенное количество времени на этапе разрешения DNS, для некоторых веб-сайтов с высоким трафиком хорошее кэширование DNS в определенной степени повысит эффективность веб-сайта. Кэширование CDN, как сети распространения для файлов статических ресурсов, сама CDN была улучшена, скорость получения статических ресурсов веб-сайта, ускорение скорости загрузки веб-сайта, а также выполнение работы по кэшированию статических ресурсов, эффективное использование кэшированных статических ресурсов, Получить быстрее. Кэширование HTTP также устанавливает время кэширования для ресурсов, чтобы предотвратить повторную загрузку ресурсов в течение эффективного времени кэширования, тем самым повышая скорость загрузки всей веб-страницы.
На самом деле, на сетевом уровне еще много оптимизаций, особенно для мобильных страниц. Как мы все знаем, мобильный терминал более чувствителен к сети.За исключением нынешних 4G и WIFI, другие сети мобильных терминалов эквивалентны слабой сетевой среде.В этой среде использование кэш-памяти очень важно. Кроме того, также очень важно уменьшить количество http-запросов, в слабом сетевом окружении мобильного терминала время для http-запросов также будет увеличиваться. Итак, давайте посмотрим на оптимизации, которые мы можем сделать с точки зрения мобильных сетей:
-
Мобильная оптимизация: Используйте следующие методы, чтобы ускорить оптимизацию мобильной сети:
- Используйте длинный кеш, чтобы уменьшить перенаправление
- Оптимизация первого экрана гарантирует, что загружаемые данные на первом экране будут меньше 14 КБ.
-
Не злоупотребляйте веб-шрифтами
«Использование длинного кеша» может привести к тому, что некоторые ресурсы на мобильном терминале настроят долгосрочный кеш, который может гарантировать, что ресурсам не нужно отправлять запросы на сервер, чтобы сравнить, обновлены ли ресурсы, тем самым избегая ситуации 304. Перенаправление 304 может не повлиять на скорость загрузки веб-страницы на стороне ПК, однако при условии, что мобильная сеть нестабильна, еще один запрос увеличит время загрузки. «Оптимизация первого экрана» имеет решающее значение для мобильных устройств. 2-секундное время — лучший опыт для пользователей, как только это время будет превышено, это приведет к потере пользователей. Следовательно, в соответствии с сетевой ситуацией мобильного терминала невозможно загрузить все ресурсы веб-страницы за такое короткое время, поэтому мы должны убедиться, что содержимое на первом экране отображается первым, и на основе медленного запуска TCP и перегрузки. управление, первые 14кб Данные очень важны, поэтому необходимо следить за тем, чтобы заголовок загружаемых данных мог быть меньше 14кб. "Не злоупотребляйте веб-шрифтами". Преимущество веб-шрифтов в том, что они могут заменить некоторые ресурсы изображения. Однако использование слишком большого количества веб-шрифтов на мобильной стороне приведет к большой загрузке ресурсов страницы. Поэтому используйте веб-шрифты с осторожность.
Аспекты рендеринга и манипулирования DOM
Сначала кратко поговорим о важности оптимизации рендеринга. Когда веб-страница изначально загружается, после получения HTML-файла первоначальная работа заключается в построении двух деревьев: DOM и CSSOM, затем их слиянии для формирования дерева рендеринга и, наконец, их печати. Мы можем взглянуть на картинку, простой процесс:
Здесь весь процесс вытащен и написан, и можно написать еще одну статью.Простите меня за лень и порекомендуйте всем статью получше.Процесс рендеринга в браузере и оптимизация производительности
Продолжая наш разговор, как можно сократить этот процесс? Оптимизация может быть выполнена из следующих операций.
-
Оптимизация веб-рендеринга:
- Файл css помещается в начало, а файл js помещается в конец или асинхронно
-
Старайтесь избегать встроенных стилей
Файл css помещается в «загрузку заголовка», что может гарантировать, что файл css будет проанализирован при анализе DOM. Потому что CSS (внешняя ссылка или встроенный) заблокирует отрисовку всего DOM, но парсинг DOM будет проходить нормально, поэтому размещение CSS-файла в голове для парсинга может ускорить построение веб-страниц. Предполагая, что он расположен в конце, когда дерево DOM почти построено, вам нужно подождать, пока дерево CSSOM будет построено, прежде чем вы сможете продолжить следующие шаги. «js в конце»: js-файлы разные, причина размещения js-файлов в конце или асинхронной загрузки в том, что JS (внешний или встроенный) будет блокировать последующий синтаксический анализ DOM, и последующий рендеринг DOM также будет заблокирован, и как только js Скорее всего, это повлияет на работу элемента DOM, обнаруженного в DOM. Вот статья, которую я рекомендую -Асинхронная загрузка скриптов повышает производительность страницы. "Избегайте использования встроенных стилей" может эффективно уменьшить объем html. Как правило, когда рассматриваются встроенные стили, сам стиль часто меньше по размеру, и загрузка сетевых ресурсов часто занимает больше времени, чем это происходит.
Помимо оптимизации на уровне рендеринга страницы, конечно, самое главное — это оптимизация DOM-операций, этой части оптимизации должно быть больше всего, и это тоже то место, на которое можно обратить внимание при нормальной разработке. . Если вы понимаете эти принципы на ранней стадии разработки и одновременно применяете их на практике, вы можете приложить много усилий для дальнейшего повышения производительности. Затем давайте взглянем на конкретную операцию:
-
Оптимизация манипуляций с DOM:
- Избегайте частых манипуляций с DOM непосредственно в документе.
- Используйте имя класса вместо большого количества встроенных модификаций стиля
- Для сложных элементов пользовательского интерфейса установите абсолютное или фиксированное положение.
- Максимально используйте анимацию CSS.
- Используйте requestAnimationFrame вместо операции setInterval
- Правильное использование холста
- Сведите к минимуму использование выражений CSS
-
Использование делегатов событий
Первые три операции фактически надеются «уменьшить перекомпоновку и перерисовку». На самом деле стоимость выполнения операции DOM очень велика. Раньше об этом можно было судить по тому, зависла ли работа веб-страницы. Однако прогресс современных браузеров значительно снизил влияние в этом отношении. Тем не менее, нам все еще нужно четко понимать, как уменьшить проблемы перекомпоновки и перерисовки. Поскольку я не хочу подробно останавливаться на этом знании здесь, если вы хотите узнать больше, вы можете прочитать эту статью-Перекомпоновка и перерисовка: производительность CSS замедляет работу JavaScript?. Это статья, написанная Чжан Синьсюй (^.^). «Максимально используйте CSS-анимацию», потому что сама CSS-анимация относительно проста, и по сравнению со сложной анимацией js браузер сам ее оптимизировал, и при ее использовании не будет проблем типа заеданий. «Используйте requestAnimationFrame вместо операции setInterval», я думаю, все слышали об этом, таймер setInterval будет иметь определенную задержку, а для анимаций с высокой изменчивостью будет явление задержки. А requestAnimationFrame просто решает всю проблему. "Правильное использование канваса", должен сказать, что канвас - это прогресс во фронтенде, после его появления возросла и сложность интерфейса фронтенда. Некоторым сложным для завершения анимациям может помочь холст. Однако, если холст используется часто, это увеличит нагрузку на рендеринг браузера и приведет к снижению производительности. Таким образом, это хорошее предложение использовать холст, когда это уместно. "Свести к минимуму использование выражений css", это тоже упоминается в правилах YUI, часто выражения css красивы в начале дизайна, но в процессе использования, из-за его частых характеристик срабатывания, это будет тормозить. производительность веб-страницы зависла. Поэтому постарайтесь уменьшить использование css-выражений в процессе использования, можно перейти на js для работы. «Использование делегатов событий». Часто для всплывающих событий хорошим подходом является использование делегатов событий. Например: список должен установить событие щелчка.В настоящее время, если вы устанавливаете прослушиватель для каждого элемента в списке, это часто приводит к снижению общей производительности, но если вы устанавливаете событие для всего списка, а затем найдите его, щелкнув цель, чтобы вызвать соответствующее действие, часто производительность будет улучшена.
Есть много других оптимизаций для работы с DOM, в том числе, конечно, и для мобильных устройств. Это будет упомянуто в разделе мобильной оптимизации позже, так что давайте сначала продадим это здесь. Выше мы изложили некоторые соображения при запуске рендеринга и при манипулировании DOM. Следующее, о чем стоит поговорить, — это внимание к некоторым мелким деталям.Эти детали могут мало влиять на страницу, но как только их становится слишком много, это также влияет на производительность.
-
Внимание к деталям операции:
- Избегайте использования пустого src для изображений или фреймов.
- Когда свойство css равно 0, удалите блок
- Отключить масштабирование изображения
- Правильное использование префиксов css
- удалить пустые правила css
- Для наследуемых свойств в css, таких как размер шрифта, попробуйте использовать наследование и установить меньше
-
Сократите селекторы CSS и используйте псевдоэлементы для облегчения позиционирования.
Некоторые из вышеперечисленных операционных деталей обычно требуются при разработке и могут рассматриваться как спецификации разработки. (Основная операция, садитесь ^_^)
После перечисления основных операций давайте поговорим о некоторых оптимизациях операций DOM на мобильной стороне.
-
Мобильная оптимизация:
- Оптимизация прокрутки длинного списка
- Функция подавления дребезга и функция дросселирования
- Используйте touchstart, touchend вместо щелчка
- Настройки области просмотра HTML
-
Включить ускорение рендеринга GPU
Во-первых, проблема прокрутки длинного списка — это то, с чем приходится сталкиваться мобильному терминалу: IOS старается максимально использовать локальную прокрутку, а андроид старается максимально использовать глобальную прокрутку. При этом нужно добавить -webkit-overflow-scrolling: touch к телу, чтобы оптимизировать прокрутку мобильного сегмента. Если вам интересно, вы можете узнать о разнице и оптимизации операций прокрутки ios и android. «Защита от сотрясения и регулирования», события DOM, которые предназначены для частого запуска, такие как прокрутка, должны хорошо справляться с защитой от сотрясения и регулирования. Все они предназначены для ограничения частоты выполнения функции для оптимизации скорости отклика, вызванной высокой частотой срабатывания функции, которая не может соответствовать частоте срабатывания, что приводит к задержкам, приостановке анимации или зависаниям.
представлять:Функция защиты от тряски, при вызове действия в течение n миллисекунд действие будет выполнено, при повторном вызове действия в течение n миллисекунд время выполнения будет пересчитано;регулирование функции, задать цикл выполнения, когда время вызова действия больше или равно циклу выполнения, действие выполняется, а затем вводится следующий новый цикл.
«touchstart, touchend вместо click» также является часто используемой операцией на мобильном терминале. Щелчок по мобильному терминалу будет иметь задержку 300 мс, что должно быть здравым смыслом. (Кто не знает, добавляйте в закладки). Такой подход влияет на опыт пользователя. Поэтому при оптимизации проще всего использовать touchstart или touchend вместо click. Потому что их порядок выполнения событий таков: touchstart->touchmove->touchend->click. В качестве альтернативы используйте событие касания fastclick или zepto вместо события щелчка. «Настройки области просмотра HTML» могут предотвратить масштабирование страницы для оптимизации производительности. «Включить ускорение рендеринга графического процессора», вы наверняка слышали о ЦП, но здесь ГП нельзя путать с ЦП. Полное название графического процессора — это графический процессор, который представляет собой метод аппаратного ускорения. Общий рендеринг CSS, механизм рендеринга браузера не будет его использовать. Однако при 3D-рендеринге объем вычислений велик и тяжел, и браузер включит аппаратное ускорение графической карты, чтобы помочь выполнить эти операции. Поэтому мы можем использовать настройку translateZ в css, чтобы обмануть браузер и позволить ему помочь включить ускорение GPU и ускорить процесс рендеринга.
Оптимизация части DOM — это скорее привычка. Вы должны заставить себя обращать внимание на эти спецификации в процессе разработки. Поэтому этой части контента можно уделить больше внимания, чтобы постепенно разбираться. В то же время мое описание вышеизложенных пунктов носит общий характер. Он не был подробно расширен. Поэтому вам также необходимо тщательно проверить Google.
Аспекты данных
Можно также сказать, что данные являются важной частью контента для оптимизации внешнего интерфейса. Интерактивный ответ между страницей и пользователем часто сопровождается взаимодействием данных, обработкой и асинхронным запросом ajax. Так что можно и об этом знании поговорить. Первый — это обработка данных изображения:
-
Обработка загрузки изображений:
- Предварительная загрузка изображения
- Ленивая загрузка изображения
-
Отображение индикатора выполнения при загрузке выше сгиба
«Предварительная загрузка изображения», значение предварительной загрузки заключается в предварительной загрузке контента. Предварительная загрузка изображений часто используется, когда ресурсы изображений относительно велики, а мгновенная загрузка приведет к длительному процессу ожидания. Общая сцена: когда отображается мультфильм. Часто предварительно загружаются одно или два изображения. «Ленивая загрузка картинок», возможно, вы впервые слышите о ленивой загрузке, но этот метод часто используется в разработке. Прежде всего, нам нужно понять истину: часто нужны только те ресурсы, которые видны, а другие ресурсы могут отображаться по мере прокрутки пользователем. Таким образом, особенно для веб-сайтов с большим количеством графических ресурсов, ленивая загрузка изображений может значительно повысить скорость загрузки веб-страниц.
Обычный способ ленивой загрузки изображений заключается в том, чтобы сначала установить относительно простое изображение для источника изображения, затем установить реальный адрес изображения в пользовательский атрибут, создать заполнитель, а затем установить событие прослушивателя для изображения. , как только изображение поступит в диапазон области просмотра, получите реальный адрес из пользовательского атрибута изображения, а затем назначьте его src, чтобы он загружался.
«Отображение индикатора выполнения на первом экране»: если вы часто недовольны объемом данных, оптимизированных на первом экране, и не можете дополнительно сократить длину пакета первого экрана, вы можете использовать индикатор выполнения, чтобы напомнить пользователям ждать.
После разговора об обработке ресурса данных картинки нам часто требуется оптимизировать содержимое этой части асинхронного запроса. Потому что асинхронный сбор данных также неотделим от внешнего интерфейса. Мы также можем выполнить некоторую обработку в этой части:
-
Оптимизация асинхронных запросов:
- Взаимодействие с использованием обычного формата данных json
- Кэш некоторых часто используемых данных
-
Встраивание данных и статистика
«Взаимодействие JSON», формат данных JSON является легким и простым по структуре, что часто может значительно оптимизировать обмен данными между интерфейсом и сервером. «Кэш общих данных» может кэшировать некоторую общую информацию, такую как основная информация о пользователях, что может обеспечить сокращение запросов ajax. При этом содержимому вновь добавленного хранилища в HTML5 не нужно опасаться утечки информации, вызванной разоблачением файлов cookie. «Захоронение данных и статистика» относительно знакомы старшим программистам. И большинство нынешних компаний также сделают это. Заинтересованные друзья могут проверить это сами.
Наконец, есть работа с большими объемами данных. Для языка javascript его ограничивает собственный единственный поток и он не может вычислить большой объем данных, что часто приводит к зависанию страницы. И, возможно, некоторые сложные пользовательские интерфейсы в бизнесе требуют выполнения большого количества операций, поэтому,Использование вебворкераэто важно. Возможно, отсталость популяризации фронтенд-стандартов приведет к кратковременному отсутствию этих обновок.
Суммировать
В этой статье делается краткий обзор темы производительности внешнего интерфейса. Возможно, это не исчерпывающие, но некоторые знания, которые часто используются в повседневной разработке. Я надеюсь, что те, кто заинтересован, могут попробовать эти оптимизации лично. В этой статье изложены несколько пунктов знаний:
- Оптимизация на сетевом уровне
- Оптимизация уровня данных
- Управление DOM и оптимизация уровня рендеринга
Если у вас есть какие-либо вопросы по поводу того, что я написал, вы можете прокомментировать.Если есть ошибка в том, что я написал, пожалуйста, поправьте меня. Если вам нравится мой блог, подписывайтесь на меня в Star~ Yo. Давайте добиваться прогресса вместе. Добро пожаловать, чтобы следовать за мнойблог на гитхабе
Последнее объявление
Я слышал, что за написание статей можно получить книгу «Асинхронное сообщество». «Асинхронное сообщество» — это ведущее книжное сообщество ИТ-специалистов в Китае. Мне очень нужны его книги, поэтому я изо всех сил старался написать эту статью, я хочуЭта книга, если вы думаете, что это хорошо, поставьте мне лайк ^-^