Как делается в JavaScript оптимизация производительности тестирование и ускорение загрузки сайта
Оптимизация сайта на «Битрикс»
Как оценить, что ваш сайт работает достаточно быстро и не теряет посетителей из поисковых систем, лояльность пользователей и конверсию из-за медленной загрузки страниц? Какие шаги помогут увеличить скорость загрузки сайта на Bitrix, и сколько времени это займет? Читайте в пошаговой инструкции, составленной нашим техническим специалистом.
Медленную скорость загрузки сайта можно сравнить с очередями в реальном магазине. Необходимость ждать вызывает раздражение и недовольство — никто не хочет зря терять свое время. В условиях, когда переключиться на сайт конкурента можно буквально за секунду, привлечь и удержать посетителей могут только очень «быстрые» сайты.
Итак, давайте примем за данность три факта:
- Скорость загрузки страниц сайта влияет на его конверсию и лояльность пользователей.
- «Быстрые» сайты удобны для просмотра и совершения покупок с мобильных устройств — доля мобильного трафика растет с каждым днем.
- Скорость загрузки страниц сайта влияет на его ранжирование в поисковых системах, то есть на его видимость относительно конкурентов.
Из-за промедления загрузки сайта в пару секунд вы можете потерять «горячего» покупателя навсегда.
График 1. Скорость отрисовки страниц по данным Яндекс.Метрика до и после оптимизации сайта. График 2. Динамика числа запросов, по которым сайт вышел в ТОП поисковой системы GOOGLE в Московском регионе. Всего было проанализировано 85 запросов. После увеличения скорости загрузки страниц число запросов в рамках ТОП-10 осталось неизменным. Однако было замечено явное улучшение позиций по запросам в рамках ТОП-3.
Рассуждения о том, насколько сильно влияет, оставим для отдельной статьи с кейсами и результатами экспериментов. Сегодня о том, как правильно измерять скорость загрузки, и какие шаги помогут ускорить сайт на «Битрикс».
Как измерить скорость сайта?
Чтобы объективно оценить скорость загрузки сайта — выполнить разовую проверку или постоянно отслеживать изменения, вы можете использовать следующие инструменты:
1. Сервис Pingdom (pingdom.com)
Работает в трех режимах:
- Для разовой экспресс-проверки удобно использовать инструмент https://tools.pingdom.com/. С его помощью вы можете узнать точную скорость загрузки сайта в секундах, оценку сайта в баллах по PageSpeed Insights, вес страницы, а также посмотреть развернутый отчет по техническим параметрам.
- Page Speed Reports — синтетические тесты скорости загрузки. Получаем общую информацию на основе регулярных тестов скорости загрузки главной страницы сайта, включая время «подтягивания» элементов со всех внешних источников, с информацией о размере и типе загружаемого контента.
- Real User Monitoring Reports (RUM) — агрегированная информация о скорости загрузки всех страниц сайта у реальных пользователей. Для использования требуется установка на сайт JavaScript кода. Вы получаете подробный отчет о скорости загрузки страниц с сегментацией по регионам пользователей, браузерам, устройствам (mobile/desktop/tablet), а также информацию о распределении времени по этапам загрузки — сетевые запросы, ответ сервера, загрузка статики.
Если сайт содержит много «тяжелых» картинок, то синтетические тесты могут завышать скорость загрузки, но RUM от Pingdom покажет реальное время ожидания, с которым сталкиваются посетители сайта.
2. Проверка от Google PageSpeed Insights
Сервис позволяет определить факторы, влияющие на скорость загрузки страниц всего сайта, — отдельно для мобильной и десктопной версии:
- сжатие изображений,
- объем JS кода,
- время ответа сервера и другие.
В результате проверки сервис предложит рекомендации по внедрению тех или иных изменений.
Чаще всего предлагаются следующие направления оптимизации:
- используйте кеширование,
- избавьтесь от лишнего кода или сожмите его,
- заставьте сервер отвечать быстрее,
- уменьшите «вес» изображений.
По итогам проверки выставляется балл от 0 до 100. Этот показатель среди прочих равных учитывается при ранжировании сайта в поисковой выдаче Google.
3. Для сайтов на «Битрикс» — сервис «Скорость сайта»
Встроенный мониторинг производительности можно использовать как средство «разбора полетов» и для выявления проблемных участков на сайте — сервис помогает локализовать «тормозящий» компонент. Применяется для разового анализа, не подходит для регулярного мониторинга.
Нормальные показатели загрузки сайта
Как понять, не теряете ли вы посетителей сайта по причине медленной загрузки сайта?
Сравните полученную в результате тестов скорость загрузки сайта с целевыми показателями:
| Сервис | Нормальный показатель загрузки страницы для небольших сайтов | Нормальный показатель загрузки страницы для сложных интернет-магазинов |
|---|---|---|
| Pingdom RUM | 1,5-3 с | 3-4 с |
| PageSpeed Insights | от 80 баллов | |
| Сервис «Скорость сайта» в Битрикс | до 1 с | до 2 с |
Таблица 1. Целевые показатели скорости загрузки сайта по разным сервисам
Если значения будут ощутимо отличаться в большую сторону — это проблема. Значит ваш сайт «тормозит» и необходимо оптимизировать его с точки зрения скорости загрузки.
Детальный аудит
Когда проблема медленной загрузки сайта определена, нужно выполнить детальный аудит.
Стадия технического аудита обязательна для проектов со сложной структурой каталога и большим количеством фильтров, где есть кастомный функционал (технические доработки). Очень часто такие сайты имеют плохое техническое наследие и следование стандартным инструкциям не дает ожидаемого результата.
В этом случае лучше довериться техническому специалисту, у которого есть опыт оптимизации различных сайтов.
Скорость загрузки сайта складывается из двух показателей:
- скорость генерации страниц сервером;
- скорость загрузки и отрисовки страниц и всего контента на них браузером.
Например, у сайта может быть достаточно «лёгкий» дизайн и мало картинок, но очень сложные и неоптимальные выборки товаров из каталога на стороне сервера. В этом случае непосредственное получение контента страниц и их отрисовка браузером будет проходить быстро, но промежуток времени от запроса до момента, когда сервер начнет отдавать этот контент, будет большим. Может быть и наоборот: сервер генерирует страницы очень быстро, но на них слишком много тяжелых картинок. Это необходимо учитывать при оптимизации.
Чтобы сделать объективные выводы, специалист в своей работе опирается на данные, полученные с помощью различных сервисов.
Сначала специалист проверяет сайт с помощью сервиса PageSpeed Insights.
Полученный результат служит отправной точкой для анализа конкретных факторов, влияющих на скорость загрузки сайта:
- скорость генерации страниц сервером,
- структура html-кода,
- размер изображений,
- размер css файлов и т.д.
По итогам детального аудита специалист предложит вам конкретные шаги по оптимизации сайта.
«Детальный аудит позволяет обнаружить все недочеты, оценить, сколько времени потребуется на устранение каждого из них, и какие шаги дадут максимальный эффект. Это поможет расставить приоритеты в процессе технических доработок и даже при ограниченном бюджете достичь значительного улучшения скорости загрузки сайта.»
Директор по развитию, руководитель технического отдела
Кроме того, специалист определит, насколько стратегически верно дорабатывать существующий сайт. В некоторых случаях лучшим решением будет создать новый сайт — это актуально, если стоимость технических доработок составляет хотя бы половину стоимости разработки нового сайта.»
Для понимания процедуры технического аудита, вы можете изучить внутренние документы нашей компании:
Как ускорить сайт на Bitrix?
Работы по оптимизации скорости загрузки сайта могут потребовать от 0,5 ч до N часов работы технического специалиста. Сложность, а значит и продолжительность работ зависит от состояния сайта и причин низкой скорости загрузки: в некоторых случаях достаточно просто уменьшить вес изображений, для других сайтов необходимо перерабатывать код.
Разберем варианты реализации самых популярных рекомендаций в контексте сайтов на «Битрикс».
«Битрикс» — одна из самых популярных платформ для создания сайтов. Низкий порог входа для разработчиков приводит к частому внедрению некачественных технических решений, которые снижают скорость загрузки страниц сайта.
Схема 1. Шаги по оптимизации скорости загрузки сайта и среднее время, которое затрачивает технический специалист на их реализацию.
Оптимизировать изображения — 0,5-4 +1-6 часов работы.
Правильный подход — настраивать корректно ресайз изображений при выводе, и размещать в контенте заранее подготовленные сжатые изображения.
Картинки элементов/разделов инфоблоков и других сущностей базы данных (например, изображения товаров в каталоге интернет-магазина) можно сжать при генерации шаблонов компонентов. В зависимости от количества шаблонов это может занять 0,5-4 часа работы программиста.
Изображения в статичном контенте (например фотография, вставленная в статью через визуальный редактор) и элементы дизайна сайта необходимо сжимать вручную с помощью сторонних сервисов. Обычно на это уходит 1-6 часов.
Сократить время ответа сервера — 10-16 часов.
Именно в этом блоке работ исправляются ошибки, допущенные при планировании структуры данных и в процессе программирования.
Чаще всего такое наведение порядка в коде проекта даёт самое заметное улучшение скорости работы сайта.
Этот блок прорабатывают в два этапа:
- Технический аудит, составление рекомендаций — 10-16 часов.
- Внедрение рекомендаций и рефакторинг — 12-24 часа.
Необходимые трудозатраты зависят от состояния сайта: общей сложности функционала проекта, качества кода и технических решений, негативного наследия проекта.
Бывают, конечно, особо запущенные случаи или просто очень большие проекты, когда нужно вложить больше 40 часов, но это скорее исключение.
Удалите код JavaScript и CSS, блокирующий отображение верхней части страницы — от 0,5 ч.
В настройках главного модуля «Битрикс» есть галочка «Переместить весь Javascript в конец страницы». Она перемещает вниз страницы все JS из шаблона сайта, что частично решает вопрос. Включается за 2 минуты. Но бывают случаи, когда это приводит к поломке JS плагинов или обработчиков, приходится разбираться и вручную исправлять коллизии, тогда решение задачи может занять больше времени.
При стандартном подключении стилей в «Битрикс» их нельзя переместить вниз, они всегда подключаются вначале страницы. Если подключать скрипты нестандартно, то теряются другие преимущества, такие как объединение/сжатие стилей и размещение стилей в CDN. И то и другое влияет на скорость загрузки страницы больше, чем перемещение стилей вниз страницы.
Сократите CSS — 0,5-1 час.
Для сжатия CSS можно использовать эти инструменты: https://developers.google.com/speed/docs/insights/MinifyResources.
Также в настройках главного модуля «Битрикс» есть галочка «Объединять CSS файлы», которая склеит несколько CSS файлов в один.
Сократите JavaScript — 0,5-1 час.
Алгоритм действий аналогичен сжатию CSS. В верстке нужно использовать сжатые версии js-библиотек или можно сжать их с помощью сторонних сервисов.
Также нужно включить галочку «Объединять JS файлы» в настройках главного модуля — она склеивает все js-скрипты в один файл.
Включите сжатие — 0,5 ч.
На большинстве виртуальных хостингов сжатие включено по умолчанию. Если нет, то можно попробовать включить его только через файл .htaccess (mod_deflate), так как доступа к полноценным настройкам сервера обычно нет. На выделенных серверах это делается в настройках сервера (apache/nginx).
Используйте кеш браузера — 1-2 часа.
На виртуальных серверах эта опция должна быть настроена автоматически. Если нет, также через .htaccess нужно указать заголовки для определенных типов файлов (скрипты, стили, картинки). На выделенных серверах — снова корректируем настройки сервера (apache/nginx).
Оптимизация по пункту 6 и 7 актуальна только для локальных ресурсов.
Оптимизируйте загрузку видимого контента.
Рекомендуется изменить структуру HTML таким образом, чтобы сначала загружался важный контент, располагающийся в верхней части страницы. Это может оказаться сложной или даже невыполнимой доработкой, так как придется менять структуру верстки и порядок загрузки элементов страницы. «Битрикс» не позволяет полностью поменять порядок загрузки: стили не переносятся вниз. Верстальщику будет не просто размещать блоки в идеальном для загрузки порядке.
В этот пункт входит сокращение CSS и JS, о которых сказано выше. Чтобы сократить сам HTML код, необходимо переработать верстку шаблонов, если это возможно.
Дополнительные возможности «Битрикса»
Если продолжать разговор о «Битриксе», то в ходе комплексной работы над ускорением сайта нужно обязательно обратить внимание на следующие технологии, предлагаемые CMS:
С их помощью можно добиться эффективного ускорения сайта, но процесс внедрения во многих случаях требует серьезных технических доработок.
Так, технология «Композитный сайт» отлично работает только в проектах, которые идеально соответствуют стандартам — таких сайтов очень мало. Обычно необходимо сначала довести сайт с помощью доработок до такого состояния, чтобы он мог поддерживать эту технологию.
Скорость и стабильность работы сайта – важные факторы, которые напрямую влияют на конверсию сайта и позиции в поисковой выдаче. Экономить на этом вопросе не стоит. Если нет возможности выделить разом необходимый ресурс для технической оптимизации сайта, нужно провести технический аудит и в комфортном темпе устранять все выявленные замечания. При этом начать стоит с тех рекомендаций, которые при минимальных трудозатратах обеспечат наилучший эффект.
Мы осуществляем техническую поддержку проектов на долгосрочной основе и знаем, как ускорить сайт на «Битрикс». Обратившись к нам, вы можете быть уверены, что ваш сайт будет правильно оптимизирован с точки зрения технических возможностей платформы: мы не идем на сделки с совестью и предлагаем действительно эффективные решения.
8 трюков для ускорения JavaScript
Опыт в оптимизации браузерного JavaScript нынче на вес золота. Поэтому я перевел для вас статью с полезными трюками, помогающими повысить производительность приложений в браузере.
ag-Grid — библиотека для отображения больших объемов данных в браузере, внешне похожая на Excel и написанная на JS. Она хорошо работает даже в IE и на больших объемах данных. Сегодня мы расскажем о том, какие оптимизации мы используем, чтобы все работало быстро.
Мы расскажем о том, как выжать максимум из браузера, и наш опыт может оказаться полезным всем, кто хочет оптимизировать свои приложения. Это может также быть интересно пользователям ag-Grid для понимания того, как работает библиотека. Мы поддерживаем здоровую конкуренцию, так что мы рады внести свой вклад в знания сообщества.
Виртуализация строк
Виртуализация строк означает то, что мы отрисовываем только те строки, которые видны на экране. Например, есть таблица на 10 тысяч строк, но только 40 из них на самом деле отрисовываются(каждая строка представлена одним DIV). По мере прокрутки библиотека на лету создает новые элементы для появляющихся строк.
Если попытаться отрисовать сразу 10 тысяч строк, это скорее всего уронит браузер, учитывая одновременный рендеринг 10 тысяч DOM-элементов. Виртуализация строк позволяет отображать очень большое количество строк, отрисовывая только видимые.
Картинка ниже наглядно показывает, как работает виртуализация. Обратите внимание, что в DOM в один момент времени присутствуют только пять или шесть строк, которые в этот момент реально видны на экране.
Виртуализация колонок
Виртуализация колонок работает ровно так же, как виртуализация строк. Иными словами, отрисовываются только видимые колонки, и библиотека отрисовывает колонки при горизонтальной прокрутке.
Виртуализация колонок позволяет отображать большое количество колонок без деградации производительности.
Распространение событий
Проблема: регистрация обработчиков событий
Библиотека обрабатывает клики и нажатия клавиш для каждой ячейки, так что для каждой ячейки мы вынуждены регистрировать обработчики событий. Всего мы используем восемь событий: click, dblclick, mousedown, contextmenu, mouseover, mouseout, mouseenter and mouseleave.
Добавление обработчиков событий в DOM несколько влияет на производительность. Для таблицы в 20 видимых колонок и 50 видимых строк количество обработчиков равно 20 колонок * 50 строк * 8 событий = 8000 обработчиков событий. По мере прокрутки начинает работать виртуализация, и обработчики постоянно снимаются и регистрируются, создавая тормоза при прокрутке.
Решение: распространение событий
Шесть из восьми событий распространяемы, кроме mouseenter and mouseleave. Так что вместо добавления обработчиков на каждую ячейку мы добавляем обработчик для контейнера, содержащего все ячейки. Таким образом мы добавляем обработчик при инициализации таблицы, а не индивидуально для каждой ячейки.
Вопрос в том, как определить, для какой ячейки вызвано событие?
Вероятно, вы заметили, что мы добавляем атрибуты __col и __row к элементам и думаете, безопасно ли это? Я надеюсь, что да, так как ag-Grid используется в приложении контроля авиатрафика над Австралией, насколько мне известно. Иными словами, библиотека работает так уже давно, и таким образом протестирована в боевой обстановке.
Это похоже на то, как работает React’s Synthetic Events. React использует делегирование событий и обрабатывает события в корне приложения, при этом отслеживая, какие ноды имеют обработчики. В React реализована собственная система событий, которая в итоге вызывает нужные обработчики.
Отбросьте DOM
Чутье программиста подсказывает вам, чтобы вы не забыли деконструировать все, что создали. Это значит, что вы должны удалить все созданные элементы DOM при очистке. В контексте вашего фреймворка это значит удалять компоненты, когда они больше не используются.
Этот прием работает так: если вы удаляете элемент из DOM (например ячейку), но вы знаете, что родительский элемент (например строка) тоже подлежат удалению, вам нет необходимости удалять ячейки по одной.
В ag-Grid по мере создания строк мы используем композицию, чтобы создать сложную структуру в DOM. Однако удаляя строки, мы не удаляем ячейки вручную, вместо этого мы удаляем строку одним вызовом.
Используйте innerHTML, где это возможно
Какой самый быстрый способ добавить кучу ячеек и строк в браузер? Стоит ли использовать JavaScript(document.createElement()) для создания каждого элемента, обновления атрибутов и сборки элементов воедино с помощью appendChild()? Или вам стоит работать с фрагментами документа? Или может лучше собрать все в большой кусок HTML и вставить в DOM с помощью innerHTML?
Мы проверили все это. Ответ: используйте innerHTML.
Так что мы выигрываем в скорости с innertHTML, собирая большой HTML и вставляя его в DOM с помощью element.insertAdjacentHTML(). Мы обнаружили, что insertAdjacentHTML() добавляет контент, в то время как innerHTML() заменяет его.
Это хорошо работает, когда вы не используете отдельный рендеринг ячеек. В этом случае библиотека рендерит строку целиком и вставляет ее в DOM. Если используются дополнительные компоненты, библиотека вставляет их уже после рендеринга строки.
Рендеры ячеек — отдельный тип компонентов. Сама идея компонентов хороша для приложений, они как строительные блоки для больших приложений, когда мелкие элементы (компоненты) собираются воедино в большие элементы. Однако в ag-Grid мы делаем ставку на скорость, так что лучше избегать рендеров ячеек в пользу быстрого рендеринга строк с innerHTML.
Если вы используете ag-Grid, вам может быть интересно, как использование рендеров ячеек влияет на производительность. Во многом это зависит от платформы: в Chrome рендеринг небольшой и несложной таблицы не создаст проблем. Однако при выводе больших таблиц в IE вы можете ощутить заметное падение производительности при использовании рендеров ячеек.
Объединение событий прокрутки
Когда вы прокручиваете таблицу в ag-Grid, виртуализация влечет за собой удаление элементов DOM. Удаление занимает время, и если оно вызывается внутри обработчика события, это пагубно влияет на ощущения от прокрутки.
Чтобы избежать этого, библиотека объединяет несколько близких событий прокрутки с кадрами анимации. Это привычный трюк для достижения плавной прокрутки и он хорошо объясняется в статье Leaner, Meaner, Faster Animations with RequestAnimationFrame. Я не буду повторно объяснять его принцип тут. Достаточно сказать, что мы обнаружили, что этот трюк хорошо поднимает производительность.
Кадры анимации
Даже со всеми описанными трюками наши пользователи до сих пор просят нас «сделать побыстрее, это недостаточно хорошо работает в IE, прокрутка ужасна, она занимает кучу времени». Некоторые пользователи встречаются с лагами отрисовки строк в IE длиной в несколько секунд.
Так что следующий трюк — разбиение отрисовки строк по кадрам анимации. Когда пользователь прокручивает таблицу вертикально, чтобы посмотреть другие строки, вот что происходит внутри:
- 1 задача: прокрутка к закрепленной панели, если пользователь ее закрепляет
- n задач: вставить контейнеры со строками (в результате строки раскрашены в нужные цвета)
- n задач: вставить ячейки, используя innertHTML
- n задач: вставить ячейки, используя рендер ячеек
- n задач: вставить обработчики mouseenter and mouseleave на каждую строку для добавления hover-эффекта
- n задач: удалить старые строки
Так что если вы прокрутили таблицу, чтобы увидеть 10 новых строк, у вас появляется 50 с лишним задач. Каждая прокрутка, создание строки, создание ячеек — все это отдельные задачи.
Библиотека использует кадры анимации (или таймауты, если браузер не поддерживает кадры) для выполнения задач в определенном порядке. Порядок такой:
- Сперва прокрутка: максимальные усилия прилагаются к тому, чтобы держать закрепленные секции на своих местах.
- Затем вставка контейнеров строк: первое, что увидит пользователь — границы строк.
- Ячейки отрисовываются по порядку настолько быстро, насколько позволяет браузер.
- Потом удаляются старые строки, поскольку это никак визуально не отображается.
- Если происходит еще прокрутка, очередь задач перестраивается в пользу новых задач над старыми.
- Старые задачи отменяются, если их результат больше не понадобится после новой прокрутки.
Учитывая все вышесказанное, такое количество задач потребует много кадров. Чтобы избежать этого, библиотека не выполняет каждую задачу в отдельном кадре, особенно в связи с тем, что само создание, удаление и планирование кадров требует ресурсов. Вместо этого библиотека запрашивает кадр и выполняет столько задач, сколько сможет, в течении 60 миллисекунд. Мы выбрали такой промежуток после тестов. Если библиотека не успеет выполнить все задачи, она запросит новый кадр и будет выполнять оставшиеся задачи в нем, пока они не кончатся.
Быстрые браузеры вроде Chrome могут сделать все необходимое в одном кадре без видимой визуальной задержки. Медленным браузерам вроде IE может потребоваться 10 и более кадров для выполнения всех задач. Внешне это выглядит, как поступенчатая отрисовка, что гораздо лучше блокирования UI и отрисовки всего в один момент.
Вы возможно заметили, что мы используем кадры анимации для добавления mouseenter and mouseleave. Это отличается от остальных событий, где мы используем распространение событий, чтобы перехватывать их на верхнем уровне. mouseenter and mouseleave не поддаются такому трюку, так что мы просто добавляем их обработчики к строкам после их отрисовки. Пользователи от этого не страдают.
Библиотека использует аналогичный механизм для горизонтальной прокрутки. Сперва прокручивается заголовок, потом остальные колонки. Остальное работает точно так же.
Упорядочивание строк
Обычно DOM, созданный библиотекой, отображает строки в порядке создания. Это может создать рассинхронизацию между строками на экране, если они были отсортированы или отфильтрованы пользователем. Виртуализация строк добавляет и удаляет строки по мере прокрутки.
Программы для чтения экрана или другие инструменты обеспечения доступности требуют, чтобы порядок строк на экране соответствовал порядку в DOM. Поддержание постоянного порядка строк бьет по производительности, потому что в таком случае мы больше не можем вставлять строки большими пачками.
Однако компромисс возможен. Обычно библиотека не сортирует строки. Если пользователь хочет поддерживать порядок строк, он может использовать свойство ensureDomOrder=true. Таблица отображается немного медленнее, но тогда она совместима с программами для чтения с экрана.
Опыт в оптимизации браузерного JavaScript нынче на вес золота. Поэтому я перевел для вас статью с полезными трюками, помогающими повысить производительность приложений в браузере.
ag-Grid — библиотека для отображения больших объемов данных в браузере, внешне похожая на Excel и написанная на JS. Она хорошо работает даже в IE и на больших объемах данных. Сегодня мы расскажем о том, какие оптимизации мы используем, чтобы все работало быстро.
Мы расскажем о том, как выжать максимум из браузера, и наш опыт может оказаться полезным всем, кто хочет оптимизировать свои приложения. Это может также быть интересно пользователям ag-Grid для понимания того, как работает библиотека. Мы поддерживаем здоровую конкуренцию, так что мы рады внести свой вклад в знания сообщества.
Виртуализация строк
Виртуализация строк означает то, что мы отрисовываем только те строки, которые видны на экране. Например, есть таблица на 10 тысяч строк, но только 40 из них на самом деле отрисовываются(каждая строка представлена одним DIV). По мере прокрутки библиотека на лету создает новые элементы для появляющихся строк.
Если попытаться отрисовать сразу 10 тысяч строк, это скорее всего уронит браузер, учитывая одновременный рендеринг 10 тысяч DOM-элементов. Виртуализация строк позволяет отображать очень большое количество строк, отрисовывая только видимые.
Картинка ниже наглядно показывает, как работает виртуализация. Обратите внимание, что в DOM в один момент времени присутствуют только пять или шесть строк, которые в этот момент реально видны на экране.
Виртуализация колонок
Виртуализация колонок работает ровно так же, как виртуализация строк. Иными словами, отрисовываются только видимые колонки, и библиотека отрисовывает колонки при горизонтальной прокрутке.
Виртуализация колонок позволяет отображать большое количество колонок без деградации производительности.
Распространение событий
Проблема: регистрация обработчиков событий
Библиотека обрабатывает клики и нажатия клавиш для каждой ячейки, так что для каждой ячейки мы вынуждены регистрировать обработчики событий. Всего мы используем восемь событий: click, dblclick, mousedown, contextmenu, mouseover, mouseout, mouseenter and mouseleave.
Добавление обработчиков событий в DOM несколько влияет на производительность. Для таблицы в 20 видимых колонок и 50 видимых строк количество обработчиков равно 20 колонок * 50 строк * 8 событий = 8000 обработчиков событий. По мере прокрутки начинает работать виртуализация, и обработчики постоянно снимаются и регистрируются, создавая тормоза при прокрутке.
Решение: распространение событий
Шесть из восьми событий распространяемы, кроме mouseenter and mouseleave. Так что вместо добавления обработчиков на каждую ячейку мы добавляем обработчик для контейнера, содержащего все ячейки. Таким образом мы добавляем обработчик при инициализации таблицы, а не индивидуально для каждой ячейки.
Вопрос в том, как определить, для какой ячейки вызвано событие?
Вероятно, вы заметили, что мы добавляем атрибуты __col и __row к элементам и думаете, безопасно ли это? Я надеюсь, что да, так как ag-Grid используется в приложении контроля авиатрафика над Австралией, насколько мне известно. Иными словами, библиотека работает так уже давно, и таким образом протестирована в боевой обстановке.
Это похоже на то, как работает React’s Synthetic Events. React использует делегирование событий и обрабатывает события в корне приложения, при этом отслеживая, какие ноды имеют обработчики. В React реализована собственная система событий, которая в итоге вызывает нужные обработчики.
Отбросьте DOM
Чутье программиста подсказывает вам, чтобы вы не забыли деконструировать все, что создали. Это значит, что вы должны удалить все созданные элементы DOM при очистке. В контексте вашего фреймворка это значит удалять компоненты, когда они больше не используются.
Этот прием работает так: если вы удаляете элемент из DOM (например ячейку), но вы знаете, что родительский элемент (например строка) тоже подлежат удалению, вам нет необходимости удалять ячейки по одной.
В ag-Grid по мере создания строк мы используем композицию, чтобы создать сложную структуру в DOM. Однако удаляя строки, мы не удаляем ячейки вручную, вместо этого мы удаляем строку одним вызовом.
Используйте innerHTML, где это возможно
Какой самый быстрый способ добавить кучу ячеек и строк в браузер? Стоит ли использовать JavaScript(document.createElement()) для создания каждого элемента, обновления атрибутов и сборки элементов воедино с помощью appendChild()? Или вам стоит работать с фрагментами документа? Или может лучше собрать все в большой кусок HTML и вставить в DOM с помощью innerHTML?
Мы проверили все это. Ответ: используйте innerHTML.
Так что мы выигрываем в скорости с innertHTML, собирая большой HTML и вставляя его в DOM с помощью element.insertAdjacentHTML(). Мы обнаружили, что insertAdjacentHTML() добавляет контент, в то время как innerHTML() заменяет его.
Это хорошо работает, когда вы не используете отдельный рендеринг ячеек. В этом случае библиотека рендерит строку целиком и вставляет ее в DOM. Если используются дополнительные компоненты, библиотека вставляет их уже после рендеринга строки.
Рендеры ячеек — отдельный тип компонентов. Сама идея компонентов хороша для приложений, они как строительные блоки для больших приложений, когда мелкие элементы (компоненты) собираются воедино в большие элементы. Однако в ag-Grid мы делаем ставку на скорость, так что лучше избегать рендеров ячеек в пользу быстрого рендеринга строк с innerHTML.
Если вы используете ag-Grid, вам может быть интересно, как использование рендеров ячеек влияет на производительность. Во многом это зависит от платформы: в Chrome рендеринг небольшой и несложной таблицы не создаст проблем. Однако при выводе больших таблиц в IE вы можете ощутить заметное падение производительности при использовании рендеров ячеек.
Объединение событий прокрутки
Когда вы прокручиваете таблицу в ag-Grid, виртуализация влечет за собой удаление элементов DOM. Удаление занимает время, и если оно вызывается внутри обработчика события, это пагубно влияет на ощущения от прокрутки.
Чтобы избежать этого, библиотека объединяет несколько близких событий прокрутки с кадрами анимации. Это привычный трюк для достижения плавной прокрутки и он хорошо объясняется в статье Leaner, Meaner, Faster Animations with RequestAnimationFrame. Я не буду повторно объяснять его принцип тут. Достаточно сказать, что мы обнаружили, что этот трюк хорошо поднимает производительность.
Кадры анимации
Даже со всеми описанными трюками наши пользователи до сих пор просят нас «сделать побыстрее, это недостаточно хорошо работает в IE, прокрутка ужасна, она занимает кучу времени». Некоторые пользователи встречаются с лагами отрисовки строк в IE длиной в несколько секунд.
Так что следующий трюк — разбиение отрисовки строк по кадрам анимации. Когда пользователь прокручивает таблицу вертикально, чтобы посмотреть другие строки, вот что происходит внутри:
- 1 задача: прокрутка к закрепленной панели, если пользователь ее закрепляет
- n задач: вставить контейнеры со строками (в результате строки раскрашены в нужные цвета)
- n задач: вставить ячейки, используя innertHTML
- n задач: вставить ячейки, используя рендер ячеек
- n задач: вставить обработчики mouseenter and mouseleave на каждую строку для добавления hover-эффекта
- n задач: удалить старые строки
Так что если вы прокрутили таблицу, чтобы увидеть 10 новых строк, у вас появляется 50 с лишним задач. Каждая прокрутка, создание строки, создание ячеек — все это отдельные задачи.
Библиотека использует кадры анимации (или таймауты, если браузер не поддерживает кадры) для выполнения задач в определенном порядке. Порядок такой:
- Сперва прокрутка: максимальные усилия прилагаются к тому, чтобы держать закрепленные секции на своих местах.
- Затем вставка контейнеров строк: первое, что увидит пользователь — границы строк.
- Ячейки отрисовываются по порядку настолько быстро, насколько позволяет браузер.
- Потом удаляются старые строки, поскольку это никак визуально не отображается.
- Если происходит еще прокрутка, очередь задач перестраивается в пользу новых задач над старыми.
- Старые задачи отменяются, если их результат больше не понадобится после новой прокрутки.
Учитывая все вышесказанное, такое количество задач потребует много кадров. Чтобы избежать этого, библиотека не выполняет каждую задачу в отдельном кадре, особенно в связи с тем, что само создание, удаление и планирование кадров требует ресурсов. Вместо этого библиотека запрашивает кадр и выполняет столько задач, сколько сможет, в течении 60 миллисекунд. Мы выбрали такой промежуток после тестов. Если библиотека не успеет выполнить все задачи, она запросит новый кадр и будет выполнять оставшиеся задачи в нем, пока они не кончатся.
Быстрые браузеры вроде Chrome могут сделать все необходимое в одном кадре без видимой визуальной задержки. Медленным браузерам вроде IE может потребоваться 10 и более кадров для выполнения всех задач. Внешне это выглядит, как поступенчатая отрисовка, что гораздо лучше блокирования UI и отрисовки всего в один момент.
Вы возможно заметили, что мы используем кадры анимации для добавления mouseenter and mouseleave. Это отличается от остальных событий, где мы используем распространение событий, чтобы перехватывать их на верхнем уровне. mouseenter and mouseleave не поддаются такому трюку, так что мы просто добавляем их обработчики к строкам после их отрисовки. Пользователи от этого не страдают.
Библиотека использует аналогичный механизм для горизонтальной прокрутки. Сперва прокручивается заголовок, потом остальные колонки. Остальное работает точно так же.
Упорядочивание строк
Обычно DOM, созданный библиотекой, отображает строки в порядке создания. Это может создать рассинхронизацию между строками на экране, если они были отсортированы или отфильтрованы пользователем. Виртуализация строк добавляет и удаляет строки по мере прокрутки.
Программы для чтения экрана или другие инструменты обеспечения доступности требуют, чтобы порядок строк на экране соответствовал порядку в DOM. Поддержание постоянного порядка строк бьет по производительности, потому что в таком случае мы больше не можем вставлять строки большими пачками.
Однако компромисс возможен. Обычно библиотека не сортирует строки. Если пользователь хочет поддерживать порядок строк, он может использовать свойство ensureDomOrder=true. Таблица отображается немного медленнее, но тогда она совместима с программами для чтения с экрана.
Правильное ускорение сайтов: устраняем реальные причины
Ваш сайт может зарабатывать больше
Ускорение загрузки сайта это повышение конверсии
Экспертное ускорение сайтов без CDN. Оптимизация скорости сайта
Цена от 39 900 Р
Правильное ускорение сайта: как это делается Метод Лаб
Мы находим и устраняем истинную причину торможения сайта. Для этого мы располагаем обширным набором инструментов тестирования производительности. В ходе работы по ускорению мы точно определяем проблемные места кода сайта (профилирование) и архитектуры веб-сервера (анализ живой нагрузки мониторингом, нагрузочное тестирование). Мы переверстываем шаблоны сайта, исправляем HTML, CSS, Javascript. Выявляем и ускоряем медленные SQL-запросы. Оптимизируем контент сайта самыми передовыми компрессорами и минификаторами. После завершения работ по ускорению, ваш сайт работает быстро, дополнительных расходов нет.
Стоимость ускорения сайтов
| Тариф | Бизнес | Ультима | Максима |
|---|---|---|---|
| Контрольные страницы | 3 | 5 | 5 |
| Оптимизация настроек Nginx, Apache | + | + | + |
| Оптимизация отдельной мобильной версии | – | – | + |
| Клиентская оптимизация (изображения) | + | + | + |
| Клиентская оптимизация (JS, CSS) | + | + | + |
| Глубокая оптимизация CSS | – | + | + |
| Сокращение количества блокирующих JS | + | + | + |
| Повышение рейтинга Google Pagespeed | + | + | + |
| Ускорение индексации роботами (SEO) | + | + | + |
| Подключение протокола HTTP/2 | + | + | + |
| Оптимизация настроек TLS | + | + | + |
| Оптимизация настроек TCP/IP в Linux | – | – | + |
| Оптимизация настроек MySQL, PostgreSQL | + | + | + |
| Оптимизация SQL-запросов и схемы БД | – | – | + |
| Компрессор текста | – | – | + |
| Оптимизатор изображений | – | – | + |
| Профилирование серверного кода (PHP) | – | – | + |
| Оптимизация HTML-вёрстки | – | + | + |
| Оптимизация шрифтов | + | + | + |
| Проведение работ на отдельной копии сайта | + | + | + |
| Индивидуальная сборка Nginx | – | + | + |
| Консультация разработчиков клиента | – | – | + |
| Нестандартный стэк разработки (не LAMP) | – | – | + |
| Размер сайта Заказчика | до 50 Гб | до 100 Гб | до 200 Гб |
| Отчет об ускорении | базовый | расширенный | расширенный |
| Гарантия | 21 день | 30 дней | 45 дней |
| Стоимость пакета | 39 900 Р | 99 900 Р | 189 900 Р |
Как мы работаем
Мы разработали собственный алгоритм ускорения сайтов на основе многолетнего опыта. Основные этапы услуги:
- Подробный аудит скорости сайта, замер основных метрик.
- Получение полной копии сайта.
- Запуск копии сайта на нашей площадке (для старших планов).
- Оптимизация состава и порядка загрузки CSS, JS.
- Оптимизация подключаемых шрифтов (для старших планов).
- Оптимизация картинок сайта.
- Тестирование сайта на корректность отображения и JS-ошибки.
- Замер скорости оптимизированной версии, составление отчета.
- Оптимизация настроек сервера.
- Запуск оптимизированной версии в Интернет.
- Гарантийный срок по оптимизации (в соответствии с планом).
Не повторяйте чужих ошибок
Многие наши клиенты обращаются к нам уже после нескольких неудачных попыток решить проблему скорости сайта с другими подрядчиками. Не повторяйте чужих ошибок — выгоднее сразу обратиться к экспертам! Ускорение сайта при помощи CDN — не работает и тянет деньги каждый месяц, ускорить сайт за несколько тысяч рублей у неквалифицированного вебмастера с биржи труда тоже невозможно. Доказано многими. А вы можете серьезно сэкономить время и деньги, не повторяя этот путь. Делайте сразу правильно: ускоряйте свой сайт с нами.
Метод Лаб предлагает ускорение сайта только без абонентской платы. Платите один раз — эффект сохраняется навсегда. Альтернативные способы (веб-сервисы ускорения, CDN) предполагают ежемесячную абонентскую плату, оплату за трафик. Как только перестанете платить, «карета превратится в тыкву». Мы устраняем причины медленной работы сайта, а не боремся с последствиями.
Зачем нужно ускорение
Многие даже не догадываются, сколько проблем можно решить, если сделать сайт быстрым:
- Ваш сайт зарабатывает деньги, но вы хотите увеличить доход.
- Вы хотите, чтобы ваш бренд, компанию воспринимали с большим доверием.
- У вас сайт-СМИ и вы хотите продавать больше рекламы, не теряя аудиторию.
- Вашей компании (продукту) не хватает премиальности.
- Вы тратите деньги на рекламу, а сайт не продает, много отказов.
- Ваш сайт проигрывает сайтам конкурентов в поисковой выдаче.
- У вас плохая лояльность клиентов, мало повторных покупок (обращений).
- Доля мобильных пользователей у вашего сайта велика, а конверсия очень низкая.
Мой сайт и так быстрый
Научно доказано, что психология человека не приемлет время загрузки медленнее 1 секунды. Поэтому ускорение нужно любому сайту! Скорость загрузки сайта для мобильной аудитории значительно ниже, а её доля постоянно растёт. Поэтому быстрая загрузка вашего сайта на ПК с быстрым интернетом ничего не говорит о реальном опыте ваших клиентов.
Проверьте свой сайт прямо сейчас!
Мы разработали автоматический сервис для проверки скорости загрузки сайтов в реальных условиях, который показывает в отчете самые важные метрики. Проверьте скорость своего сайта сейчас, это бесплатно.
Ускорение загрузки сайта — оптимизация css, js и картинок (изображений)
Технические данные
Описание
| Adwex.Minified — модуль для быстрой оптимизации загрузки сайта. Модуль оптимизирует стилевые файлы, файлы скриптов и изображения. Также добавлены дополнительные возможности: инлайн стилей (inline), конвертация изображений в формат WebP, прекконект к службам метрики, ленивая загрузка изображений. |
Пишите предложения по улучшению или замечания по работе, на почту [email protected]
| Минимизация Модуль создает файлы с минимизированным кодом внутри. В коде убираются пробелы, переносы строк и комментарии, сокращаются цветовые обозначения. Это уменьшает вес файлов, а следовательно и время загрузки. |
Встраивание (inline)
Благодаря встраиванию CSS уменьшается количество запросов к серверу, пользователь
получает CSS код сразу вместе со страницей. Иногда, если CSS файлы большие, это
приводит к уменьшению оценки в Google PageSpeed, для того, чтобы этого не происходило,
включите опцию « Встраивать только небольшие файлы » — в этом случае
количество запросов к серверу сокращается, а размер HTML кода увеличивается,
но не критично.
В последних обновлениях, добавлено оптимизированное встраивание стилей.
Стили встраиваются в страницу только в первый заход пользователя, тогда же
они кэшируются браузером в фоновом режиме. В следующий заход пользователь получит
стили из кэша, а HTML код будет без доп. вставок кода, что значительно сократит
его размер.
| Модуль создает файлы с минимизированным кодом внутри. Это уменьшает вес файлов. Т.к. JS код может быть самым разным, для работы можно использовать одну из четырех библиотек:
|
| Изображения В первую очередь на скорость загрузки сайта влияют изображения. Модуль оптимизирует как уже загруженные файлы, так и только загружаемые в автоматическом режиме. Для минимизации используется различные библиотеки, результат их работы сравнивается и остаётся файл с наименьшим весом. |
В версии 2.0.5 добавлена конвертация изображений в формат WebP . WebP изображения
создаются из уже оптимизированых, хранятся отдельно от оригиналов, и показываются
только в современных браузерах.
Обратите внимание, что конвертация работает не на всех хостингах. После установки
в настройках модуля, можно проверить хостинг на поддержку формата.
Сравните качество изображений до оптимизации, после, и в формате WebP
|
Шрифты
Если на сайте используется подключаемые шрифты Fonts.Google (решения Аспро,
BXReady, INTEC и др.), то с помощью модуля вы сможете оптимизировать их загрузку.
В последних версиях Битрикс добавляет загрузку шрифта Open Sans. Если он вам не
нужен или он уже подключается из другого места, его можно убрать с помощью
соответствующей опции.
Оптимизация HTML
Модуль также сжимает итоговый код HTML. Это экспериментальная функция, мы рекомендуем
использовать ее только на небольших сайтах или сайтах, где контент редко изменяется
(новостные, корпоративные, блоги). Для минификации используются библиотеки:
- Patchwork
- PHPWee
- TinyHtml
- Shaun
| Для сжатия изображений используются различные библиотеки: optipng, pngquant, jpegoptim, svgo, ImageMagick. Рекомендуется установить их на вашем хостинге перед оптимизацией изображений. |
При оптимизации изображений, оригиналы НЕ сохраняются, поэтому, перед
оптимизацией изображений рекомендуем сделать бэкап файлов.
Используем такой вариант оптимизации изображений по следующим причинам:
- изображения можно оптимизировать заранее, чтобы пользователю не нужно
было ждать, когда произойдет оптимизация «на лету»; - экономится место на хостинге;
- при сохранении оригиналов, нужно следить за удалением файлов. Пример:
на страницу добавили новый файл, а старый удалили. Для нового файла создастся
оптимизированная копия, но копия для старого файла, также останется, ведь
её не удалили. Со временем, это может сказаться на занимаемом месте;
Вы не зависите от работоспособности сторонних сервисов, т.к. все операции
происходят на вашем сервере.
JS и CSS файлы оптимизируются только если они подключены через API Битрикса.
Для работы модуля нужен PHP версии >5.6. Для быстрой и стабильной работы
сайта, рекомендуется PHP версии >7.1
Также рекомендуем настроить на сервере HTTP/2, это необходимо как для быстрой
загрузки, так и для безопасности вашего сайта.
17 Способов улучить производительность JavaScript
JavaScript – это незаменимая часть практически любой веб-страницы, мобильного приложения или веб ПО. И хотя особенности кода делают его более динамичным и гибким, некорректно написанный код может снизить производительность и ухудшить пользовательский опыт. Узнайте, как можно улучшить функциональность кода JavaScript и оптимизировать код.
Типичные проблемы с производительностью JavaScript
Перед тем, как исправить проблемы, их нужно сначала определить. Вот несколько вещей, которые могут негативно сказаться на коде:
— Слишком много интеракций с узлом сети. С каждой интеракцией с пользовательским браузером или главным объектом риск ошибок и низкой производительности растет. Эту проблему можно определить, если загрузка DOM объектов (объектная модель документа) слишком медленная. И хотя вы не можете полностью исключить все интеракции, их количество можно снизить, блокировав DOM.
— Слишком много зависимостей от манипуляций в JavaScript, из-за чего страдает производительность веб-страниц и приложений. Пользователю приходится ждать вечность, пока объекты прогрузятся, что особенно неудобно для мобильных пользователей с ограниченной пропускной способностью.
— Неправильная обработка событий. Если вы используете инструменты для обработки грамотно, то производительность действительно может стать выше, но невозможно уследить за каждым из них, а потому они могут повторяться даже без вашего ведома. Пользуйтесь обработкой событий продуманно.
— Излишние повторения цикла. Поскольку повторение цикла занимает немало времени, нужно избавиться от ненужных циклов и переходов внутри них для ускорения производительности.
— Неорганизованный код. У медали две стороны, так же как и у кода JavaScript, который предоставляет много лексических структурных компонентов, но при плохой организации может привести к неправильному распределению ресурсов. Чтобы научиться грамотно писать JavaScript код, стоит ознакомиться со стандартами Европейской ассоциации производителей вычислительной техники.
17 способов улучшить производительность JavaScript
Теперь, когда вы знаете, что может негативно повлиять на производительность JavaScript, пришла пора научиться исключать эти факторы и повышать эффективность кода.
1. Используйте протокол HTTP/2. Это новая версия протокола HTTP, которая не только повышает производительность сайта и JavaScript, но и ускоряет загрузку вашего сайта. Поскольку протокол HTTP/2 поддерживает многократную передачу данных, несколько запросов и ответов могут обрабатываться одновременно. Так что если вы еще не перешли на HTTPS, самое время сделать это и воспользоваться преимуществами протокола.
2. Используйте указатели ссылок. Если вы храните указатели ссылок на объекты браузера во время установки, вы можете исключить установку связи с DOM объектами. Если же DOM объекты вряд ли будут меняться, вы можете сохранить ссылку на DOM или jQuery Use объекты при создании страниц, чтобы ускорить их загрузку.
3. Сокращайте HTML код. От сложности HTML кода зависит время, необходимое для обработки запроса и модификации DOM-объектов. Вы можете ускорить загрузку HTML кода в два раза, если повысите скорость связи с DOM-объектами. Это сложная задача, но вы можете начать с удаления лишних тегов и
Как упороться по оптимизации скорости загрузки страниц
При оптимизации скорости загрузки сайта я анализирую результаты автоматического тестирования в сервисах Google Lighthouse, Google PageSpeed Insights и Webpagetest.org и только потом готовлю рекомендации. Эти же инструменты мы будем рассматривать в статье.
Небольшое объявление. В ноябре 2020 года ребята из Google обновили инструмент Google PageSpeed Insights: теперь проверка страницы выполняется средствами инструмента Lighthouse. Таким образом, результаты проверки Google PSI теперь являются данными из Google Lighthouse.
Важно помнить, что сайт состоит не только из главной страницы, но и многих других. Оптимизация всего ресурса начинается с исследования каждой типовой страницы. Например, на этом сайте я использую два шаблона: главная и статья. При анализе скорости загрузки нужно анализировать каждую такую шаблонную страницу. Нельзя забывать про «маловажные», которые не приносят трафика — поисковая система оценивает как показатели отдельных страниц, так и всего сайта в целом.
Статья поделена на несколько блоков для удобной группировки задач по оптимизации. Также постарался распределить их по сложности исполнения (хаха, нет).
Содержание:
Оптимизация изображений
Высота и ширина
Наиболее частая проблема при использовании изображений — некорректная высота и ширина. Это случается практически на всех сайтах и не удивлюсь, что это можно будет найти на этом.
В качестве примера рассмотрим довольно подробную статью от Serpstat про оптимизацию изображений. В статье используются картинки такого вида (скриншот из сервиса webspeedtest.cloudinary.com):
Браузер должен загрузить изображение огромного размера (2,7 мегабайта), а также с большей высотой и шириной, с которой оно будет использоваться на самой странице сайта:
Просмотреть такое соотношение можно проще и без использования дополнительных сервисов. В браузерных инструментах для разработчиков можно навести на адрес изображения:
Необходимо по возможности использовать размер изображения такой, чтобы совпадал с размерами блока, в котором оно отображается. Нельзя, чтобы браузер сначала скачивал картинку большого размера, а потом перестраивал её под нужную высоту и ширину. На это тратится память устройства и ресурсы процессора, что в совокупности влияет на общую скорость загрузки страницы.
Оптимизировать таким образом нужно абсолютно все картинки на сайте. Да, это слишком дорого сказывается на рабочем времени, но чаще всего именно изображения крадут большую часть времени загрузки.
Этот процесс можно автоматизировать средствами CMS или плагинов для них. Например, в MODx Revolution в этом помогает дополнение phpThumbOf. Из основных функций: изменение высоты или ширины изображения, обрезание картинки до нужных размеров и применение фильтров (например, чёрно-белый). Это всё делается на лету и пользователю чаще необходимо просто настроить шаблон.
Помимо оптимизации используемой высоты и ширины, нужно обязательно делать сжатие качества изображения для уменьшения их объёма.
Объём, или же размер изображения
Мной заботливо украдена таблица из справочника Google для разработчиков, где наглядно показана корреляция объёма изображения от его размера (ширины и высоты):
| Размер | Пиксели | Размер файла |
|---|---|---|
| 100 x 100 | 10 000 | 39 КБ |
| 200 x 200 | 40 000 | 156 КБ |
| 300 x 300 | 90 000 | 351 КБ |
| 500 x 500 | 250 000 | 977 КБ |
| 800 x 800 | 640 000 | 2500 КБ |
Чем больше высота и ширина изображения, тем больше оно будет весить (логично), но масштабы увеличения этого объёма губительны для скорости загрузки.
То есть следует понимать, что для максимальной оптимизации изображения, необходимо:
- Уменьшить ширину и высоту
- Сжать качество
Для сжатия качества я чаще всего использую сервис compressor.io, однако у него есть существенный недостаток — работает только с одним изображением. Для оптимизации нескольких картинок нужно искать другие сервисы. Тут на помощь можно звать сервис Google PageSpeed Insights, который после анализа любой страницы предлагает скачать архив с уже оптимизированными и сжатыми ресурсами:
Lazy Load
Одна из рекомендаций в моём арсенале — реализация Lazy Load.
При возможности, для части изображений страниц рекомендуется использовать отложенную загрузку (Lazy Load), которая позволит первоначально загрузить только те изображения, которые видны пользователю при открытии страницы. Все последующие изображения будут догружаться по мере скроллинга.
Тут буду краток — круто, если это будет реализовано на большом контентном проекте. Однако после внедрения на одном из самых крупных сайтов в моей практике, скорость загрузки не изменилась.
5 ноября Google добавил рекомендации для Lazy Load, а вот тут собрана подробная инструкция по настройке изображений и видео (материал на английском языке).
BASE64 и CSS-спрайты
Для небольших вспомогательных изображений-элементов дизайна рекомендуется рассмотреть кодирование картинок в BASE64 или использование CSS-спрайтов. Это позволит убрать дополнительный запрос к серверу, а изображение будет корректно отображаться на странице (во всех современных браузерах). Таким образом можно «разгрузить» сервер лишними обращениями, что тоже ускорит время загрузки. Как показывает практика, изображения лидируют по количеству обращений к серверу, однако вместе с использованием base64 можно изменить этот стандарт. Ниже показан скриншот из сервиса webpagetest.org. С перекодированием изображений в base64 мне удалось на одном своём сайте сократить количество реквестов до 14, и это очень мало.
Следует отметить, что использование base64 подходит только для совсем маленьких элементов — иконки или кнопки. Допускается использование для небольших не сложных изображений, например, однотонных или с добавлением текста. Для больших картинок использованный в html-разметке код будет занимать больше объема, чем объём самого изображения в формате, к примеру, jpeg. Подробнее про влияние большого нерационального количества Base64 в коде сайта можно почитать в этой статье на английском языке.
Подробнее о цели этой доработки можно прочитать в блоке «Оптимизация количества серверных реквестов».
Оптимизация CSS
Прежде чем отобразить страницу, браузер загружает и считывает все CSS файлы. При этом при загрузке каждого нового CSS файла браузер заново перестраивает страницу, что замедляет её загрузку.
Для оптимизации CSS следует придерживаться нескольких техник:
Загрузка только нужных CSS
Загружать только те CSS, которые используются на странице. Браузеру не следует загружать лишние правила или отдельные файлы таблиц стилей, если они не используются на рассматриваемой странице. Подробная рекомендация представлена на данной странице официальных рекомендаций от Google.
Для оптимизации этого сайта я воспользовался инструментом unused-css.com.
Суть его работы заключается в исследовании сайта и используемых CSS правил. Если инструмент находит правила, которые не используются на страницах, то он их удаляет. В конечном итоге можно получить из огромного файла список только необходимых сайту стилей:
Используемый мной файл стал на 72% процента «легче» после того как инструмент удалил 78% правил CSS.
Малые CSS лучше включить сразу в HTML-код
Лучше отказаться от загрузки небольших CSS файлов. Если отдельный документ CSS содержит 10-20 строк кода, содержимое этого файла рекомендуется встроить сразу в html код с помощью тега . Это позволит сократить время обработки правил CSS, минуя стадию загрузки отдельного файла (опять же, оптимизация серверных реквестов).
Использование только файлов CSS и тега
Не рекомендуется встраивать стили оформления в теги документа. Следует использовать файлы или теги в связке с атрибутами class. Пример некорректного использования:
Встраивание стиля элемента в сам тег является устаревшей техникой написания кода. Валидатор кода W3 будет сигнализировать об ошибках, а браузер вновь перестраивать макет страницы.
Минификация файлов CSS
Рекомендуется для всех файлов CSS провести минификацию. Это позволит удалить ненужные символы и пустые строки / пробелы в файлах, что повлечёт за собой сокращение объёма каждого файла. Для CSS Google рекомендует использовать CSSNano или ccso.
Можно встретить примеры плагинов для разных CMS, которые делают минификацию файлов CSS, например, бесплатные AutoOptimize для WordPress, MinifyX для MODx Revolution или отдельные плагины для Битрикс.
Если же доработка по минификации разовая, можно обратиться к выгрузке оптимизированных данных из отчёта Google PageSpeed Insights как это было показано в пункте про оптимизацию изображений.
Оптимизация JS
Аналогично файлам CSS, браузер может задерживать время отображения контента страниц сайта из-за загрузки и обработки файлов JS. Большинство рекомендаций повторяются, однако есть дополнения.
Для оптимизации скриптов на сайте необходимо следовать рекомендациям:
Загрузка только используемых файлов JS
Загружать только те скрипты, которые используются на странице. Браузеру не следует загружать лишние скрипты, которые не влияют на работу элементов просматриваемой страницы.
Например, если у вас есть отдельный скрипт для работы слайдера на главной странице сайта, не нужно загружать этот скрипт на других страницах. Побойтесь Бога.
Нужно обязательно следить за тем, чтобы у каждой страницы был свой отдельный набор скриптов.
Встраивание JS скриптов в HTML-код
Небольшие скрипты сайта рекомендуется не загружать отдельным серверным запросом, а встроить в код страниц с помощью тега
Ускоряем загрузку своего сайта
Оптимизация загрузки положительно влияет на отношение клиентов к продукту, уровень конверсии, SEO, и, в итоге, на успех вашего проекта.
Если сайт загружается дольше трёх секунд, 53 % пользователей покинут его.
Предположим, у вас уже есть готовый сайт или приложение, которое использует современный JS-фреймворк (Angular, React, VueJS). Как убедиться, что текущая производительность не мешает вашему продукту стать успешным?
Вначале стоит собрать данные о производительности фронтенда вашего приложения. Есть два отличных инструмента:
Оба эти инструмента позволяют отслеживать основные показатели производительности вашего приложения (KPI).
Lighthouse уже входит в Chrome DevTools. Проанализировав ваш сайт/веб-приложение, этот инструмент может дать дельные советы по оптимизации.
Статистика из Lighthouse
Speedcurve делает всё то же самое, но данные можно просматривать ещё и в динамике.
9–10 ноября, Москва, беcплатно
Теперь, когда есть возможность измерять производительность, приступим к оптимизации сайта.
Изображения
Изображения занимают достаточно большую часть загружаемых на сайт данных, поэтому их оптимизация крайне важна для производительности сайта.
Адаптация размеров изображений
Первым делом нужно убедиться, что размеры изображений не больше, чем это необходимо. Поэтому нужно подогнать их в точности под размеры на макете.
Адаптивные изображения на адаптивных шаблонах
К тому же нужно убедиться, что сами изображения так же адаптивны, как и макет. Responsive Image Breakpoints Generator выдаёт все необходимые версии изображений и HTML-код для их вставки. Достаточно будет 8–10 сгенерированных изображений.
Сгенерированный в этом инструменте HTML-код можно будет использовать не только на сайтах, но и в веб-приложениях. Для тех, кто работает с Gulp, есть специальный плагин gulp-responsive, который автоматизирует этот процесс.
Не забываем про ленивую загрузку
Компоненты и модули ленивой загрузки
Ленивая загрузка (англ. lazy load) предполагает, что не все изображения будут загружены сразу при открытии страницы — часть будет подгружаться после, при необходимости. Изображение, которое не находится в текущей области видимости, будет подгружаться в будущем (главное помнить, что изображение нужно подгружать чуть раньше, чем оно должно появиться в области видимости).
Независимо от того, какой фреймворк вы используете, в нём, вероятнее всего, будет плагин для ленивой загрузки изображений (к примеру, v-lazy-image в Vue). Хотя ничто не мешает вам самим реализовать эту функциональность. Чтобы проверить, находится ли элемент в области видимости, хорошо подходит IntersectionObserver API.
Доставляем изображения через CDN
Если вы уже оптимизировали размер изображений и их количество и ждёте посетителей со всего мира, то вам не помешает CDN — Content Delivery Network (Сеть доставки содержимого) для обслуживания изображений.
Эта система кеширует изображения на глобально-распределённой сети серверов. Допустим, если кто-нибудь из Австралии запросит изображение с вашего веб-сайта, то вместо того, чтобы загружать это изображение с сервера в Европе, CDN загрузит его с ближайшего к Австралии сервера. Такая система ускоряет процесс загрузки изображений на сайте.
CSS, JS и HTML
Все современные фреймворки в процессе сборки оптимизируют ваш код (code-splittiong, tree shaking, minification и др.). Что ещё можно придумать?
Оптимизация основной HTML-страницы
HTML-документ — это скелет почти всех веб-приложений. При работе с ссылками на внешние ресурсы стоит придерживаться нескольких советов:
- Помещайте ссылки на CSS вверху HTML-документа для ускорения загрузки страницы.
Прим. перев. Есть более оптимальные способы ускорения загрузки, например вынесение критичного css в тег style , а для оставшихся стилей (обязательно соберите их в один файл с помощью какого-либо сборщика фронтенда) применять предварительную загрузку или отправлять их с помощью http/2 Server Push; - Размещайте JS-скрипты внизу страницы. Это предотвращает блокировку рендеринга страницы тегами
Как оптимизировать загрузку js для многостраничных сайтов?
Исходные условия проблемы примерно таковы — есть многостраничный сайт, скажем так «портального» типа, но не очень большой. Бэкэнд традиционно написан на php. На фронтэнде используем jquery со всякими сторонними и своими плагинами для улучшения пользовательского интерфейса — всякие там лайтбоксы, календари, всплывающие подсказки и прочий довольно стандартный зоопарк.
Не так давно нами было решено внедрить модульный подход? асинхронную загрузку с использованием require.js и разделение бэкэнда и фронтэнда. Внедрение прошло удачно, но встал вопрос как теперь оптимизировать загрузку яваскриптов?
Самое популярное решение для require.js, которое предлагается везде, это используя r.js склеить все в один файл и подключать его на продакшене. Но, простите, друзья, для чего мы тогда внедряем всю эту модульность? Только ради удобства в разработке?
У нас в общей сумме на сайте используется около 300-400 кб разного яваскрипта, причем это использование идет совершенно неравномерно по разделам. И мне кажется, что запаковать это все в один файл и отдавать каждому посетителю не совсем правильно. Дело в том, что наш среднестатистический пользователь может никогда не дойдет до страницы или раздела сайта, где мы используем datepicker или загрузку фото, или еще какие-то специфические скрипты. Так зачем мы будем его нагружать этими подарками при первой встрече, заставлять его качать все 400 кб скриптов, а потом заставлять его браузер проводить синтаксический анализ всего этого кода.
Сейчас у нас используется какое-то промежуточное решение, которым мы по прежнему не очень довольны. При первой встрече мы отдаем пользователю минимальный набор необходимых скриптов (100-150 кб), а остальное подтягиваем в виде requirejs модулей. В итоге получаем, что при большом количестве интерактивных элементов на некоторых страницах, в дополнение к базовому набору скриптов у нас запрашивается и качается еще 5-7 javascript файлов. С точки зрения оптимизации, кажется, это тоже не очень красивое решение.
Наверное, не мы первые сталкиваемся с таким вопросом. Сайт у нас не уникальный и проблема тоже.
Что же выгоднее делать с точки зрения правильной клиентской оптимизации:
1. Паковать все скрипты в один файл, отдавать его сразу и не заботиться, что большая часть из этих скриптов не будет востребована многими посетителями сайта?
2. Пытаться как-то поделить скрипты. Отдавать только то, что нужно посетителю на конкретной странице сайта?
Если идти вторым путем, то что делать с оптимизацией? Как быть если страница требует загрузки десятка мелких js модулей?
ТОП-12 вариантов, как улучшить скорость загрузки сайта самому
Медленный сайт не нравится никому – ни пользователям, ни поисковикам. При нынешней скорости интернета люди уже не готовы долго ждать загрузки страницы. Это вам не подключение по диал-апу, где ожидание было неизбежно. А поисковые системы, борясь за качество результатов поиска, не хотят выдавать пользователям плохие (в данном случае, медленные) сайты. Поэтому при прочих равных медленный сайт будет в выдаче ниже, чем его более шустрые конкуренты.
Какую скорость загрузки считать нормой
Чем быстрее, тем лучше. Но в среднем, 2-3 секунды для загрузки основной части контента страницы – это вполне нормально.
От чего зависит скорость загрузки
В загрузке сайта участвуют две стороны – браузер пользователя и сервер, где физически расположены файлы сайта. Между этими сторонами происходит обмен данными.
Тормозить загрузку сайта могут проблемы на каждой из сторон и в промежутке между ними.
- Медленный сервер: может банально не хватать оперативной памяти или ядер в процессоре, как у обычного компьютера.
- Медленный движок сайта (CMS): если код был написан неопытными программистами без учета его быстродействия.
- Сервер далеко от пользователя: например, сервер с файлами сайта физически находится в Москве, а на сайт заходит пользователь из Владивостока.
- Много файлов: для отображения страницы браузеру нужно загрузить много картинок, файлов, стилей, скриптов и шрифтов.
- Тяжелые файлы: плюс эти файлы много весят.
Все шаги по оптимизации скорости сайта направлены на устранение данных проблем.
Как проверить скорость сайта
Из множества онлайн-сервисов для проверки скорости сайта самый популярный, пожалуй, это инструмент Google PageSpeed. Работать с ним просто – указываем адрес сайта и жмем кнопку «Анализировать».
В результате мы увидим такие показатели (отдельно для компьютеров и для мобильных):
- Через какое время браузер получает ответ от сервера и начинает отрисовывать контент страницы (FCP – First Contentful Paint).
- Через какое время пользователь видит основной контент в браузере (DCL – DOM Content Loaded).
- Насколько сайт оптимизирован в плане скорости загрузки.
- Конкретные рекомендации по оптимизации. Нажимая на ссылки «Как исправить», видим адреса проблемных картинок и файлов, с которыми нужно что-то сделать (в основном, сжать).
Желательно попасть в зеленую зону – и в блоке «Скорость сайта» (Page Speed), и в блоке «Оптимизация».
Еще один хороший сервис для проверки скорости загрузки, правда, на английском – Pingdom. Отличительная черта – вот такие красивые графики (называются waterfall – водопад) показывают какие файлы, в каком порядке и сколько времени загружаются:
А теперь к сути:
Как ускорить сайт
Шаг 1. Оптимизация картинок
Неоптимизированные картинки – самая «тяжелая» часть сайта. Поэтому работа с картинками может дать значительный прирост к скорости.
Размер картинок (ширина и высота)
Если вы отсняли товар и получили фотографии шириной около 5000 пикселей, можете смело уменьшать ширину до 1600, в большинстве случаев этого будет достаточно. Исключением будут те сайты (в основном, интернет-магазины), где можно рассмотреть товар с «лупой», но и там увеличенная картинка загружается не сразу, а только если человек решил воспользоваться этим инструментом.
Вес картинок (килобайты)
Изображения с фотоаппарата можно (и нужно) сжимать в объеме перед выкладкой на сайт. Делают это либо в Фотошопе (или другом редакторе изображений), либо через онлайн-сервисы, например, TinyPNG или Optimizilla.
Превью к большим картинкам
Если у вас есть фотографии товаров (или выполненных работ) и есть страница с их списком, разумно будет сделать небольшие превью (уменьшенные картинки). Тогда список товаров, работ или фотографий будет загружаться быстрее.
Например, Спортмастер использует картинки товаров в трех вариантах:
Картинка для списка товаров (весит 7 Кб)
Картинка для карточки товара (весит 18 Кб)
Картинка для просмотра товара с «лупой» (весит 942 Кб)
Представьте, как долго загружался бы список товаров, если бы Спортмастер использовал только исходные картинки (те, что по 900 с лишним килобайт).
При проверке скорости сайта через Google PageSpeed вы получите готовый список картинок, которые следует оптимизировать:
Шаг 2. Gzip-сжатие
Gzip – это программа для сжатия файлов на сервере (аналог zip-архивов на компьютере). При включенном Gzip сервер, перед тем как отправлять браузеру код страницы (а также скрипты, стили и прочую текстовую информацию), сперва заархивирует эти файлы. Браузер получит архив и распакует его на компьютере пользователя. Сжатая информация будет передаваться быстрее между браузером и сервером.
Как включить Gzip-сжатие:
Если у вас есть доступ к файлу htaccess, добавьте в него такие строчки (в конец файла):
Если у вас не Apache, а Nginx (кто знает, тот поймет), то вам понадобится файл конфигурации nginx.conf. Дописываем код в секцию http <. >и перезапускаем сервер:
Если у вас нет доступа к htaccess или конфигурации сервера, напишите в техподдержку хостинга, что вам нужно включить gzip-сжатие.
Если сжатие работает, то в результатах проверки PageSpeed вы увидите (в блоке «Внедренные приемы оптимизации»):
Шаг 3. Кэширование на стороне браузера
Когда браузер загружает сайт, то он сохраняет часть информации с него (файлы стилей, скриптов, картинки) в свою собственную память (кэш, cache). Тогда на других страницах этого сайта или при повторном заходе на текущую страницу браузер не будет запрашивать эту информацию заново с сервера (что долго), а подгрузит ее из собственной памяти (что быстрее). Поэтому в настройках браузера есть кнопки «Очистить кэш», и все мы знаем сочетание клавиш CTRL+F5 (обновить страницу с очисткой кэша).
Чтобы использовать кэш браузера, нужно указать ему, какие типы файлов с вашего сайта сохранять в кэш. Как это сделать:
Через файл htaccess (кэшируем статические файлы на 10 дней):
Для Nginx добавляем в конфигурацию:
* \.(jpg|jpeg|gif|png|ico|css|js|txt)$ <
root /var/www/user/data/www/site.ru;
expires 10d;
>
.
>
Если к настройкам сервера доступа нет, опять же пишем в техподдержку и просим настроить кэширование статических файлов.
Аналогично списку картинок, Google PageSpeed выдает список ресурсов, для которых кэширование не настроено, а можно было бы:
Обратите внимание, что настроить кэширование вы можете только для своих ресурсов. Изменить настройки кэша, например, для скриптов Яндекс.Метрики уже не получится.
Шаг 4. Минимизация css- и js-файлов
Минимизация – это сокращение объема файла за счет удаления пробелов, пустых строк, комментариев, использования более коротких имен переменных и т.п. Браузеру все равно, с каким файлом работать – обычным или минимизированным, а весит такой файл меньше.
Пример обычного кода:
Популярные плагины и библиотеки (jQuery, Bootstrap и пр.) всегда имеют минимизированные версии своих скриптов и стилей – подключайте на сайт именно их. Например, обычная версия скрипта jQuery весит 265 Кб, а ее сжатый вариант – 85 Кб. Чувствуете разницу?
Единственный минус минификации – теряется читабельность файла. Если понадобится внести изменения в сжатый файл – сделать это будет сложно, человеку работать с таким файлом неудобно (там одна сплошная строка). Поэтому для минификации своих скриптов обычно используются дополнительные плагины к CMS – они автоматически сжимают css- и js-файлы перед загрузкой на сайт. А верстальщик при этом может спокойно работать с обычными версиями файлов.
PageSpeed и здесь заботливо показывает нам список файлов, размер которых можно уменьшить за счет минимизации:
Шаг 5. Порядок загрузки css- и js-файлов
Браузеры имеют свои алгоритмы для наиболее быстрой загрузки страниц (никто не хочет прослыть «тормозным» браузером). Поэтому, получив код страницы, браузер пытается вычислить, какие из подключаемых файлов ему нужно начать загружать в первую очередь. Иногда бывает так, что браузер уже добрался до отрисовки какой-нибудь формы на странице, а файл со стилями для нее еще не загрузился – тогда отрисовка остановится.
Чтобы браузер мог загружать файлы сайта оптимальным образом, рекомендуется все файлы стилей (css) и шрифтов подключать в начале кода страницы (в теге ), а все файлы скриптов (js) – в конце страницы, перед закрывающим тегом
Советы по оптимизации производительности JavaScript: обзор
08.05.2020 Комментарии к записи Советы по оптимизации производительности JavaScript: обзор отключены 351 Просмотров
От автора: как происходит в JavaScript оптимизация производительности? В этой статье нужно много всего рассказать по такой широкой и резко меняющейся области. Эта тема также затрагивает всеми любимое: JS фреймворк месяца.
Постараемся придерживаться мантры «инструменты, а не правила» и сократить умные словечки по JS до минимума. Поскольку мы не сможем уместить все по теме производительности JS в 2000 слов, прочитайте ссылки и проведите свое исследование.
Прежде чем погрузиться в детали, давайте получим широкое понимание проблемы, ответив на следующий вопрос. Что считается быстрым JS, как он вписывается в более широкий диапазон показателей веб-производительности?
Подготовка
Во-первых, сделаем следующее: если вы тестируете только на десктоп устройстве, вы исключаете более 50% пользователей.
Тенденция будет только расти, поскольку развивающийся рынок предпочитает использовать устройства Android по цене менее $100 для выхода в сеть. Эра выхода в интернет с десктопа как с основного устройства подошла к концу, и следующий миллиард интернет пользователей посетят ваши сайты в первую очередь с мобильного устройства.
Тестирование в режиме устройства в Chrome DevTools не заменяет тестов на реальном устройстве. Замедление CPU и скорости сети помогает, но это совсем другое. Тестируйте на реальных устройствах.
Даже если вы тестируете на реальном мобильном устройстве, вы можете делать это на своем новейшем флагманском смартфоне. Суть в том, что ваши пользователи сидят на других устройствах. Среднее устройство – это что-то типа Moto G1 – устройство с 1Гб ОЗУ и очень слабым CPU и GPU.
Давайте посмотрим на график парсинга среднего JS пакета.
Ого. Изображение показывает только парсинг и время компиляции JS (подробнее об этом позже), а не общую производительность. Но данные все равно можно сопоставить с общей производительность JS.
Процитирую Bruce Lawson: «это всемирная сеть, а не богатая западная сеть». Поэтому ваше целевое устройство примерно в 25 раз медленнее вашего MacBook или iPhone. Подумайте об этом. Но все становится еще хуже. Давайте посмотрим, на что мы на самом деле нацеливаемся.
Что именно представляет собой быстрый JS-код?
Мы выяснили нашу целевую платформу. Теперь давайте ответим на вопрос: что такое быстрый JS-код?
Нет абсолютной классификации определения быстрого кода, но у нас точно есть модель производительности, ориентированная на пользователя, которую можно использовать: модель RAIL.
Ответ
Если приложение отвечает на действие пользователя менее чем за 100мс, пользователь воспринимает ответ мгновенно. Это касается нажимаемых элементов, но не относится к прокрутки и перетаскиванию.
Анимация
На мониторах 60Hz постоянно необходимо иметь 60 кадров в секунду для анимации и прокрутки. Получается, где-то 16мс на кадр. Из этих 16мс у вас на все про все реально есть 8-10мс. Оставшееся время отнимают внутренние механизмы браузера.
Работа в режиме простоя
Если у вас есть тяжелые, постоянно запущенные задачи, разбейте их на маленькие части, чтобы главная ветка могла реагировать на действия пользователя. Нельзя, чтобы задача задерживала пользовательский ввод более чем на 50мс.
Загрузка
Необходимо стремиться к загрузке страницы менее чем за 1000мс. Чуть выше, и пользователь уже начинает нервничать. Добиться этого довольно сложно на мобильных устройствах, так как страница должна быть не просто отрисована на экране с возможностью прокрутки, она должна быть интерактивной. На практике цифры еще меньше:
На практике, цельтесь в отметку взаимодействия 5с. Ее использует Chrome на сайте Lighthouse audit.
Мы узнали цифры, теперь давайте посмотрим статистику:
53% посетителей покидают мобильный сайт, если он загружается более 3 секунд
1 из 2 людей ожидает, что страница загрузится менее чем за 2 секунды
77% мобильных сайтов загружаются более 10 секунд на 3G сетях
19 секунд – среднее время загрузки мобильных сайтов на 3G сетях
И еще от Addy Osmani:
Приложения стали интерактивными за 8 секунд на десктопе (по проводу) и за 16 секунд на мобильном соединении (Moto G4 на 3G)
В среднем разработчики загружают 410Кб сжатого JS на страницы.
Разочарованы? Хорошо. Давайте исправим веб.
Контекст – все
Вы могли заметить, что главное узкое место – это время загрузки сайта. В частности время загрузки, парсинга, компиляции и выполнения JS. Здесь ничего не сделаешь, остается лишь грузить меньше JS и делать это умнее.
Но что еще делает ваш код, помимо простой загрузки сайта? Должен быть некий прирост производительности, так ведь?
Прежде чем погрузиться в оптимизацию кода, посмотрите, что строите. Вы строите фреймворк или VDOM библиотеку? Должен ли ваш код делать тысячи операций в секунду? Вы делаете библиотеку с упором на время для обработки вводимых пользователем данных и/или анимации? Если нет, можете потратить время и энергию на что-то более влиятельное.
Не то чтобы писать быстрый код бесполезно, но обычно это мало влияет на общую схему вещей, особенно когда речь идет о микрооптимизации. Поэтому прежде чем перейти в споры на Stack Overflow по циклам .map или .forEach или for, сравнивая результаты с JSperf.com, убедитесь что видите целую картину. На бумаге 50k ops/s может смотреться в 50 раз лучше, чем 1k ops/s, но в большинстве случаев разницы нет.
Парсинг, компиляция и выполнение
Фундаментальная проблема большинства медленного JS кроется не в запуске кода, а во всех тех шагах, которые необходимо предпринять перед выполнением кода.
Мы говорим об уровнях абстракции. CPU на вашем компьютере запускает машинный код. Большая часть кода, запускаемого на компьютере, находится в скомпилированном двоичном формате. (учитывая все Electron приложения сегодня, я сказал код, а не программы) То есть код запускается непосредственно на железе, все уровни абстракции ОС отметаются. Подготовка не нужна.
JS не компилируется предварительно. Он попадает в ваш браузер (по медленным сетям) как читаемый код, что, в сущности, является ОС для JS программ.
Сперва, этот код необходимо распарсить – т.е. прочитать и перевести в индексируемую компьютером структуру, которую можно использовать для компиляции. Далее он компилируется в код байтов и далее в машинный код, после чего уже может выполняться на устройстве/браузере.
Также очень важно отметить, что JS работает в одном потоке и запускается на главном потоке браузера. То есть за раз можно запустить только один процесс. Если таймлайн в DevTools заполнен желтыми всплесками, нагружая CPU на 100%, вы получите длинные/отброшенные кадры, трясущуюся прокрутку и другие неприятности.
Все это нужно выполнить перед тем, как ваш JS начнет работать. Парсинг и компиляция занимают до 50% общего времени выполнения JS на движке V8 Chrome.
Из этого раздела нужно запомнить:
Необязательно линейно, но время парсинга JS увеличивается с ростом размера пакета. Чем меньше скачивать JS, тем лучше.
Каждый используемый JS фреймворк (React, Vue, Angular, Preact…) – это еще один уровень абстракции (если он не скомпилирован предварительно, как Svelte). Это не только увеличивает размер пакета, но и замедляет код, потому что вы не говорите с браузером напрямую.
Есть способы смягчить это, например, использовать сервис воркеры для выполнения заданий в фоновом режиме и в другом потоке, используя asm.js для написания кода, который легче скомпилируется для машинных инструкций. Это целая отдельная тема.
Однако вы можете не использовать фреймворки анимации JS для всего и прочитать, что вызывает орисовку и макетирование. Используйте библиотеки только тогда, когда абсолютно невозможно реализовать анимацию, используя обычные переходы и анимации CSS.
Несмотря на то, что они могут использовать переходы CSS, составные свойства и requestAnimationFrame (), они все еще работают в JS, в основном потоке. Они в основном просто забивают ваш DOM встроенными стилями каждые 16 мс, поскольку делать им больше нечего. Вы должны убедиться, что весь JS будет выполняться менее 8 мс на кадр, чтобы анимация была плавной.
С другой стороны, анимации и переходы CSS сбиваются с основного потока — на графическом процессоре, если они реализованы, не вызывая relayouts/reflows.
Учитывая, что большинство анимаций работают либо во время загрузки, либо при взаимодействии с пользователем, это может дать вашим веб-приложениям столь необходимое пространство для маневра.
Web Animations API — это набор функций, который позволит вам выполнять анимацию JS с основного потока, но на данный момент придерживаться переходов CSS и таких методов, как FLIP.
Размер пакета – все
Сегодня все в пакетах. Прошли те времена Bower и десятков тегов script перед закрывающим тегом body.
Теперь все делается через npm install, устанавливая любую новую игрушку, которую вы найдете на NPM, объединив их вместе с Webpack в огромном одном JS-файле размером 1 МБ и забивая браузер своих пользователей в обход, закрывая тарифы.
Попробуйте отправлять меньше JS. Вам может не понадобиться вся библиотека Lodash для вашего проекта. Вам точно нужно использовать JS фреймворк? Если да, смотрели ли вы что-то отличное от React, например Preact или HyperHTML, размер которых меньше 1/20 размера React? Вам нужен TweenMax для этой анимации с прокруткой вверх? Удобство npm и изолированных компонентов в рамках имеет недостаток: первый ответ разработчиков на проблему — бросать еще больше JS. Когда у вас есть молот, все выглядит как гвоздь.
Когда закончите вырезать сорняки и уменьшите количество загружаемого JS, попробуйте отправить его умнее. Отправляйте, что вам нужно, когда вам это нужно.
Webpack 3 обладает потрясающими функциями, разделением кода и динамическим импортом. Вместо объединения всех ваших JS-модулей в монолитный пакет app.js он может автоматически разбить код с помощью синтаксиса import () и загрузить его асинхронно.
Вам также не нужно использовать фреймворки, компоненты и маршрутизацию на стороне клиента, чтобы получить выгоду от этого. Допустим, у вас есть сложная часть кода, которая активирует ваш .mega-widget, который может быть на любом количестве страниц. Вы можете просто написать следующее в своем основном JS-файле:
Если ваше приложение найдет виджет на странице, будет динамически загружен требуемый код поддержки. В противном случае все нормально.
Кроме того, Webpack требует свой собственный runtime для работы, и он внедряется во все созданные файлы .js. Если вы используете плагин commonChunks, вы можете использовать следующее, чтобы извлечь runtime в свой кусок:
