Оптимизировать js: Как оптимизировать JavaScript и ускорить загрузку сайта

Увеличиваем скорость работы сайта при помощи оптимизации JavaScript

Сайт может работать быстрее, если выполнены следующие рекомендации по оптимизации JS-кода. Если же этого не сделать, то сайт будет недостаточно быстро отображаться на стороне клиента.

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

Если без каких-то скриптов сайт функционален, то загрузку этих JS-скриптов осуществлять после отрисовки страницы (для этого надо поместить код в конец секции body). Некоторые скрипты нужны для создания эффектов, которые инициируются не сразу после загрузки страницы или их отложенная загрузка не влияет на первое впечатление от сайта. Автоматическое пролистывание слайдера или скрипт для сбора статистики посещений, например, легко могут быть инициированы уже после отрисовки страницы в браузере. Пусть лучше пользователь побыстрее увидит страницу, а не ждёт тратит при загрузке лишнее время ради того, чтобы через 5 секунд красиво перелистнулся рекламный баннер или чтобы его посчитали.

Загружайте скрипты с поддоменов, с других доменов или используйте CDN — даже у самых продвинутых браузеров файлы с одного домена загружаются в ограниченное число потоков. Если изображений, стилей и скриптов на странице достаточно много, то образуется очередь на загрузку данных. Количество используемых потоков лимитируется только для домена, поэтому если JS-файлы будут загружаться с другого домена (или поддомена), то их загрузка произойдёт быстрее за счёт параллельности.

Блокирующие скрипты не должны подгружаться с «непонятных» внешних доменов. Если внешний домен перестанет отвечать или станет отвечать с длительной задержкой, то будет «тормозить» весь ваш сайт, а пользователи будут «любоваться» белым экраном. Если используете внешние домены для скриптов, то убедитесь, что эти домены достаточно стабильны.

JS надо сжать, минимизировать и оптимизировать. Удаление пробелов, переносов строк, сокращение названий переменных и другие оптимизации значительно уменьшают размер файлов скриптов и ускоряют загрузку. При использовании сторонних библиотек — подключайте минимизированную версию в production-окружении. Для собственных скриптов используйте специальные библиотеки, сжимающие и оптимизирующие JavaScript, — UglifierJS, JSMin, Closure Compiler, YUI Compressor. При использовании агрессивных оптимизаций обязательно прочтите рекомендации для используемого компрессора и протестируйте работоспособность полученных файлов.

Совместно используемые скрипты должны быть объединены в один файл. Загрузка одного файла в 50 Kb осуществляется быстрее загрузки 10 файлов по 5 Kb, отдача таких файлов меньше грузит сервер, да и сжатие эффективнее работает на больших файлах.

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

Кэшируйте скрипты на стороне клиента — не заставляйте пользователей многократно скачивать один и тот же скрипт: используйте соответствующие заголовки в ответе веб-сервера (Expires или Cache-Control max-age, Last-Modified или ETag).

Не используйте большие библиотеки без надобности — например, ради какого-то элементарного эффекта на главной странице сайта не стоит на всех страницах подключать jQuery. Если для реализации всей интерактивности сайта может хватить 30 строчек простого js-кода, то использование объёмной библиотеки просто нерационально.

Про оптимизацию javascript кода (часть 1)

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

Все больше статей по клиентской оптимизации появляется. Но проблема в том, что практики из статей начинают применять молодые разработчики без понимания причин. Зачастую авторы статей рассказывают как они решили свою проблему.

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

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

 // 1
