❌ 10 ошибок в lazy-loading, которые замедляют сайт

Недавно мы писали про lazyLoading в этом посте. Продолжаем тему

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

❌ Ленивая загрузка критичного UI

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

❌ Грузить код лениво, но слишком поздно

Ошибка, с которой сталкиваются многие: компонент загружается лениво, но нуждается в немедленной активации. Из-за этого возникает задержка, и пользователь видит лаги или мерцание. Чтобы избежать этого, используйте предзагрузку (prefetch) вместе с ленивой загрузкой.

<link rel="prefetch" href="/modal.js">

❌ Ленивое загружение там, где нужна отложенная инициализация

Некоторые операции, такие как работа с картами, сложными таблицами или WebGL, требуют, чтобы код был загружен сразу, но его выполнение можно отложить. Для этого используйте requestIdleCallback, setTimeout(0) или Scheduler API.

❌ Ленивая загрузка маленьких модулей

Если модуль весит 1-3 KB, разбивать его на отдельный чанк — это лишняя нагрузка. Модули такого размера не нужно загружать лениво, так как это добавит ненужные сетевые запросы и усложнит граф зависимостей. Ленивая загрузка должна применяться только к тяжелым и ресурсозатратным модулям.

❌ Ленивая загрузка без учета поведения пользователя

Ошибка заключается в том, что модалки или другие элементы функционала загружаются лениво, даже если пользователь почти сразу же взаимодействует с ними. В 2025 году есть инструменты, как prediction-preload в Next.js, Astro или Remix, которые помогают предугадывать действия пользователя и загружать необходимые компоненты заранее.

❌ Ленивая загрузка изображений без настроек fetchpriority

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

<img src="hero.jpg" loading="eager" fetchpriority="high">
<img src="section.jpg" loading="lazy">

❌ Ленивая загрузка CSS и блокировка first-paint

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

<link rel="stylesheet" href="theme.css" media="print" onload="this.media='all'">

❌ Ленивая загрузка маленьких иконок и SVG-спрайтов

Ленивая загрузка маленьких графических ассетов, таких как иконки или SVG-спрайты, приводит к лишним сетевым запросам, но почти не экономит ресурсы. Вместо этого используйте inline SVG, спрайты в <defs>, или пакуйте через Vite или Next.js.

❌ Неправильный threshold в IntersectionObserver

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

new IntersectionObserver(callback, { rootMargin: '200px' });

❌ Отсутствие fallback UI

Когда чанк ещё грузится, а пользователь уже видит пустое пространство, это создаёт ощущение тормозящего приложения. Чтобы этого избежать, всегда добавляйте skeletons, placeholders, мини-лоадеры или заранее зарендеренные контейнеры. Это сделает загрузку более плавной и улучшит восприятие приложения.

📌 Правильная ленивая загрузка — это не просто отложить всё на потом. Это умение понять, что можно подождать, а что лучше сразу загрузить.

🚪 Frontender's notes

🔫 CI/CD для фронтенда: как сделать процессы безболезненными

Когда проект растёт, настоящая боль для команды не всегда в коде, а в процессе CI/CD. Долгие сборки, случайные ошибки, непонятные артефакты — всё это превращается в ежедневную головную боль. Однако, правильно настроенная система CI/CD может быть гораздо проще и эффективнее, чем кажется.

👨‍🎨 Линтить → тестировать → билдить

Частая ошибка команд — начинать с билда и только потом замечать пропущенные ошибки. Это может привести к ситуациям, когда сборка занимает 5 минут, а где то одна недостающая запятая. Правильный порядок: линтинг с ESLint и TypeScript, юнит-тесты, E2E и интеграционные тесты, и только потом билд. Так вы сэкономите время и ресурсы.

⚡️ Кеш — ваш лучший друг

Использование кеша для ускорения процессов стало нормой. Не стоит недооценивать его влияние на скорость работы. Настроенные кеши в pnpm, npm, yarn, Turbo, Nx, Bun, Vite, и GitHub Actions помогут значительно ускорить процессы и сократить время на каждом пуше.

🗳 Разделяйте CI и CD

