Производительность и организация

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

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

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

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

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

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

Остерегайтесь @import в HTML

Это странный раздел. Очень странный. Я провалился в настолько глубокую кроличью нору, исследуя эту тему… В Blink и WebKit всё поломано, потому что в них баг; в Firefox и IE/Edge только кажется, что поломано. Я завел баги про это в их багтрекерах.

Чтобы полностью понять этот раздел, сначала нужно знать о сканере предварительной загрузки в браузере: во всех основных браузерах реализован вспомогательный, облегченный парсер, называемый обычно «Сканер предварительной загрузки» (Preload Scanner). Основной парсер в браузере отвечает за создание DOM, CSSOM, запуск JavaScript и так далее, и он постоянно приостанавливается по мере того, как он блокируется разными частями документа. Сканер предварительной загрузки может спокойно забегать вперед основного, сканируя остальной HTML в поисках ссылок на другие подресурсы (такие как CSS-файлы, JS и изображения). После их обнаружения сканер предварительной загрузки начинает загружать их, готовый к тому, чтобы основной парсер потом мог подхватить их уже готовыми для использования. Внедрение сканера предварительной загрузки улучшило производительность веб-страниц примерно на 19%, причём разработчикам даже не пришлось и пальцем пошевелить. Это отличная новость для пользователей!

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

В данном разделе рассматриваются баги в сканере предварительной загрузки в WebKit и Blink, а также его неэффективность в Firefox’s и IE/Edge.

Не размещайте перед асинхронными сниппетами

Предыдущий раздел был про то, как другие ресурсы могут тормозить CSS (из-за глюков, как оказалось), а здесь речь пойдет о том, как CSS может нечаянно задержать загрузку последующих ресурсов, прежде всего JavaScript, асинхронно подгружаемого кодом наподобие такого:

<script>
  var script = document.createElement('script');
  script.src = "analytics.js";
  document.getElementsByTagName('head').appendChild(script);
</script>

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

Браузер не выполнит , если он в это время еще работает с каким-то CSS-кодом

<link rel="stylesheet" href="slow-loading-stylesheet.css" />
<script>
console.log("пока грузится оочеень-мееедлееенный-файл.css");
</script>

Это специально. Так задумано. Ни один синхронный элемент в вашем HTML не выполнится, пока грузится какой-либо CSS. Это простая защитная стратегия для особого случая, когда может запросить что-то о стилях страницы: если скрипт запрашивает цвет страницы до того, как загружен и разобран CSS, то ответ JavaScript может оказаться неверным и неактуальным. Чтобы избежать этого, браузер не выполняет , пока CSSOM не будет готова.

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

Если поместить перед нашим асинхронным сниппетом, тот не сработает, пока CSS-файл не загрузится и не распарсится. Следовательно, ваш CSS всё тормозит.

<link rel="stylesheet" href="app.css" />

<script>
  var script = document.createElement('script');
  script.src = "analytics.js";
  document.getElementsByTagName('head').appendChild(script);
</script>

При таком порядке очевидно, что JavaScript-файл не начинает грузиться, пока создаётся CSSOM. Любое распараллеливание полностью потеряно.

Из-за таблицы стилей перед асинхронным сниппетом теряется возможность распараллеливания.

Интересно, что сканер предварительной загрузки хотел бы уже подхватить ссылку на заранее, но мы непроизвольно скрыли её: — строка, и не становится атрибутом src, который можно разобрать на токены, пока элемент не появится в DOM. Именно это я имел ввиду ранее, говоря «Подробнее об этом позже».

Сторонние сервисы довольно часто предоставляют такие асинхронные сниппеты для более безопасной загрузки своих скриптов. Также разработчики часто с подозрением относятся к таким сторонним ресурсам, размещая свои асинхронные сниппеты позже на странице. Пусть намерения здесь и благие — «Я не хочу размещать сторонние теги раньше моих собственных ресурсов!» — от этого часто бывает лишь вред. На самом деле, Google Analytics даже говорит нам, что делать, и они правы:

Поэтому посоветую вот что:

Если блоки не зависят от CSS, размещайте их выше ваших таблиц стилей.

Вот что получается, если следовать этому паттерну:

<script>
  var script = document.createElement('script');
  script.src = "analytics.js";
  document.getElementsByTagName('head').appendChild(script);
</script>

<link rel="stylesheet" href="app.css" />

Если поменять местами таблицу стилей и асинхронный сниппет, то распараллеливание восстановится.

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

Минифицируйте и сжимайте CSS-файлы

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

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

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

Опции CSS

Оптимизировать код CSS? Оптимизация (сокращение) кода стилей CSS.

Объединить файлы CSS? Опция включает объединение стилей-файлов CSS — они останутся загружаться в «верхней» части сайта, но вместо 10-20 файлов будет один.

Объединять встроенный CSS? Стили прописанные HTML в разных местах (не файлами css), будут объединены в один кусок HTML.

Создать данные: URI для изображений? Если у вас в файлах CSS прописываются пути к картинкам размером меньше 4 КБ, они не будут подгружаться как отдельный запрос, а будут идти в загрузке вместе с основным файлом CSS. Уменьшение количества запросов — всегда плюс для «пузомерок». Пример такой картинки — «галочка» в списках.

Встроить и отложить выполнение CSS? Самый интересный и сложный пункт. Он позволяет интегрировать в HTML только тот CSS код, который используется для отрисовки видимой части сайта. И отложить загрузку всех остальных CSS и, самое главное, переместить их из шапки.

Рассмотрим этот пункт отдельно ниже.

Встраивать все CSS? Стили из файлов CSS и HTML прописываются в шапку (head) сайта в виде HTML. Визуально большой блок кода виден в шапке, что на мой взгляд может не понравиться поисковым системам.

Исключить CSS из Autoptimize. Можно исключить из оптимизации некоторые CSS файлы, если это вызывает проблемы.

Общий анализ производительности

Firefox, Chrome и другие браузеры предоставляют встроенные инструменты, которые могут помочь вам диагностировать медленный рендеринг. В частности, Firefox’s Network Monitor покажет точное время, когда произошёл каждый сетевой запрос, насколько большим он был и как долго обрабатывался.

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

Встроенный Gecko Profiler — очень полезный инструмент, который позволяет вам получить ещё более подробную информацию о том, какие части кода работают медленно. Это довольно сложный инструмент, но он предоставляет множество деталей.

Примечание: вы можете использовать эти инструменты и в Android браузере, запустив Firefox и включив remote debugging.

Например, множественные сетевые запросы в мобильной сети занимают больше времени. Рендеринг больших изображений и CSS градиентов может происходить дольше. Простое скачивание больших изображений может занять большее время, даже через быструю сеть, так как аппаратная часть мобильных устройств зачастую слишком медленна, чтобы использовать все возможности быстрых каналов данных. Для получения полезных подсказок о производительности на мобильных устройствах, ознакомьтесь с докладом Максимилиано Фёртмана Mobile Web High Performance.

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

Убедитесь, что вы можете воспроизвести проблему, просто сохраняя и загружая статическую копию HTML-страницы (включая изображения/стили/скрипты). Если так — удалите из HTML файла всю личную информацию и обратитесь к за помощью (отправьте отчёт в Bugzilla или, например, сохраните файл на своём сервере и поделитесь ссылкой). Вам также понадобится поделиться информацией профилировщика, которую вы собрали с помощью инструментов отладки.

3.5.1 Использование сборки Production

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

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

Если вы не уверены, правильно ли настроен процесс сборки, вы можете проверить это,
установив React Developer Tools для Chrome. Если вы заходите на сайт с React в режиме production,
значок будет иметь темный фон:

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

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

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

Firefox и IE/Edge: поместите @import перед JS и CSS в HTML

В Firefox и IE/Edge сканер предварительной загрузки, похоже, не подхватывает какие-либо директивы @import, определённые после или

