Chrome DevTools: подробное руководство с примерами

Кнопка исчезает при наведении, запрос возвращает ошибку, таблица выходит за экран, а после нескольких открытий окна сайт начинает тормозить. Для каждой из этих задач в Chrome есть инструменты, которые показывают, что происходит внутри страницы. DevTools помогает перейти от догадки «что-то сломалось» к конкретному правилу CSS, ответу сервера или строке JavaScript.

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

Что потребуется: Chrome на компьютере, страница с воспроизводимой проблемой и несколько минут на один сценарий. Изменения CSS и HTML в инструментах обычно временные: они помогают проверить решение, но сами по себе не обновляют сайт.

На телефоне можно читать руководство и просматривать примеры. Пошаговые задания с панелями и клавиатурными сочетаниями выполняйте в настольном Chrome; проверка сайта на настоящем телефоне понадобится позже, на этапе мобильного сценария.

Учебный стенд: исследуем настоящую страницу

Ниже — практические задания с намеренно добавленными проблемами. Это учебная веб-страница, которую вы можете исследовать своими инструментами Chrome. Сам DevTools открывается в браузере посетителя; мастерская не изображает его панели и не запускает удалённую отладку.

Для упражнений удобнее открыть учебную страницу в отдельной вкладке: тогда Elements, Console и Network будут работать с её элементами и файлами. Если исследовать пример внутри встроенного окна, придётся учитывать отдельный документ и выбирать его контекст в Console. Кнопки стенда позволяют воспроизвести проблему и начать заново; подробный маршрут для каждой панели находится ниже.

Практика в браузере

Исследуйте учебную страницу

Выберите задание и откройте DevTools в Chrome. Здесь работает обычная страница с понятными исходниками и заранее подготовленными примерами.

Открыть стенд отдельно ↗

В отдельной вкладке проще найти lab.js и запросы стенда. Инструменты Chrome открываются на вашем компьютере.

Как открыть DevTools и организовать рабочее место

Начните со страницы, на которой проблема повторяется. В Windows и Linux нажмите Ctrl + Shift + I, в macOS — ⌘ + ⌥ + I. Другой способ — правый щелчок по элементу и команда Inspect («Просмотреть код»): сразу откроется Elements с нужным узлом. Для выбора другого элемента используйте Ctrl + Shift + C или соответствующую кнопку со стрелкой.

В статье используются английские названия пунктов. Перевод, расположение и набор команд зависят от языка и версии Chrome. Если панель скрыта, проверьте меню дополнительных вкладок » или откройте Command Menu: Ctrl + Shift + P в Windows/Linux, ⌘ + Shift + P в macOS. Например, команда Show Coverage открывает анализ покрытия кода.

Через меню с тремя точками выберите удобный Dock side: справа, снизу или в отдельном окне. Закреплённые сбоку инструменты уменьшают ширину самой страницы и могут включить её мобильные стили. Это полезно для проверки, но способно изменить условия воспроизведения.

Результат: нужная страница и панель открыты, проблема воспроизводится одним понятным действием. Частая ошибка: исследовать другую вкладку, забытый iframe или уже исправленное состояние. До изменений запишите ширину окна и шаги, которые приводят к сбою.

Elements: почему элемент выглядит неправильно

Представим кнопку с белым текстом на тёмном фоне. При наведении фон становится белым, и надпись исчезает. Задача — найти правило, которое управляет именно этим состоянием.

Почему Elements: панель показывает действующий DOM и применённые стили. Здесь можно сопоставить исходное правило с тем, что браузер действительно нарисовал, и проверить гипотезу сразу на элементе.

1. Выберите кнопку через Inspect. В дереве DOM будет выделен её реальный HTML-узел.
2. В Styles нажмите :hov и включите :hover. Состояние зафиксируется, даже когда указатель находится в инструментах.
3. В фильтре Styles введите background или color. Найдите правило наведения и ссылку на файл со строкой.
4. Откройте Computed, проверьте итоговые цвета и раскройте свойство, чтобы увидеть источник значения.
5. Временно измените фон или цвет текста в Styles. Снимите принудительное наведение и проверьте обычное состояние.

В собственном CSS исправление может выглядеть так:

.action {
  background: #155e63;
  color: #fff;
}
.action:hover {
  background: #0f4549;
  color: #fff;
}
.action:focus-visible {
  outline: 3px solid #e6a941;
  outline-offset: 3px;
}

