[{"data":1,"prerenderedAt":1724},["ShallowReactive",2],{"blog-post-ru-kak-uskorit-sajt":3,"blog-list-ru":1689},{"id":4,"title":5,"body":6,"category":1635,"cover":1636,"date":1637,"description":12,"excerpt":1638,"extension":1639,"faq":1640,"featured":1680,"meta":1681,"metaDescription":1682,"metaTitle":1683,"navigation":855,"path":1684,"readingMinutes":1685,"seo":1686,"slug":1687,"stem":1687,"updated":1637,"__hash__":1688},"blogRu/kak-uskorit-sajt.md","Как ускорить сайт: от замера в DevTools до архитектуры",{"type":7,"value":8,"toc":1604},"minimark",[9,13,16,21,24,130,144,148,151,154,161,164,167,170,174,177,180,186,192,198,204,225,228,232,235,240,243,246,250,253,259,265,271,275,278,281,287,293,296,300,303,306,309,393,396,400,403,407,410,477,481,484,514,518,560,564,567,570,573,603,607,610,740,750,754,780,788,792,795,812,829,833,836,839,844,936,939,943,946,949,952,958,964,1028,1042,1056,1069,1080,1097,1106,1109,1113,1116,1119,1122,1133,1144,1150,1158,1161,1165,1168,1171,1177,1183,1189,1268,1271,1278,1282,1285,1288,1291,1294,1298,1301,1304,1310,1316,1322,1328,1334,1337,1340,1343,1362,1365,1369,1372,1375,1391,1407,1410,1413,1416,1419,1422,1425,1428,1432,1435,1444,1450,1463,1469,1478,1484,1490,1496,1499,1503,1506,1509,1515,1521,1527,1530,1534,1537,1542,1556,1561,1581,1593,1600],[10,11,12],"p",{},"Скорость сайта это не про «красиво в отчёте», это про деньги и позиции. Медленная страница теряет посетителя раньше, чем он увидел твой товар, а поисковик тихо опускает её ниже. При этом почти все советы, как ускорить сайт, из топа выдачи либо устарели, либо сводятся к «поставь плагин кеширования и не думай». Плагин симптом приглушит, причину не тронет. В этой статье мы сделаем иначе: сначала руками найдём конкретный тормоз в DevTools, потом починим базу, а дальше разберём, как со скоростью работают на масштабе, где живут тысячи страниц и три языка. Без магии, с реальными числами.",[10,14,15],{},"Меня зовут Евгений Волков, я fullstack-разработчик, и скорость для меня не хобби, а часть работы над каждым проектом. Я разгонял и лендинги, и e-commerce, и международную платформу на 1000+ страниц. Поэтому пишу не «10 универсальных советов», а показываю рабочий процесс инженера: как замерить, как прочитать цифры, где обычно спрятан тормоз и чем его чинят. Числа в статье настоящие, из моей практики и из документации. Где данных нет, я так и говорю.",[17,18,20],"h2",{"id":19},"кратко-как-ускорить-сайт-по-шагам","Кратко: как ускорить сайт по шагам",[10,22,23],{},"Если нужен план сразу, вот он одним взглядом. Ниже каждый пункт раскрыт подробно, с воркфлоу и числами.",[25,26,27,43],"table",{},[28,29,30],"thead",{},[31,32,33,37,40],"tr",{},[34,35,36],"th",{},"Шаг",[34,38,39],{},"Что делаешь",[34,41,42],{},"Что чинит",[44,45,46,61,74,87,104,117],"tbody",{},[31,47,48,55,58],{},[49,50,51],"td",{},[52,53,54],"strong",{},"1. Замерь",[49,56,57],{},"PageSpeed + Lighthouse + Яндекс.Метрика (полевые данные)",[49,59,60],{},"Понимаешь, где реально тормоз",[31,62,63,68,71],{},[49,64,65],{},[52,66,67],{},"2. Найди руками",[49,69,70],{},"DevTools: Performance, Network, Coverage",[49,72,73],{},"Конкретную причину, а не догадку",[31,75,76,81,84],{},[49,77,78],{},[52,79,80],{},"3. Почини базу",[49,82,83],{},"Картинки WebP/AVIF, шрифты, кеш, Brotli, чистка скриптов",[49,85,86],{},"70% типовых проблем",[31,88,89,94,101],{},[49,90,91],{},[52,92,93],{},"4. Разбери бандл",[49,95,96,97],{},"Code splitting, ленивые чанки, tree-shaking, ",[98,99,100],"code",{},"nuxt analyze",[49,102,103],{},"Тяжёлый первый экран, плохой INP",[31,105,106,111,114],{},[49,107,108],{},[52,109,110],{},"5. Выбери архитектуру",[49,112,113],{},"SSR / SSG / ISR под задачу, аккуратная гидрация",[49,115,116],{},"Потолок скорости и TTFB",[31,118,119,124,127],{},[49,120,121],{},[52,122,123],{},"6. Закрепи",[49,125,126],{},"Мониторинг реальных пользователей, ловля регрессий",[49,128,129],{},"Чтобы не замедлился обратно",[10,131,132,133,136,137,136,140,143],{},"Нормы, к которым идём: ",[52,134,135],{},"LCP ≤ 2,5 с",", ",[52,138,139],{},"INP ≤ 200 мс",[52,141,142],{},"CLS ≤ 0,1",". Это целевые пороги Core Web Vitals, дальше объясню каждую метрику и как её читать.",[17,145,147],{"id":146},"почему-скорость-решает-деньги-и-позиции","Почему скорость решает деньги и позиции",[10,149,150],{},"Начнём с честного «зачем», чтобы дальше было ясно, ради чего мы возимся с миллисекундами.",[10,152,153],{},"Скорость бьёт по двум фронтам сразу. Первый это конверсия. Человек не ждёт. Каждая лишняя секунда загрузки это часть посетителей, которые закрыли вкладку, не дождавшись. На медленном сайте растёт показатель отказов, падает глубина просмотра, дешевеет трафик, за который ты уже заплатил. Тут скорость это прямые деньги, без всякого SEO.",[10,155,156,157,160],{},"Второй фронт это ранжирование. И Google, и Яндекс учитывают скорость страницы как один из факторов. Google оформил это в ",[52,158,159],{},"Core Web Vitals",", три метрики, которые описывают реальный опыт пользователя. Яндекс тоже смотрит на скорость и время до загрузки. Оговорюсь честно: скорость это не главный рычаг ранжирования. Контент, ссылки и соответствие интенту весят больше. Но при прочих равных быстрый сайт обгоняет медленный, а на конкурентной тематике «прочие равные» встречаются постоянно.",[10,162,163],{},"Есть и третий, менее очевидный слой. Быстрый сайт легче краулить. Поисковый бот тратит на него меньше краулингового бюджета, глубже заходит, чаще переобходит. На большом сайте это напрямую влияет на то, как быстро новые страницы попадают в индекс. Про это забывают, а зря.",[10,165,166],{},"Отдельно проговорю про мобильных. Больше половины трафика в рунете это телефоны, и часто не флагманы, а бюджетные Android на нестабильной сети в метро или за городом. То, что на твоём рабочем ноутбуке грузится за секунду, на таком устройстве может тянуться пять. А поисковики давно оценивают скорость именно по мобильной версии, не по десктопной. Так что когда я говорю «сайт медленный», я имею в виду не свой Mac с быстрым интернетом, а реального человека с телефоном в руке и одной палкой сети. На него и ориентируемся, потому что это и есть твой покупатель.",[10,168,169],{},"Вывод простой. Скорость это не косметика ради зелёной цифры в PageSpeed. Это выручка, позиции и индексация одним пакетом. Поэтому её стоит не «подкрутить разок», а держать под контролем. Как именно, разбираем дальше.",[17,171,173],{"id":172},"как-измерить-скорость-и-как-читать-цифры","Как измерить скорость и как читать цифры",[10,175,176],{},"Первое правило оптимизации: не оптимизируй вслепую. Пока не замерил, любые правки это гадание на кофейной гуще. Сначала цифры, потом руки.",[10,178,179],{},"Инструментов много, но реально нужны четыре.",[10,181,182,185],{},[52,183,184],{},"PageSpeed Insights."," Веб-сервис Google. Вбиваешь URL, получаешь и лабораторный прогон (Lighthouse), и, если у сайта есть трафик, полевые данные реальных пользователей (CrUX). Бесплатно, быстро, для первого взгляда идеально.",[10,187,188,191],{},[52,189,190],{},"Lighthouse в DevTools."," Тот же движок, но прямо в Chrome. Открываешь DevTools, вкладку Lighthouse, жмёшь «Analyze». Удобно гонять локально во время работы, не выкладывая сайт наружу.",[10,193,194,197],{},[52,195,196],{},"Яндекс.Метрика и Яндекс.Вебмастер."," Вот это конкуренты в топе почему-то забывают, а для российского трафика они важнее западных инструментов. Метрика показывает реальные Core Web Vitals твоих живых посетителей, а Вебмастер отдельно следит за скоростью в контексте индексации Яндексом. Если аудитория в России, смотреть надо сюда.",[10,199,200,203],{},[52,201,202],{},"Chrome DevTools (Performance, Network, Coverage)."," Это уже не «оценка», а расследование. Тут ловят конкретный тормоз руками. Про этот воркфлоу будет отдельный раздел ниже, он и есть главное отличие инженерного подхода от «поставил плагин».",[10,205,206,207,136,209,211,212,214,215,218,219,224],{},"Про цифры коротко, потому что дальше вся статья про починку. Нормы Core Web Vitals на 2026 год такие: ",[52,208,135],{},[52,210,139],{}," (старую FID Google убрал в марте 2024, если сервис всё ещё меряет FID, он отстал), ",[52,213,142],{},". Отдельно TTFB, ответ сервера, в идеале ",[52,216,217],{},"≤ 0,8 с",". И одна оговорка, на которой все спотыкаются: лабораторный прогон (Lighthouse, PageSpeed) и полевые данные живых пользователей (CrUX, Яндекс.Метрика) часто расходятся, и верить надо полевым, тому что видят люди. Как читать каждую метрику, чем мерить и что из инструментов работает в России, я подробно разобрал в отдельной статье, ",[220,221,223],"a",{"href":222},"/blog/kak-proverit-skorost-sajta","как проверить скорость сайта",". Тут дальше про то, как эти цифры чинить.",[10,226,227],{},"Мой рабочий порядок такой. Сначала PageSpeed для общей картины и полевых данных. Потом Lighthouse локально, чтобы быстро крутить гипотезы. И DevTools, когда надо докопаться до конкретной секунды. К нему и переходим.",[17,229,231],{"id":230},"devtools-как-найти-тормоз-руками","DevTools: как найти тормоз руками",[10,233,234],{},"Вот раздел, ради которого стоило писать статью. Ни один гайд из топа не показывает реальный воркфлоу разбора в DevTools, все ограничиваются «прогоните Lighthouse». А Lighthouse только говорит, что болит. Где именно болит, показывают три другие панели. Разберём по шагам, как это делаю я.",[236,237,239],"h3",{"id":238},"шаг-1-lighthouse-как-отправная-точка","Шаг 1. Lighthouse как отправная точка",[10,241,242],{},"Открой сайт в Chrome, зайди в DevTools (F12), вкладка Lighthouse. Выбери Mobile, категорию Performance, жми Analyze. Через полминуты получишь оценку и список проблем: «Reduce unused JavaScript», «Properly size images», «Eliminate render-blocking resources». Это не приговор, это карта. Lighthouse говорит куда копать, но не копает за тебя.",[10,244,245],{},"Записал главные жалобы. Дальше идём проверять их руками, потому что синтетика ошибается, а панели показывают правду по твоему конкретному сайту.",[236,247,249],{"id":248},"шаг-2-network-waterfall-кто-блокирует-первый-экран","Шаг 2. Network waterfall: кто блокирует первый экран",[10,251,252],{},"Вкладка Network. Поставь галку Disable cache, выбери троттлинг Fast 3G или Slow 4G (чтобы увидеть картину как у пользователя с телефоном), перезагрузи страницу. Получишь водопад запросов. Смотрим на три вещи.",[10,254,255,258],{},[52,256,257],{},"TTFB."," Наведи на первый запрос документа, посмотри Timing. Если «Waiting for server response» большой, тормозит сервер, а не фронтенд, и картинки тут ни при чём. Это сигнал копать в бэкенд, кеш и хостинг.",[10,260,261,264],{},[52,262,263],{},"Render-blocking ресурсы."," Ищи CSS и синхронный JS в самом начале водопада, до первой отрисовки. Каждый такой файл браузер обязан скачать и обработать, прежде чем показать страницу. Это главные враги LCP. Их либо откладывают (defer/async), либо инлайнят критическую часть.",[10,266,267,270],{},[52,268,269],{},"Порядок и вес."," Видно, что грузится первым, что самое тяжёлое, что тянется с чужих доменов. Часто именно здесь ловишь неожиданное: шрифт на 300 КБ, аналитику, которая блокирует рендер, картинку-баннер в полном разрешении.",[236,272,274],{"id":273},"шаг-3-performance-где-горит-main-thread","Шаг 3. Performance: где горит main-thread",[10,276,277],{},"Самая мощная панель и самая недооценённая. Вкладка Performance, включи троттлинг CPU (4x или 6x slowdown, эмуляция слабого телефона), жми запись, перезагрузи, останови через пару секунд после загрузки.",[10,279,280],{},"Ты получишь флейм-график (flame chart) активности главного потока. Что искать:",[10,282,283,286],{},[52,284,285],{},"Long tasks."," Любая задача длиннее 50 мс помечается красным уголком. Это куски JavaScript, которые надолго занимают main-thread, и именно из-за них страница «залипает» и не реагирует на клики. Long tasks это главная причина плохого INP. Кликаешь на задачу и видишь, какая функция или скрипт её породил.",[10,288,289,292],{},[52,290,291],{},"Main-thread activity."," Смотришь, чем поток занят между загрузкой и интерактивом. Если там сплошной жёлтый (scripting), значит браузер давится JavaScript вместо того, чтобы рисовать страницу. Часто это гидрация тяжёлого SPA или сторонний скрипт.",[10,294,295],{},"Однажды я так ловил тормоз, который Lighthouse показывал как «высокий Total Blocking Time», но не говорил причину. В Performance оказалось, что виджет чата инициализировал сам себя синхронно на старте и держал main-thread почти секунду. Убрали синхронную инициализацию, отложили загрузку до взаимодействия, и INP вернулся в зелёную зону. Без Performance-панели это была бы неделя гаданий.",[236,297,299],{"id":298},"шаг-4-coverage-сколько-кода-вообще-не-используется","Шаг 4. Coverage: сколько кода вообще не используется",[10,301,302],{},"Открой командную палитру (Cmd/Ctrl+Shift+P), набери Coverage, запусти. Перезагрузи страницу. Панель покажет по каждому CSS и JS файлу, какой процент кода реально выполнился, а какой просто скачался и лёг мёртвым грузом.",[10,304,305],{},"Часто видишь красное: 70–80% CSS фреймворка не используется на этой странице, половина JS-бандла не нужна для первого экрана. Это прямое указание, где резать. Неиспользуемый CSS чистят (PurgeCSS, правильная сборка Tailwind), лишний JS выносят в ленивые чанки. Про это подробно в разделе про бандл.",[10,307,308],{},"Сведу воркфлоу в таблицу, чтобы было под рукой как шпаргалка.",[25,310,311,327],{},[28,312,313],{},[31,314,315,318,321,324],{},[34,316,317],{},"Панель",[34,319,320],{},"Что ищем",[34,322,323],{},"На какую метрику влияет",[34,325,326],{},"Чем чиним",[44,328,329,345,361,377],{},[31,330,331,336,339,342],{},[49,332,333],{},[52,334,335],{},"Lighthouse",[49,337,338],{},"Список общих жалоб, карта проблем",[49,340,341],{},"Общая оценка",[49,343,344],{},"Отправная точка, не лечение",[31,346,347,352,355,358],{},[49,348,349],{},[52,350,351],{},"Network",[49,353,354],{},"TTFB, render-blocking, тяжёлые запросы",[49,356,357],{},"LCP, TTFB",[49,359,360],{},"defer/async, кеш, сжатие картинок",[31,362,363,368,371,374],{},[49,364,365],{},[52,366,367],{},"Performance",[49,369,370],{},"Long tasks, занятость main-thread",[49,372,373],{},"INP, TBT",[49,375,376],{},"Разбить/отложить JS, убрать тяжёлые скрипты",[31,378,379,384,387,390],{},[49,380,381],{},[52,382,383],{},"Coverage",[49,385,386],{},"Неиспользуемый CSS/JS",[49,388,389],{},"LCP, размер бандла",[49,391,392],{},"Чистка, ленивые чанки, tree-shaking",[10,394,395],{},"Вот и весь воркфлоу: Lighthouse сказал где болит, Network показал что блокирует, Performance показал где горит поток, Coverage показал что выкинуть. Четыре панели, ноль плагинов, полная картина. Замечу главное отличие от типового совета «прогони PageSpeed». PageSpeed выдаёт балл и общие рекомендации, но он не покажет, что именно на твоём сайте виджет чата душит main-thread, а шрифт грузится с чужого домена с задержкой в 400 мс. Это видно только руками, в этих панелях. Поэтому инженер начинает не с балла, а с расследования. Дальше чиним найденное.",[17,397,399],{"id":398},"базовая-оптимизация-которая-реально-работает","Базовая оптимизация, которая реально работает",[10,401,402],{},"Теперь конкретные фиксы. Это база, которую можно и нужно сделать почти на любом сайте, и она закрывает процентов семьдесят проблем. Пройдусь по блокам и по ходу поправлю советы, которые в топе выдачи устарели.",[236,404,406],{"id":405},"картинки","Картинки",[10,408,409],{},"Картинки почти всегда самый тяжёлый вес страницы. С них и начинаем.",[411,412,413,428,442,452,458,464],"ul",{},[414,415,416,419,420,423,424,427],"li",{},[52,417,418],{},"Современные форматы."," Переводи JPEG и PNG в ",[52,421,422],{},"WebP"," или ",[52,425,426],{},"AVIF",". WebP легче JPEG примерно в полтора-два раза при том же качестве, AVIF ещё легче. Это самый дешёвый и самый заметный выигрыш.",[414,429,430,433,434,437,438,441],{},[52,431,432],{},"Отдавай под размер экрана."," Используй ",[98,435,436],{},"srcset"," и ",[98,439,440],{},"sizes",", чтобы телефон грузил маленькую версию, а не десктопную картинку шириной 2000 пикселей, ужатую в CSS до 400.",[414,443,444,447,448,451],{},[52,445,446],{},"Ленивая загрузка."," Всё, что ниже первого экрана, помечай ",[98,449,450],{},"loading=\"lazy\"",". Браузер не будет тянуть эти картинки, пока пользователь до них не докрутит.",[414,453,454,457],{},[52,455,456],{},"Задавай размеры."," Ширина и высота (или aspect-ratio) в атрибутах спасают от прыжков вёрстки и держат CLS в норме.",[414,459,460,463],{},[52,461,462],{},"Сжимай заранее."," Не надейся, что «браузер разберётся». Прогоняй через sharp, squoosh или imagemin на этапе сборки.",[414,465,466,469,470,473,474,476],{},[52,467,468],{},"Приоритет для LCP-картинки."," Главную картинку первого экрана помечай ",[98,471,472],{},"fetchpriority=\"high\""," и НЕ вешай на неё ",[98,475,450],{},". Частая ошибка: ленят вообще все картинки подряд, включая ту, что и есть LCP-элемент, и своими руками замедляют главный показатель. Лениво грузим то, что ниже сгиба, а не то, что человек видит первым.",[236,478,480],{"id":479},"шрифты","Шрифты",[10,482,483],{},"Шрифты недооценивают, а они блокируют отрисовку текста и ломают LCP с CLS.",[411,485,486,492,502,508],{},[414,487,488,491],{},[52,489,490],{},"font-display: swap."," Чтобы текст показался сразу шрифтом по умолчанию, а кастомный подхватился, когда догрузится. Без этого пользователь смотрит на пустое место (FOIT).",[414,493,494,497,498,501],{},[52,495,496],{},"preload ключевого шрифта."," ",[98,499,500],{},"\u003Clink rel=\"preload\" as=\"font\">"," для того начертания, что нужно на первом экране. Браузер начнёт тянуть его раньше.",[414,503,504,507],{},[52,505,506],{},"Сабсеттинг."," Оставь в файле шрифта только те символы, что реально нужны (кириллица + латиница), выкинь остальные. Вес падает в разы.",[414,509,510,513],{},[52,511,512],{},"Локальный хостинг."," Свои шрифты быстрее и надёжнее внешних CDN, плюс без сторонних запросов.",[236,515,517],{"id":516},"код-css-и-javascript","Код: CSS и JavaScript",[411,519,520,526,548,554],{},[414,521,522,525],{},[52,523,524],{},"Минификация."," CSS и JS должны идти в прод сжатыми, без пробелов и комментариев. Любой нормальный сборщик делает это сам, проверь, что оно включено.",[414,527,528,531,532,535,536,539,540,543,544,547],{},[52,529,530],{},"defer и async."," Скрипты, не нужные для первой отрисовки, помечай ",[98,533,534],{},"defer"," (выполнится после парсинга) или ",[98,537,538],{},"async"," (выполнится как загрузится). Синхронный ",[98,541,542],{},"\u003Cscript>"," в ",[98,545,546],{},"\u003Chead>"," без этих атрибутов блокирует рендер.",[414,549,550,553],{},[52,551,552],{},"Critical CSS."," Стили первого экрана инлайнят прямо в HTML, остальное грузят асинхронно. Так первый экран рисуется без ожидания внешнего CSS.",[414,555,556,559],{},[52,557,558],{},"Мёртвый код."," Тот самый неиспользуемый CSS/JS из Coverage. Чистим.",[236,561,563],{"id":562},"сторонние-скрипты-тихий-убийца-скорости","Сторонние скрипты: тихий убийца скорости",[10,565,566],{},"Про этот пункт молчат почти все, а он в моей практике один из самых частых виновников плохого INP. Речь про чужой JavaScript: аналитика, пиксели рекламных кабинетов, виджет чата, карта, кнопки соцсетей, онлайн-консультант. Каждый такой скрипт это отдельный запрос на чужой домен и, что хуже, чужой код, который крутится в твоём main-thread и которым ты не управляешь.",[10,568,569],{},"Проблема в том, что маркетолог добавляет их «на пять минут», а платит за это скорость. Три пикселя, чат и тепловая карта легко съедают секунду отзывчивости, и в Performance-панели ты увидишь их как долгие задачи с чужих доменов.",[10,571,572],{},"Что с этим делать:",[411,574,575,581,591,597],{},[414,576,577,580],{},[52,578,579],{},"Ревизия."," Открой, что реально стоит на сайте, и выкини то, чем никто не пользуется. Часто половина скриптов это забытое наследие прошлых кампаний.",[414,582,583,586,587,590],{},[52,584,585],{},"Отложенная загрузка."," Чат и второстепенную аналитику грузи не на старте, а по взаимодействию или через ",[98,588,589],{},"requestIdleCallback",", когда браузер освободился. Пользователю чат не нужен в первую секунду.",[414,592,593,596],{},[52,594,595],{},"Атрибуты async/defer"," на всех сторонних тегах, чтобы они не блокировали рендер.",[414,598,599,602],{},[52,600,601],{},"Считай цену."," Каждый новый скрипт это осознанное решение «эта секунда отзывчивости стоит этих данных?», а не рефлекс «добавим на всякий».",[236,604,606],{"id":605},"подсказки-браузеру-preconnect-dns-prefetch-preload","Подсказки браузеру: preconnect, dns-prefetch, preload",[10,608,609],{},"Дешёвый приём, который недооценивают. Браузеру можно заранее сказать, куда он скоро пойдёт, и он начнёт готовиться, не дожидаясь, пока встретит ссылку в коде.",[611,612,617],"pre",{"className":613,"code":614,"language":615,"meta":616,"style":616},"language-html shiki shiki-themes github-light github-dark","\u003C!-- Заранее устанавливаем соединение с доменом, откуда придут шрифты/API -->\n\u003Clink rel=\"preconnect\" href=\"https://fonts.example.com\" crossorigin>\n\u003C!-- Только резолвим DNS, полегче preconnect -->\n\u003Clink rel=\"dns-prefetch\" href=\"https://analytics.example.com\">\n\u003C!-- Тянем критичный ресурс первого экрана раньше -->\n\u003Clink rel=\"preload\" as=\"font\" href=\"/fonts/main.woff2\" type=\"font/woff2\" crossorigin>\n","html","",[98,618,619,628,664,670,693,699],{"__ignoreMap":616},[620,621,624],"span",{"class":622,"line":623},"line",1,[620,625,627],{"class":626},"sJ8bj","\u003C!-- Заранее устанавливаем соединение с доменом, откуда придут шрифты/API -->\n",[620,629,631,635,639,643,646,650,653,655,658,661],{"class":622,"line":630},2,[620,632,634],{"class":633},"sVt8B","\u003C",[620,636,638],{"class":637},"s9eBZ","link",[620,640,642],{"class":641},"sScJk"," rel",[620,644,645],{"class":633},"=",[620,647,649],{"class":648},"sZZnC","\"preconnect\"",[620,651,652],{"class":641}," href",[620,654,645],{"class":633},[620,656,657],{"class":648},"\"https://fonts.example.com\"",[620,659,660],{"class":641}," crossorigin",[620,662,663],{"class":633},">\n",[620,665,667],{"class":622,"line":666},3,[620,668,669],{"class":626},"\u003C!-- Только резолвим DNS, полегче preconnect -->\n",[620,671,673,675,677,679,681,684,686,688,691],{"class":622,"line":672},4,[620,674,634],{"class":633},[620,676,638],{"class":637},[620,678,642],{"class":641},[620,680,645],{"class":633},[620,682,683],{"class":648},"\"dns-prefetch\"",[620,685,652],{"class":641},[620,687,645],{"class":633},[620,689,690],{"class":648},"\"https://analytics.example.com\"",[620,692,663],{"class":633},[620,694,696],{"class":622,"line":695},5,[620,697,698],{"class":626},"\u003C!-- Тянем критичный ресурс первого экрана раньше -->\n",[620,700,702,704,706,708,710,713,716,718,721,723,725,728,731,733,736,738],{"class":622,"line":701},6,[620,703,634],{"class":633},[620,705,638],{"class":637},[620,707,642],{"class":641},[620,709,645],{"class":633},[620,711,712],{"class":648},"\"preload\"",[620,714,715],{"class":641}," as",[620,717,645],{"class":633},[620,719,720],{"class":648},"\"font\"",[620,722,652],{"class":641},[620,724,645],{"class":633},[620,726,727],{"class":648},"\"/fonts/main.woff2\"",[620,729,730],{"class":641}," type",[620,732,645],{"class":633},[620,734,735],{"class":648},"\"font/woff2\"",[620,737,660],{"class":641},[620,739,663],{"class":633},[10,741,742,745,746,749],{},[98,743,744],{},"preconnect"," заранее делает DNS-резолв, TCP-рукопожатие и TLS для домена, с которого скоро придёт важное. ",[98,747,748],{},"preload"," поднимает приоритет конкретного ресурса первого экрана (шрифт, ключевая картинка). Только не переусердствуй: если запрелоадить десять вещей, ты не ускоришь ничего, а размажешь приоритеты. Preload это скальпель для одного-двух критичных ресурсов, а не ковровая бомбёжка.",[236,751,753],{"id":752},"кеш-и-сжатие-на-сервере","Кеш и сжатие на сервере",[411,755,756,770],{},[414,757,758,761,762,765,766,769],{},[52,759,760],{},"Cache-Control: immutable."," Для статики с хешем в имени файла (",[98,763,764],{},"app.a1b2c3.js",") ставь ",[98,767,768],{},"Cache-Control: max-age=31536000, immutable",". Браузер закеширует навсегда и не будет перезапрашивать. При изменении меняется хеш, значит и URL.",[414,771,772,775,776,779],{},[52,773,774],{},"ETag."," Для контента, который может меняться, ETag позволяет браузеру спросить «изменилось?» и получить лёгкий ",[98,777,778],{},"304 Not Modified"," вместо полной перекачки.",[611,781,786],{"className":782,"code":784,"language":785},[783],"language-text","# Пример заголовков для статики с хешем в имени\nCache-Control: public, max-age=31536000, immutable\n\n# Для HTML, который меняется\nCache-Control: no-cache\n","text",[98,787,784],{"__ignoreMap":616},[236,789,791],{"id":790},"сжатие-и-протокол-тут-топ-выдачи-особенно-отстал","Сжатие и протокол: тут топ выдачи особенно отстал",[10,793,794],{},"Вот два места, где старые советы прямо вредят.",[796,797,798],"pros",{},[411,799,800,806],{},[414,801,802,805],{},[52,803,804],{},"Brotli вместо голого Gzip."," Многие гайды до сих пор пишут только про Gzip. Brotli сжимает текст (HTML, CSS, JS) плотнее Gzip на 15–25%, и его поддерживают все актуальные браузеры. Включай Brotli, Gzip оставляй как fallback для древних клиентов.",[414,807,808,811],{},[52,809,810],{},"HTTP/2 (или HTTP/3)."," Мультиплексирование: много файлов едут по одному соединению параллельно, без очереди. Почти все хостинги это уже умеют, проверь, что включено.",[813,814,815],"cons",{},[411,816,817,823],{},[414,818,819,822],{},[52,820,821],{},"Domain sharding больше не нужен."," Старый трюк «раскидай статику по нескольким поддоменам, чтобы обойти лимит соединений» под HTTP/1.1 работал. Под HTTP/2 он вредит: лишние соединения, лишние TLS-рукопожатия, потеря приоритизации. Если тебе всё ещё советуют шардить домены, совет из 2015 года.",[414,824,825,828],{},[52,826,827],{},"Gzip без Brotli."," Не ошибка, но упущенная выгода. Плотнее сжатие бесплатно лежит рядом.",[236,830,832],{"id":831},"cdn","CDN",[10,834,835],{},"CDN раздаёт статику с ближайшего к пользователю узла. Нужен, когда аудитория размазана по стране или миру. Если все посетители в одном регионе и сервер рядом, выигрыш почти нулевой. Важный нюанс для России: убедись, что у CDN есть точки присутствия внутри страны, иначе запросы поедут в Европу и станет хуже, а не лучше.",[10,837,838],{},"Сведу базу в чеклист, чтобы было с чем сверяться.",[10,840,841],{},[52,842,843],{},"Чеклист базовой оптимизации:",[411,845,848,865,871,881,887,897,903,909,918,924,930],{"className":846},[847],"contains-task-list",[414,849,852,857,858,860,861,437,863],{"className":850},[851],"task-list-item",[853,854],"input",{"disabled":855,"type":856},true,"checkbox"," Картинки в WebP/AVIF, с ",[98,859,436],{},"/",[98,862,440],{},[98,864,450],{},[414,866,868,870],{"className":867},[851],[853,869],{"disabled":855,"type":856}," У картинок заданы размеры (нет скачков CLS)",[414,872,874,876,877,880],{"className":873},[851],[853,875],{"disabled":855,"type":856}," Шрифты: ",[98,878,879],{},"font-display: swap",", preload ключевого, сабсет",[414,882,884,886],{"className":883},[851],[853,885],{"disabled":855,"type":856}," CSS и JS минифицированы",[414,888,890,892,893,860,895],{"className":889},[851],[853,891],{"disabled":855,"type":856}," Некритичные скрипты с ",[98,894,534],{},[98,896,538],{},[414,898,900,902],{"className":899},[851],[853,901],{"disabled":855,"type":856}," Critical CSS инлайнится, остальное асинхронно",[414,904,906,908],{"className":905},[851],[853,907],{"disabled":855,"type":856}," Мёртвый CSS/JS вычищен (проверено Coverage)",[414,910,912,914,915],{"className":911},[851],[853,913],{"disabled":855,"type":856}," Статика с хешем отдаётся с ",[98,916,917],{},"Cache-Control: immutable",[414,919,921,923],{"className":920},[851],[853,922],{"disabled":855,"type":856}," Включён Brotli (Gzip как fallback)",[414,925,927,929],{"className":926},[851],[853,928],{"disabled":855,"type":856}," HTTP/2 или HTTP/3 работает",[414,931,933,935],{"className":932},[851],[853,934],{"disabled":855,"type":856}," CDN, если аудитория широкая географически",[10,937,938],{},"Это фундамент. Он снимает большинство проблем на большинстве сайтов. Но есть тормоза, которые базой не лечатся, потому что сидят в архитектуре бандла. О них дальше, и вот тут начинается инженерия, которой в топе нет вообще.",[17,940,942],{"id":941},"бандл-code-splitting-ленивые-чанки-и-tree-shaking","Бандл: code splitting, ленивые чанки и tree-shaking",[10,944,945],{},"Базовые фиксы дают быстрый результат, но упираются в потолок, если сама сборка кода собрана плохо. Главный симптом: один жирный JavaScript-бандл, который браузер обязан скачать, распарсить и выполнить, прежде чем страница станет живой.",[10,947,948],{},"Почему это убивает первый экран. Пока грузится и парсится мегабайтный бандл, main-thread занят, страница не реагирует, INP в красной зоне, а LCP ждёт, пока JS дорисует контент. Ты можешь идеально сжать картинки, но если на входе висит 2 МБ JavaScript, всё остальное не спасёт.",[10,950,951],{},"Лечится это архитектурой сборки. Разберём инструменты.",[10,953,954,957],{},[52,955,956],{},"Route-level code splitting."," Не грузи код всех страниц сразу. Каждый роут должен тянуть только свой чанк. Nuxt и Next делают это из коробки при файловой маршрутизации, но легко сломать, затащив всё в глобальные импорты. Проверяй.",[10,959,960,963],{},[52,961,962],{},"Dynamic import()."," Тяжёлые куски, которые нужны не сразу, грузи по требованию. Модалка, которая открывается по клику. Библиотека графиков на странице, куда доходит не каждый. Редактор, тяжёлый календарь, карта.",[611,965,969],{"className":966,"code":967,"language":968,"meta":616,"style":616},"language-js shiki shiki-themes github-light github-dark","// Плохо: библиотека графиков в основном бандле у всех\nimport Chart from 'heavy-chart-lib'\n\n// Хорошо: подтянется, только когда реально нужна\nconst Chart = await import('heavy-chart-lib')\n","js",[98,970,971,976,991,996,1001],{"__ignoreMap":616},[620,972,973],{"class":622,"line":623},[620,974,975],{"class":626},"// Плохо: библиотека графиков в основном бандле у всех\n",[620,977,978,982,985,988],{"class":622,"line":630},[620,979,981],{"class":980},"szBVR","import",[620,983,984],{"class":633}," Chart ",[620,986,987],{"class":980},"from",[620,989,990],{"class":648}," 'heavy-chart-lib'\n",[620,992,993],{"class":622,"line":666},[620,994,995],{"emptyLinePlaceholder":855},"\n",[620,997,998],{"class":622,"line":672},[620,999,1000],{"class":626},"// Хорошо: подтянется, только когда реально нужна\n",[620,1002,1003,1006,1010,1013,1016,1019,1022,1025],{"class":622,"line":695},[620,1004,1005],{"class":980},"const",[620,1007,1009],{"class":1008},"sj4cs"," Chart",[620,1011,1012],{"class":980}," =",[620,1014,1015],{"class":980}," await",[620,1017,1018],{"class":980}," import",[620,1020,1021],{"class":633},"(",[620,1023,1024],{"class":648},"'heavy-chart-lib'",[620,1026,1027],{"class":633},")\n",[10,1029,1030,1033,1034,1037,1038,1041],{},[52,1031,1032],{},"Ленивые компоненты."," В Nuxt префикс ",[98,1035,1036],{},"Lazy"," (",[98,1039,1040],{},"\u003CLazyHeavyWidget />",") откладывает загрузку компонента, пока он не понадобится. Комбинируешь с ленивой гидрацией, и тяжёлый виджет не грузит первый экран.",[10,1043,1044,1047,1048,1051,1052,1055],{},[52,1045,1046],{},"Tree-shaking."," Сборщик выкидывает неиспользуемый экспорт из библиотек. Работает, только если импортируешь точечно (",[98,1049,1050],{},"import { debounce } from 'lodash-es'","), а не тянешь пакет целиком (",[98,1053,1054],{},"import _ from 'lodash'","). Одна неаккуратная строка импорта тащит в бандл сотни килобайт мёртвого кода.",[10,1057,1058,1061,1062,1064,1065,1068],{},[52,1059,1060],{},"Анализ бандла."," Команда ",[98,1063,100],{}," (или ",[98,1066,1067],{},"webpack-bundle-analyzer"," / визуализатор Rollup) рисует карту: что и сколько весит в сборке. Открываешь и сразу видишь жирные куски, которые не должны там лежать. Это как Coverage, только для сборки. Без такого анализа оптимизация бандла это гадание.",[10,1070,1071,1072,1075,1076,1079],{},"На что смотрю в этой карте первым делом. Ищу vendor-чанк, куда сборщик складывает сторонние библиотеки, и проверяю, что в нём нет неожиданных тяжеловесов. Классика жанра: целиком затащенный ",[98,1073,1074],{},"moment"," с локалями всех стран мира, ",[98,1077,1078],{},"lodash"," вместо точечных импортов, дублирующиеся версии одной библиотеки, которые притащили разные зависимости. Второе, что проверяю, это не попал ли код, нужный только на одной странице, в общий чанк, который грузится у всех. Третье, нет ли иконок или SVG, зашитых прямо в JS вместо спрайта. Одна такая находка порой снимает с первого экрана двести-триста килобайт, и это без единой правки логики, просто аккуратный импорт.",[10,1081,1082,1083,497,1086,1089,1090,497,1093,1096],{},"Пример из моей практики, но не про JS-бандл, а про ассеты, где тот же принцип виден нагляднее. На evolkov.tech в героe крутится 3D-сцена. Исходные модели весили дико: ",[98,1084,1085],{},"desktop_pc",[52,1087,1088],{},"16 МБ",", монитор ",[98,1091,1092],{},"acer",[52,1094,1095],{},"9 МБ",". Для первого экрана это приговор. Я прогнал их через gltf-transform с draco-компрессией геометрии и переводом текстур в webp. Результат на графике.",[1098,1099],"prose-chart",{":datasets":1100,":labels":1101,"caption":1102,"title":1103,"type":1104,"unit":1105},"[{\"label\":\"До\",\"data\":[16000,9000]},{\"label\":\"После\",\"data\":[1100,221]}]","[\"desktop_pc\",\"acer_monitor\"]","draco-компрессия геометрии плюс webp-текстуры. desktop_pc с 16 МБ до 1,1 МБ, acer с 9 МБ до 221 КБ. Декодер draco лежит локально, чтобы не тянуть его со стороннего CDN.","Вес 3D-моделей на evolkov.tech до и после сжатия","bar","КБ",[10,1107,1108],{},"Принцип одинаковый и для 3D, и для JavaScript: не тащи в первый экран то, без чего он отрисуется. Сжимай, дели, откладывай. Разница между «сайт грузится 8 секунд» и «сайт грузится за секунду» чаще всего живёт именно здесь, в архитектуре бандла и ассетов, а не в настройках кеша.",[17,1110,1112],{"id":1111},"i18n-на-масштабе-почему-локали-топят-старт","i18n на масштабе: почему локали топят старт",[10,1114,1115],{},"Отдельная боль, про которую не пишет никто, а на серьёзных проектах она встаёт в полный рост. Мультиязычность.",[10,1117,1118],{},"Сразу тезис: интернационализация не тормоз сама по себе. Тормозом её делает наивная реализация. И вот как это выглядит.",[10,1120,1121],{},"Классический подход i18n-библиотек: загрузить все переводы всех языков в бандл при старте приложения. На маленьком сайте с двумя десятками строк на трёх языках это незаметно. А теперь представь платформу, где тысячи страниц, у каждой свои тексты, свои описания, свои FAQ, и всё это на нескольких языках. Словари распухают до мегабайтов. И весь этот вес прилетает браузеру на старте, до того как пользователь вообще что-то сделал.",[10,1123,1124,1125,1128,1129,1132],{},"Я видел это не в теории. На международной контентной платформе, которую я разгонял, было ",[52,1126,1127],{},"275 файлов локалей"," общим весом около ",[52,1130,1131],{},"8,6 МБ"," (EN и RU). Симптом был характерный: серверный рендеринг отдавал готовый HTML, страница визуально появлялась, но кликать по ней было нельзя. Интерактив мёртв минутами, потому что браузер давился загрузкой и разбором гигантских словарей, прежде чем гидрация оживит страницу. SSR есть, а сайт как будто завис. Худший вид тормоза: выглядит загруженным, а не работает.",[10,1134,1135,1136,1139,1140,1143],{},"Решение было не «уменьшить переводы», их нельзя выкинуть, они и есть контент. Решение архитектурное: ",[52,1137,1138],{},"своя per-page i18n-загрузка",". Вместо одного гигантского словаря на всё приложение осталось маленькое ядро с общими строками (навигация, кнопки, подвал), а переводы конкретной страницы стали подтягиваться отдельным лёгким чанком по роуту. Ядро ужалось примерно до ",[52,1141,1142],{},"115 КБ",", остальное грузится ровно тогда, когда пользователь на страницу зашёл.",[1098,1145],{":datasets":1146,":labels":1147,"caption":1148,"title":1149,"type":1104,"unit":1105},"[{\"label\":\"Грузится на старте\",\"data\":[8600,115]}]","[\"Все локали в бандле\",\"Ядро + остальное по роуту\"]","Было около 8,6 МБ словарей на 275 файлов, тянувшихся к старту приложения. Стало ядро около 115 КБ, а переводы страницы подгружаются по роуту. Общий объём контента тот же, изменилась только стратегия загрузки.","Вес локалей, тянущийся к старту, до и после per-page загрузки",[10,1151,1152,1153,1157],{},"После этого интерактив вернулся туда, где ему место: сразу. Это как раз тот случай, когда проблему не решить ни плагином, ни настройкой сервера, ни сжатием картинок. Нужно менять то, как приложение грузит данные. Полный разбор этого проекта я собрал в ",[220,1154,1156],{"href":1155},"/cases/platforma-kalkulyatorov","кейсе международной платформы калькуляторов",": 1000+ страниц, два языка, и вот эта самая перф-архитектура локалей под капотом.",[10,1159,1160],{},"Мораль для тех, кто делает мультиязычный сайт. Проверь, как твоя i18n-библиотека грузит переводы. Если она тащит все языки и все страницы в один бандл, это бомба замедленного действия, которая рванёт, как только контента станет много. Грузи лениво, по роуту, с маленьким ядром. Тогда i18n не стоит тебе ни миллисекунды лишнего старта.",[17,1162,1164],{"id":1163},"архитектура-ssr-ssg-и-isr-решают-больше-чем-плагины","Архитектура: SSR, SSG и ISR решают больше, чем плагины",[10,1166,1167],{},"Поднимемся ещё на уровень выше. Самое сильное решение по скорости принимается до первой строчки оптимизации, когда выбираешь модель рендеринга. Оно бьёт мощнее любого плагина кеширования, потому что определяет, что вообще браузер получит в ответ.",[10,1169,1170],{},"Разложу три подхода простыми словами.",[10,1172,1173,1176],{},[52,1174,1175],{},"SSR (server-side rendering)."," Сервер на каждый запрос собирает готовый HTML и отдаёт браузеру. Пользователь видит контент сразу, поисковик получает готовую страницу, LCP хороший. Плата: сервер работает на каждый запрос, TTFB зависит от его скорости, нужен живой сервер и кеш. Подходит, когда контент часто меняется и завязан на пользователя.",[10,1178,1179,1182],{},[52,1180,1181],{},"SSG (static site generation)."," Страницы собираются один раз на этапе билда в статические HTML-файлы. Дальше их раздаёт хоть простой файловый сервер, хоть CDN. Это самое быстрое, что бывает: TTFB почти нулевой, ломаться на рантайме нечему, нагрузки на сервер нет. Плата: при изменении контента нужна пересборка, и на миллионе страниц билд становится долгим. Идеально для контента, который меняется не ежесекундно.",[10,1184,1185,1188],{},[52,1186,1187],{},"ISR (incremental static regeneration)."," Гибрид. Страницы статические, но сервер умеет пересобирать отдельные из них по расписанию или по запросу, не трогая остальные. Свежесть почти как у SSR, скорость почти как у SSG. Плата: сложнее в настройке и требует поддержки со стороны хостинга или фреймворка.",[25,1190,1191,1210],{},[28,1192,1193],{},[31,1194,1195,1198,1201,1204,1207],{},[34,1196,1197],{},"Модель",[34,1199,1200],{},"TTFB",[34,1202,1203],{},"Свежесть контента",[34,1205,1206],{},"Нагрузка на сервер",[34,1208,1209],{},"Кому",[44,1211,1212,1231,1250],{},[31,1213,1214,1219,1222,1225,1228],{},[49,1215,1216],{},[52,1217,1218],{},"SSR",[49,1220,1221],{},"Средний, зависит от сервера",[49,1223,1224],{},"Всегда свежий",[49,1226,1227],{},"Высокая, на каждый запрос",[49,1229,1230],{},"Личные кабинеты, часто меняющиеся данные",[31,1232,1233,1238,1241,1244,1247],{},[49,1234,1235],{},[52,1236,1237],{},"SSG",[49,1239,1240],{},"Минимальный",[49,1242,1243],{},"На момент билда",[49,1245,1246],{},"Нулевая",[49,1248,1249],{},"Контент, лендинги, блоги, витрины",[31,1251,1252,1257,1259,1262,1265],{},[49,1253,1254],{},[52,1255,1256],{},"ISR",[49,1258,1240],{},[49,1260,1261],{},"Свежий по расписанию",[49,1263,1264],{},"Низкая",[49,1266,1267],{},"Большие каталоги, где важна и скорость, и свежесть",[10,1269,1270],{},"Ключевая мысль: тяжёлая CMS, которая на каждый запрос собирает страницу из PHP и базы, а потом разгоняется серверным кешем, почти всегда проигрывает по TTFB заранее собранной статике. Кеш CMS это попытка догнать статику, начиная с отставания. Если контент позволяет, честнее сразу отдавать статику, а не догонять кешем медленный рендер.",[10,1272,1273,1274,1277],{},"Пример у тебя перед глазами. Сам evolkov.tech собран как статика: ",[98,1275,1276],{},"nuxt generate"," превращает сайт в набор HTML-файлов, которые лежат на моём сервере и раздаются напрямую через Caddy. Нет прослойки, нет рендера на каждый запрос, нет базы, которая может лечь. TTFB минимальный, ломаться на рантайме нечему. Для сайта-визитки и блога это оптимальная модель, и я выбрал её осознанно, а не по инерции «все делают SSR».",[236,1279,1281],{"id":1280},"цена-гидрации-почему-ssr-не-бесплатный","Цена гидрации: почему SSR не бесплатный",[10,1283,1284],{},"Тут есть ловушка, в которую попадают, поверив, что «поставил SSR и всё летает». Сервер отдал готовый HTML, пользователь увидел контент, красота. Но страница ещё не живая. Чтобы кнопки нажимались, а формы работали, браузеру нужно скачать JavaScript и «оживить» уже нарисованный HTML. Это и есть гидрация.",[10,1286,1287],{},"И вот тут прячется коварство. Между «вижу контент» и «могу кликать» лежит окно, пока грузится и выполняется JS. Если бандл жирный, окно растягивается, и получается ровно та картина, что я разбирал на i18n: страница выглядит загруженной, а не отвечает. Формально LCP хороший, а INP в красной зоне, и пользователь злится, тыкая в мёртвую кнопку.",[10,1289,1290],{},"Лечится это тем, что гидрируют не всё и не сразу. Ленивая гидрация откладывает оживление тяжёлых компонентов до того момента, когда они попадут в зону видимости или пользователь до них дотронется. Островная архитектура (islands) идёт дальше и гидрирует только интерактивные куски, оставляя статичный контент статичным навсегда. Nuxt умеет и то и другое. Смысл один: не заставляй браузер оживлять весь тяжёлый JavaScript ради пары кнопок в подвале.",[10,1292,1293],{},"Оговорюсь честно про пределы. SSR и SSG не волшебство. Если поверх правильного рендеринга висит жирный бандл и тяжёлая гидрация, выигрыш от серверной отрисовки съедается на клиенте. Архитектура рендеринга задаёт потолок скорости, но не освобождает от работы с бандлом. Поэтому реальный результат это связка: правильная модель рендеринга плюс аккуратный бандл плюс базовая оптимизация. Всё вместе, а не по отдельности.",[17,1295,1297],{"id":1296},"почему-самоделки-и-коробки-не-тянут-1000-страниц","Почему самоделки и коробки не тянут 1000+ страниц",[10,1299,1300],{},"Пока страниц десятки, тормоза не видно. Проблемы масштаба вылезают, когда контента становятся тысячи, и вот тут коробочные решения и наивные самоделки начинают трещать.",[10,1302,1303],{},"Разберу типовые точки отказа.",[10,1305,1306,1309],{},[52,1307,1308],{},"Билд-тайм."," Если сайт статический, а страниц много, наивная сборка пересобирает всё на каждое изменение. На тысяче страниц билд из минут превращается в десятки минут. Нужен инкрементальный подход (тот самый ISR или умное кеширование сборки), иначе деплой становится мучением.",[10,1311,1312,1315],{},[52,1313,1314],{},"Asset-pipeline на каждую страницу."," Каждая страница тянет картинки, которые надо сжать, форматы, которые надо сгенерировать, превью. Без нормального пайплайна обработки ассетов на масштабе это либо забивает билд, либо отдаёт неоптимизированное в прод.",[10,1317,1318,1321],{},[52,1319,1320],{},"Отсутствие чанкинга."," Возвращаемся к бандлу и локалям. На маленьком сайте «всё в один бандл» прощается. На тысяче страниц с мультиязычностью это гарантированный мёртвый старт, который мы разбирали выше.",[10,1323,1324,1327],{},[52,1325,1326],{},"Cache invalidation."," Обновил товар, а на витрине старая цена, потому что где-то в цепочке кешей застряла прошлая версия. На масштабе инвалидация кеша это отдельная инженерная задача, а не галочка. Известная шутка про то, что это одна из двух труднейших вещей в программировании, ровно про это.",[10,1329,1330,1333],{},[52,1331,1332],{},"N+1 запросы."," Классика бэкенда. Страница со списком дёргает базу по разу на каждый элемент вместо одного запроса на всех. На десяти элементах незаметно, на тысяче страница висит секундами. Ловится профилировщиком запросов, лечится нормальными выборками.",[10,1335,1336],{},"Покажу на пальцах, как это выглядит на билде. Статический сайт на сотню страниц собирается за пару минут, и наивный подход «пересобрать всё на любое изменение» никого не раздражает. Умножь на десять. Тысяча страниц, у каждой свои картинки, которые надо сжать и сгенерить в трёх размерах и двух форматах, свои данные, свои переводы. Наивная сборка честно делает всю работу заново на каждый чих, и деплой из двух минут превращается в двадцать. Правишь опечатку в подвале, ждёшь двадцать минут. На этом объёме без инкрементальной сборки и кеша ассетов жить нельзя, а коробочные генераторы про это часто не думают, потому что их тестировали на демо из десяти страниц.",[10,1338,1339],{},"То же с базой. Пока в каталоге сто товаров, кривой запрос отвечает за миллисекунды, и никто не замечает N+1. На пятидесяти тысячах позиций тот же запрос кладёт страницу на секунды, а под нагрузкой роняет сервер. Это ловится профилировщиком и лечится нормальной выборкой с джойнами и индексами, но только если кто-то вообще знает, что туда надо смотреть. Самоделка и коробка обычно не знают.",[10,1341,1342],{},"Коробочные CMS и собранные на коленке движки спотыкаются об это постоянно, потому что их архитектура не рассчитана на объём. Они прекрасно работают на сотне страниц и осыпаются на тысячах.",[10,1344,1345,1346,1349,1350,1353,1354,1357,1358,1361],{},"Как это выглядит, когда сделано правильно, покажу на реальных числах. Международная контентная платформа, которую я упоминал: ",[52,1347,1348],{},"1094 страницы"," контента, ",[52,1351,1352],{},"201 статья"," в блоге, два языка, и всё это не только не тормозит, но и растёт в поиске. По Ahrefs домен добрался до ",[52,1355,1356],{},"DR 39",", что высоко для молодого сайта в тяжёлой YMYL-тематике. Трафик за месяц по Яндекс.Метрике вырос на ",[52,1359,1360],{},"+47%",", и главный источник роста это поиск, а не соцсети. Платформу цитируют AI-поисковики (ChatGPT, Copilot), а это отдельный маркер того, что контент и структура на масштабе собраны здорово. Тысяча с лишним быстрых, проиндексированных, ранжирующихся страниц это не случайность, а следствие архитектуры, которая изначально рассчитана на объём.",[10,1363,1364],{},"Вывод. Если ты заранее знаешь, что сайт будет большим (каталог на тысячи позиций, контентный проект, мультиязычная платформа), выбор стека и архитектуры важнее любых поздних оптимизаций. Дешёвый на старте движок, который не тянет масштаб, потом стоит переезда. А переезд это всегда дороже, чем сделать правильно сразу.",[17,1366,1368],{"id":1367},"вайб-кодинг-и-ии-инструмент-дирижёра-а-не-дирижёр","Вайб-кодинг и ИИ: инструмент дирижёра, а не дирижёр",[10,1370,1371],{},"Тема, которую нельзя обойти в 2026 году. Раз речь про ускорение работы, стоит честно поговорить про ускорение самого инженера с помощью ИИ. И заодно про то, где вайб-кодинг помогает, а где ломает скорость сайта.",[10,1373,1374],{},"Сразу расставлю точки. Я не против ИИ, наоборот. ИИ-агенты (Claude Code, ChatGPT с Codex, Gemini CLI) реально ускоряют разработку, и я сам работаю с ними каждый день. Написать бойлерплейт, накидать тесты, разобрать незнакомую библиотеку, отрефакторить рутину: тут они экономят часы. Это мощный инструмент, и отрицать его глупо.",[796,1376,1377],{},[411,1378,1379,1382,1385,1388],{},[414,1380,1381],{},"Бойлерплейт и рутина. Накидать компонент, форму, типовой CRUD, конфиг ИИ делает быстро и без ошибок усталости.",[414,1383,1384],{},"Тесты и документация. Покрыть код юнит-тестами, описать функцию, разобрать чужую библиотеку это его сильная сторона.",[414,1386,1387],{},"Точечный рефакторинг под присмотром, когда ты знаешь, что хочешь, и проверяешь каждый шаг.",[414,1389,1390],{},"Скорость гипотез. Быстро набросать вариант, посмотреть, отбросить. Как черновик, который потом доводишь сам.",[813,1392,1393],{},[411,1394,1395,1398,1401,1404],{},[414,1396,1397],{},"Не видит замысел целиком. Работает с тем куском, что перед глазами, и не знает, зачем в соседнем файле сделано «странно».",[414,1399,1400],{},"Считает намеренные перф-компромиссы багами и «чинит» их, ломая скорость.",[414,1402,1403],{},"Уверенно наводит красоту там, где красота вредит: сносит ручной чанкинг, кеш, отложенную гидрацию.",[414,1405,1406],{},"Чем дальше от типовой задачи и ближе к оптимизации, тем чаще вредит, а не помогает.",[10,1408,1409],{},"Но у инструмента есть граница, и на оптимизации она видна особенно резко. ИИ-агенты работают как оркестр под дирижёром. Ты задаёшь направление, держишь в голове всю картину и архитектуру, проверяешь результат. Они виртуозно исполняют партии, но не видят замысел целиком. Сами по себе, без дирижёра, они не понимают, почему в конкретном месте сделано именно так.",[10,1411,1412],{},"А перф-оптимизация это сплошные осознанные компромиссы, у каждого из которых есть причина, которую не видно в коде.",[10,1414,1415],{},"Живой пример, инженерный и правдоподобный. Допустим, ответ API или целую страницу намеренно закешировали через SWR или ISR, а то и просто заголовками. Почему? Потому что данные меняются редко, а TTFB и скорость важнее секундной свежести. Это осознанный компромисс, принятый инженером, который знает продукт. В коде причина не написана, она в голове у человека.",[10,1417,1418],{},"Теперь запускаем на этот код ИИ-агента без контекста. Он видит: данные отдаются устаревшие, стоит странный кеш, код «неидеальный». Логика агента: это баг, надо починить. Он убирает кеш или переписывает на чистый SSR без кеширования. Итог: TTFB подскочил, скорость просела, полезная оптимизация уничтожена. Хуже того, агент не останавливается: он по цепочке трогает связанное, «улучшает» соседний код, и ломает ещё в паре мест, потому что не знает, где проходят невидимые провода.",[10,1420,1421],{},"То же самое с любым намеренным перф-решением. Заинлайненный руками критический CSS выглядит как «дублирование стилей, надо вынести». Отложенная гидрация выглядит как «почему компонент не гидрируется сразу, это баг». Ручной чанкинг локалей, тот самый, что спас старт на 275 файлах, выглядит как «зачем так сложно, давай стандартный импорт». Без понимания «почему так» ИИ причёсывает код под общие best practices и сносит ровно те решения, которые держали скорость.",[10,1423,1424],{},"Отсюда вывод, и он не про «ИИ плохой». ИИ исполняет, дирижирует человек, который знает, почему сделано именно так. Вайб-кодинг ускоряет генерацию кода, это правда и это ценно. Но он не заменяет понимание архитектуры и перф-компромиссов. На масштабе и в оптимизации слепой ИИ-рефакторинг это тот же тупик самоделки, только достигается быстрее. Скорость сайта держится на решениях, у которых есть причина, а причину пока держит в голове инженер, а не модель.",[10,1426,1427],{},"Так что на вопрос «можно ли ускорить сайт нейросетью» честный ответ: нейросетью можно ускорить работу инженера, который ускоряет сайт. Инструмент в руках дирижёра. Без дирижёра оркестр играет вразнобой.",[17,1429,1431],{"id":1430},"частые-ошибки-которые-я-вижу-в-аудитах","Частые ошибки, которые я вижу в аудитах",[10,1433,1434],{},"За годы аудитов набор тормозов повторяется до узнаваемости. Соберу самые частые, потому что, возможно, твой сайт спотыкается ровно об это, и половину можно поправить сегодня же.",[10,1436,1437,1440,1441,1443],{},[52,1438,1439],{},"Ленивая загрузка на картинке первого экрана."," Человек прочитал «lazy ускоряет» и навесил ",[98,1442,450],{}," на всё, включая баннер героя. Итог: браузер откладывает загрузку именно того, что должно появиться первым, и LCP проседает. Лениво грузим то, что ниже сгиба, не то, что видно сразу.",[10,1445,1446,1449],{},[52,1447,1448],{},"Слайдер-карусель на главной."," Красиво в макете, больно в проде. Пять-десять полноразмерных фото, которые грузятся все и сразу, плюс тяжёлая библиотека слайдера, плюс автопрокрутка, дёргающая рендер. Я не помню аудита с каруселью на весь экран, где она бы не была в тройке тормозов. Чаще всего её вообще не листают.",[10,1451,1452,1455,1456,1458,1459,1462],{},[52,1453,1454],{},"Шрифты с внешнего домена без подготовки."," Подключили набор начертаний с чужого CDN, без ",[98,1457,744],{},", без сабсета, без ",[98,1460,1461],{},"font-display",". Текст мигает, LCP ждёт шрифт, лишние запросы на сторонний домен. Свои шрифты, локально, с сабсетом почти всегда быстрее.",[10,1464,1465,1468],{},[52,1466,1467],{},"Весь JavaScript одним куском."," «Работает же». Работает, пока сайт маленький. Как только контента и функций становится много, единый бандл превращается в кирпич на старте, и никакой кеш этого не спасает. Про лечение был целый раздел выше.",[10,1470,1471,1474,1475,1477],{},[52,1472,1473],{},"Аналитика и чат синхронно в head."," Классика. Три счётчика, пиксель и виджет консультанта грузятся первыми, блокируют рендер и держат main-thread, пока пользователь смотрит на белый экран. Всё это спокойно живёт с ",[98,1476,534],{}," или откладывается до взаимодействия.",[10,1479,1480,1483],{},[52,1481,1482],{},"Кеш выключен «чтобы видеть свежее»."," Разработчик отключил кеширование на время работы и забыл вернуть. Или CMS по умолчанию не кеширует ничего. Каждый запрос собирается заново, TTFB высокий на ровном месте. Проверяй заголовки на проде, а не только на глаз.",[10,1485,1486,1489],{},[52,1487,1488],{},"Тема-комбайн на все случаи жизни."," Купили тему, которая «умеет всё»: и магазин, и портфолио, и блог, и лендинг. Внутри код под все сценарии сразу, из которых ты используешь один. Вес тащишь за все. Лучше лёгкая тема под свою задачу, чем универсальный комбайн.",[10,1491,1492,1495],{},[52,1493,1494],{},"Прыгающая вёрстка от поздних баннеров."," Реклама, куки-баннер, промо-плашка вставляются в DOM с задержкой и сдвигают контент под уже читающим пользователем. Это разрушает CLS и бесит людей. Резервируй под них место заранее, задавай размеры контейнерам.",[10,1497,1498],{},"Заметь общую нить. Почти каждая ошибка это не «сайт плохо написан», а «сделали удобно для себя и забыли про пользователя с телефоном». Скорость возвращается, когда начинаешь смотреть на сайт его глазами, а не глазами разработчика на быстрой машине.",[17,1500,1502],{"id":1501},"как-закрепить-результат-мониторинг-реальных-пользователей","Как закрепить результат: мониторинг реальных пользователей",[10,1504,1505],{},"Разогнать сайт это половина дела. Вторая половина не дать ему замедлиться обратно. Скорость деградирует незаметно: добавили баннер, подключили ещё один аналитический скрипт, обновили библиотеку, и вот LCP тихо уполз в жёлтую зону. Поэтому за скоростью не «прогоняют Lighthouse раз в полгода», а следят постоянно.",[10,1507,1508],{},"Ключевое различие мы уже проговорили: лабораторные данные врут про реальность, полевые говорят правду. Значит и мониторить надо полевые.",[10,1510,1511,1514],{},[52,1512,1513],{},"CrUX и PageSpeed"," для международного и Google-трафика. Показывают агрегированные Core Web Vitals реальных пользователей по 75-му перцентилю. Если поехало вниз, увидишь.",[10,1516,1517,1520],{},[52,1518,1519],{},"Яндекс.Метрика и Яндекс.Вебмастер"," для российской аудитории. Метрика собирает реальные метрики скорости твоих посетителей, Вебмастер отслеживает скорость в разрезе индексации. Для рунета это основной, а не запасной инструмент.",[10,1522,1523,1526],{},[52,1524,1525],{},"RUM (Real User Monitoring)."," Если хочется глубже, ставят сбор метрик прямо с живых сессий: у каждого пользователя замеряются LCP, INP, CLS и отправляются в аналитику. Тогда видно не средний градус по больнице, а распределение, и можно ловить, что на дешёвых Android всё плохо, хотя на твоём ноутбуке идеально.",[10,1528,1529],{},"Практический смысл мониторинга в ловле регрессий. Настроил слежение, договорился с собой о порогах (LCP ≤ 2,5 с, INP ≤ 200 мс, CLS ≤ 0,1), и когда метрика их пробивает, идёшь разбираться в DevTools по тому же воркфлоу, что в начале статьи. Скорость это не разовая акция, а состояние, которое поддерживают. Один тяжёлый скрипт, добавленный маркетологом «на пять минут», способен откатить месяц работы.",[17,1531,1533],{"id":1532},"когда-чинить-самому-а-когда-звать-инженера","Когда чинить самому, а когда звать инженера",[10,1535,1536],{},"Честная рамка на финал, без попытки затащить всех в платную работу. Часть проблем реально решается своими руками, часть требует инженера. Разделю прямо.",[10,1538,1539],{},[52,1540,1541],{},"Чини сам, если:",[411,1543,1544,1547,1550,1553],{},[414,1545,1546],{},"Проблема в картинках. Сжать, перевести в WebP, добавить lazy это делается без разработчика, инструментами и плагинами.",[414,1548,1549],{},"Нужен базовый кеш и сжатие. Включить Brotli, выставить Cache-Control, поставить кеш-плагин на CMS это уровень настроек.",[414,1551,1552],{},"Надо почистить очевидный мусор. Убрать десяток неиспользуемых плагинов, выкинуть лишний внешний скрипт, поправить шрифты.",[414,1554,1555],{},"Ты на конструкторе. Там всё равно тонко не порулишь, выжми что дают штатные настройки и не мучайся.",[10,1557,1558],{},[52,1559,1560],{},"Зови инженера, если:",[411,1562,1563,1569,1572,1575,1578],{},[414,1564,1565,1566,1568],{},"Тормоз в бандле или гидрации. Code splitting, ленивые чанки, tree-shaking, разбор ",[98,1567,100],{}," это уже разработка, а не настройка.",[414,1570,1571],{},"Проблема в архитектуре рендеринга. Выбор между SSR, SSG и ISR, переезд с медленной CMS, настройка кеширования на уровне приложения.",[414,1573,1574],{},"Мультиязычность топит старт. Per-page загрузка локалей это инженерная работа, плагином не решается.",[414,1576,1577],{},"Сайт большой и растёт. Тысячи страниц, каталог, N+1, инвалидация кеша, долгий билд. Тут нужен тот, кто держит всю картину.",[414,1579,1580],{},"Базовая оптимизация сделана, а зелёной зоны нет. Значит тормоз глубже, чем настройки, и его надо искать в коде.",[10,1582,1583,1584,1588,1589,1592],{},"Я делаю ровно это как fullstack-разработчик: беру сайт, замеряю по воркфлоу из статьи, показываю, где именно теряются секунды, и чиню то, что даёт максимум эффекта за минимум работы. Не «оптимизацию ради красивой цифры», а конкретные секунды, которые видит пользователь и учитывает поиск. Разбор скорости входит в мою услугу ",[220,1585,1587],{"href":1586},"/uslugi/tehnicheskoe-seo","технического SEO",", она стартует ",[52,1590,1591],{},"от 10 000 ₽",": начинаем с честного аудита, где я показываю тормоза на твоих цифрах, а дальше вместе решаем, что чинить в первую очередь.",[10,1594,1595,1596,1599],{},"Если сайт медленный и непонятно почему, ",[220,1597,1598],{"href":1586},"напиши мне",", и разберёмся предметно. Пришлю замер, покажу узкие места и скажу прямо, где хватит своих рук, а где правда нужна инженерная работа. Мне важнее, чтобы ты понимал, за что платишь, чем продать тебе оптимизацию, которая тебе не нужна.",[1601,1602,1603],"style",{},"html pre.shiki code .sJ8bj, html code.shiki .sJ8bj{--shiki-default:#6A737D;--shiki-dark:#6A737D}html pre.shiki code .sVt8B, html code.shiki .sVt8B{--shiki-default:#24292E;--shiki-dark:#E1E4E8}html pre.shiki code .s9eBZ, html code.shiki .s9eBZ{--shiki-default:#22863A;--shiki-dark:#85E89D}html pre.shiki code .sScJk, html code.shiki .sScJk{--shiki-default:#6F42C1;--shiki-dark:#B392F0}html pre.shiki code .sZZnC, html code.shiki .sZZnC{--shiki-default:#032F62;--shiki-dark:#9ECBFF}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html pre.shiki code .szBVR, html code.shiki .szBVR{--shiki-default:#D73A49;--shiki-dark:#F97583}html pre.shiki code .sj4cs, html code.shiki .sj4cs{--shiki-default:#005CC5;--shiki-dark:#79B8FF}",{"title":616,"searchDepth":630,"depth":630,"links":1605},[1606,1607,1608,1609,1615,1625,1626,1627,1630,1631,1632,1633,1634],{"id":19,"depth":630,"text":20},{"id":146,"depth":630,"text":147},{"id":172,"depth":630,"text":173},{"id":230,"depth":630,"text":231,"children":1610},[1611,1612,1613,1614],{"id":238,"depth":666,"text":239},{"id":248,"depth":666,"text":249},{"id":273,"depth":666,"text":274},{"id":298,"depth":666,"text":299},{"id":398,"depth":630,"text":399,"children":1616},[1617,1618,1619,1620,1621,1622,1623,1624],{"id":405,"depth":666,"text":406},{"id":479,"depth":666,"text":480},{"id":516,"depth":666,"text":517},{"id":562,"depth":666,"text":563},{"id":605,"depth":666,"text":606},{"id":752,"depth":666,"text":753},{"id":790,"depth":666,"text":791},{"id":831,"depth":666,"text":832},{"id":941,"depth":630,"text":942},{"id":1111,"depth":630,"text":1112},{"id":1163,"depth":630,"text":1164,"children":1628},[1629],{"id":1280,"depth":666,"text":1281},{"id":1296,"depth":630,"text":1297},{"id":1367,"depth":630,"text":1368},{"id":1430,"depth":630,"text":1431},{"id":1501,"depth":630,"text":1502},{"id":1532,"depth":630,"text":1533},"seo","/images/blog/kak-uskorit-sajt.webp","2026-07-03",null,"md",[1641,1644,1647,1650,1653,1656,1659,1662,1665,1668,1671,1674,1677],{"q":1642,"a":1643},"Почему сайт медленно грузится?","Чаще всего виноваты три вещи: тяжёлые несжатые картинки, раздутый JavaScript-бандл, который блокирует первый экран, и медленный ответ сервера (TTFB). Реже, но больно бьют шрифты без font-display, отсутствие кеша и куча сторонних скриптов вроде чатов и аналитики. Точную причину не угадывают, а замеряют: открой DevTools, вкладку Performance и Network, и увидишь, что именно съедает секунды. У каждого сайта свой тормоз, поэтому универсального ответа нет, есть замер.",{"q":1645,"a":1646},"Как проверить скорость сайта бесплатно?","Три бесплатных инструмента закрывают почти всё. PageSpeed Insights даёт и лабораторный прогон Lighthouse, и полевые данные CrUX, если у сайта есть трафик. Сам Lighthouse встроен в Chrome DevTools, вкладка Lighthouse. Для российского трафика бери Яндекс.Метрику и Яндекс.Вебмастер: там живут реальные Core Web Vitals твоих посетителей. Лабораторный тест показывает потолок в идеальных условиях, полевые данные показывают правду. Смотри оба.",{"q":1648,"a":1649},"Что такое Core Web Vitals?","Core Web Vitals это набор из трёх метрик Google, которыми измеряют реальный опыт пользователя. LCP отвечает за то, как быстро прогружается главный элемент экрана. INP за отзывчивость на клики и ввод. CLS за визуальную стабильность, чтобы контент не прыгал под пальцем. И Google, и Яндекс учитывают скорость при ранжировании, а сами метрики стали общим языком, на котором говорят про производительность фронтенда.",{"q":1651,"a":1652},"Какие нормы LCP, INP и CLS считаются хорошими?","Хорошие пороги такие: LCP не больше 2,5 секунды, INP не больше 200 миллисекунд, CLS не больше 0,1. Важная деталь: FID, старую метрику отзывчивости, Google убрал в марте 2024 и заменил на INP, так что если гайд всё ещё пишет про FID, он устарел. Ориентируйся именно на INP. И помни, что нормы проверяют по 75-му перцентилю живых пользователей, а не по одному удачному прогону на быстром ноутбуке.",{"q":1654,"a":1655},"Влияет ли скорость сайта на позиции в поиске?","Да, но не как главный рычаг. Скорость и Core Web Vitals это один из факторов ранжирования и у Google, и у Яндекса, но контент и ссылки весят больше. Прямее скорость бьёт по деньгам: медленный сайт теряет посетителей ещё до того, как они увидели товар, растёт показатель отказов, падает конверсия. Так что ускорение это в первую очередь про выручку и удержание, а бонусом идёт помощь позициям.",{"q":1657,"a":1658},"Что даёт SSR и Nuxt для скорости?","Серверный рендеринг отдаёт браузеру готовый HTML, а не пустую страницу, которую потом дорисовывает JavaScript. Первый экран появляется раньше, LCP улучшается, поисковику проще индексировать. Nuxt умеет и SSR, и полную статику через generate, и гибрид с кешированием отдельных роутов. Это не серебряная пуля: тяжёлая гидрация и жирный бандл убьют выигрыш от SSR. Но как фундамент архитектуры правильная модель рендеринга даёт больше, чем десяток плагинов поверх медленной CMS.",{"q":1660,"a":1661},"Почему WordPress медленный?","Сам по себе WordPress не приговор, медленным его делает типовая обвязка. На каждый запрос движок собирает страницу из PHP и базы, а сверху навешаны десятки плагинов, тяжёлая тема и внешние скрипты. Каждый плагин тащит свой CSS и JS, они конфликтуют и раздувают страницу. Разогнать реально: кеш страниц, оптимизация картинок, чистка плагинов, CDN. Но управлять бандлом и рендерингом так же тонко, как на кастомном Nuxt, не выйдет. Это потолок архитектуры, а не настроек.",{"q":1663,"a":1664},"Нужен ли сайту CDN?","Зависит от географии аудитории. Если посетители в одном городе, а сервер рядом, CDN почти ничего не даст. Если трафик размазан по стране или миру, CDN раздаёт статику (картинки, CSS, JS) с ближайшего к пользователю узла и заметно срезает задержку. Для российской аудитории проверь, что у CDN есть точки присутствия в России, иначе запросы поедут в Европу и станет только хуже. Правило простое: широкая география и много статики, значит CDN оправдан.",{"q":1666,"a":1667},"Как ускорить картинки на сайте?","Картинки почти всегда самый жирный вес страницы, и разгоняются они предсказуемо. Переведи в современные форматы WebP или AVIF, они легче JPEG в полтора-два раза без потери качества. Отдавай под размер экрана через srcset и sizes, чтобы телефон не тянул десктопную картинку. Всё, что ниже первого экрана, грузи лениво через loading=lazy. Сжимай перед загрузкой, а не полагайся на браузер. На evolkov.tech я так ужал 3D-модели с 16 МБ до 1,1 МБ, и с обычными фото логика та же.",{"q":1669,"a":1670},"Замедляет ли i18n (мультиязычность) сайт?","Мультиязычность замедляет сайт только если её делать в лоб. Классическая ошибка: затащить все переводы всех языков в один бандл, и тогда старт тонет под весом словарей. Правильно грузить лениво: ядро с общими строками маленькое, а переводы конкретной страницы подтягиваются по роуту. На международной контентной платформе с 275 файлами локалей я так и сделал, ядро осталось около 115 КБ, а остальное грузится по мере надобности. i18n не тормоз, тормоз это неправильная загрузка локалей.",{"q":1672,"a":1673},"Можно ли ускорить сайт через нейросеть или вайб-кодинг?","ИИ-агенты вроде Claude Code или Codex реально ускоряют работу инженера, я сам работаю с ними каждый день. Но на оптимизации они помогают только под присмотром. Перф это сплошные осознанные компромиссы: где-то намеренно закеширован ответ, где-то вручную разбит бандл, где-то отложена гидрация. ИИ контекста «почему так» не видит, считает это багом и «причёсывает», ломая скорость. Вайб-кодинг ускоряет генерацию кода, но не заменяет понимание архитектуры. Дирижирует человек, инструмент исполняет.",{"q":1675,"a":1676},"Ускорит ли сайт установка плагина кеширования?","Немного ускорит, но это не лечение, а обезболивающее. Плагин кеша складывает готовую страницу и отдаёт её быстрее, и на медленной CMS это правда помогает с TTFB. Проблему он не убирает: тяжёлый бандл, лишние скрипты, неоптимизированные картинки и раздутая тема остаются на месте. Плагин прячет симптом. Если сайт медленный по архитектуре, никакой кеш-плагин не вытянет его в зелёную зону Core Web Vitals, нужна работа со стеком.",{"q":1678,"a":1679},"Сколько стоит ускорить сайт?","Зависит от глубины. Базовая оптимизация (картинки, кеш, чистка скриптов, шрифты) на типовом сайте это несколько часов работы. Разбор тяжёлого бандла, настройка code splitting, ленивой загрузки и рендеринга это уже инженерная задача на дни. Переезд на нормальную архитектуру с медленной CMS это отдельный проект. Моё техническое SEO с аудитом скорости стартует от 10 000 ₽: сначала замеряю и показываю, где тормоз, а потом мы решаем, что чинить в первую очередь.",false,{},"Как ускорить сайт в 2026: замер в DevTools, картинки, шрифты, бандл, кеш, SSR и i18n на масштабе. Разбираю с реальными числами, приходи на разбор.","Как ускорить сайт: гайд по скорости 2026","/kak-uskorit-sajt",34,{"title":5,"description":12},"kak-uskorit-sajt","-mk6OYzpHB6SKCTAqmBAJW_qEqdKrISdaKXhocib8WQ",[1690,1697,1702,1707,1713,1714,1719],{"slug":1691,"title":1692,"excerpt":1638,"category":1693,"cover":1694,"date":1695,"updated":1695,"readingMinutes":1696,"featured":1680},"chto-takoe-veb-prilozhenie","Что такое веб-приложение: как устроено, виды и на чём делают","frontend","/images/blog/chto-takoe-veb-prilozhenie.webp","2026-07-04",26,{"slug":1698,"title":1699,"excerpt":1638,"category":1635,"cover":1700,"date":1695,"updated":1695,"readingMinutes":1701,"featured":1680},"kak-proverit-skorost-sajta","Как проверить скорость сайта и как читать отчёт","/images/blog/kak-proverit-skorost-sajta.webp",15,{"slug":1703,"title":1704,"excerpt":1638,"category":1635,"cover":1705,"date":1695,"updated":1695,"readingMinutes":1706,"featured":1680},"skolko-stoit-sdelat-sajt","Сколько стоит сделать сайт под ключ в 2026 году","/images/blog/skolko-stoit-sdelat-sajt.webp",22,{"slug":1708,"title":1709,"excerpt":1638,"category":1710,"cover":1711,"date":1637,"updated":1637,"readingMinutes":1712,"featured":1680},"kak-sdelat-internet-magazin","Как сделать интернет-магазин с нуля: полный разбор от разработчика","ecommerce","/images/blog/kak-sdelat-internet-magazin.webp",33,{"slug":1687,"title":5,"excerpt":1638,"category":1635,"cover":1636,"date":1637,"updated":1637,"readingMinutes":1685,"featured":1680},{"slug":1715,"title":1716,"excerpt":1638,"category":1710,"cover":1717,"date":1637,"updated":1637,"readingMinutes":1718,"featured":1680},"platforma-dlya-internet-magazina","На чём сделать интернет-магазин: конструктор, CMS или кастом","/images/blog/platforma-dlya-internet-magazina.webp",24,{"slug":1720,"title":1721,"excerpt":1638,"category":1710,"cover":1722,"date":1637,"updated":1637,"readingMinutes":1723,"featured":1680},"skolko-stoit-internet-magazin","Сколько стоит интернет-магазин в 2026 году","/images/blog/skolko-stoit-internet-magazin.webp",12,1783795884803]