Поэтому этот HTML:

<script src="app.js"></script>

<style>
  @import url(app.css);
</style>

… даст вот такую каскадную диаграмму:

Потеря распараллеливания в Firefox из-за неработающего сканера предварительной загрузки (примечание: точно такая же каскадная диаграмма получается в IE/Edge).

Здесь хорошо видно, что таблица стилей из не начинает загружаться до завершения JavaScript-файла.

Эта проблема – не что-то уникальное для JavaScript. С таким HTML всё так же:

<link rel="stylesheet" href="style.css" />

<style>
  @import url(app.css);
</style>

Потеря распараллеливания в Firefox из-за неэффективного сканера предварительной загрузки (примечание: точно такая же каскадная диаграмма получается в IE/Edge).

Быстрое решение этой проблемы — поменять местами блоки или и . Однако, из-за этого, что-то наверняка может сломаться, поскольку мы меняем порядок зависимостей (читай, каскад).

Правильное решение этой проблемы — вообще обходиться без и использовать второй

<link rel="stylesheet" href="style.css" />
<link rel="stylesheet" href="app.css" />

Гораздо лучше:

Два восстанавливают параллельность. (примечание: точно такая же каскадная диаграмма получается в IE/Edge).

Совет по настройке производительности MySQL № 8: неистово накапливайте статистику, но не увлекайтесь чрезмерными оповещениями

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

Мы предлагаем воспринимать мониторинг в двух разрезах. Во-первых, как можно подробнее фиксировать показатели и оповещения

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

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

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

Примеры

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

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

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

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

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

Рефакторинг CSS

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

Рефакторинг CSS — это многоступенчатый процесс, в ходе которого Вам нужно проанализировать каждый аспект Вашего CSS кода. Вам нужно проверить следующие моменты:

• присутствуют ли неиспользуемые или дублирующие CSS-правила или ресурсы
• возможно ли использование более современных техник, таких как Flexbox и CSS Grid
• не используется ли слишком много специфичности (посчитать это можно с помощью визуального калькулятора специфичности)
• грамотно ли организована структура CSS-файлов (например, легче поддерживать меньшие файлы, чем большИе)
• стоит ли начать использовать инструменты автоматической сборки
• и многое другое.

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

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

Стилевая диета

Тест позволил получить довольно интересные показатели. Например, Firefox
выполнил этот тест в 1,7 раз медленнее чем тест с самым медленным селектором
(тест 6). Android 4.3 потратил в 1,2 больше времени чем на тест с самым
медленным селектором (тест 6). Internet Explorer выполнил этот тест в целых
2,5 раза медленнее чем тест с самым медленным селектором!

Как видите, все показатели для Firefox существенно уменьшились, когда была
удалена половина стилей (примерно 1500 строчек). Устройство с Android также
практически приблизилось к скорости теста с самым медленным селектором.

Удаление неиспользуемых стилей

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

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

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

Впрочем, это не повлияет на реальную производительность вашего CSS.

Плагин Autoptimize для оптимизации WordPress

Autoptimize — это бесплатный плагин для оптимизации WordPress. Помимо оптимизации HTML, CSS и JavaScript, Autoptimize также включает в себя функции оптимизации , ориентированные на другие аспекты современных сайтов WordPress. Плагин работает с кодом, скриптами и стилями страницы, ускоряя загрузку. Хорошо справляется в тандеме с плагином кэширования.

Оптимизация сайта с помощью Autoptimize

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

Возможности Autoptimize:

• Оптимизация JavaScript и CSS;
• Исправление кода, блокирующего отображение верха страницы.
• Кэширование и объединение скриптов и стилей;
• Работа с заголовками;
• Перемещение скриптов в нижний колонтитул;
• Упрощение HTML.