for (var i = 0; i 

Вторая версия чуть более многословна, но быстрее первой. Третья менее многословна, но не совсем понятна слету (проход по массиву в обратном порядке не естественен для понимания).

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

Подобные оптимизации сработают для старых браузеров. Но тут возникает вопрос целесообразности: надо ли держать такое количество непонятного кода только для оптимизации (еще не понятно необходимой ли) работы старых браузеров. Намного лучше оставить код многословным и однозначным. Пусть оптимизируют интерпретаторы.

А вот третий конец — это DOM. Обновление одного узла в DOM-e ведет за собой каскад телодвижений со стороны браузера: обновление свойств children, parentNode, nextSibling у нод, которые «цепляются» этим изменением, обновление liveCollections, триггер repaint и reflow, очистка памяти, если использован innerHTML, то еще дополнительный парсинг текста в DOM модель.

Узких мест в DOM-е множество. Самые тяжелые — обновление: добавление и удаление узлов. При том время отработки одного и того же кода зависит от общей сложности DOM дерева, максимальной вложенности, количества таблиц стилей и количества правил. Это означает, что один и тот же способ оптимизации даст различный прирост, в зависимости от сложности страницы.

Браузерные производители понимают, и со своей стороны стараются оптимизировать код движков. И тут мы наблюдаем другую интересную ситуацию: разные подходы к оптимизации дают разный прирост в разных браузерах. Чем древнее браузер, тем вероятнее, что хитрые манипуляции дадут преимущество.

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

Я к чему веду: смысла в особой оптимизации кода нет. Самый разумный подход — написать код как есть, структурировать и сделать его читаемым и понятным. И только если профилирование покажет необходимость оптимизаций, начать именно с оптимизации работы с DOM.

Оптимизация node.js приложения

Всех заинтересованных добро пожаловать под кат!

Для начала определимся с методикой тестирования производительности.
Нас будет интересовать количество обслуженных запросов за 1 секунду: rps.
Запускать будем приложение в режиме 1 воркера (1 процесса), замеряя производительность старого кода и кода с оптимизациями — абсолютная производительность не важна, важна сравнительная производительность.

Сразу надо оговорится, что в плане блокирующих запросов, ожидания БД и т.п. приложение уже оптимизировано, все упирается в cpu: при тестах воркер потребляет 100% cpu.

На продашен серверах используется node.js версии 6 — с неё и начнем:
Requests/sec: 1210

Пробуем на 8й ноде:
Requests/sec: 2308
10я нода:
Requests/sec: 2590

Разница очевидна. Ключевую роль тут играет обновление версии v8 — множество плохо оптимизирующегося v8 кода осталось в прошлом. И чтобы не бороться с ветряными мельницами исчезнувшими в node.js v8 — лучше сразу обновиться, а потом уже заниматься оптимизацией кода.

Переходим собственно к поиску узких мест: на мой взгляд, лучший инструмент для этого — flamegraph. И с появлением проекта 0x получить flamegraph стало очень просто — запускам 0x вместо node: 0x -o ваш_скрип.js, делаем тест, останавливаем скрипт, смотрим результат в браузере.

Примерно так выглядит flamegraph тестируемого кода до оптимизаций:

Внизу фильтры, оставляем app, deps — только код приложения и сторонних модулей.

Чем шире полоска — тем больше времени потрачено на выполнения этой функции (включая вложенные вызовы).

Дальше возможен простой алгогритм действий: оптимизировать самые широкие функции, переходя от одной к другой. Но я выбрал другой подход: оптимизировать начиная от точки входа в приложения (обработчик запроса в http.createServer). В конце исследуемой функции вместо вызова следующих функций я завершаю обработку запроса, отвечая ответом-пустышкой, и изучаю производительность именно этой функции. После её оптимизации ответ-пустышка перемещается дальше по стеку вызовов к следующей функции и т.д.

Итак, оставляем только стартовую функцию, получаем:
Requests/sec:

Подключая фильтры core, v8 можно увидеть, что практически вся исследуемая функция состоит из отправки ответа, логгирования и других слабо оптимизируемых вещей — едем дальше.

Переходим к следующей функции:
Requests/sec: 16111
Ничего не изменилось — погружаемся дальше:
Requests/sec: 13330

Наш клиент! Видно что задействованная функция getByUrl занимает значимую часть стартовой функции — что хорошо коррелирует с проседанием rps.
Смотрим внимательно что в ней происходит (включаем core, v8):

много чего происходит… курим код, оптимизируем:

for (var i in this.data) {
  if (this[i]._options.regexp_obj.test(url)) return this[i];
}
return null;

let result = null;
for (let i=0; i<this.length && !result; i++) {
  if (this[i]._options.regexp_obj.test(url)) result = this[i];
}

Идем дальше, к следующей функции
Requests/sec: 13316

В этой функции много array функций и, несмотря на существенное ускорение в последних версиях node.

И так раз за разом, для каждой следующей функции.
Еще несколько пригодившихся оптимизаций: для хешей с динамически изменяемым набором ключей new Map() может быть на 40% быстрее обычного {};
Math.round(el*100)/100 в 2 раза быстрее чем toFixed(2).
В flamegraph-е для core и v8 функций можно увидеть как и малопонятные записи, так и вполне говорящие StringPrototypeSplit или v8::internal::Runtime_StringToNumber, и, если это значимая часть выполнения кода, попытаться оптимизировать, например просто переписать код, не выполняющий эти операции.
Например, замена split на несколько вызовов indexOf и substring может давать двойной выигрыш в производительности.

Отдельная большая и сложная тема — jit оптимизация, а вернее деоптимизированные функции.
При наличии большой доли таких функций надо будет разбираться и с ними.
Тут может помочь вдумчивое изучение вывода node —trace_file_names —trace_opt_verbose —trace-deopt —trace_opt

Например, строчки вида
deoptimizing (DEOPT soft): begin 0x2bcf38b2d079 <JSFunction getTime… Insufficient type feedback for binary operation привели к строчке
return val >= 10? val: ‘0’+val;
Замена на
return (val >= 10? »: ‘0’)+val;
исправила ситуацию.

Для старого v8 движка есть достаточно много информации по причинам и способах борьбы с деоптимизацией функций:
github.com/P0lip/v8-deoptimize-reasons — список,
www.netguru.co/blog/tracing-patterns-hinder-performance — разбор типовых причин,
www.html5rocks.com/en/tutorials/speed/v8 — про оптимизации для v8, думаю справедливо и для текущего движка v8.
Но многие из проблем уже не актуальны для нового v8.

Так или иначе, после всех оптимизаций удалось получить Requests/sec: 9971, т.е. ускорится примерно в 2 раза за счет перехода на свежую версию node. js, и еще в 4 раза за счет оптимизации кода.
Надеюсь, этот опыт будет полезен кому-нибудь еще.

Оптимизация скриптов и стилей сайта

Частая проблема неоптимизированных сайтов — это множество дополнительно подключаемых файлов. Интересно, что периодически я встречал ситуацию, что эти файлы даже не использовались. Они просто впустую нагружали сайт. В этой статье поговорим о скриптах (.js) и стилях (.css).

Оптимизация js скриптов

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

В первую очередь, нужно сделать анализ того, используются ли каждый подключаемый скрипт на сайте. Во вторую очередь, нужно проверить, используются ли скрипты на всех страницах или только на одной/нескольких. Если пара скриптов используется только на главной странице, то не нужно их загружать на всех других страницах сайта. В любой CMS можно создать несколько шаблонов раздела head, которые будут отличаться списком подключаемых файлов.

Итак, вы убедились, что скрипты только нужные, а загружаются они только на нужных страницах. Далее смотрим внутри этих файлов. Сжат ли там код? Если нет, то простое сокращение ненужных символов может сэкономить десятки килобайт. Можно это сделать вручную (например, https://jscompress.com/), а можно с помощью дополнительных сервисов, которые сжимают код всех подключенных js файлов автоматически (например, в Modx это MinifyX).

Следующий этап оптимизации — проверить место подключения js файлов. Чем выше в шаблоне сайта подключение скриптов, тем сильнее их загрузка откладывает отображение основного контента сайта. Не всем скриптам обязательно подключение в разделе head, некоторые можно перенести в самый конец документа перед закрывающим тегом body.

Ещё один приём — это использование асинхронной загрузки скриптов, которая не блокирует загрузку прочих файлов сайта. Опять же, не все скрипты могут работать в таком режиме. Каждый нужно проверять отдельно.

<script async src="/путь-к-файлу.js"></script>

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

Важно соблюдать последовательность объединения. Если у вас jquery плагин, то его код должен идти после самого jquery. Объединить файлы можно вручную, но лучше делать это автоматически (например, в Modx это может сделать плагин MinifyX).

Оптимизация css стилей

Также сначала проверяем необходимость подключения конкретных стилей. Если вы используете библиотеки типа Bootstrap, то выбирайте только необходимые стили, не нужно загружать то, чем вы не пользуетесь.

Принципы оптимизации загрузки css файлов аналогичны js:

• Загружаем нужны стили на нужных страницах
• Сжимаем код
• Объединяем в один файл

Можно выделить самые важные стили (описание 10-100 самых базовых элементов) и встроить их (inline) в код страницы. Google рекомендует это делать для ускорения прорисовки шаблона/структуры страницы.

Все оптимизации css стилей также лучше автоматизировать с помощью плагинов.

Вышеперечисленные базовые действия могут существенно ускорить загрузку страниц. То есть вы один раз проведёте эту работу, а количество запросов, которые требуются для загрузки сайта может сократиться на несколько десятков. Общий размер всех js и css файлов можно сократить в несколько раз после сжатия.

К сожалению, многие CMS (WordPress, Битрикс) идут с шаблонами, которые изначально сделаны так, как будто они специально хотят замедлить ваш сайт. Оптимизируйте подключаемые js и css файлы — это обязательный этап работы по ускорению скорости загрузки сайта.

Автор: Александр Дергунов
Дата публикации: 29.12.2019 г.

Как оптимизировать CSS- и JS-файлы в WordPress?

Каждый современный веб-сайт для своей работы использует CSS- и JS-файлы. Первые используются для построения разметки внешнего вида, а JS – это JavaScript-скрипты, отвечающие за расширение функционала.

Для чего оптимизировать CSS- и JS-файлы?

В рамках оптимизации (увеличения скорости) работы сайта веб-мастера стараются уменьшить размер файлов обеих типов. Это имеет смысл делать, если на сайте одновременно подключаются несколько таких файлов. В процессе эволюции сайтостроения была придумана технология минификации, которая позволяет уменьшить размеры файлов скриптов за счет удаления в них комментариев, лишних пробелов, переносов строк.

В арсенале WordPress имеется множество бесплатных плагинов, поддерживающих и успешно применяющих эту технологию. Одним их таких есть AssetsMinify.

Плагин AssetsMinify

После установки и активации плагина в админ-панели WordPress появляется страница настроек плагина, на которую можно попасть, выполнив переход Настройки -> AssetsMinify.

Тут можно сделать основные настройки. Во-первых, для включения работы плагина следует отметить галочкой пункт Use Compass. Дальше для оптимизации стилей нужно отметить пункт Compress styles, а для скриптов – Compress scripts. Следующим шагом идет включение пункта Async attribute on footer’s script tag, отвечающего за асинхронную загрузку файлов, которая позволяет Вашему веб-браузеру грузить основной код страницы, не дожидаясь загрузки css- и js-скриптов.

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

Нажмите, пожалуйста, на одну из кнопок, чтобы узнать понравилась статья или нет.

Если Вам понравилась статья — поделитесь с друзьями

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

React использует несколько умных подходов для минимизации количества дорогостоящих DOM-операций, необходимых для обновления пользовательского интерфейса. Для многих приложений, использование React приведёт к быстрому пользовательскому интерфейсу без особых усилий по оптимизации производительности. Тем не менее, существует несколько способов ускорить React-приложение.

Использование продакшен-сборки

Если вы испытываете проблемы с производительностью в React-приложении, убедитесь в том, что вы проводите тесты с настройками минифицированной продакшен-сборки.

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

Если вы не уверены в том, что процесс сборки настроен правильно, вы можете проверить это, установив React Developer Tools for Chrome. Если вы посетите сайт, работающий на React в продакшен-режиме, иконка будет с чёрным фоном:

Если вы посетите сайт с React в режиме разработки, у иконки будет красный фон:

Как правило, режим разработки используется во время работы над приложением, а продакшен-режим при деплое приложения для пользователей.

Ниже вы можете найти инструкцию по сборке своего приложения для продакшена.

Create React App

Если ваш проект сделан с помощью Create React App, выполните:

Эта команда создаст продакшен-сборку вашего приложения в папке build/ вашего проекта.

Помните, что это необходимо только перед деплоем на продакшен. Для обычной разработки используйте npm start.

Однофайловые сборки

Мы предлагаем готовые для продакшена версии React и React DOM в виде отдельных файлов:

<script src="https://unpkg. com/react@17/umd/react.production.min.js"></script>
<script src="https://unpkg.com/react-dom@17/umd/react-dom.production.min.js"></script>

Помните, что для продакшена подходят только те файлы, которые заканчиваются на .production.min.js.

Brunch

Для наиболее эффективной продакшен-сборки с Brunch, установите плагин terser-brunch.

# В случае использования npm
npm install --save-dev terser-brunch

# В случае использования Yarn
yarn add --dev terser-brunch

Затем, для создания продакшен сборки, добавьте флаг -p к команде build:

Помните, что это нужно делать только для продакшен-сборки. Вам не нужно использовать флаг -p или применять этот плагин во время разработки, потому что это скроет вспомогательные предупреждения React и замедлит процесс сборки.

Browserify

Для наиболее эффективной продакшен-сборки с Browserify, установите несколько плагинов:

# В случае использования npm
npm install --save-dev envify terser uglifyify

# В случае использования Yarn
yarn add --dev envify terser uglifyify

При создании продакшен-сборки, убедитесь, что вы добавили эти пакеты для преобразования (порядок имеет значение):

• Плагин envify обеспечивает правильную среду для сборки. Сделайте его глобальным (-g).
• Плагин uglifyify удаляет импорты, добавленные при разработке. Сделайте его глобальным (-g).
• Наконец, полученная сборка отправляется к terser для минификации (прочитайте, зачем это нужно).

К примеру:

browserify ./index.js \
  -g [ envify --NODE_ENV production ] \
  -g uglifyify \
  | terser --compress --mangle > ./bundle.js

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

Rollup

Для наиболее эффективной продакшен-сборки с Rollup, установите несколько плагинов:

npm install --save-dev rollup-plugin-commonjs rollup-plugin-replace rollup-plugin-terser


yarn add --dev rollup-plugin-commonjs rollup-plugin-replace rollup-plugin-terser

При создании продакшен-сборки, убедитесь, что вы добавили эти плагины (порядок имеет значение):

• Плагин replace обеспечивает правильную среду для сборки.
• Плагин commonjs обеспечивает поддержку CommonJS в Rollup.
• Плагин terser сжимает и оптимизирует финальную сборку.

plugins: [
  
  require('rollup-plugin-replace')({
    'process.env.NODE_ENV': JSON.stringify('production')
  }),
  require('rollup-plugin-commonjs')(),
  require('rollup-plugin-terser')(),
  
]

Полный пример настройки можно посмотреть здесь.

Помните, что это нужно делать только для продакшен-сборки. Вам не следует использовать плагин terser или плагин replace со значением 'production' в процессе разработки, потому что это скроет вспомогательные предупреждения React и замедлит процесс сборки.

webpack

Примечание:

Если вы используете Create React App, пожалуйста, следуйте инструкциям выше.
Этот раздел подойдёт для тех, кто самостоятельно настраивает webpack.

Webpack 4.0 и выше по умолчанию минифицирует код в продакшен-режиме.

const TerserPlugin = require('terser-webpack-plugin');

module.exports = {
  mode: 'production',
  optimization: {
    minimizer: [new TerserPlugin({  })],
  },
};

Вы можете узнать об этом больше в документации webpack.

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

Анализ производительности компонентов с помощью вкладки Chrome «Performance»

В режиме разработки вы можете видеть как компоненты монтируются, обновляются и размонтируются с помощью инструментов производительности в браузерах, которые их поддерживают. Например:

Для того, чтобы сделать это в Chrome:

1. Временно отключите все расширения Chrome, особенно React DevTools. Они могут существенно исказить результаты!
2. Убедитесь, что вы запускаете приложение в режиме разработки.
3. Откройте в инструментах разработчика Chrome вкладку Performance и нажмите Record.
4. Выполните действия, которые вы хотите проанализировать на производительность. Не записывайте более 20 секунд, иначе Chrome может зависнуть.
5. Остановите запись.
6. События React будут сгруппированы под меткой User Timing.

Для более детального ознакомления, посмотрите эту статью от Бена Шварца (Ben Schwarz).

Обратите внимание, что результаты являются относительными и в продакшене рендеринг компонентов будет быстрее. Всё же это должно помочь вам понять, когда какой-то пользовательский компонент обновляется по ошибке, а также как глубоко и часто обновляется пользовательский интерфейс.

В настоящее время Chrome, Edge и IE единственные браузеры, которые поддерживают данную возможность, но мы используем стандарт User Timing API, поэтому ожидайте, что больше браузеров добавят его поддержку.

Пакеты react-dom версии 16.5+ и react-native версии 0.57+ предоставляют расширенные возможности анализа производительности в режиме разработки с помощью инструментов разработчика React Profiler. Обзор профайлера можно найти в посте блога «Введение в React Profiler». Пошаговое видео-руководство также доступно на YouTube.

Если вы ещё не установили инструменты разработчика React, вы можете найти их здесь:

Примечание

Профилирование продакшен-пакета для react-dom также доступно как react-dom/profiling. Подробнее о том, как использовать этот пакет, читайте на fb.me/react-profiling

Виртуализация длинных списков

Если ваше приложение рендерит длинные списки данных (сотни или тысячи строк), мы рекомендуем использовать метод известный как «оконный доступ». Этот метод рендерит только небольшое подмножество строк в данный момент времени и может значительно сократить время, необходимое для повторного рендера компонентов, а также количество создаваемых DOM-узлов.

react-window и react-virtualized — это популярные библиотеки для оконного доступа. Они предоставляют несколько повторно используемых компонентов для отображения списков, сеток и табличных данных. Если вы хотите использовать что-то более специфическое для вашего конкретного случая, то вы можете создать собственный компонент с оконным доступом, как это сделано в Twitter.

Избежание согласования

React создаёт и поддерживает внутреннее представление отображаемого пользовательского интерфейса. Оно также включает React-элементы возвращаемые из ваших компонентов. Это представление позволяет React избегать создания DOM-узлов и не обращаться к текущим без необходимости, поскольку эти операции могут быть медленнее, чем операции с JavaScript-объектами. Иногда его называют «виртуальный DOM», но в React Native это работает точно так же.

Когда изменяются пропсы или состояние компонента, React решает нужно ли обновление DOM, сравнивая возвращённый элемент с ранее отрендеренным. Если они не равны, React обновит DOM.

Несмотря на то, что React обновляет только изменённые DOM-узлы, повторный рендеринг всё же занимает некоторое время. В большинстве случаев это не проблема, но если замедление заметно, то вы можете всё ускорить, переопределив метод жизненного цикла shouldComponentUpdate, который вызывается перед началом процесса ререндеринга. Реализация этой функции по умолчанию возвращает true, указывая React выполнить обновление:

shouldComponentUpdate(nextProps, nextState) {
  return true;
}

Если вы знаете ситуации, в которых ваш компонент не нуждается в обновлении, вы можете вернуть false из shouldComponentUpdate, чтобы пропустить весь процесс рендеринга, включая вызов render() и так далее ниже по иерархии.

В большинстве случаев вместо того, чтобы писать shouldComponentUpdate() вручную, вы можете наследоваться от React.PureComponent. Это эквивалентно реализации shouldComponentUpdate() с поверхностным сравнением текущих и предыдущих пропсов и состояния.

shouldComponentUpdate в действии

Вот поддерево компонентов. Для каждого из них SCU указывает что возвратил shouldComponentUpdate, а vDOMEq указывает эквивалентны ли отрендеренные React элементы. Наконец, цвет круга указывает требуется ли согласовать компонент или нет.

Поскольку shouldComponentUpdate возвратил false для поддерева с корнем C2, React не пытался отрендерить C2, следовательно не нужно вызывать shouldComponentUpdate на C4 и C5.

Для C1 и C3 shouldComponentUpdate возвратил true, поэтому React пришлось спуститься к листьям и проверить их. Для C6 shouldComponentUpdate вернул true, и поскольку отображаемые элементы не были эквивалентны, React должен был обновить DOM.

Последний интересный случай — C8. React должен был отрисовать этот компонент, но поскольку возвращаемые им React-элементы были равны ранее предоставленным, ему не нужно обновлять DOM.

Обратите внимание, что React должен был делать изменения только для C6. Для C8 этого удалось избежать сравнением отрендеренных React-элементов, а для поддеревьев C2 и C7 даже не пришлось сравнивать элементы, так как нас выручил shouldComponentUpdate и render не был вызван.

Примеры

Если единственный случай изменения вашего компонента это когда переменная props.color или state.count изменяются, вы могли бы выполнить проверку в shouldComponentUpdate следующим образом:

class CounterButton extends React.Component {
  constructor(props) {
    super(props);
    this.state = {count: 1};
  }

  shouldComponentUpdate(nextProps, nextState) {
    if (this.props.color !== nextProps.color) {
      return true;
    }
    if (this. state.count !== nextState.count) {
      return true;
    }
    return false;
  }

  render() {
    return (
      <button
        color={this.props.color}
        onClick={() => this.setState(state => ({count: state.count + 1}))}>
        Счётчик: {this.state.count}
      </button>
    );
  }
}

В этом коде shouldComponentUpdate — это простая проверка на наличие каких-либо изменений в props.color или state.count. Если эти значения не изменяются, то компонент не обновляется. Если ваш компонент стал более сложным, вы можете использовать аналогичный паттерн «поверхностного сравнения» между всеми полями props и state, чтобы определить должен ли обновиться компонент. Этот механизм достаточно распространён, поэтому React предоставляет вспомогательную функцию для работы с ним — просто наследуйтесь от React.PureComponent. Поэтому, следующий код — это более простой способ добиться того же самого эффекта:

class CounterButton extends React. PureComponent {
  constructor(props) {
    super(props);
    this.state = {count: 1};
  }

  render() {
    return (
      <button
        color={this.props.color}
        onClick={() => this.setState(state => ({count: state.count + 1}))}>
        Счётчик: {this.state.count}
      </button>
    );
  }
}

В большинстве случаев вы можете использовать React.PureComponent вместо написания собственного shouldComponentUpdate. Но он делает только поверхностное сравнение, поэтому его нельзя использовать, если пропсы и состояние могут измениться таким образом, который не сможет быть обнаружен при поверхностном сравнении.

Это может стать проблемой для более сложных структур данных. Например, вы хотите, чтобы компонент ListOfWords отображал список слов, разделённых через запятую, с родительским компонентом WordAdder, который позволяет кликнуть на кнопку, чтобы добавить слово в список. Этот код работает неправильно:

class ListOfWords extends React. PureComponent {
  render() {
    return <div>{this.props.words.join(',')}</div>;
  }
}

class WordAdder extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      words: ['словцо']
    };
    this.handleClick = this.handleClick.bind(this);
  }

  handleClick() {
    
    const words = this.state.words;
    words.push('словцо');
    this.setState({words: words});
  }

  render() {
    return (
      <div>
        <button onClick={this.handleClick} />
        <ListOfWords words={this.state.words} />
      </div>
    );
  }
}

