🔧 Как оптимизировать фронтенд?
Во-первых, знание способов оптимизации фронтенд-приложений полезно абсолютно всем разработчикам: это помогает писать более качественный, эффективный и поддерживаемый код.
Во-вторых, тема оптимизаций регулярно всплывает на собеседованиях. Когда вас спрашивают, важно не просто перечислить техники, а уметь рассуждать, приводить примеры и объяснять, почему именно этот подход работает. Нужно чувствовать себя в этом вопросе как рыба в воде.
Чтобы в этом разобраться, мы будем делить оптимизации на разные категории. Это позволит системно подойти к теме, а не сваливать все приёмы в одну кучу:
📌 1. По направлению оптимизации (Что именно оптимизируем?)
→ Загрузка (быстрее доставить код и ассеты пользователю)
→ Выполнение (ускорить работу JS, рендера, анимаций)
→ Рендеринг (уменьшить количество перерисовок, оптимизировать DOM и Virtual DOM)
→ Сеть (сократить количество запросов, уменьшить вес ресурсов)
→ Память (контролировать утечки и тяжелые структуры данных)
→ Пользовательский опыт (UX perf) (перфоманс как часть удобства: LCP, FID, CLS)
📌 2. По подходу (активные / пассивные)
→ Активные — мы прямо пишем код с учетом оптимизаций (мемоизация, lazy-loading, code splitting).
→ Пассивные — оптимизации «под капотом», которые происходят автоматически и не требуют явных действий разработчика. Мы их напрямую не пишем, но должны понимать, что они есть и как работают (батчинг, tree shaking и тд)
📌 3. По уровню применения
→ Фреймворк-специфичные (React: memo, useCallback, Suspense; Vue: computed, watchEffect, и т.д.)
→ Языковые/ванильные (JS: Event delegation, Web Workers; CSS: will-change, contain; HTML: loading="lazy")
→ Инфраструктурные (CDN, кеши, SSR/SSG, bundlers: webpack/vite/rollup)
→ Браузерные и DevTools (Performance tab, Lighthouse, Coverage, профилировщики)
→ Архитектурные и паттерны (Декомпозиция, DRY, SOLID и тд.)
📌 4. По типу эффекта
→ Скорость загрузки (Load performance) — как быстро сайт открывается.
→ Интерактивность (Runtime performance) — как быстро реагирует на действия.
→ Гладкость (Smoothness) — FPS, плавность анимаций, отсутствие "лагов".
→ Устойчивость (Stability) — CLS, предсказуемость интерфейса.
📌 5. По времени применения
→ До разработки — проектирование архитектуры, выбор стека.
→ Во время разработки — правильные паттерны, линтеры, code splitting.
→ После разработки — профилирование, мониторинг перфоманса, оптимизация по данным реальных пользователей (RUM).
Я запускаю цикл постов, в котором на конкретных примерах разберём каждую категорию. Посмотрим, какие инструменты и практики можно применять, обсудим их плюсы и минусы, а также то, как они работают в реальных проектах.
Цель — собрать большую базу знаний из 50+ способов оптимизации фронтенда (а может, получится и больше). В итоге выйдет не просто серия постов, а полноценная карта оптимизаций, которая станет шпаргалкой для собесов и практической помощью в работе.
#оптимизации #react #frontend
Во-первых, знание способов оптимизации фронтенд-приложений полезно абсолютно всем разработчикам: это помогает писать более качественный, эффективный и поддерживаемый код.
Во-вторых, тема оптимизаций регулярно всплывает на собеседованиях. Когда вас спрашивают, важно не просто перечислить техники, а уметь рассуждать, приводить примеры и объяснять, почему именно этот подход работает. Нужно чувствовать себя в этом вопросе как рыба в воде.
Чтобы в этом разобраться, мы будем делить оптимизации на разные категории. Это позволит системно подойти к теме, а не сваливать все приёмы в одну кучу:
📌 1. По направлению оптимизации (Что именно оптимизируем?)
→ Загрузка (быстрее доставить код и ассеты пользователю)
→ Выполнение (ускорить работу JS, рендера, анимаций)
→ Рендеринг (уменьшить количество перерисовок, оптимизировать DOM и Virtual DOM)
→ Сеть (сократить количество запросов, уменьшить вес ресурсов)
→ Память (контролировать утечки и тяжелые структуры данных)
→ Пользовательский опыт (UX perf) (перфоманс как часть удобства: LCP, FID, CLS)
📌 2. По подходу (активные / пассивные)
→ Активные — мы прямо пишем код с учетом оптимизаций (мемоизация, lazy-loading, code splitting).
→ Пассивные — оптимизации «под капотом», которые происходят автоматически и не требуют явных действий разработчика. Мы их напрямую не пишем, но должны понимать, что они есть и как работают (батчинг, tree shaking и тд)
📌 3. По уровню применения
→ Фреймворк-специфичные (React: memo, useCallback, Suspense; Vue: computed, watchEffect, и т.д.)
→ Языковые/ванильные (JS: Event delegation, Web Workers; CSS: will-change, contain; HTML: loading="lazy")
→ Инфраструктурные (CDN, кеши, SSR/SSG, bundlers: webpack/vite/rollup)
→ Браузерные и DevTools (Performance tab, Lighthouse, Coverage, профилировщики)
→ Архитектурные и паттерны (Декомпозиция, DRY, SOLID и тд.)
📌 4. По типу эффекта
→ Скорость загрузки (Load performance) — как быстро сайт открывается.
→ Интерактивность (Runtime performance) — как быстро реагирует на действия.
→ Гладкость (Smoothness) — FPS, плавность анимаций, отсутствие "лагов".
→ Устойчивость (Stability) — CLS, предсказуемость интерфейса.
📌 5. По времени применения
→ До разработки — проектирование архитектуры, выбор стека.
→ Во время разработки — правильные паттерны, линтеры, code splitting.
→ После разработки — профилирование, мониторинг перфоманса, оптимизация по данным реальных пользователей (RUM).
Я запускаю цикл постов, в котором на конкретных примерах разберём каждую категорию. Посмотрим, какие инструменты и практики можно применять, обсудим их плюсы и минусы, а также то, как они работают в реальных проектах.
Цель — собрать большую базу знаний из 50+ способов оптимизации фронтенда (а может, получится и больше). В итоге выйдет не просто серия постов, а полноценная карта оптимизаций, которая станет шпаргалкой для собесов и практической помощью в работе.
#оптимизации #react #frontend
5👍42🔥24❤4🤝2
🧠 Оптимизация памяти во фронтенде
Когда говорят про оптимизацию фронтенда, чаще всего думают о скорости загрузки или анимациях. Но есть ещё одна важная область — память.
- утечки замедляют приложение со временем
- на мобильных устройствах это может приводить к крашам
- стабильность UX напрямую зависит от того, как мы управляем памятью
Теперь давайте поговорим об основных источниках проблем
1️⃣ Замыкания и долгоживущие ссылки
Частая ошибка — сохранять в замыкании большие объекты или DOM-элементы, которые уже не нужны. В итоге GC (сборщик мусора) не может их очистить.
Решение: не тащить в замыкания лишнее, по возможности использовать WeakMap/WeakSet для хранения.
2️⃣ Неудалённые обработчики событий
Навесили addEventListener, но забыли removeEventListener. Опасно при работе с компонентами: удалённый компонент может остаться в памяти из-за висящего обработчика.
Решение: всегда отписываемся.
3️⃣ Таймеры и интервалы
Забытые setInterval или setTimeout продолжают жить, даже если компонент уже размонтирован.
Решение: чистим вручную.
4️⃣ Кэширование «без меры»
Иногда мы храним результаты в памяти (memoization, cache, global store), но не думаем про «старые» данные. В итоге кэш растёт бесконечно. Избыточное кэширование и мемоизация тоже могут быть вредны: на лёгких операциях выгоднее пересчитать заново, чем хранить всё в памяти.
Решение: использовать LRU cache или ограничивать размер хранения.
5️⃣ Глобальные ссылки и синглтоны
Всё, что записано в глобальную область (window, global store), живёт всё время жизни приложения. Если туда положить тяжёлый объект, GC его никогда не удалит.
Решение: хранить только действительно нужное, очищать ссылки вручную, если объект больше не нужен.
6️⃣ DOM-ссылки и оторванные узлы
Если держать ссылку на DOM-элемент, удалённый из документа, он остаётся в памяти. Особенно актуально при ручной работе с document.createElement.
Решение: обнулять ссылки после удаления узлов.
#оптимизации #react #frontend #память
Когда говорят про оптимизацию фронтенда, чаще всего думают о скорости загрузки или анимациях. Но есть ещё одна важная область — память.
- утечки замедляют приложение со временем
- на мобильных устройствах это может приводить к крашам
- стабильность UX напрямую зависит от того, как мы управляем памятью
Теперь давайте поговорим об основных источниках проблем
Частая ошибка — сохранять в замыкании большие объекты или DOM-элементы, которые уже не нужны. В итоге GC (сборщик мусора) не может их очистить.
Решение: не тащить в замыкания лишнее, по возможности использовать WeakMap/WeakSet для хранения.
Навесили addEventListener, но забыли removeEventListener. Опасно при работе с компонентами: удалённый компонент может остаться в памяти из-за висящего обработчика.
Решение: всегда отписываемся.
useEffect(() => {
const handler = () => console.log("scroll");
window.addEventListener("scroll", handler);
return () => {
window.removeEventListener("scroll", handler);
};
}, []);
Забытые setInterval или setTimeout продолжают жить, даже если компонент уже размонтирован.
Решение: чистим вручную.
const id = setInterval(() => doWork(), 1000);
// позже
clearInterval(id);
Иногда мы храним результаты в памяти (memoization, cache, global store), но не думаем про «старые» данные. В итоге кэш растёт бесконечно. Избыточное кэширование и мемоизация тоже могут быть вредны: на лёгких операциях выгоднее пересчитать заново, чем хранить всё в памяти.
Решение: использовать LRU cache или ограничивать размер хранения.
Всё, что записано в глобальную область (window, global store), живёт всё время жизни приложения. Если туда положить тяжёлый объект, GC его никогда не удалит.
Решение: хранить только действительно нужное, очищать ссылки вручную, если объект больше не нужен.
Если держать ссылку на DOM-элемент, удалённый из документа, он остаётся в памяти. Особенно актуально при ручной работе с document.createElement.
Решение: обнулять ссылки после удаления узлов.
#оптимизации #react #frontend #память
Please open Telegram to view this post
VIEW IN TELEGRAM
👍18🔥7❤2
Замыкания в JavaScript позволяют функциям «запоминать» переменные внешнего окружения. Но если в замыкании остаются большие объекты или DOM-элементы, сборщик мусора их не очистит — это приводит к утечкам памяти.
🔹 Проблема: долгоживущие ссылки
Когда замыкание хранит объект, на который больше нет других ссылок, сборщик мусора не может его удалить, потому что замыкание всё ещё держит ссылку.
function createCache() {
const cache = { largeData: new Array(1000000).fill('*') };
return function getCache() {
return cache;
};
}
const getCache = createCache();
// cache занимает память, пока существует getCache
Здесь cache будет жить в памяти пока существует функция getCache, даже если мы больше не используем её данные.
🔹 Решение 1: функция очистки
Можно добавить метод для обнуления ссылок, чтобы GC мог очистить объект:
function createCache() {
let cache = { largeData: new Array(1000000).fill('*') };
function getCache() {
return cache;
}
getCache.cleanup = function () {
cache = null; // память освобождается
};
return getCache;
}
const getCache = createCache();
getCache.cleanup(); // теперь память под cache может быть освобождена
🔹 Решение 2: WeakMap для временных данных
Если нужно хранить состояние объектов, но не держать их в памяти навсегда, используйте WeakMap. Сборщик мусора автоматически очистит объект, когда на него не останется ссылок.
const objectData = new WeakMap();
function attachData(obj) {
objectData.set(obj, { temp: 'data' });
}
let obj = {};
attachData(obj);
obj = null; // объект и данные в WeakMap будут автоматически удалены
🔹 Резюме: как безопасно использовать замыкания
- Не храните в замыканиях лишние объекты.
- Для больших структур или временных данных используйте WeakMap/WeakSet.
- Добавляйте функции очистки (cleanup) для объектов и стейта, которые больше не нужны.
- Проверяйте память через DevTools, чтобы убедиться, что объекты удаляются.
💡 Совет для разработчиков:
Любой state или кеш, который вы храните в замыкании, должен иметь «точку выхода» — иначе ваше приложение постепенно «накопит» память, которая больше не используется.
#оптимизации #react #frontend #память #замыкания
Please open Telegram to view this post
VIEW IN TELEGRAM
👍15🔥10❤4🤝2🫡1
🎯 Менторство до трудоустройства (всё включено, оплата после оффера)
Редко пишу про своё дело, хотя уверен — программа одна из лучших на рынке. Вот почему:
🔹 Авторская программа — все курсы, гайды и материалы написаны мной: от основ HTML до деплоя и архитектуры.
🔹 Реальная стажировка — участие в большом проекте с командой из 60 специалистов (QA, Backend, Analyst, Frontend, iOS, Android, дизайнеры). Работаем по всем процессам как в настоящей компании.
🔹 Максимальная вовлечённость ментора — экзамены, мок-собесы, групповые занятия, личные разборы.
🔹 Трудоустройство под ключ — подготовка резюме, тренировка собесов, сопровождение на этапе оффера и поддержка на испытательном сроке.
🔹 Сообщество 200+ выпускников и студентов — ребята, которые уже прошли этот путь, нашли работу и помогают друг другу.
🔹 Большая база знаний — 200+ записей лекций, собесов, гайдов и полезных материалов.
Если ищешь качественное обучение до трудоустройства — пиши.
Подробнее 👉 https://news.1rj.ru/str/mentor_reactify/150
Редко пишу про своё дело, хотя уверен — программа одна из лучших на рынке. Вот почему:
🔹 Авторская программа — все курсы, гайды и материалы написаны мной: от основ HTML до деплоя и архитектуры.
🔹 Реальная стажировка — участие в большом проекте с командой из 60 специалистов (QA, Backend, Analyst, Frontend, iOS, Android, дизайнеры). Работаем по всем процессам как в настоящей компании.
🔹 Максимальная вовлечённость ментора — экзамены, мок-собесы, групповые занятия, личные разборы.
🔹 Трудоустройство под ключ — подготовка резюме, тренировка собесов, сопровождение на этапе оффера и поддержка на испытательном сроке.
🔹 Сообщество 200+ выпускников и студентов — ребята, которые уже прошли этот путь, нашли работу и помогают друг другу.
🔹 Большая база знаний — 200+ записей лекций, собесов, гайдов и полезных материалов.
Если ищешь качественное обучение до трудоустройства — пиши.
Подробнее 👉 https://news.1rj.ru/str/mentor_reactify/150
🔥18❤6👍5
📚 Кэширование без меры: когда оптимизация становится проблемой
Кэширование и мемоизация звучат как бесплатная оптимизация. Мы думаем: «Раз вычисление можно не делать повторно, значит всегда лучше закэшировать». Но это опасное заблуждение. Если кэшировать без меры, приложение начинает засорять память и работать хуже, а не лучше.
🚨 Как мы засоряем память
Представьте, что вы храните в памяти результаты всех вычислений. Старые данные не удаляются, новые постоянно добавляются. В итоге кэш разрастается до сотен мегабайт. На слабых устройствах это выливается во фризы или даже падение.
Был реальный кейс: разработчик решил «оптимизировать» React-страницу и мемоизировал каждый UI-компонент. На странице их было сотни. В итоге выигрыш оказался мизерным, а память улетела в космос. Сам процесс мемоизации стал дороже, чем пересчёт. Правильнее было бы мемоизировать целую форму или контейнер, где решение о перерисовке действительно экономит ресурсы.
❌ Пример бессмысленной мемоизации
Сложение и так работает за наносекунды. Хранить результаты в памяти бессмысленно — найти их в Map будет дольше.
✅ Пример, где кэш оправдан
Тяжёлые операции, например парсинг или генерация отчётов.
Если вызывать её часто с одними и теми же данными, кэш реально ускоряет работу. Но нужен лимит. Самый популярный вариант — LRU Cache (Least Recently Used).
Теперь кэш не растёт бесконечно. Когда хранилище достигает 100 элементов, старые записи выбрасываются.
🔧 Пример из UI
Вместо того чтобы мемоизировать каждый компонент по отдельности:
Лучше мемоизировать контейнер, внутри которого они все живут:
Так вы экономите не на «каждой кнопке», а на всей форме сразу. Это дешевле и эффективнее.
💡Правило простое: если сомневаешься — лучше пересчитай, чем закэшируй навсегда.
#оптимизации #react #frontend #память #memo #кеширование
Кэширование и мемоизация звучат как бесплатная оптимизация. Мы думаем: «Раз вычисление можно не делать повторно, значит всегда лучше закэшировать». Но это опасное заблуждение. Если кэшировать без меры, приложение начинает засорять память и работать хуже, а не лучше.
🚨 Как мы засоряем память
Представьте, что вы храните в памяти результаты всех вычислений. Старые данные не удаляются, новые постоянно добавляются. В итоге кэш разрастается до сотен мегабайт. На слабых устройствах это выливается во фризы или даже падение.
Был реальный кейс: разработчик решил «оптимизировать» React-страницу и мемоизировал каждый UI-компонент. На странице их было сотни. В итоге выигрыш оказался мизерным, а память улетела в космос. Сам процесс мемоизации стал дороже, чем пересчёт. Правильнее было бы мемоизировать целую форму или контейнер, где решение о перерисовке действительно экономит ресурсы.
❌ Пример бессмысленной мемоизации
function add(a, b) {
return a + b;
}
// кто-то решил мемоизировать даже это
function memoize(fn) {
const cache = new Map();
return function(...args) {
const key = args.join(',');
if (cache.has(key)) return cache.get(key);
const result = fn(...args);
cache.set(key, result);
return result;
};
}
const memoAdd = memoize(add);
console.log(memoAdd(2, 3)); // 5
console.log(memoAdd(2, 3)); // 5 из кэша (но толку?)
Сложение и так работает за наносекунды. Хранить результаты в памяти бессмысленно — найти их в Map будет дольше.
✅ Пример, где кэш оправдан
Тяжёлые операции, например парсинг или генерация отчётов.
function heavyComputation(key) {
// имитация дорогой операции
for (let i = 0; i < 1e7; i++) {}
return `Result for ${key}`;
}
Если вызывать её часто с одними и теми же данными, кэш реально ускоряет работу. Но нужен лимит. Самый популярный вариант — LRU Cache (Least Recently Used).
import LRU from 'lru-cache';
const cache = new LRU({ max: 100 }); // максимум 100 элементов
function getData(key) {
if (cache.has(key)) {
return cache.get(key);
}
const result = heavyComputation(key);
cache.set(key, result);
return result;
}
console.log(getData("a")); // долго
console.log(getData("a")); // быстро, из кэша
Теперь кэш не растёт бесконечно. Когда хранилище достигает 100 элементов, старые записи выбрасываются.
🔧 Пример из UI
Вместо того чтобы мемоизировать каждый компонент по отдельности:
const MemoButton = React.memo(Button);
const MemoInput = React.memo(Input);
const MemoLabel = React.memo(Label);
Лучше мемоизировать контейнер, внутри которого они все живут:
const Form = ({ fields, onSubmit }) => {
return (
<form onSubmit={onSubmit}>
{fields.map((f) => (
<Input key={f.id} {...f} />
))}
<button type="submit">Submit</button>
</form>
);
};
// мемоизируем целиком форму
export default React.memo(Form);
Так вы экономите не на «каждой кнопке», а на всей форме сразу. Это дешевле и эффективнее.
Кэш — это инструмент, а не магическая палочка. Он действительно помогает на тяжёлых вычислениях и часто используемых данных. Но хранить всё подряд — значит засорять память. Лёгкие операции всегда лучше пересчитать заново. А в UI выгоднее мемоизировать крупные контейнеры, а не каждую мелочь.
💡Правило простое: если сомневаешься — лучше пересчитай, чем закэшируй навсегда.
#оптимизации #react #frontend #память #memo #кеширование
🔥22❤4👍2
🚀 UX Performance: как скорость ощущается глазами пользователя
Когда мы говорим "сайт быстрый" — это не про цифры в Lighthouse, а про то, как человек ощущает взаимодействие.
Google выделил три ключевых метрики, которые напрямую влияют на удобство:
LCP — Largest Contentful Paint
INP (ранее FID) — Interaction to Next Paint
CLS — Cumulative Layout Shift
Давай разберём их: что значат, как ломаются и как чинить.
1. 🖼 LCP — "Когда я увидел главное"
Что это: за сколько секунд показывается главный кусок контента (большая картинка, заголовок, постер видео).
Пример плохого UX:
Открываешь страницу новостей, а вместо фото и заголовка долго смотришь на белый экран. Даже если внизу уже подгрузился футер, пользователю кажется, что страница медленная.
Что ломает LCP:
- Ленивая загрузка (loading="lazy") у главной картинки.
- Большой TTFB (медленный сервер/БД).
- Картинка грузится через JS, а не сразу в HTML.
Как починить:
- Ускорить бэкенд + CDN.
- Добавить preload для картинки
- Не ленизируйте главный баннер.
- Используйте современные форматы (AVIF/WebP).
2. ⚡ INP — "Насколько сайт слушается"
Что это: измеряет задержку между действием (клик, ввод) и моментом, когда UI реально отвечает.
Пример плохого UX:
Ты кликаешь на кнопку "Добавить в корзину", а сайт думает 1–2 секунды, и только потом подсвечивает товар. Даже если заказ оформляется успешно — ощущение тормоза.
Что ломает INP:
- Тяжёлый JS-бандл, грузящий CPU.
- Обработчик события делает слишком много (например, ререндер целого списка).
- Длинные задачи > 50мс на главном потоке.
Как починить:
- Разбивайте работу на части (Web Worker, requestIdleCallback).
- Даём быстрый визуальный отклик, а данные подгружаем асинхронно.
- Слушатели прокрутки/тача → всегда passive: true
- Для длинных списков — content-visibility: auto; в CSS.
3. 📏 CLS — "Ничего не прыгает"
Что это: метрика стабильности интерфейса.
Пример плохого UX:
Ты хотел кликнуть "Оплатить", но страница прыгнула из-за подгрузившейся рекламы, и ты ткнул в "Удалить". Боль.
Что ломает CLS:
- Картинки без размеров.
- Баннеры/видео без зарезервированного места.
- Подключение шрифтов без font-display: swap.
Как починить:
- Всегда задаём размеры/aspect-ratio у изображений
- Резервируем контейнеры под рекламу.
- Используем font-display: swap и fallback-шрифты близкие по метрикам.
- Анимации — только через transform/opacity.
#оптимизации #react #frontend #ux #performance
Когда мы говорим "сайт быстрый" — это не про цифры в Lighthouse, а про то, как человек ощущает взаимодействие.
Google выделил три ключевых метрики, которые напрямую влияют на удобство:
LCP — Largest Contentful Paint
INP (ранее FID) — Interaction to Next Paint
CLS — Cumulative Layout Shift
Давай разберём их: что значат, как ломаются и как чинить.
1. 🖼 LCP — "Когда я увидел главное"
Что это: за сколько секунд показывается главный кусок контента (большая картинка, заголовок, постер видео).
👉 Хорошо: ≤ 2.5с, Плохо: > 4с.
Пример плохого UX:
Открываешь страницу новостей, а вместо фото и заголовка долго смотришь на белый экран. Даже если внизу уже подгрузился футер, пользователю кажется, что страница медленная.
Что ломает LCP:
- Ленивая загрузка (loading="lazy") у главной картинки.
- Большой TTFB (медленный сервер/БД).
- Картинка грузится через JS, а не сразу в HTML.
Как починить:
- Ускорить бэкенд + CDN.
- Добавить preload для картинки
- Не ленизируйте главный баннер.
- Используйте современные форматы (AVIF/WebP).
2. ⚡ INP — "Насколько сайт слушается"
Что это: измеряет задержку между действием (клик, ввод) и моментом, когда UI реально отвечает.
👉 Хорошо: ≤ 200мс, Плохо: > 500мс.
Пример плохого UX:
Ты кликаешь на кнопку "Добавить в корзину", а сайт думает 1–2 секунды, и только потом подсвечивает товар. Даже если заказ оформляется успешно — ощущение тормоза.
Что ломает INP:
- Тяжёлый JS-бандл, грузящий CPU.
- Обработчик события делает слишком много (например, ререндер целого списка).
- Длинные задачи > 50мс на главном потоке.
Как починить:
- Разбивайте работу на части (Web Worker, requestIdleCallback).
- Даём быстрый визуальный отклик, а данные подгружаем асинхронно.
- Слушатели прокрутки/тача → всегда passive: true
- Для длинных списков — content-visibility: auto; в CSS.
3. 📏 CLS — "Ничего не прыгает"
Что это: метрика стабильности интерфейса.
👉 Хорошо: ≤ 0.1, Плохо: > 0.25.
Пример плохого UX:
Ты хотел кликнуть "Оплатить", но страница прыгнула из-за подгрузившейся рекламы, и ты ткнул в "Удалить". Боль.
Что ломает CLS:
- Картинки без размеров.
- Баннеры/видео без зарезервированного места.
- Подключение шрифтов без font-display: swap.
Как починить:
- Всегда задаём размеры/aspect-ratio у изображений
- Резервируем контейнеры под рекламу.
- Используем font-display: swap и fallback-шрифты близкие по метрикам.
- Анимации — только через transform/opacity.
#оптимизации #react #frontend #ux #performance
🔥19👍6❤4💯3
Мне нравится IT за возможность бесконечно развиваться. Приятно и круто, когда твоя экспертиза не ограничивается одной областью. Я считаю, что хороший специалист должен мыслить архитектурно, понимать инфраструктуру и не ограничиваться своей узкой частью, а видеть, как работает приложение целиком.
Помню, как писал пост о том, какие технологии я знаю и с чем успел поработать. Также был список того, с чем хотел бы поработать для полного счастья. В этом списке были Kubernetes и умение создавать инфраструктуру продуктов. И вот я это сделал. Я полностью, от начала и до конца, мигрировал всю инфраструктуру на Kubernetes в YeaHub. Теперь это стартап с enterprise-уровнем инфраструктуры в полном фарше.
Я мог нанять DevOps, но решил сделать всё сам — мне нужно было закрыть этот пункт. Все свои шаги я записывал и оформил в пошаговый гайд с объяснениями. Теперь, если у меня появится идея стартапа, я смогу за день развернуть инфраструктуру продукта любой сложности.
Круто, что мои ученики изучают процессы разработки на реальном боевом проекте с таким сложным стеком. Мы изучаем разработку на примере YeaHub, учимся работать в команде и писать качественный код. Сейчас мы создаем приложение на Next.js, чтобы ученики получили ещё и опыт с этим стеком.
А ещё наша команда растёт. YeaHub объединяет менторов, которые хотят, чтобы их ученики умели работать, а не просто проходили собесы. Для меня это тоже прокачка, только уже в сторону менеджера, руководителя. Сейчас у нас 100 человек на проекте YeaHub, из которых большинство — новички. Сложно всё это поддерживать и контролировать. Легко, когда ты Product Owner в команде из 20 опытных специалистов, но сложно, когда ты Product Owner в команде из 100 человек, 90% которых — новички без опыта 😅
В общем, большие планы у нас. Работаем дальше 💪🚀
ПС. На 1 скрине расписание в YeaHub. На 2 скрине scrum-доска. На 3 скрине наша документация
Пост, где я говорю о своих навыках и планах:
https://news.1rj.ru/str/reactify_IT/1404
Описание инфраструктуры YeaHub:
https://news.1rj.ru/str/yeahub/75
Помню, как писал пост о том, какие технологии я знаю и с чем успел поработать. Также был список того, с чем хотел бы поработать для полного счастья. В этом списке были Kubernetes и умение создавать инфраструктуру продуктов. И вот я это сделал. Я полностью, от начала и до конца, мигрировал всю инфраструктуру на Kubernetes в YeaHub. Теперь это стартап с enterprise-уровнем инфраструктуры в полном фарше.
Я мог нанять DevOps, но решил сделать всё сам — мне нужно было закрыть этот пункт. Все свои шаги я записывал и оформил в пошаговый гайд с объяснениями. Теперь, если у меня появится идея стартапа, я смогу за день развернуть инфраструктуру продукта любой сложности.
Круто, что мои ученики изучают процессы разработки на реальном боевом проекте с таким сложным стеком. Мы изучаем разработку на примере YeaHub, учимся работать в команде и писать качественный код. Сейчас мы создаем приложение на Next.js, чтобы ученики получили ещё и опыт с этим стеком.
А ещё наша команда растёт. YeaHub объединяет менторов, которые хотят, чтобы их ученики умели работать, а не просто проходили собесы. Для меня это тоже прокачка, только уже в сторону менеджера, руководителя. Сейчас у нас 100 человек на проекте YeaHub, из которых большинство — новички. Сложно всё это поддерживать и контролировать. Легко, когда ты Product Owner в команде из 20 опытных специалистов, но сложно, когда ты Product Owner в команде из 100 человек, 90% которых — новички без опыта 😅
В общем, большие планы у нас. Работаем дальше 💪
ПС. На 1 скрине расписание в YeaHub. На 2 скрине scrum-доска. На 3 скрине наша документация
Пост, где я говорю о своих навыках и планах:
https://news.1rj.ru/str/reactify_IT/1404
Описание инфраструктуры YeaHub:
https://news.1rj.ru/str/yeahub/75
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9👍6🤝2
Уже собираем интересные вопросы и задачи. Выбран кандидат на прохождение собеса 🤝
Будет пушка 🏆
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥45👍5🤝4
Как думаете, нормально ли назвать канал Куянец Руслан | Reactify и сделать ребрендинг?)
Anonymous Poll
31%
Да, будешь человеком, а не обезличенным каналом
7%
Отпишусь
26%
Все равно
36%
Не меняй, итак классно все
❤8😁4👍2
Готовность 5 минут, скоро съемки 👩💻
Вопросы + Задачи
Новый герой видео - Владимир.
Во вторник (надеюсь) выйдет видео
Вопросы + Задачи
Новый герой видео - Владимир.
Во вторник (надеюсь) выйдет видео
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥23❤4👍4
Это видео представляет собой структурированный разбор ключевых тем React, необходимых для успешного прохождения технического собеседования. Формат сочетает теоретические вопросы с практическим решением задач.
Рекомендую посмотреть это видео, как и предыдущее. Считай, сразу готов к собесам 😎
Видео уже на канале!
Я не оставляю ссылку, так как видео лучше продвигается, если заходить на него напрямую с YouTube. Это помогает улучшить его рейтинг и увеличить шансы на органическое продвижение.
00:00:00 Введение: тема собеседования по React
00:01:44 Что такое React
00:02:43 React как библиотека
00:03:40 SPA-приложения
00:05:25 Компонентный подход
00:06:12 JSX
00:07:11 Состояние и props
00:08:05 Рендеринг списков
00:09:44 Условный рендеринг
00:12:38 Триггеры рендера
00:13:08 Изменение пропсов и перерендер
00:14:25 Роль хуков в React
00:15:41 Основные хуки
00:16:37 Дополнительные хуки
00:18:34 Оптимизация с помощью мемоизации
00:21:02 Жизненные циклы компонентов
00:23:01 Фазы жизненного цикла
00:24:21 Жизненные циклы компонента
00:25:13 Жизненные циклы в функциональных компонентах
00:26:47 Ленивая инициализация состояния
00:27:28 React Children
00:28:27 Обработка данных запроса
00:32:59 Рефакторинг компонента
00:37:38 Оптимизация функции
00:41:07 Работа с запросами и событиями
00:42:37 Сервис «Хаб»
00:43:54 Функциональность тренажёра
00:44:55 Задания на консоль
00:46:23 React Memo
00:51:14 Рефакторинг кода
00:54:24 Обработка событий в React
00:55:54 React Fragment
00:56:15 Проп-дриллинг
00:57:10 Контексты в React
00:57:33 Контролируемые и неконтролируемые входы
00:58:27 Порталы в React
00:59:54 Создание контекста
01:00:54 useEffect vs useLayoutEffect
01:01:32 Использование useRef
01:02:31 Кастомные хуки
01:03:30 Мемоизация и кэширование
01:06:04 Хуки как декораторы
01:07:11 UserUseContext
01:08:04 ImperativeHandle
01:09:24 Поднятие и опускание состояния
01:11:06 Реф и форвард реф
01:13:12 Пьюр компонент
01:14:14 Эра баундере (Error Boundary)
01:15:25 React Router
01:16:18 Render Props
01:18:40 Синтетические события
01:19:40 Управляемый и неуправляемый input
01:22:33 Кастомный хук toggle
01:26:26 Пример с меню
01:27:02 Рендеринг компонентов
01:28:30 Изменение состояния isValid
01:31:52 Оптимизация рендеринга
01:33:10 Рефакторинг кода и оптимизация
01:37:53 StrictMode
01:38:51 Код-сплит и ленивая загрузка
01:40:15 Анлодинг (загрузка при монтировании)
01:41:24 React Lazy и Suspense
01:42:23 Инструменты разработчика React
01:43:23 Оптимизация в React
01:44:49 Дополнительные оптимизации
01:45:40 Мемоизация и код-сплитинг
01:46:37 Батчинг в React
01:48:58 Реактивность в React
01:50:53 Реализация реактивности
01:51:20 Прокси-объекты и паттерны
01:52:15 Эвристики React
01:53:55 Принудительный рендер
01:54:20 Кастомный хук с debounce
01:57:47 Рекурсивное отображение структуры
02:02:46 Компонент «Файл»
02:06:38 Рефакторинг рендеринга файлов
02:08:50 Завершение и React 18
02:09:44 Конкурентный режим и хуки
02:10:14 Управление конкурентным режимом
02:11:00 React 19: новые возможности
02:11:44 Планировщик Fiber
02:12:44 Фазы рендеринга и коммита
02:12:48 Конкурентный режим и приоритеты
02:13:49 Серверные компоненты
02:15:09 Серверный рендеринг и гидрация
02:16:14 Асинхронные обновления в React
02:17:51 Виртуальный и теневой DOM
02:18:42 Типы элементов в React
02:19:11 Принцип единой ответственности
02:20:05 Принцип открытости-закрытости
02:21:42 Принципы SOLID в React
02:22:31 Render-пропсы и слоты
02:23:25 Антипаттерн компоновщика
02:24:22 Изучение паттернов
02:26:18 Подготовка к собеседованиям
#react #собеседования
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤35🔥13👍6
Forwarded from React Frontend | YeaHub
Техническое собеседование. Лето 2025. Вилка: 300к+. Опыт в резюме: 3+ года. Проект:
редизайн сайта Аэрофлота (система бронирования), поддержка старого сайта, дизайн-
система. Были практические задачи (Event Loop, реализация метода groupBy).
Вопросы:
- SEO - для чего нужно, как достигается?
- Как реализовать глубокое копирование обьекта без использования JSON.stringify и
StructuredClone? Какие сложности могут возникнуть?
- Event Loop, что относится к микро и макро задачам?
- Что такое мемоизация, и как её можно использовать для оптимизации производительности?
- Как работает сборщик мусора (garbage collector) в JavaScript? Какие есть стратегии для
управления памятью?
Все 29 вопросов можно посмотреть на нашей платформе
#собес
Please open Telegram to view this post
VIEW IN TELEGRAM
❤12🔥5👍4
Forwarded from YeaHub
🚀 Прокачиваем подготовку к собеседованиям на максимум!
Если ты ещё не заглядывал(а) в👍 «Авось Прорвёмся» — самое время.
Это проект Ани для самостоятельной подготовки, где есть:
- 1000+ записей реальных собеседований с разбором задач и вопросов;
- контакты рекрутеров;
- гайды по резюме, трудоустройству и стратегиям поиска работы.
- задачи и вопросы с собеседований
Мы в YeaHub продолжаем добавлять собеседования из этих чатов — теперь их можно проходить в тренажёре, тренируя ответы на реальные вопросы работодателей.
🎧 Сначала слушай, как проходят настоящие собесы,
💡 потом — разбирай и практикуй те же кейсы в тренажёре.
Направления: iOS, Android, Frontend, Python, Go, Java, C#, QA, Analytics.
👉 Обучайтесь, общайтесь, растите вместе с YeaHub и Авось Прорвемся
Если ты ещё не заглядывал(а) в
Это проект Ани для самостоятельной подготовки, где есть:
- 1000+ записей реальных собеседований с разбором задач и вопросов;
- контакты рекрутеров;
- гайды по резюме, трудоустройству и стратегиям поиска работы.
- задачи и вопросы с собеседований
Мы в YeaHub продолжаем добавлять собеседования из этих чатов — теперь их можно проходить в тренажёре, тренируя ответы на реальные вопросы работодателей.
🎧 Сначала слушай, как проходят настоящие собесы,
💡 потом — разбирай и практикуй те же кейсы в тренажёре.
Направления: iOS, Android, Frontend, Python, Go, Java, C#, QA, Analytics.
👉 Обучайтесь, общайтесь, растите вместе с YeaHub и Авось Прорвемся
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8👍4❤3🤝1