Минусы:

• Долгая первая загрузка (Time to Interactive)Долгая первая загрузка (Time to Interactive)

• Плохо для SEO — боты видят пустой HTML

• Требует хорошего интернета у пользователя

Главная проблема CSR — поисковые боты. Googlebot умеет выполнять JavaScript, но делает это с задержкой и не всегда корректно. Яндекс справляется хуже. В итоге страницы индексируются медленнее и хуже.

Когда CSR — правильный выбор:

•  Дашборды и админки за авторизацией — SEO не нужен

•  SPA с богатой интерактивностью: редакторы, конструкторы, таблицы

•  Внутренние инструменты компании

•  Приложения, где пользователь авторизован и контент персональный

SSR — Server-Side Rendering

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

Плюсы:

• Отличный SEO — боты видят готовый HTML

• Актуальные данные на каждый запрос

Минусы:

• Нагрузка на сервер при каждом запросе

• Медленнее навигация, чем CSR

• Нужен сервер — хостинг дороже

SSR — лучший выбор для SEO-важных страниц. Поисковик получает готовый HTML с контентом, мета-тегами и структурированными данными. Индексация быстрее и надёжнее, чем при CSR.

Когда SSR — правильный выбор:

•  Интернет-магазины — карточки товаров должны индексироваться

•  Новостные сайты и блоги с часто меняющимся контентом

•  Страницы с персонализированным контентом (лента, рекомендации)

•  Любые публичные страницы, где важен SEO и актуальность данных

SSG — Static Site Generation

HTML генерируется один раз — во время сборки проекта. Готовые файлы раздаются с CDN без участия сервера. Это самый быстрый способ доставить контент пользователю.

Плюсы:

• Максимальная скорость

• Отличный SEO

• Дешёвый хостинг — просто файлы

• Высокая надёжность — нет сервера

Минусы:

• Данные могут быть устаревшими

• Долгая сборка при большом числе страниц

• Не подходит для часто меняющихся данных

Когда SSG — правильный выбор:

•  Лендинги и маркетинговые сайты

•  Документация и справочники

•  Блоги и портфолио

•  Сайты, где контент меняется редко или по расписанию

Главное про SEO

SEO — это часто решающий фактор при выборе рендеринга. Вот простое правило:

•  Страница публичная и должна находиться в поиске → SSR или SSG

•  Страница за авторизацией или контент персональный → CSR

•  Контент меняется часто → SSR

•  Контент меняется редко → SSG

Отдельно про Core Web Vitals — Google учитывает LCP, FID и CLS в ранжировании. SSG и SSR дают лучшие показатели, чем CSR по умолчанию, но и CSR можно оптимизировать через lazy loading, code splitting и prefetching.

Хорошая новость: Next.js позволяет миксовать все подходы в одном проекте. Лендинг — SSG, карточка товара — SSR, личный кабинет — CSR. Именно поэтому он стал стандартом индустрии.

Больше материалов про разработку и запуск своих продуктов — в Telegram-канале @deep_in_prod

Часть живёт на сервере: рендеринг, подготовка данных, проверка прав. Часть - в браузере: интерактивность, ввод, мгновенная обратная связь. Часть - в кэше: CDN, query cache, prefetch, service worker. А часть вообще не выглядит как Frontend: она в контракте API, в схеме данных, в дизайн-системе, в правилах релиза.

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

Кнопка не просто вызывает onClick. Она может запускать optimistic update, инвалидировать кэш, отправлять событие аналитики, менять URL, зависеть от прав пользователя, показывать pending-состояние, откатывать UI после ошибки или повторять запрос.

Это уже не «покрасить кнопку». Это проектирование поведения системы в условиях неопределённости.

Компоненты не спасают архитектуру

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

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

Самая частая ошибка - смешать UI-состояние, серверные данные, процесс сохранения, ошибки и производные значения в одном месте. Тогда форма знает про API, кнопка - про бизнес-правила, таблица - про инвалидирование кэша, а страница хранит копию данных из query cache «на всякий случай». Дальше начинаются исключения, быстрые фиксы, дублирование, страх менять экран и фраза «проще переписать».

Redux, Zustand, React Query, SWR, Signals, Context - ни один инструмент не решит за команду главный вопрос: где источник правды.