Проблема в том, что PureComponent сделает сравнение по ссылке между старыми и новыми значениями this.props.words. Поскольку этот код мутирует массив words в методе handleClick компонента WordAdder, старые и новые значения this.props.words при сравнении по ссылке будут равны, даже если слова в массиве изменились. ListOfWords не будет обновляться, даже если он содержит новые слова, которые должны быть отрендерены.

Сила иммутабельных данных

Лучший способ решения этой проблемы — избегать мутирования значений, которые вы используете как свойства или состояние. К примеру, описанный выше метод handleClick можно переписать с помощью concat следующим образом:

handleClick() {
  this.setState(state => ({
    words: state.words.concat(['словцо'])
  }));
}

ES6 поддерживает синтаксис расширения для массивов, который поможет сделать это проще. Если вы используете Create React App, то этот синтаксис доступен там по умолчанию.

handleClick() {
  this.setState(state => ({
    words: [...state.words, 'словцо'],
  }));
};

Таким же образом вы можете переписать код, который мутирует объекты. К примеру, мы имеем объект с именем colormap и хотим написать функцию, которая изменяет colormap. right на 'blue'. Мы могли бы написать:

function updateColorMap(colormap) {
  colormap.right = 'blue';
}

Чтобы написать это без мутирования исходного объекта, мы можем использовать метод Object.assign:

function updateColorMap(colormap) {
  return Object.assign({}, colormap, {right: 'blue'});
}

Функция updateColorMap теперь возвращает новый объект, вместо того, чтобы мутировать исходный. Метод Object.assign входит в ES6 и требует полифила.

Синтаксис расширения свойств объекта упрощает обновление объектов без мутаций:

function updateColorMap(colormap) {
  return {...colormap, right: 'blue'};
}

Этот синтаксис был добавлен в JavaScript в ES2018.

Если вы используете Create React App, то Object.assign и синтаксис расширения объектов доступны вам по умолчанию.

При работе с глубоко вложенными объектами, постоянное их обновление может запутать. Если вы столкнулись с такой проблемой, обратите внимание на Immer или immutability-helper. Эти библиотеки позволяют писать хорошо читаемый код, не теряя преимуществ иммутабельности.

Оптимизация canvas — Интерфейсы веб API

Элемент <canvas> является одним из наиболее широко используемых инструментов для рендеринга 2D-графики в Интернете. Однако когда веб-сайты и приложения используют Canvas API на пределе его возможностей, производительность начинает снижаться. В этой статье приводятся предложения по оптимизации использования элемента canvas для обеспечения хорошей работы графики.

Ниже приведён сборник советов по улучшению производительности canvas.

Предварительно отрисуйте похожие примитивы или повторяющиеся объекты на offscreen canvas

Если вы повторяете одни и те же операции рисования в каждом кадре анимации, рассмотрите возможность их выгрузки на offscreen canvas. Затем вы можете визуализировать закадровое изображение на свой основной canvas так часто, как это необходимо, без необходимости повторять шаги, необходимые для его генерации.

myCanvas.offscreenCanvas = document.createElement('canvas');
myCanvas.offscreenCanvas.width = myCanvas.width;
myCanvas.offscreenCanvas.height = myCanvas.height;

myCanvas.getContext('2d').drawImage(myCanvas.offScreenCanvas, 0, 0);

Избегайте координат с плавающей точкой и используйте вместо них целые числа

Субпиксельный рендеринг происходит при рендеринге объектов на canvas без целых значений.

ctx.drawImage(myImage, 0.3, 0.5);

Это заставляет браузер выполнять дополнительные вычисления для создания эффекта сглаживания. Чтобы избежать этого, обязательно округлите все координаты, используемые в вызовах drawImage(), например, с помощью Math.floor().

Не масштабируйте изображения в