Параметры «Extra» позволяют оптимизировать шрифты Google и изображения ( Autoptimize включает оптимизацию изображений на «лету» (с поддержкой форматов WebP и AVIF) и CDN через ShortPixel), асинхронный не агрегированный JavaScript. Удалять основные эмоции (emoji) WordPress и многое другое. Таким образом, он может улучшить производительность вашего сайта, даже если уже используется HTTP / 2! Доступен обширный API, позволяющий адаптировать Autoptimize к конкретным потребностям каждого сайта WP.

Оптимизация CSS в WordPress

В WordPress оптимизацию CSS можно реализовать автоматически с помощью плагинов. Как работают эти дополнения? Плагины по оптимизации CSS минимизируют и сжимают CSS-файлы:

• удаляют комментарии из CSS
• удаляют новые и пустые строки, двойные пробелы, табуляции и т.д.
• объединяют однотипные стили
• переводят значения цветов в короткие (#ffffff и #fff — работают одинаково хорошо)
• используют GZIP компрессию для оптимизированного CSS

Среди популярных плагинов можно назвать:

• CSS Compress https://plugins.trac.wordpress.org/wiki/css-compress
• Autoptimize https://ru.wordpress.org/plugins/autoptimize/
• Better WordPress Minify https://ru.wordpress.org/plugins/bwp-minify/

Кстати, оптимизацию CSS целесообразно проводить вместе с JavaScript. И два последних плагина работают как раз в обоих направлениях (умеют оптимизировать JS наравне с CSS).

Включение Gzip сжатия

Gzip – это формат сжатия веб-страниц, файлов CSS и JavaScript на стороне сервера перед отправкой их в браузер. Можно проверить сжимается ли уже сайт с помощью нескольких инструменов (https://seolik.ru/gzip-compression-test или https://checkgzipcompression.com). Есть смысл вложиться в данный вариант оптимизации, ибо колоссальная разница заметна сразу.При использовании Apache, можно включить сжатие, добавив следующий фрагмент в файл .htaccess.<IfModule mod_deflate.c> # Compress HTML, CSS, JavaScript, Text, XML and fonts AddOutputFilterByType DEFLATE application/javascript AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/vnd.ms-fontobject AddOutputFilterByType DEFLATE application/x-font AddOutputFilterByType DEFLATE application/x-font-opentype AddOutputFilterByType DEFLATE application/x-font-otf AddOutputFilterByType DEFLATE application/x-font-truetype AddOutputFilterByType DEFLATE application/x-font-ttf AddOutputFilterByType DEFLATE application/x-javascript AddOutputFilterByType DEFLATE application/xhtml+xml AddOutputFilterByType DEFLATE application/xml AddOutputFilterByType DEFLATE font/opentype AddOutputFilterByType DEFLATE font/otf AddOutputFilterByType DEFLATE font/ttf AddOutputFilterByType DEFLATE image/svg+xml AddOutputFilterByType DEFLATE image/x-icon AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE text/html AddOutputFilterByType DEFLATE text/javascript AddOutputFilterByType DEFLATE text/plain AddOutputFilterByType DEFLATE text/xml

# Remove browser bugs (only needed for really old browsers) BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4\.0 no-gzip BrowserMatch \bMSIE !no-gzip !gzip-only-text/html Header append Vary User-Agent</IfModule>Для Nginx, сжатие можно включить, добавив в файл nginx.conf фрагмент:gzip on;gzip_vary on;gzip_comp_level 2;gzip_http_version 1.0;gzip_proxied any;gzip_min_length 1100;gzip_buffers 16 8k;gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;gzip_disable «MSIE .(?!.*SV1)»;Необходимо отметить специфическую особенность, выявленную в практической эксплуатации сайта bmstu-kaluga.ru: когда производительность упирается в скорость сжатия, на двухядерной системе nginx с 2-мя процессами работает практически в 2 раза быстрее, чем с одним процессом.Как оказалось, результирующая производительность весьма ограничена производительностью процессора, и оснований думать что «процессоры нынче быстрые» нет, бездумно ставить сжатие на 9 уровень не выйдет. При сжатии на 9-тку nginx полностью занимает оба ядра процессора, но отдает всего контент на скорости всего 4 Мб/с, т.е. не способен загрузить канал 100 Мбит, не говоря уже о большей пропускной способности.Если сравнивать скорость сжатия и размер полученных файлов, то видно, что после степени 5 сжатие практически не растет, а вот скорость падает почти в 2 раза если сжимать на 9. Рекомендуемое решение заключается в использовании модуля ngx_http_gzip_static_module. Этот модуль позволяет избавиться от сжатия одних и тех же файлов. Мы просто максимально сжимаем их заранее, и помещаем в том же каталоге с расширением .gz, и если есть – то будет отдаваться сжатый файл, причем моментально. Если включить и gzip_static и обычный gzip с уровнем сжатия например 1, то если предварительно сжатый файл будет найден – его и отдадут, а если такого файла нет, или например контент от Apache приходит – то его сожмут на 1, максимально быстро.Для реализации описанной методики необходимо подготовить сжатые файлы:

for i in `find ./* -type f -name '*.js'`; do echo $i; gzip -c -9 $i > $i.gz; done;for i in `find ./* -type f -name '*.css'`; do echo $i; gzip -c -9 $i > $i.gz; done;

А в конфигурацию nginx добавляем строчку gzip_static on:gzip_static on;

Что же мы можем сделать?Скопировать ссылку

Фронтенд-разработчики тихо и с успехом в течение многих лет разрабатывали крупные веб-проекты без использования методологий CSS-фреймворков. Тот простой факт, что эти крупные проекты обошлись без использования OOCSS, БЭМ и других методологий, показывает, что можно вполне эффективно работать и без них. Вот несколько рекомендаций от людей, с которыми я обсуждал написание CSS, а также — несколько предложений, основанных на моем личном опыте.

Ради всего святого, используйте !

В ряде методологий CSS-фреймворков считается, что использовать в CSS — плохая идея. Объяснение этого следующее: обладают большой специфичностью, поэтому переопределить правила, описанные для , можно только с помощью (презираемого) модификатора . Я абсолютно не согласен с этим: цитируя Ангуса Кролла, «стратегия избегания беспокоит меня тем, что нельзя освоить язык, не зная его с ног до головы, а страх и уклонение — враги знания». Если уж вы профессиональный веб-разработчик, вы должны понимать, как работает специфичность и как она влияет на селекторы, которые вы пишете. Кроме того,  — совершенно полноправная часть структуры документа, и у них есть очень полезные функциональные и семантические свойства.

Пишите селекторы так, чтобы они были настолько специфическими и настолько описательными, насколько это нужно: ни больше, ни меньше.

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

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

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

Много файлов и процесс сборки.

Черт возьми, вы же профессиональный веб-разработчик. Вы не пишете код в «Блокноте» — нет никакого повода не использовать в своей работе лучшие из существующих инструментов. На каком бы фреймворке или платформе вы ни разрабатывали, всегда есть возможность пользоваться CSS-препроцессорами! Есть много отличных примеров эффективного повторного использования CSS в разных проектах. Почитайте и посмотрите, как это делают другие люди — расширяйте свои знания.

Разрабатывайте статические прототипы. Делайте скриншоты всего, чего можно.

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

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

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

Используйте градиенты и SVG вместо изображений

Загрузка всех изображений на веб-странице может отнимать много времени. Для сокращения этого времени, разработчики используют множество методов оптимизации изображений, таких как загрузка изображений из внешнего CDN или использование инструментов сжатия изображений, таких как TinyJPG. Эти решения могут существенно помочь, однако в некоторых ситуациях использование ресурсоёмких JPG и PNG изображений можно заменить CSS-эффектами.

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

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

Для более сложных градиентов и текстур, Вы также можете использовать генераторы, такие как CSSmatic (на изображении ниже) и ColorZilla

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

3.5.6 Rollup

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

Код

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

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

Код

Полный пример установки смотреть

здесь
.

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