Если правда на сервере, Frontend должен уважать сервер и не показывать пользователю фантомное состояние. Если правда в пользовательском вводе, нельзя терять его после refetch. Если правда в URL, состояние должно переживать перезагрузку и передаваться ссылкой. Плохая архитектура начинается там, где источник не выбран: сервер говорит одно, кэш помнит другое, форма хранит третье, URL показывает четвёртое, а компонент делает пятое, потому что «так быстрее».

Где должна жить логика

Главный вопрос: кто за что отвечает, и что произойдёт, когда что-то пойдёт не так.

Возьмём простой сценарий - пользователь переименовывает проект.

Слабая версия: Пользователь жмёт «Сохранить». Форма отправляет PATCH, показывает спиннер. Через 800 мс ответ приходит, спиннер исчезает, имя в форме обновляется. Хорошо. Но в сайдбаре имя меняется ещё через секунду, потому что список проектов перезапрашивается отдельно. А в соседней вкладке, открытой час назад, имя вообще старое. Пользователь видит три разных состояния одной сущности и не понимает, какому верить.

Сильная версия: То же действие. Имя в инпуте меняется мгновенно - здесь источник правды сам пользователь. После сабмита UI сразу показывает новое имя во всех местах: в сайдбаре, в заголовке, в хлебных крошках, но визуально помечает его как ещё не сохранённое (например, приглушённым цветом). Если сервер подтвердил, тогда пометка исчезает. Если вернул ошибку - UI откатывается к старому имени и показывает причину человеческим языком: «нет прав» или «имя уже занято». Список проектов в кэше обновляется по одному правилу, а не по совпадению.

Из этого вытекает несколько практических правил.

Источник правды - один на каждое значение. Если правда на сервере, Frontend читает её оттуда и не хранит копий «на всякий случай». Если правда в URL - фильтры, поиск, выбранная вкладка, она переживает перезагрузку и передаётся ссылкой. Если правда во вводе пользователя, её нельзя потерять при refetch. Дублирование источников - это не ускорение, это будущий баг.

Frontend не решает то, за что не отвечает. Он может скрыть кнопку под роль пользователя, но не должен сам определять, разрешено ли действие. Это решает сервер. Frontend может показать бизнес-правило и объяснить его, но само правило живёт в домене, а не в компоненте. Если правило про деньги, права или статусы случайно осело в JSX, его рано или поздно нарушат.

Кэш это договор, а не оптимизация. Когда мы держим данные в query cache, мы говорим пользователю: «верь этому, пока я не скажу обратное». У договора должны быть условия: сколько данным можно верить, кто их обновляет, когда инвалидировать, что показывать, если они устарели. Быстрый интерфейс не должен быстро врать.

Производительность и ошибки

Производительность часто сводят к Lighthouse, Core Web Vitals и размеру бандла. Метрики полезны, но не объясняют главного.

Пользователь не обязан ждать. Медленный Frontend почти всегда - сумма решений: слишком много клиентского кода, тяжёлая дизайн-система, водопад запросов, дорогой рендер, небрежная гидратация. Это нельзя починить в конце. Это проектируется в начале: что отдать с сервера, что загрузить заранее, что отложить, какой экран остаётся полезным при частичном отказе.

С ошибками то же самое. В продакшене сеть медленная, API отвечает не сразу, сессия истекает, пользователь кликает быстро, данные меняются в другой вкладке. Ошибка валидации должна жить рядом с формой. Ошибка прав - приходить от сервера. Ошибка сети - объяснять, можно ли повторить действие. Ошибка бизнес-правила должно быть написана по-человечески: не «400 Bad Request», а «Нельзя удалить проект, пока в нём есть активные задачи».

Надёжность Frontend - это не отсутствие ошибок в консоли. Это способность интерфейса вести себя предсказуемо, когда мир вокруг неидеален.

Что отличает сильного Frontend-инженера

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

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

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

Заключение

Frontend больше не тонкая оболочка вокруг API. Он стал местом, где техническая архитектура встречается с человеческим ожиданием. Пользователь не видит server components, query cache, hydration и source of truth. Он видит другое: страница открылась или нет, действие сохранилось или потерялось, ошибка объяснена или спрятана, интерфейс помогает или заставляет сомневаться.

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

Этой вводной статьёй я хотел поделиться мыслями и начать этот блог. Всем спокойных релизов и поменьше багов в продакшене ❤

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