При загрузке кешируйте изображения разных размеров на offscreen canvas, а не постоянно масштабируйте их в drawImage().

Используйте несколько слоёв canvas для сложных сцен

Вы можете обнаружить, что некоторые объекты в вашем приложении нужно часто перемещать или менять, в то время как другие остаются относительно статичными. Возможной оптимизацией в этой ситуации является наложение ваших элементов с использованием нескольких элементов <canvas>.

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

<div>
  <canvas></canvas>
  <canvas></canvas>
  <canvas></canvas>
</div>

<style>
  #stage {
    width: 480px;
    height: 320px;
    position: relative;
    border: 2px solid black;
  }

  canvas { position: absolute; }
  #ui-layer { z-index: 3; }
  #game-layer { z-index: 2; }
  #background-layer { z-index: 1; }
</style>

Используйте простой CSS для больших фоновых изображений

Если у вас есть статическое фоновое изображение, вы можете нарисовать его на простом элементе <div>, используя свойство CSS background, и расположить его под canvas. Это сведёт на нет необходимость рендеринга фона на canvas на каждом тике.

Масштабирование холста с использованием CSS-преобразований

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

var scaleX = window.innerWidth / canvas.width;
var scaleY = window.innerHeight / canvas.height;

var scaleToFit = Math.min(scaleX, scaleY);
var scaleToCover = Math.max(scaleX, scaleY);

stage.style.transformOrigin = '0 0'; 
stage.style.transform = 'scale(' + scaleToFit + ')';

Отключите прозрачность

Если ваше приложение использует canvas и не нуждается в прозрачном фоне, установите для параметра alphaзначение false при создании контекста рисования с помощью HTMLCanvasElement.getContext(). Эта информация может использоваться браузером для оптимизации рендеринга.

var ctx = canvas.getContext('2d', { alpha: false });

Другие советы

• Объединяйте запросы к canvas. Например, рисуйте одну ломанную линию вместо нескольких отдельных линий.
• Избегайте ненужных изменений состояния canvas.
• Отображайте только изменения экрана, а не заново перерисовывайте.
• По возможности избегайте свойства shadowBlur (en-US).
• Избегайте рендеринга текста, когда это возможно.
• Попробуйте разные способы очистки canvas ((clearRect(), или fillRect(), или изменение размера canvas).
• С анимациями используйте window.requestAnimationFrame() вместо window.setInterval() (en-US).
• Будьте осторожны с тяжёлыми физическими библиотеками.

Оптимизация запуска JavaScript | Основы веб-технологий

Eng Менеджер по связям с веб-разработчиками

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

Сеть

Когда большинство разработчиков думают о стоимости JavaScript, они думают об этом в сроки загрузки и стоимость исполнения . Отправка большего количества байтов JavaScript по проводу занимает больше времени, чем медленнее соединение пользователя.

Это может быть проблемой даже в странах первого мира, поскольку эффективная сеть тип подключения , который имеет пользователь, на самом деле может не быть 3G, 4G или Wi-Fi. Вы можете быть на кофейня Wi-Fi, но подключена к сотовой точке доступа со скоростью 2G.

Вы можете уменьшить стоимость сетевой передачи JavaScript через:

• Только отправка кода, необходимого пользователю .
  • Используйте разделение кода для взлома разберитесь в своем JavaScript в том, что критично, а что нет. Сборщики модулей как поддержка webpack расщепление кода.
  • Ленивая загрузка некритичного кода.
• Минификация
• Сжатие
  • Как минимум, используйте gzip для сжатия текстовых ресурсов.
  • Рассмотрите возможность использования Бротли ~ q11. Бротли превосходит gzip по степени сжатия. Это помогло CertSimple сэкономить 17% от размера сжатых байтов JS и сохранения в LinkedIn 4% на время их загрузки.
• Удаление неиспользуемого кода .
• Код кэширования для минимизации сетевых отключений.
  • Использовать HTTP кеширование чтобы браузеры эффективно кэшировали ответы. Определить оптимальный время жизни для скриптов (max-age) и токены проверки (ETag), чтобы избежать передача неизмененных байтов.
  Кэширование
  • Service Worker может сделать сеть вашего приложения устойчивой и дать вам жадный доступ к таким функциям, как код V8 кеш.
  • Используйте долгосрочное кэширование, чтобы избежать повторной выборки ресурсов, которые не измененный. При использовании Webpack см. Имя файла хеширование.

Синтаксический анализ / компиляция

После загрузки одна из самых больших затрат JavaScript — это время для JS engine для разобрать / скомпилировать этот код. В Chrome DevTools, синтаксический анализ и компиляция являются частью желтого Время «написания сценария» на панели «Производительность».

Вкладки Bottom-Up и Call Tree показывают точное время синтаксического анализа / компиляции:

Но какое это имеет значение?

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

байтов, JavaScript дороже для обработки браузером, чем изображение аналогичного размера или веб-шрифт — Tom Dale

По сравнению с JavaScript, обработка требует значительных затрат. изображения одинакового размера (их все равно нужно декодировать!), но в среднем на мобильных устройствах аппаратного обеспечения, JS с большей вероятностью негативно повлияет на интерактивность страницы.

Когда мы говорим о медленном синтаксическом анализе и компиляции; контекст важен — мы речь идет о средних мобильных телефонах здесь. У обычных пользователей могут быть телефоны с медленными процессорами и графическими процессорами, без кеша L2 / L3 и может даже быть памятью сдерживается.

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

Ниже мы видим стоимость синтаксического анализа ~ 1 МБ распакованного (простого) JavaScript на низкое и высококачественное оборудование. Разница во времени синтаксического анализа / компиляции составляет 2–5 раз. код между самыми быстрыми телефонами на рынке и средними телефонами .

А как насчет реального сайта, такого как CNN.com?

На iPhone 8 высокого класса для синтаксического анализа / компиляции JS CNN требуется всего ~ 4 секунды. до ~ 13 с для среднего телефона (Moto G4) . Это может существенно повлиять на то, как быстро пользователь может полностью взаимодействовать с этим сайтом.

Это подчеркивает важность тестирования на среднем оборудовании (например, Moto G4) вместо телефона, который может быть у вас в кармане. Контекст имеет значение однако: оптимизируйте для устройств и условий сети, которые есть у ваших пользователей.

Неужели мы действительно отправляем слишком много JavaScript? Эээ, возможно 🙂

Использование HTTP-архива (~ 500 тыс. Самых популярных сайтов) для анализа состояния JavaScript на мобильный, мы можем видите, что 50% сайтов становятся интерактивными за 14 секунд. Эти сайты тратят до 4 секунд только на парсинг и компиляцию JS.

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

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

Время исполнения

Это не просто синтаксический анализ и компиляция, которые могут иметь свою цену. Выполнение JavaScript (запуск кода после синтаксического анализа / компиляции) — одна из операций, которые должны произойти в основном потоке. Длительное время выполнения также может повлиять на то, как скоро пользователь сможет взаимодействовать с вашим сайтом.

Если скрипт выполняется более 50 мс, время до интерактивности задерживается на всего времени, необходимого для загрузки, компиляции и выполнения JS — Алекс Рассел

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

Прочие расходы

JavaScript может влиять на производительность страницы и другими способами:

• Память.Страницы могут часто зависать или останавливаться из-за GC (мусор коллекция). Когда браузер освобождает память, выполнение JS приостанавливается, поэтому браузер, часто собирающий мусор, может приостанавливать выполнение чаще, чем нам может понравиться. Избегайте утечек памяти и частые паузы gc, чтобы страницы не зависали.
• Во время выполнения долго работающий JavaScript может блокировать основной поток, вызывая страницы, которые не отвечают. Разделение работы на более мелкие части (используя requestAnimationFrame () или requestIdleCallback () для планирования) может минимизировать проблемы с быстродействием.

Шаблоны для снижения стоимости доставки JavaScript

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

ПРПЛ

PRPL (Push, Render, Pre-cache, Lazy-load) — это шаблон, который оптимизирует интерактивность за счет агрессивного разделения кода и кеширования:

Давайте представим, какое влияние это может оказать.

Мы анализируем время загрузки популярных мобильных сайтов и прогрессивных веб-приложений, используя Статистика вызовов времени выполнения V8.Как мы видим, время синтаксического анализа (показано оранжевым) — это значительная часть того, где проводят время многие из этих сайтов:

Wego, сайту, использующему PRPL, удается поддерживать низкий уровень синтаксического анализа время для их маршрутов, становясь интерактивными очень быстро. Многие другие сайты выше принятые бюджеты на разделение кода и производительность, чтобы попытаться снизить их JS расходы.

Прогрессивная начальная загрузка

Многие сайты оптимизируют видимость контента ценой интерактивности.Получить Быстрая первая отрисовка, когда у вас есть большие пакеты JavaScript, разработчики иногда используют рендеринг на стороне сервера; затем «обновите» его, чтобы прикрепить событие обработчики, когда, наконец, будет получен JavaScript.

Будьте осторожны — это имеет свои издержки. Вы 1) обычно отправляете больших HTML ответ, который может подтолкнуть нашу интерактивность, 2) может оставить пользователя в жутком долина, где половина опыта не может быть интерактивной до тех пор, пока JavaScript заканчивает обработку.