CI (Continuous Integration) и CD (Continuous Deployment) — это два разных процесса. CI отвечает на вопрос: «Можно ли собрать код и пройти тесты?» CD же решает, готов ли код к деплою в продакшн. Когда эти процессы объединяются в один пайплайн, только добавляется хаос.

💡 Feature Environments

Каждая ветка должна иметь свою отдельную превью-среду, как например в Vercel, Netlify, Cloudflare Pages или Render. Это помогает PM увидеть изменения до мерджа, QA не зависеть от локальных настроек, а дизайнерам проверять анимации. Без этой практики рецензировать UI-фичи становится крайне сложно.

🔄 Деплой должен быть атомарным

Каждый коммит должен приводить к одному артефакту и одному деплою. Без «подправил на сервере» и «почему на проде другая версия файла?». Артефакты должны быть воспроизводимыми, неизменяемыми и версионируемыми.

❌ Прерывание старых джобов

При каждом новом пуше в PR старые CI процессы должны отменяться, чтобы избежать лишних билдов подряд. Это можно настроить в GitHub Actions с помощью простого конфигурационного кода.

📦 Проверка бандла — часть CI, а не когда вспомним

Проверка бандла на каждом этапе CI с помощью таких инструментов как Bundlephobia API, Webpack Bundle Analyzer, Lighthouse-ci поможет избежать случайных увеличений размера бандла.

🤚 Rollout фичей — через feature flags

Деплой не всегда означает релиз. Фича-флаги позволяют постепенно выкатывать изменения, откатывать без деплоя, тестировать экспериментальные сценарии и проводить A/B тестирование.

🔄 Автоматический откат

Настройте автоматический откат на таких платформах, как Cloudflare или Vercel, чтобы обеспечить стабильность в случае ошибок.

💼 CI/CD должен быть другом, а не врагом

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

📌 CI/CD не просто про автоматизацию, это про создание комфортной среды для разработчиков. Правильно настроенная система CI/CD ускоряет процесс разработки и помогает команде работать с минимальными проблемами.

🚪 Frontender's notes

😎 Найдено самое оригинальное портфолио

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

Все ассеты, кстати, тоже сделаны с нуля.

✖️ xCode Journal

❗️ Memory leaks в браузере: как не упустить реальную проблему

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

❌ Зависшие ссылки в замыканиях

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

Проблема (в примерах): bigData остаётся в памяти, пока существует ссылка на колбэк.

❌ Глобальные переменные

Ошибки с глобальными переменными часто возникают, когда забывают использовать const или let.

Проблема (в примерах): Любой объект в глобальной области будет жить вечно.

❌ Слушатели событий и DOM-узлы

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

Проблема (в примерах): После удаления элемента слушатель остаётся, удерживая объект в памяти.

❌ Неправильное использование таймеров

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

Проблема: Таймер продолжает работать, сохраняя контекст.

❌ Неправильное использование таймеров

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

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

❌ Кэши без лимитов

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

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

❌ Проблемы с Web Workers

Ошибки в работе с Web Workers, такие как передача данных без Transferables или не закрытые воркеры, могут стать причиной утечек.

❌ Сторонние библиотеки

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

❌ React: stale effects

В React утечки могут происходить из-за старых ссылок в эффектах, которые не пересоздаются.

Проблема (в примерах): Эффект не пересоздается, старые ссылки остаются.

📝 Примеры

// Зависшие ссылки в замыканиях
function createTracker() {
const bigData = new Array(1_000_000).fill('x');
return () => console.log(bigData.length);
}

// Глобальные переменные
foo = {}; // теперь это window.foo

// Слушатели событий и DOM-узлы
element.addEventListener('scroll', handler);
// element.removeEventListener(...) забыли

// Кэши без лимитов
const cache = {};
cache[key] = heavyObject;

// React: stale effects
useEffect(() => {
subscribe();
return () => unsubscribe();
}, []); // но зависимость должна быть!