Перечёркнутая декларация в Styles обычно проиграла другому правилу. Невалидное или неактивное свойство может сопровождаться предупреждением. Сначала выясните, какое правило победило, и только затем меняйте селектор: случайное добавление !important часто усложняет следующую правку.

Результат: вы знаете файл и правило, а кнопка читается в обычном состоянии, при наведении и клавиатурном фокусе. Частая ошибка: считать изменение в DevTools сохранённой правкой сайта. Обычно после перезагрузки оно исчезнет; перенесите проверенное решение в исходный CSS проекта.

Размеры, отступы, Flexbox и Grid

Если карточка шире контейнера, проблема может быть в минимальной ширине её содержимого, а не в отступах. В Elements выберите карточку, затем родительский контейнер. В Computed или диаграмме Box Model сравните ширину содержимого, padding, border и margin. Наведение на части диаграммы подсветит соответствующие области на странице.

Рядом с контейнерами Grid и Flexbox в дереве появляются значки grid и flex. Включите наложение, чтобы увидеть границы колонок, промежутки и фактическое расположение элементов. Панель Layout помогает управлять такими наложениями, когда сеток несколько.

Для двух колонок с длинными строками полезен такой исходный пример:

.catalog {
  display: grid;
  grid-template-columns: repeat(2, minmax(0, 1fr));
  gap: 16px;
}
.catalog > article { min-width: 0; }
.catalog a { overflow-wrap: anywhere; }
@media (max-width: 600px) {
  .catalog { grid-template-columns: 1fr; }
}

Проверьте длинное название, URL без пробелов и увеличенный размер текста. Временное отключение min-width или замена сетки в Styles позволяет проверить гипотезу до изменения проекта. Для таблицы горизонтальная прокрутка внутри её контейнера может быть правильным решением; для всей страницы она обычно мешает.

Результат: видна конкретная причина переполнения, а все элементы остаются доступны. Частая ошибка: поставить всему документу overflow-x: hidden. Полоса прокрутки исчезнет, но часть содержимого может остаться за экраном.

Console: проверяем значения и читаем ошибки

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

Установите нужные уровни в Log levels, уберите лишний текст из фильтра и повторите действие. Если ошибка возникает перед переходом на другую страницу, включите Preserve log. После диагностики его удобно выключить, чтобы сообщения разных загрузок не смешивались.

Для проверки данных лучше вывести небольшую таблицу:

const demoRows = [
  { title: 'Монтаж кабеля', quantity: 12, price: 180 },
  { title: 'Установка розетки', quantity: 3, price: 450 }
];
console.table(demoRows.map(row => ({
  ...row,
  total: row.quantity * row.price
})));

Выбранный в Elements узел доступен в Console как $0. Например, getComputedStyle($0).color покажет итоговый цвет. Команда copy($0.textContent) скопирует текст выбранного элемента. Это утилиты консоли DevTools; copy() и $0 не следует переносить в обычный скрипт сайта.

Результат: понятны входные данные и место сбоя. Частая ошибка: выбрать в верхнем списке контекстов top, когда исследуемый код находится во встроенном документе. Убедитесь, что работаете с нужным контекстом. Чужие команды в Console могут выполнять действия от имени текущей страницы: для обучения используйте понятные небольшие примеры.

Network: запрос ушёл, но что вернулось?

Здесь разберём ситуацию «нажал кнопку — данные не появились». Откройте Network до действия. Панель записывает запросы, пока работает; если список пуст, перезагрузите страницу или снова нажмите кнопку. Оставьте запись включённой и выберите фильтр Fetch/XHR для запросов данных.

Почему Network: сообщение интерфейса может скрывать настоящую причину. Панель позволяет независимо проверить, отправлялся ли запрос, куда именно, с какими параметрами и какой ответ вернулся. В стенде сравните загрузку data/prices.json с запросом отсутствующего файла.

1. Выполните действие один раз и найдите новый запрос. Если он не появился, переходите к Console и обработчику кнопки.
2. Посмотрите Status, Type, Size и Time. Затем откройте строку запроса.
3. В Headers проверьте URL, метод и статус. В Payload — отправленные параметры, если они есть.
4. В Preview и Response изучите содержимое. В Initiator найдите причину запуска запроса.
5. Откройте Timing, если нужно разобраться с задержкой.

Статус 200 не означает, что пришли ожидаемые данные. Вместо JSON сервер может вернуть HTML страницы входа. 404 означает, что ресурс по адресу не найден, 500 — серверную ошибку; сообщение внутри ответа часто даёт больше информации, чем один номер.

В своём приложении проверяйте ответ до использования:

async function loadCatalog() {
  const response = await fetch('./catalog.json');
  if (!response.ok) {
    throw new Error(`Не удалось загрузить каталог: ${response.status}`);
  }
  const data = await response.json();
  if (!Array.isArray(data.items)) {
    throw new Error('В ответе нет массива items');
  }
  return data.items;
}
loadCatalog().then(console.table).catch(console.error);

Результат: вы разделили сбой интерфейса, неправильные параметры и ошибку ответа. Частая ошибка: менять CSS, когда проблема в данных, или обходить CORS на стороне клиента вместо исправления разрешений и адресов на сервере.

Медленная сеть, кэш и передача HAR

В Timing длинное ожидание Waiting for server response нельзя автоматически считать временем выполнения PHP или базы данных: на него также влияют сеть и работа инфраструктуры. Долгое скачивание содержимого — другой этап. Сравнивайте одинаковые запросы несколько раз и фиксируйте условия.

Для первого посещения включите Disable cache при открытом DevTools и перезагрузите страницу. Для повторного посещения выключите этот флажок и повторите загрузку. Селектор Throttling позволяет замедлить соединение; режим Offline помогает проверить состояние без сети. Если сайт использует Service Worker, его кэш нужно исследовать отдельно в Application.

Чтобы передать коллеге сетевой журнал, воспроизведите только нужный сценарий на тестовых данных и используйте Export HAR (sanitized)…. Такой экспорт исключает, в частности, заголовки Cookie, Set-Cookie и Authorization. Однако слово sanitized не гарантирует отсутствие личных данных: параметры URL, отправленные значения и содержимое ответа тоже требуют проверки.

Просмотрите полученный HAR перед отправкой, удалите ненужные записи или запишите новый короткий журнал. Команды Copy as fetch и Copy as cURL тоже могут содержать чувствительные данные; не публикуйте их автоматически.

Результат: у вас воспроизводимый пример с условиями сети и подходящий для передачи журнал. Частая ошибка: забыть включённое замедление, Disable cache или Preserve log и потом принять изменённые условия за новый дефект.

Sources: останавливаем код и ищем неправильный расчёт

Когда Console показывает только итог, откройте Sources. Найдите свой файл через Ctrl + P или поиск по всем источникам Ctrl + Shift + F. На macOS используйте ⌘ вместо Ctrl. Нажмите номер строки, чтобы поставить точку останова — breakpoint — перед выполнением этой строки.

Почему Sources: ошибочное итоговое значение может выглядеть правдоподобно. Пауза показывает типы и значения непосредственно перед расчётом. На стенде найдите в lab-model.js функции calculateBuggy() и calculateFixed(): сравните строковое сложение и числовое умножение на одинаковых входных данных. Обработчики кнопок находятся в lab.js.

В учебном расчёте распространённая ошибка — складывать строки из полей формы:

function calculateTotal(quantityText, priceText) {
  const quantity = Number(quantityText);
  const price = Number(priceText);
  if (!Number.isFinite(quantity) || !Number.isFinite(price)) {
    throw new Error('Введите числовые значения');
  }
  return quantity * price;
}
console.log(calculateTotal('3', '450')); // 1350

Остановитесь на return, посмотрите значения в Scope и выражения в Watch. Call Stack показывает цепочку вызовов, которая привела к текущей строке. Команды Step over, Step into и Step out позволяют пройти шаг, зайти в функцию и выйти из неё. Resume script execution продолжит работу.

Результат: вы видите значения до ошибочного действия, а не пытаетесь восстановить их по результату. Частая ошибка: забыть паузу и решить, что страница зависла. Пока выполнение остановлено, обычные обработчики страницы могут не работать; продолжите выполнение и отключите ненужные breakpoints.

Условные точки, события и ошибки

Если функция вызывается много раз, правым щелчком по номеру строки выберите Add conditional breakpoint и задайте условие, например quantity < 0. Add logpoint выводит сообщение без остановки и без добавления console.log в исходный файл.

Если неизвестно, где обработчик кнопки, используйте Event Listener Breakpoints для события click. Если код незаметно меняет узел, в Elements выберите Break on → Subtree modifications. Для исключений включите Pause on uncaught exceptions; при необходимости отдельно проверяйте пойманные исключения, учитывая возможный шум библиотек.

Минифицированный файл можно сделать читаемее кнопкой Pretty print с обозначением {}. Это форматирование не восстанавливает имена переменных. Для исходного TypeScript или JSX нужны корректные source maps от сборки. Если карта отсутствует или не соответствует текущему файлу, DevTools не сможет достоверно показать исходную строку.

Performance: находим причину медленного отклика

Network объясняет загрузку ресурсов, но не всю работу страницы. Данные могут прийти быстро, а их обработка занять главный поток на сотни миллисекунд. Для такой задачи нужна панель Performance. В старых материалах встречается слово Timeline: здесь оно означает временную шкалу записи, а рабочая панель называется Performance.

1. Подготовьте состояние перед проблемным действием. Закройте лишнюю нагрузку и запишите настройки CPU и сети.
2. Нажмите Record, выполните один короткий сценарий и нажмите Stop. Для загрузки страницы используйте Record and reload.
3. На временной шкале выделите интервал задержки. Посмотрите дорожку Main: какие функции, Layout или Paint заняли время?
4. В Bottom-up найдите наиболее затратные операции. Call tree помогает понять цепочку вызовов. В актуальном интерфейсе также есть подсказки Insights.
5. Измените одну причину и повторите тот же сценарий в одинаковых условиях.

Пример повторного принудительного пересчёта размеров:

const cards = [...document.querySelectorAll('.card')];
// Плохо: запись стиля чередуется с чтением геометрии.
for (const card of cards) {
  card.style.padding = '20px';
  console.log(card.offsetHeight);
}
// Для этой задачи сначала выполняем все записи.
for (const card of cards) card.style.padding = '20px';
const heights = cards.map(card => card.offsetHeight);

Это учебная гипотеза, а не обещание ускорения любого сайта. На маленькой странице различие может быть незаметно; проверяйте реальную запись. Длинная задача главного потока способна задержать обработку клика и следующий кадр, но причина может находиться в любой части показанной цепочки.

В стенде другой небольшой эксперимент: добавление карточек по одной и через DocumentFragment. Число элементов ограничено; показанная длительность иллюстрирует этот запуск, а не служит полноценным сравнительным тестом. Найдите оба пути в записи и повторите опыт несколько раз, чтобы увидеть разброс.

Результат: найдена конкретная операция и подтверждено изменение времени. Частая ошибка: записать минуту разнородных действий, сравнить разные условия или считать любую большую функцию проблемой без привязки к пользовательскому ожиданию.

Core Web Vitals и Lighthouse: что именно мы измерили

На стартовом экране Performance доступны локальные показатели LCP, CLS и, после взаимодействий, INP. LCP относится к появлению крупнейшего содержательного элемента, CLS — к неожиданным сдвигам вёрстки, INP — к отклику на взаимодействия. Вкладки Interactions и Layout shifts помогают связать число с конкретным событием.

Для проверки CLS перезагрузите страницу и наблюдайте, не сдвигает ли поздняя картинка кнопку. Для INP повторите реальный клик, раскрытие списка или ввод, который вызывает задержку. Неизменившееся число без воспроизведения проблемного взаимодействия ничего не доказывает.

Через Field data Performance может получить данные Chrome UX Report и сопоставить их с локальным измерением. Для небольшой страницы данных может не хватить. Проверяйте, относится ли результат к конкретному URL или origin, каков период и выбран ли нужный тип устройства. Один быстрый запуск на вашем компьютере не описывает опыт всех посетителей.

Lighthouse полезен как автоматическая проверка категорий Accessibility, Best Practices и SEO; Performance позволяет подробнее исследовать причины задержек. В Lighthouse выберите режим, устройство и категории. Navigation анализирует загрузку, Timespan — интервал взаимодействий, Snapshot — текущее состояние; доступность проверок различается по режимам.

Результат: вы понимаете, какую страницу и сценарий оценивали. Частая ошибка: воспринимать оценку Lighthouse как гарантию качества или сравнивать баллы разных компьютеров. Это лабораторный тест; после исправлений нужны повторяемые измерения и наблюдения за реальными пользователями.

Memory: проверяем, остаются ли лишние объекты

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