Почему гугл-то не тормозит при вводе в поиск буковок? У вас поиск серьёзнее гугла? Уметь посылать запросы в сеть в другом потоке/воркере, никогда не блокируя пользовательские потоки - это ваши патлатые сеньёры-архитекты-техлиды так не не научились? А чем они заняты? На работе по созвонам весь день уши дрочат, а дома в сраные компутерные игры наяривают, работать некогда? Может им перестать платить 550 тыр в месяц, ведь на эти деньги они игровые видяхи домой покупают и потом деградируют в танчиках до 5 утра и приходят на работку не выспавшись и отупев. Тут же поделка уровня джуна за 60 тыр в месяц.

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

Я уже молчу про ту шайку гомодрилов, которые умудрились сделать неработоспособным выбор типа сортировки объявлений до тех пор, пока не подгрузится 100500 каких-то JS-оперденей. И даже кеширование не помогает, то есть как будто ты каждый раз жмёшь CTRL + F5, хотя это был просто F5. Мне кажется, на собесе в гугл ваших инженеров, задействованных в проектировании и реализайии фронтенда бы просто из двустволки застрелили и даже хоронить бы не стали, в реку выкинули тела. Ваши JS-кнопкодавы - яркий пример мальчика, совравшего маме в ответе на вопрос "а тебе точно для учёбы" при покупке компутера. Явно без уважения ваши ребята относятся к достижениям в микроэлектронике.

Выбирайте с точки зрения шапки, сайдбара и постов

👍 - 1-ое изображение

👎 - 2-ое изображение

🔥 - 3-ие изображение

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

Затем я так же через знакомого решил откликнуться на вакансию в один популярный финансовый сервис. И тут уже появилась капля надежды, так как мне напрямую написала HR, и сразу же предложила созвониться. На тот момент я находился в соседнем городе, так как не ожидал, что мне вообще хоть кто-то напишет. Мне предложили созвон на следующий день, и я согласился, чтобы точно не упустить этот шанс. К счастью я успел приехать домой за час до созвона, быстренько подготовиться, и вот наступил долгожданный момент. Первый же вопрос: "будет ли вам удобно ездить до станции метро ...". Я ничего не понимаю, так как живу в городе без метро, и тут же сообщаю об этом. После пары секунд неловкой тишины добавляю, что мой нынешний город проживания указан в резюме. В ответ HR извинилась, и сказала, что изначально город не увидела. По итогу разговор завершился за 3 минуты. Если офис обязателен, почему бы сразу не проверить указанный в резюме город... "Все ж мы люди", так что ладно, человеческий фактор никто не отменял, но осадок остался.

После этого я увидел вакансию в компанию, у которой офис на Пхукете. Тут я вспомнил, что и там был один дружочек-пирожочек. Пишу ему, он говорит, что рефералки у них нет, и "просто упомяни меня при отклике". Я благодарю за помощь, и отправляю отклик. Через пару дней на почту прилетает отказ. Если честно, то тогда я расстроился, так как подходил как минимум на 80%, и в целом хотел туда попасть. После этого я решил на всякий продублировать отклик им на почту, но ответа не последовало. Конкуренция сейчас высокая, так что причину тишины понять можно, но и эта вакансия потом была открыта почти месяц. Зато эта ситуация научила меня проще относиться к откликам, и не надеяться заранее. С одной стороны это прописная истина, но в то же время в моменте иметь мечту тоже приятно.

И последняя попытка на данный момент попасть куда-то через кого-то была в убыточную компанию любителей синего цвета. У них я замечал достаточно часто вакансии на фронта, поэтому подумал, что вероятно хотя бы на 1 из 10 можно будет попасть. Попыток было две с промежутком в 4 месяца, и результат один и тот же. По вакансиям, где я точно не подходил отказ приходил почти сразу, но на них я и не надеялся. А вот с другими ситуация была интереснее, спустя неделю-две на почту прилетало письмо о том, что мы уже нашли другого кандидата. Недавно пришло такое письмо спустя две недели после отклика. Такая картина может показаться удручающей, но в то же время если откликаться просто через их сайт - в ответ тишина. Так что так хоть приходит отказ, а не бесконечная тишина. Кстати недавно смог найти прямой контакт HR, и решил ей написать напрямую. Это тоже не особо рабочий способ, моё сообщение просто не прочитали.

Кстати об одном красно-белом сайте. Его я тоже использовал. Из ±50 откликов 3 были в статусе "собеседование", что наверное может показаться хорошим результатом на данный момент, но реальность чуть иначе, чем хотелось бы.

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

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