Скил performance — паттерны оптимизации при проектировании и ревью
Как скил performance даёт агентам Datarim компактный справочник по ленивой загрузке, кешированию, пакетированию, индексированию баз данных и оптимизации бандла при проектировании и проверке производительности.
Проблемы производительности обычно обнаруживаются поздно, когда их цена уже высока. Отсутствующий индекс находят в бою под нагрузкой. N+1-запрос замечают на нагрузочном тесте. Бандл, который браузер разбирает шесть секунд, блокирует каждый первый визит. Скил performance загружает паттерны во время проектирования и ревью — до того, как проблема становится частью кода.
Скил охватывает три уровня: общие паттерны оптимизации, рекомендации для баз данных и рекомендации для фронтенда. Каждый уровень — это отдельная точка, где решается производительность.
Паттерны оптимизации
Три паттерна применимы повсеместно. Первый — ленивая загрузка: ресурсы и модули загружаются только тогда, когда они нужны. За модуль, импортированный в начале файла, платят всегда; за модуль, загруженный по требованию, — только когда пользователь доходит до нужного пути.
Второй — кеширование. Для операций, результат которых дорого вычислять и достаточно стабилен для повторного использования — запрос к базе, вызов внешнего API, вычисленная агрегация — слой кеширования (Redis или хранилище в памяти) избавляет от повторения работы. Конкретный TTL и стратегия инвалидации зависят от того, как часто меняются данные и насколько устаревший ответ допустим.
Третий — пакетирование. Когда приложение делает много маленьких запросов к базе или API в цикле, замена их одним запросом, который забирает все данные сразу, убирает накладные расходы на каждый вызов. Цикл, который обращается к базе по одному запросу на элемент, — кандидат на пакетирование.
Базы данных
Два правила для баз данных покрывают большинство проблем производительности запросов. Первое: индексы должны существовать на столбцах, которые используются в фильтрах и соединениях. Полный перебор большой таблицы — самая частая причина медленного запроса; решение — индекс, а не переписывание логики запроса.
Второе: N+1-запросы нужно устранять. N+1-запрос возникает, когда код загружает список из N записей и затем делает по одному дополнительному запросу на каждую запись, чтобы получить связанный ресурс. Решение — жадная загрузка: либо директива include в вызове ORM, либо паттерн пакетной загрузки, который забирает все связанные записи одним запросом.
Фронтенд
Три паттерна для фронтенда применяются на этапе сборки и отрисовки. Размер бандла определяет, сколько времени браузер тратит на разбор и выполнение JavaScript до того, как страница становится интерактивной. Маленький бандл — через tree-shaking, разбивку кода и замену тяжёлых зависимостей на лёгкие альтернативы — напрямую влияет на время первой загрузки.
Оптимизация изображений — это формат WebP и ленивая загрузка. WebP даёт меньший размер файла, чем JPEG или PNG при том же визуальном качестве. Ленивая загрузка откладывает скачивание изображений, которые находятся вне начальной области просмотра, до момента прокрутки — это уменьшает объём данных при первой загрузке.
Для страниц с длинными списками — результаты поиска, лента, история транзакций — виртуализация отрисовывает только видимые строки, а не весь список. Отрисовка десяти тысяч DOM-узлов для списка, из которого пользователь видит двадцать, создаёт накладные расходы на разметку и отрисовку, которые виртуализация устраняет.
Общая картина — в посте что такое Datarim. Ещё один пример ограничения, которое дешевле проверить при проектировании, чем исправлять позже, — пост о скиле network-exposure-baseline.