Почему Memory: удаление элемента из интерфейса и освобождение памяти — разные события. Панель помогает найти объект и ссылку, из-за которой он продолжает существовать, вместо оценки по общему размеру вкладки.

1. На учебной странице откройте Memory, выберите Heap snapshot и нужный экземпляр JavaScript.
2. Сделайте исходный снимок кнопкой Take snapshot.
3. Несколько раз выполните цикл «создать → закрыть». Вернитесь к тому же состоянию интерфейса и сделайте следующий снимок.
4. Во втором снимке выберите представление Comparison и первый снимок для сравнения. Найдите растущие группы объектов.
5. Для подозрительного объекта исследуйте Retainers: что сохраняет ссылку на него?

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

window.demoKeptNodes = [];
function createThenRemove() {
  const box = document.createElement('div');
  box.textContent = 'Временный учебный блок';
  document.body.append(box);
  window.demoKeptNodes.push(box);
  box.remove();
}
createThenRemove();
// После исследования убираем наши ссылки.
window.demoKeptNodes.length = 0;

Слово Detached помогает найти отделённые от DOM элементы. Отсутствие узла на экране не означает, что ссылка на него исчезла. Для распределения выделений по функциям есть Allocation sampling; для последовательности выделений — Allocations on timeline.

Результат: установлена цепочка удержания и проверено её исчезновение после исправления. Частая ошибка: исследовать объект в Console, оставив на него дополнительную ссылку, или требовать одинакового размера памяти после каждого действия. Сравнивайте одинаковые циклы; снимок описывает состояние JavaScript-кучи, а не весь объём памяти вкладки.

Device Mode: проверяем ширину и мобильный сценарий

Нажмите Toggle device toolbar и выберите Responsive. Начните с ширины 390 CSS-пикселей, затем проверьте 320 и промежуточные размеры. Изменение ширины вручную часто выявляет проблему точнее, чем выбор только одного популярного телефона.

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

В меню панели устройств включите Show media queries, чтобы увидеть точки переключения CSS. Число в поле ширины относится к CSS-пикселям; масштаб предпросмотра и DPR — отдельные настройки. Если страница на телефоне выглядит как уменьшенный десктоп, проверьте исходный meta viewport.

Device Mode приближает отображение и некоторые условия мобильного устройства, но код продолжает работать на вашем компьютере. Выбор телефона в списке не запускает его процессор, операционную систему или Safari. Финально проверьте страницу на настоящем устройстве: касания, экранную клавиатуру, прокрутку, загрузку и скачивание файла.

Результат: интерфейс работает на нескольких ширинах и после изменения состояния. Частая ошибка: проверить только красивый первый экран. Большинство переполнений проявляется в диалоге, длинной строке, таблице или сообщении об ошибке.

Доступность: имя кнопки, клавиатура и движение

Для кнопки с одной иконкой выберите элемент в Elements и откройте Accessibility. Посмотрите вычисленные роль и доступное имя. Изображение корзины может быть понятным визуально, но без имени пользователь вспомогательных технологий не узнает назначение кнопки.

Вместо кликабельного div используйте настоящий элемент:

<button type="button" aria-label="Удалить позицию">
  <svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">
    <path d="M5 6h14M9 6V4h6v2M7 6l1 14h8l1-14"
          fill="none" stroke="currentColor" stroke-width="2" />
  </svg>
</button>

Затем закройте или уберите инструменты в сторону и пройдите страницу клавишей Tab. Фокус должен быть заметен, порядок — понятен, действие кнопки — доступно через Enter или пробел. Для диалога проверьте закрытие и возврат фокуса к элементу, который его открыл. Правильная роль не исправляет весь сценарий автоматически.

Через Command Menu откройте Show Rendering. В Emulate CSS media feature prefers-reduced-motion выберите уменьшенное движение и проверьте, сохраняется ли смысл интерфейса без анимации. Для текста смотрите контраст в инструменте выбора цвета и отчёте Lighthouse, а затем проверьте читаемость глазами.

Результат: у управления есть имя, клавиатурный маршрут и понятное состояние. Частая ошибка: считать отсутствие автоматических предупреждений полной проверкой доступности. Нужны ручные сценарии; для важных интерфейсов — дополнительная проверка со вспомогательными технологиями.

Application: черновики, cookies и кэш