Прогрессивная загрузка может быть лучшим подходом.Отправить минимально функциональная страница (состоящая только из HTML / JS / CSS, необходимых для текущего маршрута). По мере поступления дополнительных ресурсов приложение может выполнять отложенную загрузку и разблокировать больше функций.

Загрузка кода, пропорциональная тому, что находится в поле зрения, — это Святой Грааль. PRPL и Прогрессивная загрузка — это шаблоны, которые могут помочь в этом.

Выводы

Размер передачи имеет решающее значение для сетей низкого уровня. Время синтаксического анализа важно для устройств с привязкой к ЦП.Держать эти мелкие вопросы.

добились успеха, установив строгие бюджеты производительности для сохранения своих Низкое время передачи и синтаксического анализа / компиляции JavaScript. См. «Can You Позволить себе это?: Реальная производительность в Интернете Бюджеты » для руководства по бюджету для мобильных устройств.

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

Узнать больше

optimize-js — npm

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

Последние изменения см. В журнале изменений.

Установить

  npm install -g optimize-js
  

Использование

  optimize-js input.js> output.js
  

Пример ввода:

 
! Function () {} () 
 
 function runIt (fun) {fun ()} 
 
 runIt (function () {}) 
 

Пример вывода:

 
! (Function () {}) () 
 
 function runIt (fun) {fun ()} 
 
 runIt ((function () {})) 
 

Обзор теста

Эти числа основаны на тесте общих библиотек JS. Подробные сведения о тестах см. В разделе тесты.

CLI

  Использование: optimize-js [параметры]

Параметры:
  --source-map включить исходную карту [логическое]
  -h, --help Показать справку [логическое]

Примеры:
  optimize-js input.js> output.js оптимизировать input.js
  optimize-js  output.js читается из stdin, записывается в stdout
  

JavaScript API

 
 var optimizeJs = require ('optimize-js'); 
 
 var input = "! Function () {console.log ('оберните меня!')}"; 
 
 var output = optimizeJs (вход); 
 

Вы также можете передать аргументы:

 
 var optimizeJs = require ('optimize-js'); 
 
 var input = "! Function () {console.log ('оберните меня!')}"; 
 
 var output = optimizeJs (input, {
 
 sourceMap: true 
 
}); 
 

Почему?

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

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

К сожалению, это предположение не работает в случае немедленно вызываемых функциональных выражений (IIFE), таких как эти:

 
 (функция () {console.log ('выполнено!')}) (); 
 
 (функция () {console.log ('выполнено в стиле Крокфорда!')} ()); 
 
! Function () {console.log ('выполнено в стиле UglifyJS!')} (); 
 

Хорошая новость заключается в том, что JS-движки имеют дополнительную оптимизацию , где они пытаются обнаружить такие IIFE и пропустить этап предварительного анализа. Ура!

Плохая новость в том, что эта эвристика не всегда работает. потому что они основаны на жадном методе проверки токена '(' сразу слева от функции.(Парсер избегает чего-либо более сложного, потому что это равносильно синтаксическому анализу всего этого, сводя на нет преимущества предварительного синтаксического анализа). В случаях без парена (которые включают распространенные форматы модулей, такие как UMD / Browserify / Webpack / и т. д.), браузер фактически проанализирует функцию дважды , сначала как предварительный синтаксический анализ, а второй как полный разбор. Это означает, что код JavaScript в целом выполняется намного медленнее, поскольку на синтаксический анализ тратится больше времени, чем необходимо. См. «Стоимость небольших модулей», чтобы понять, насколько это плохо.

К счастью, поскольку оптимизация '(' для IIFE хорошо известна, мы можем использовать ее в процессе сборки, предварительный анализ всего файла JavaScript (роскошь, которую браузер не может себе позволить) и вставка скобок в тех случаях, когда мы знаем функция будет немедленно выполнена (или если у нас есть хорошая догадка). Это то, что делает optimize-js .

Более подробную информацию об оптимизации IIFE можно найти в этом обсуждении.Некоторые из моих мыслей о достоинствах оптимизации во время компиляции можно найти в этом посте.

Часто задаваемые вопросы

Как это работает?

Текущая реализация заключается в синтаксическом анализе синтаксического дерева и проверке функций, которые:

1. Вызываются немедленно с помощью любого оператора вызова ( function () {} () , ! Function () {} () и т. Д.)
2. Передаются напрямую в качестве аргументов другой функции

Первый способ — легкий выигрыш — эти функции выполняются немедленно.Второй метод более эвристический, но имеет тенденцию чтобы быть безопасной ставкой, учитывая распространенные шаблоны, такие как ошибки в стиле узла, цепочки обещаний и объявления модулей UMD / Browserify / Webpack.

Во всех таких случаях optimize-js заключает функцию в круглые скобки.

Но … вы добавляете байты!

Да, optimize-js может добавить до двух байтов (ужас!) На функцию, что практически равно нулю, если вы учтите gzip. Чтобы доказать это, вот размеры gzip для библиотек, которые я использую в тесте:

Предназначен ли

Конечно! Если вы уже отправляете объединенную миниатюрную версию своей библиотеки, то нет причин не применять optimize-js (при условии, что вы протестируете свой код, чтобы убедиться, что он действительно помогает!).Однако обратите внимание, что optimize-js должен запускать после Uglify, поскольку Uglify удаляет лишние круглые скобки, а также отменяет IIFE по умолчанию. Это также означает, что если ваши пользователи применяют Uglification к вашему пакету, оптимизация будет отменена.

Также обратите внимание, что поскольку optimize-js оптимизирует некоторые шаблоны, которые основаны на эвристике, а не , известный активно вызывается функций, в некоторых случаях это может повредить вашей производительности. (Примеры см. В тестах ниже.Обязательно проверьте, что optimize-js — это помощь, а не помеха для вашей конкретной кодовой базы, используя что-то вроде:

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

Вы также можете проверить Марки, который позволяет вам легко устанавливать точки отметки / измерения, которые вы можете визуально проверять на шкале времени Dev Tools, чтобы убедиться, что время компиляции измеряется.

Также обязательно протестируйте в нескольких браузерах! Если вам нужна пограничная виртуальная машина, загляните на edge.ms.

Разве это не должно быть работой Углифи?

Возможно! Это бесплатная библиотека с открытым исходным кодом, поэтому я призываю всех позаимствовать код или хорошие идеи.:)

Почему бы не обернуть каждую функцию пареном?