📌 Для обнаружения утечек памяти используйте Chrome DevTools. Перейдите в Performance → Memory Leak Check и проанализируйте Heap snapshots и Allocation Timelines. Обращайте внимание на Detached DOM nodes и Large object groups. Утечка памяти происходит, когда объект больше не нужен, но на него всё ещё есть ссылка. Иногда это баг, который длится месяцами.

🚪 Frontender's note

📖 JSCamp

JSCamp — это полный интенсив, который проведет вас через все основные технологии экосистемы JavaScript, включая HTML, CSS, JavaScript, TypeScript, Node.js, SQL, CI/CD и Docker.

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

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

🔘Есть нюанс. Репа на испанском, придется работать с переводчиками если вы его не знаете.

🚪 Frontender's notes

💡 Чеклист для ревью фронтенд-кода

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

💬 Архитектура и структура

Первое, на что стоит обратить внимание — это структура кода. Логика должна быть разделена по слоям, например, ui, features, services, libs. Не должно быть гигантских файлов на 500 строк и больше, а импорты не должны образовывать циклических зависимостей. Код должен быть логично организован и легко поддерживаем. Особое внимание стоит уделить отсутствию общих утилит, которые непредсказуемо тянут лишний код.

💬 Чистота и читаемость

Код должен быть понятен без дополнительной документации. Названия сущностей и функций должны четко отражать их назначение, избегайте абстрактных сокращений типа a, b, c, если это не map или reduce. Логика функций не должна выходить за пределы одного экрана. Убедитесь, что мусорные console.log удалены из финальной версии.

💬 Работа с состоянием

Стейт должен быть локализован в компоненты и в стор, не стоит размывать его между ними. Нужно следить за тем, чтобы не было лишних перерендеров, а также чтобы useMemo и useCallback использовались только по делу. Эффекты должны быть грамотно настроены, чтобы не вызывать побочные действия из-за неправильных зависимостей, а бесконечные циклы useEffect — это то, что нужно избегать.

💬 Асинхронность

Везде должны быть учтены ошибки с использованием try/catch или .catch. Важно следить за гонками состояний и отменой запросов через AbortController или аналоги. Промисы не должны «висеть», и все ошибки должны быть разделены на ошибки пользователя и сервера.

💬 Производительность

Избегайте ненужных рендеров и перерасчетов layout, таких как работа с DOM вне циклов или синхронные запросы типа offsetWidth. Большие списки должны быть под виртуализацией. Оптимизируйте циклы и тяжелые вычисления, и если нужно — выносите их в Web Worker. В JSX не должно быть больших inline-функций, а ререндеры не должны происходить из-за лишних контекстов.

💬 Работа с памятью

Все таймеры должны быть очищены, и слушатели событий удаляться при очистке. Не должно быть бесконтрольных кэшей, утечек из-за замыканий или устаревших эффектов. Важно также следить за тем, чтобы не было «висячих» DOM-нод (detached nodes).

💬 Безопасность

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

💬 Работа с API

API должно быть ясным и с четко определёнными DTO/типами для запросов и ответов. Ошибки от сервера должны обрабатываться отдельно от пользовательских. Избегайте "магических строк", а также убедитесь в правильности заголовков, методов и кодов ответа. Не должно быть повторяющихся запросов, которые должны быть мемоизированы или дедуплицированы.

💬 UI и UX

Все загрузочные состояния, такие как loading, error, empty, должны быть правильно реализованы. Спиннеры не должны прыгать по экрану. Весь интерактивный контент должен быть доступен для пользователей с ограниченными возможностями (accessibility), а layout shift не должен происходить при загрузке. Анимации должны быть легкими и не блокирующими.

💬 Тестируемость

Код должен быть легко тестируемым, а компоненты не завязаны на глобальные состояния. Логика должна быть вынесена из JSX, а побочные эффекты должны быть минимизированы. Мокинг зависимостей должен быть простым и удобным. Покрытие тестами важно, но не должно быть самоцелью — главное, чтобы тесты действительно проверяли функциональность, а не просто увеличивали процент покрытия.

📌 Чеклист поможет вам избежать распространённых ошибок при работе. Когда код соответствует этим критериям, он становится проще, быстрее и стабильнее.

🚪 Frontender's notes