Если редактор после перезагрузки показывает старое значение, откройте Application → Storage → Local Storage и выберите origin страницы. Найдите ключ приложения: в таблице видны строковые значения. Это помогает отличить ошибку сохранения от ошибки восстановления.

Меняйте только учебный ключ или запись, назначение которой известно. После изменения снова выполните действие на странице и проверьте результат: данные могли остаться в памяти приложения, и само редактирование хранилища не обязательно обновит интерфейс.

В Cookies исследуйте domain, path, срок действия и атрибуты. Cookie авторизации не нужно копировать в пример для коллеги. Для офлайн-ресурсов проверьте Cache Storage и раздел Service Workers; это отдельные механизмы, и отключение HTTP-кэша в Network не объясняет весь их жизненный цикл.

Для проверки чистого старта лучше использовать отдельный тестовый профиль или заранее сохранить нужный проект. Clear site data может удалить авторизацию и локальные черновики. Включённая в Lighthouse очистка хранилища тоже меняет исходное состояние теста.

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

Coverage: что загрузилось, но не использовалось

Откройте Command Menu, найдите Show Coverage и запустите запись с перезагрузкой. Не останавливайтесь на первом экране: откройте меню, диалог, фильтр и другие важные состояния. После этого нажмите остановку записи и изучите Total Bytes и Unused Bytes.

Щелчок по файлу показывает использованные и неиспользованные участки в Sources. Для большого общего набора стилей это повод проверить состав сборки: можно ли вынести код другого раздела, загружать редкий модуль по требованию или убрать действительно устаревший компонент?

Проведите отдельный прогон на мобильной ширине. Некоторые CSS-правила нужны только там; некоторые функции запускаются после второго действия, ошибки сети или входа пользователя. Покрытие ограничено тем маршрутом, который вы выполнили.

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

Local Overrides: сохраняем эксперимент до следующей загрузки

Обычные правки Elements подходят для быстрой проверки. Если нужно несколько раз перезагрузить страницу с изменённым CSS или тестовым ответом, используйте Local Overrides. Это локальная подмена ресурса в вашем браузере, а не публикация изменения на сервере.

1. В Network выберите собственный тестовый ресурс и через контекстное меню нажмите Override content.
2. Если подмены ещё не настроены, выберите отдельную папку для них и разрешите DevTools доступ к этой папке.
3. Измените открывшийся файл в Sources и сохраните его через Ctrl + S или ⌘ + S.
4. Перезагрузите страницу и проверьте результат. Убедитесь, что ресурс помечен как подменённый.
5. После эксперимента в Sources → Overrides выключите Enable Local Overrides и повторите проверку без подмены.

Изменения непосредственно в дереве DOM не сохраняются этим механизмом. Source-mapped файлы тоже имеют ограничения: для подмены исследуйте реально загружаемый ресурс или меняйте исходный проект. Подключение Overrides автоматически отключает кэш, что нужно учитывать в измерениях.

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

Как превратить находку в полезное исправление

Хорошая диагностика заканчивается проверяемым результатом. Для одной проблемы подготовьте небольшую запись:

• Условия: версия Chrome, адрес страницы, размер viewport, состояние авторизации, настройки сети и CPU.
• Шаги: какие значения ввести и какую кнопку нажать; что ожидается и что происходит.
• Доказательство: правило с файлом и строкой, ответ запроса, цепочка вызовов или небольшой профиль проблемного интервала.
• Причина и правка: что именно изменили и почему это связано с симптомом.
• Повторная проверка: исходный сценарий, соседние состояния, мобильная ширина и клавиатура.

Например: «На ширине 390 px длинный URL расширял вторую колонку. В Styles проверили minmax(0, 1fr), перенесли правило в CSS, затем повторили тест на 320, 390 и 768 px. Диалог и таблица доступны полностью». Такая запись полезнее, чем «исправил адаптивность».

Перед финальной проверкой снимите принудительные :hover, отключите лишние breakpoints, замедление, подмены и случайные фильтры. Затем заново загрузите страницу. Если исследовали память, не оставляйте учебные массивы и ссылки; если хранилище — верните понятное тестовое состояние.

Результат: исправление можно воспроизвести и оценить независимо. Частая ошибка: считать визуальный успех в DevTools готовым обновлением. Изменение должно попасть в исходники, пройти обычную сборку и проверку на той версии сайта, которой пользуются посетители.

Шпаргалка: симптом, инструмент и первый шаг