Как описано выше, оптимизация предварительного анализа в браузерах — очень хорошая идея для подавляющего большинства веб-сайтов, где большинство функций не выполняются немедленно. Однако, поскольку optimize-js знает, когда ваши функции немедленно выполняются (или может сделать разумный догадки), может быть более разумным будет применить парен-хак.

Это действительно работает для каждого движка JavaScript?

Судя по моим тестам, эта оптимизация лучше всего работает для V8 (Chrome), за которым следует Chakra (Edge), а затем SpiderMonkey (Firefox).Для JavaScriptCore (Safari) это похоже на промывку, и на самом деле может быть небольшой регресс в целом в зависимости от вашей кодовой базы. (Опять же, вот почему так важно проводить измерения на вашей собственной кодовой базе, в браузерах, на которые вы на самом деле ориентируетесь!)

В случае с Chakra IIFE в стиле Uglify на самом деле уже оптимизированы, но использование optimize-js не повредит, потому что функция, перед которой стоит '(' по-прежнему переходит в быстрый путь.

Ориентиры

Эти тесты были запущены с использованием нескольких популярных библиотек, рассчитанных на производительность .now () измерений. В каждом тесте сообщалось о среднем 251 прогоне. optimize-js commit da51013 был протестирован. Минификация была применена с помощью uglifyjs -mc , Uglify 2.7.0.

Вы также можете попробовать живую версию теста.

Chrome 55, Windows 10 RS1, Surfacebook i5

Общее улучшение: 20,63%

Edge 14, Windows 10 RS1, SurfaceBook i5

Общее улучшение: 13,52%

Firefox 50, Windows 10 RS1, Surfacebook i5

Общее улучшение: 8.26%

Safari 10, macOS Sierra, MacBook Pro i5 2013 года выпуска

Общее улучшение: -1,04%

Обратите внимание, что эти результаты могут отличаться в зависимости от вашей машины, нагрузки на ваш ЦП, гремлинов и т. Д.Я запускал полный пакет несколько раз во всех браузерах и обнаружил, что эти цифры примерно репрезентативны. В нашем наборе тестов мы используем среднее значение 151 запуск, чтобы уменьшить вариабельность.

Плагины

См. Также

Спасибо

Спасибо @krisselden, @bmaurer и @pleath за объяснение этих концепций в различных выпусках GitHub. Также благодарим astexplorer, acorn и magic-string за то, что они сделали реализацию такой простой.

Спасибо Саше Айкину за щедрый вклад в улучшение этой библиотеки (особенно в v1.0,3) и подталкивает меня к повышению точности тестов.

Содействие

Сборка и запуск тестов:

Запустите тесты:

Покрытие тестового кода:

История изменений

