claude.ai разогнали в 3 раза за две недели с помощью Claude

Как рассказывает команда Claude, подсветка готового блока кода в ответе могла подвесить страницу примерно на секунду. Виноватым оказалось длинное тире. Эту находку команда сделала за двухнедельный спринт, который, по словам аккаунта ClaudeDevs в X, сделал claude.ai втрое быстрее. Промпты и методы приложены к разбору в блоге на claude.dev.

Коротко

• За две недели claude.ai стал втрое быстрее, причём скорость замеряли, тормоза искали и правки вносили вместе с Claude, а промпты и методы команда выложила в блоге на claude.dev.
• На сборке дерева сообщений Claude сократил число выполняемых инструкций на 48%, на сканере строк статуса в выводе Claude Code на 31%, а время по часам упало на 78% и 44% соответственно.
• В анонсе ClaudeDevs не уточняется, какая именно метрика ускорилась втрое, а в блоге цифры «до и после» приведены лишь для трёх из тринадцати замеров, выбранных командой для отслеживания.

Если вы не следили: по данным блога Claude, пользователи жаловались, что claude.ai работает медленно, и команда признаёт, что они были правы. Спринт прошёл в августе. Перед ним команда завела отдельный канал в Slack, где Claude участвовал в каждом треде, и дала ему постоянную инструкцию: отвечать за производительность сайта и десктопного приложения, ловить регрессии после деплоев, проверять телеметрию, вести дашборды и самому чинить очевидное.

Скорость разложили на тринадцать замеров от клика до отрисовки

По данным блога Claude, Claude разобрал данные об использовании через Datadog MCP и выделил четыре сценария, на которые приходится 95% активности: запуск, начало разговора, открытие старого разговора и отправка сообщения. Веб, десктоп и разные продукты вместе дали тринадцать замеров. Каждый шёл от действия пользователя до отрисовки результата.

Итоги по 75-му перцентилю, как их приводит блог. Время до страницы, где можно печатать, на свежей загрузке claude.ai сократилось с 3,1 до 0,55 секунды. Новая сессия Claude Code стала стартовать за 0,3 секунды вместо 0,8, облачная сессия Claude Cowork загружается за 0,73 секунды вместо 2,6. Команда оценивает экономию в десятки тысяч часов ожидания в день.

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

Среди запланированных проектов, по данным блога, было статичное поле ввода, вшитое в HTML: печатать можно ещё до инициализации React. Для главного процесса десктопной оболочки заранее скомпилировали кеш кода V8. Поле ввода оставили смонтированным между разговорами, сессии подгружаются при наведении курсора, а перерисовки боковой панели сократили на 90%.

Сдвиги вёрстки нашлись в 31% загрузок веб-версии

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

Один такой тред начался с видео: строки боковой панели появлялись уже после загрузки, а чаты и сессии Cowork приходили в разное время. Мониторы этого не видели. Ближайшая метрика, Cumulative Layout Shift, давала каждому сдвигу около 0,008 при пороге «хорошо» в 0,1.

Issac предложил обратиться напрямую к Layout Instability API. Claude сделал событие телеметрии, которое привязывает сдвиг к названной области и фазе загрузки, и интеграционный тест, падающий при любом сдвиге. На main тест падал в 20 запусках из 20, на ветке с исправлением проходил в 20 из 20.

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

В пути набора текста нашлось 6 900 хуков React

Перепись хуков нашла в пути набора текста 6 900 хуков и 900 подписок на стор, и всё это перерисовывалось на каждое нажатие клавиши. Один селектор :root:has() добавлял 24 миллисекунды к каждому изменению DOM. Забытый location.reload() давал полмиллиона скрытых перезагрузок в день, а в простаивающих вкладках одинаковые снимки кеша дважды в минуту клонировались в IndexedDB на главном потоке.

С подсветкой кода вышло так: если в markdown ответа был хоть один символ вне Latin-1, например длинное тире или фигурная кавычка, V8 хранил всю строку в UTF-16. Из-за этого регулярные выражения подсветки шли по медленному двухбайтовому пути. Исправление уложилось в двадцать строк: перед подсветкой блок кода копируется в однобайтовую строку.

Одновременно работало больше ста пятидесяти тредов. Отдельный тред выдавал пятьдесят, иногда сто PR, и новые треды всё чаще открывал сам Claude. В самые загруженные дни вливалось больше двухсот изменений, а примерно треть PR добавляла телеметрию или защитные проверки. Shelley, инженер из этого канала, называет модель «демоном цифр».

Счёт инструкций на сборке дерева сообщений упал на 48%

Задержку пользователь ощущает по времени на часах, но миллисекунды слишком шумные для проверки в CI. Sam спросил, нельзя ли считать инструкции JS. Claude предложил прогонять чистые JS-пути под Valgrind с node --predictable и сравнивать с сохранённой базой за один прогон, а в браузере считать коммиты React, пересчёты стилей и мутации DOM.

Каждый бенчмарк должен был доказать связь с реальной задержкой. В сборке дерева сообщений четверть инструкций уходила на мегаморфные поиски по словарю: один ID сообщения разрешался трижды. За час Claude сократил инструкции там на 48%, а на сканере строк статуса Claude Code на 31%. Время по часам упало на 78% и 44% соответственно.

Дальше включался храповик. PR, поднявший счёт инструкций на этих путях, валил CI, а ежедневная задача опускала потолок, когда счёт снижался. Как трещотка в гаечном ключе, он крутится только в одну сторону.

Цифры приводит сама команда. По её словам, работали через Claude Tag в бете на внутренней исследовательской модели, примерно сравнимой с Opus 5.5. О результатах на общедоступных моделях в материалах ничего не сказано. На наш взгляд, ценнее всего здесь правило выкидывать бенчмарки, не доказавшие связи с задержкой: без него Claude оптимизировал бы цифры, которых пользователь не чувствует.

Тринадцатая цель и бета Claude Tag

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