• v1.0.3
  • Намного более точный тест (# 37)
  • Исправления, связанные с Browserify (# 29, # 36, # 39)
  • Исправления, относящиеся к Webpack (# 7, # 34)
• v1.0.2
  • Используйте estree-walker для правильного анализа ES6 (# 31)
• v1.0,1:
  • Не вызывать process.exit (0) в случае успеха (# 11)
• v1.0.0

Как оптимизировать доставку JavaScript для ускорения вашего сайта

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

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

Влияние размера файла JS

На миллионах сайтов, измеренных с помощью HTTP-архива, на JavaScript приходится 15% веса страниц для настольных компьютеров и 16% для мобильных страниц.Для пользователей настольных компьютеров это составляет около 400 КБ на каждую посещенную страницу и 360 КБ для мобильных пользователей. Если учесть, что первое соединение, открытое для загрузки страницы, передает только 14 КБ данных, становится очевидным, что уменьшение размера файла JS является важной оптимизацией.

Но 400 КБ JavaScript не равны 400 КБ загрузки изображения, отчасти потому, что обработка JavaScript происходит при несжатом файле. Байт за байтом, JavaScript дороже, чем любой другой тип файлов для обработки на странице с точки зрения ЦП и времени.Если учесть, что сжатие GZIP может уменьшить размер доставленного текстового файла на 70–90%, 400 КБ действительно превращаются в 1,3–4,0 МБ.

Снижение воздействия JS-доставки

Итак, как мы можем уменьшить время загрузки страницы, связанное с доставкой JavaScript? Есть два способа, для каждого из которых есть лучшие практики:

1. Ускорьте загрузку JS в браузере.
   • Уменьшите объем JS, который вы используете для создания страницы.
   • Минимизируйте все ресурсы JS и используйте минимизированный сторонний JS.
   • Самостоятельное размещение стороннего JS (или использование сервис-воркера).
   • Сжать JS.
   • Используйте push и preload для критического JS.
2. Загружайте JS только тогда, когда это необходимо.
   • Удалить мертвый код JS.
   • Разделение файлов JS для доставки основных компонентов.
   • Асинхронная загрузка некритических JS-компонентов.
   • Кэш JS.

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

В следующих случаях важно убедиться, что ваша пользовательская база поддерживает реализованные методы браузером. Real User Monitoring позволяет вам увидеть, какие версии наиболее распространены среди ваших пользователей, и их следует считать необходимыми для тестирования любых изменений, которые вы вносите на свой сайт.

Ускорение загрузки JS в браузере

Уменьшите объем JS, который вы используете для создания страницы

Если вы предоставите меньше JavaScript, страница будет загружаться быстрее.

Не знаете, с чего начать? Мы уже знаем, что JS — это самый дорогой вид файлов, используемых для создания вашего сайта, поэтому вы также можете подумать о нем с точки зрения обработки. Для интерактивности на странице рекомендуется использовать JavaScript для функций, которые улучшают взаимодействие с пользователем — ожидаемых переходов, анимации и событий — а не для вещей, которые могут нарушить работу, например ярких, растянутых анимаций.

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

Разработчики Google разработали рекомендации, основанные на восприятии пользователями задержек производительности, которые вы можете использовать, чтобы судить о необходимости JS на странице в сочетании с тестированием.

Использовать минимизированные файлы JS

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

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

Самостоятельное размещение стороннего JS, если применимо (или использование сервис-воркера)

Размещение стороннего JavaScript в вашем собственном домене может быть менее удобным в обслуживании — вы не получите автоматических обновлений для скрипта, а изменения в API могут произойти без предупреждения — но это все равно может быть полезно, если скрипт критически важен для рендеринга вашего страница. Сценарий будет использовать вашу сеть и протоколы безопасности, что может привести к лучшим результатам.Вы также можете включать в библиотеки только те компоненты, которые используются в вашем исходном коде (см. «Устранение мертвого кода» ниже).

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

Сжатие JS

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

Используйте толчок и предварительную нагрузку для критических JS

Server push и предварительная загрузка могут использоваться для доставки файлов, критически важных для рендеринга страницы, раньше при загрузке страницы, чем обычно.

Файл загружается с помощью push, если указано на стороне сервера — сервер получает запрос и ему заранее сказано, что ресурсы x, y и z должны быть загружены вместе с ним.Примечательно, что методологию push можно использовать только в HTTP / 2.

Preload немного отличается, где связанным ресурсам может быть присвоен атрибут «preload» в файле HTML. Как только страница будет доставлена ​​и пока только начинается синтаксический анализ HTML, эти ресурсы запрашиваются с сервера. Это быстрее, чем обычный анализ HTML, потому что ресурсы затем запрашиваются не в том порядке, в котором они перечислены в HTML.

Загружать JS только тогда, когда это необходимо

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

Устранение мертвого кода при встряхивании дерева

Встряхивание дерева, или устранение мертвого кода, избавляет, как вы уже догадались, от кода, которого нет на вашей странице. Например, предположим, что вы загружаете миниатюрную библиотеку JQuery, но при создании страницы используете только несколько функций, предлагаемых JQuery, в собственном коде.Удаление мертвого кода позволит вам загружать только те части библиотеки JQuery, которые вы используете.

Термин «встряхивание дерева» популяризировал Rollup, который реализует эту функцию, но он также доступен через webpack и source-map-explorer. Примечательно, что эта функция работает только с модулями ES2015, используя синтаксис для ссылки на пакеты JS в других файлах. Если вы используете CommonJS, доступны некоторые параметры, например webpack-common-shake, но при использовании CommonJS вы, скорее всего, столкнетесь с ограничениями.В долгосрочной перспективе, если вы хотите использовать встряхивание деревьев, наиболее полезным будет ES2015 или более поздняя версия.

Доставка основных компонентов с разбиением на фрагменты на основе маршрута или разбиением кода

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

То, как вы определяете, где разделить код, зависит от типа загружаемого приложения, от того, кто ваши пользователи и какова ваша серверная архитектура. Есть несколько типов разделения кода:

• Разделение на поставщика отделяет ваш JS от JS, предоставленного вашим поставщиком фреймворка, например React или Vue. Разделение по поставщику предотвращает перезагрузку более крупного пакета при изменении функции в любом из источников кода. Разделение на поставщиков должно выполняться в каждом веб-приложении.
• Разделение с помощью точек входа разделяет ваш код в зависимости от того, где в вашем коде веб-пакет начинает определять зависимости в вашем приложении.Если ваш сайт не использует маршрутизацию на стороне клиента (например, SPA использует маршрутизацию на стороне клиента), использование точек входа для разделения кода может иметь смысл. При таком разбиении использование такого инструмента, как Bundle Buddy, чтобы гарантировать, что повторяющиеся пакеты не включены в дерево зависимостей, может помочь страницам загружаться быстрее.
• Динамическое разделение кода хорошо работает с приложениями, использующими маршрутизацию на стороне клиента, например одностраничными приложениями, потому что не все пользователи будут использовать все функции на странице. Это можно сделать с помощью динамического оператора import () , который возвращает обещание.По этой причине вы также можете использовать динамический импорт с помощью async / await. Parcel и webpack будут искать динамический оператор import () для отложенной загрузки ресурсов по мере необходимости.

Асинхронная загрузка некритических JS-компонентов

Использование атрибутов async и defer для внешних сценариев очень важно, особенно со сторонними сценариями. И async , и defer являются асинхронными для загрузки и анализа помеченных ими ресурсов.Почему это важно? Для JavaScript поведение по умолчанию для загрузки и анализа сценария является синхронным, что означает, что почти все остальные процессы на странице останавливаются, пока выполняются эти шаги.

Атрибут async имеет приоритет над defer в современных браузерах, поскольку современные движки браузеров лучше приспособлены для обработки JavaScript. В старых браузерах все наоборот.

Примечательно, что выполнение JavaScript происходит в одном и том же потоке браузера.JavaScript с пометкой async всегда будет выполняться до JavaScript с пометкой defer . Синхронный JavaScript выполняется немедленно, и его следует использовать только для кода, который отображает страницу (и, вероятно, даже не тогда).

Кэш JS

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

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

Takeaways and TL; DR

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

1. Меньшие размеры страницы
2. Быстрая доставка
3. Более эффективная обработка

В этом посте мы рассмотрим первые два, которые связаны между собой.Меньшие размеры страниц возможны, если вы уменьшите объем кода, который вы доставляете своим пользователям, тем самым доставляя их быстрее.

• Устранение ненужного JavaScript, минимизация и сжатие JavaScript, встряхивание дерева и разделение кода — все это снижает объем JavaScript, доставляемого на страницу.
• Доставка ресурсов с помощью сервис-воркера и использование кэширования может дополнительно контролировать, загружается ли JavaScript на страницу.
• Асинхронная загрузка скриптов с предварительной загрузкой и принудительной загрузкой критического JavaScript также позволяет странице загружаться быстрее.

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

<<< Часть 1: Как оптимизировать изображения для повышения производительности в Интернете

<< Часть 2: Как оптимизировать CSS для повышения производительности в Интернете

<Часть 3: Как оптимизировать HTML для повышения производительности сети

Как оптимизировать производительность JavaScript — Stackify

JavaScript — это общий язык в разработке мобильных и веб-приложений.Из-за своей популярности оптимизация JavaScript становится все более необходимой для повышения производительности приложений. Давайте узнаем о некоторых проблемах, связанных с JavaScript, и о том, как оптимизировать производительность js.

Существует ряд проблем, которые могут повлиять на производительность JavaScript. Вот общие проблемы, связанные с производительностью js:

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

Важно отслеживать все обработчики событий, чтобы обработчики не работали без вашего ведома.

JavaScript нечеткий, что является одновременно плюсом и минусом.

Мелкие подмножества лексических конструкций позволяют разработчикам добиться многого. Однако отсутствие организации в коде может привести к недостаточному распределению ресурсов.

Это может сильно снизить производительность JavaScript .Понимание ECMA важно для понимания JavaScript. .

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

Например, мобильные пользователи с ограниченной пропускной способностью должны будут дольше ждать визуализированных объектов.

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

JavaScript HTML сложен и играет решающую роль во времени запросов для запросов и изменения объектов DOM.

Если вдвое сократить HTML-код приложения, можно вдвое увеличить скорость DOM.Это может быть сложно, но это возможно, если отказаться от таких тегов, как

  импорт изображения из 'next / image'

function Home () {
  возвращаться (
    <>
       
 Моя домашняя страница 
 
      <Изображение
        src = "/ me.png"
        alt = "Изображение автора"
        ширина = {500}
        высота = {500}
      />
      
 Добро пожаловать на мою домашнюю страницу! 
    
  )
}

экспорт по умолчанию домой
  

  module.exports = {
  изображений: {
    домены: ['example.com'],
  },
}
  

  module.exports = {
  изображений: {
    загрузчик: 'imgix',
    путь: 'https: // example.com / myaccount / ',
  },
}
  

  module.exports = {
  изображений: {
    deviceSizes: [640, 750, 828, 1080, 1200, 1920, 2048, 3840],
  },
}
  

  module.exports = {
  изображений: {
    imageSizes: [16, 32, 48, 64, 96, 128, 256, 384],
  },
}
  

  // Конфигурация
@import "функции";
@import "переменные";
@import "миксины";
@import "коммунальные услуги";

// Макет и компоненты
@import "корень";
@import "перезагрузка";
@import "тип";
@import "изображения";
@import "контейнеры";
@import "сетка";
@import "таблицы";
@import "формы";
@import "кнопки";
@import "переходы";
@import "выпадающий список";
@import "группа кнопок";
@import "nav";
@import "навигационная панель";
@import "карта";
@import "аккордеон";
@import "хлебные крошки";
@import "разбивка на страницы";
@import "значок";
@import "предупреждение";
@import "прогресс";
@import "список-группа";
@import "закрыть";
@import "тосты";
@import "модальный";
@import "подсказка";
@import "всплывающее окно";
@import "карусель";
@import "блесны";
@import "offcanvas";

// Помощники
@import "помощники";

// Утилиты
@import "утилиты / api";
  

  // Импортируйте именно то, что нам нужно

// импортируем 'bootstrap / js / dist / alert';
// импортируем 'bootstrap / js / dist / button';
// импортируем 'bootstrap / js / dist / carousel';
// импортируем 'bootstrap / js / dist / collapse';
// импортируем 'bootstrap / js / dist / dropdown';
импортировать 'bootstrap / js / dist / modal';
// импортируем 'bootstrap / js / dist / popover';
// импортируем 'bootstrap / js / dist / scrollspy';
// импортируем 'bootstrap / js / dist / tab';
// импортируем 'bootstrap / js / dist / toast';
// импортируем 'bootstrap / js / dist / tooltip';
  

  импорт модального окна из bootstrap / js / dist / modal

const modal = новый модальный (document.getElementById ('myModal'))