Chrome DevTools
Chrome DevTools — это набор инструментов, встроенных в браузер Google Chrome, для создания и отладки сайтов. С их помощью можно просматривать исходный код сайта, отлаживать работу frontend: HTML, CSS и JavaScript. Также DevTools позволяет проверять сетевой трафик, быстродействие сайта и многое другое.
Как начать работу с DevTools
Инструмент используют инженеры по тестированию, веб-разработчики и другие специалисты. Открыть DevTools из браузера Google Chrome можно тремя способами:
Какие вкладки есть в DevTools
Elements. Здесь отображается весь HTML- и CSS-код открытой страницы. На данной вкладке можно просмотреть и внести исправления в файлы CSS и JavaScript, изменить элементы DOM (программного интерфейса (API) для HTML- и XML-документов). Отредактировать HTML-элементы на странице, открытой в браузере, можно, кликнув по нужному элементу правой кнопкой мыши и выбрав пункт Edit as HTML. Изменения можно наблюдать в режиме реального времени. Манипуляции отображаются только в браузере и не видны другим пользователям. Для того чтобы применить исправленное, необходимо поработать с соответствующими файлами на веб-сервере.
Console. Консоль позволяет смотреть вывод JavaScript, а также исполнять свой код для тестирования и отладки страницы. Если на открытой странице не подгрузились какие-либо данные, например стили, шрифты или картинки, здесь отобразятся соответствующие ошибки с подробным описанием. Также в консоль можно ввести команду на языке JavaScript, и она выполнится.
Sources. Вкладка отображает загруженные файлы из всех источников, к которым обращался сайт. В большей степени она используется при отладке кода, позволяет увидеть все файлы и просмотреть их содержимое. Sources можно использовать в качестве полноценного редактора кода, получив доступ к локальным файлам через Workspaces.
Network. На вкладке отображаются сетевые запросы, который делает сайт. Как правило, ее используют при оптимизации скорости загрузки страницы, а также для мониторинга выполняемых запросов. Запросы к данным представлены в виде таблицы. Сверху расположены инструменты: очистка таблицы, включение и отключение записи запросов и другие. Под таблицей можно увидеть количество запросов, общее время загрузки всех данных, время загрузки DOM и ресурсов, участвующих в отображении текущей страницы.
Performances. Вкладка отображает нагрузку, которую создает сайт на компьютер пользователя. Здесь можно увидеть показатели FPS, загрузки CPU и сетевые запросы, необходимые данные и инструменты для повышения производительности страницы. На панели есть таймлайн использования сети, выполнения JavaScript и загрузки памяти. После первого построения таймлайнов можно найти данные о всем жизненном цикле страницы и выполнении кода.
Также можно посмотреть время исполнения отдельных частей кода и выбрать конкретный период на шкале, чтобы увидеть, какие процессы происходили в этот интервал. Все это позволяет проанализировать каждое событие, которое происходило в момент загрузки или во время взаимодействия с пользователем.
Memory. Здесь расположено несколько инструментов, которые помогают отслеживать, какую нагрузку на систему оказывает выполнение кода:
Application. Панель, где можно быстро очистить хранилище и кэш, а также управлять базами данных.
Security. Отвечает за надежность ресурса. Здесь можно получить информацию о данных протокола и сертификата безопасности, если они есть. Также, если источник небезопасный, узнать, какие именно запросы не защищены. Поэтому этот инструмент, как правило, используется для решения проблем со смешанным контентом и другими подобными задачами.
Lighthouse. На этой вкладке можно проверить производительность сайта.
Каждый из показателей оценивается по шкале 100 баллов. Также для удобства оценка имеет цвет: зеленый — от 90 до 100 баллов, оранжевый — от 50 до 89 баллов, красный — ниже 49 баллов.
Начните свой путь в IT
Попробуйте себя в программировании, аналитике данных, Data Science и других востребованных специальностях — получите все курсы для входа в IT по цене одного.
Основные инструменты и как их использовать
Поиск нужного DOM-элемента. На панели Elements находится полное DOM-дерево, которое можно просмотреть и изменить. Найти конкретный элемент можно двумя способами.
1. Выбор элемента на странице
Необходимо навести курсор, например на картинку на сайте, нажать правую кнопку мыши и выбрать «Просмотреть код». В DOM-дереве код выбранного элемента будет подсвечен.
2. Использование функции поиска HTML-компонента
Для этого надо кликнуть по кнопке со стрелкой в левом верхнем углу консоли, а затем — по необходимому элементу на странице.
Редактирование HTML. В консоли отображаются абсолютно все элементы: div, section, footer и т. д. Чтобы, например, изменить текст, достаточно кликнуть по нему два раза. Такие же действия доступны для классов и типов данных. Чтобы редактировать конкретную часть кода, нужно кликнуть по имени класса или самому слову class. Помимо этого, можно редактировать сразу большой участок текста или, например, названия атрибутов. Необходимо просто кликнуть правой кнопкой мыши по необходимому элементу и выбрать нужную опцию.
Работа с CSS. Под редактором HTML располагается консоль работы со стилями. В Chrome DevTools можно отключать и включать любое свойство одним кликом по чекбоксу слева. Также именно Chrome DevTools имеет удобную палитру для выбора оттенка цвета и позволяет настраивать угол наклона градиента. Здесь представлена визуализация отступов элемента, поэтому можно с легкостью настроить положение одного объекта относительно других. Это далеко не полный список всех удобных функций.
Поиск и исправление «мертвого» кода. Иногда в файлах CSS и JavaScript содержится много кода, который присутствует, но нигде не используется. Его наличие напрямую влияет на производительность сайта. В Chrome DevTools для этого предусмотрен инструмент Coverage. На панели со всеми основными вкладками (Elements, Console и т.д.) с правой стороны есть три точки. Необходимо кликнуть по ним и выбрать More Tools, где расположен Coverage. Внизу появится новая вкладка, где представлены данные о неиспользуемых CSS и JavaScript в процентном выражении. Если кликнуть по одному из них, можно увидеть все строки кода с цветовым обозначением: красные — используемые, синие — неиспользуемые. Чтобы повысить производительность сайта, нужно убрать неиспользуемый код.
Структурирование кода. Код, в котором отсутствуют «мертвые» элементы, улучшает производительность сайта, но сложен для восприятия (иногда бывают удалены даже пробелы и переносы строк). Chrome DevTools позволяет его структурировать. На вкладке Elements необходимо выбрать любой минифицированный ресурс (CSS, JS или HTML), после чего в новой вкладке отобразится содержимое, а снизу появится иконка с изображением фигурных скобок. Нажав на них, Chrome DevTools структурирует код, который подходит для внесения каких-либо изменений.
Chrome DevTools: Хитрости при отладке
В сети полно обзоров Chrome DevTools, которые демонстрируют многочисленные возможности этого прекрасного инструмента. DevTools настолько большие, что познать их полностью, как мне кажется, уже почти невозможно.
В этой заметке я бы хотел остановиться на различных нюансах, полезных при отладке. Какие-то из них я почерпнул в сети (например в комментариях на Хабре), до каких-то додумался сам. Надеюсь вы найдёте для себя что-нибудь полезное.
Все горячие клавиши в статье будут даны для linux/windows.
PopUps, popovers, dropdowns и прочие «всплывашки»
Вот простое решение (upd: вот решение получше от @kamre):
Запускаем: setTimeout(‘debugger;’, 3_000)
Успеваем за эти три секунды активировать всплывашку
debugger тормозит вкладку
Всплывашка в вашем полном распоряжении
Активируем скриншот-утилиту (например. кнопка PrintSrcreen на Windows)
Передвигаем курсор за пределы страницы (например на панель devTools)
Отменяем скриншот (Esc?)
Всплывашка в вашем полном распоряжении
Бесконечный цикл
Находим искомую вкладку в списке, выделяем.
Жмём кнопку «End Process». Вкладка убита.
Хорошо, а что если мы не хотим её убивать?
Теперь вы в процессе отладки JS. Самое время понять причину бага. Разобрались? Отлично. Что дальше? Вы хотите вернуть эту же вкладку к жизни, потому что на странице есть важные данные или условия для эксперимента? Но вам мешает этот чёртов вечный цикл?
Просто «сломайте» код. Во время отладки вы можете запускать произвольный JS код в консоли. При этом у вас есть доступ к локальным переменным того участка кода, который сейчас остановлен.
Деактивация breakpoint-а
Небольшой нюанс, о котором знают не все. Поэтому я решил добавить его в подборку. Дело в том что breakpoint-ы можно не только добавлять и удалять, но и деактивировать. Для этого у вас есть три способа:
Вот эти галочки справа:
Вот это контекстное меню:
Просто Shift + LeftClick по панели breakpoint-а:
Логирование при помощи breakpoint-ов
upd: Оказалось, что для логирования есть отдельная опция «Add logpoint»:
HotFix-ы посредством breakpoint-ов
Механизм тот же самый. Предположим вы отлаживаете один баг, но в процессе отладки обнаружили другой, который всё портит, и вы не хотите на него отвлекаться. А ещё вы не хотите перезагружать вкладку, т.к. эту ситуацию вы потом уже не воспроизведёте. Что делать? Можно в breakpoint-условии написать что-нибудь, что чинит второй баг.
Таким образом можно добиться очень многого. Зависит уже от вашей фантазии и сложности отладки. Ключевое:
нет нужды перезагружать вкладку (это может быть бесценным).
breakpoint-условие будет послушно запускаться всякий раз когда JS-интерпретатор будет добираться до breakpoint-а. По сути это аналогично тому что вы добавили строку кода ровно туда, куда нужно, ничего по факту не добавляя.
Breakpoint посреди строки
Не все замечали, но Chrome DevTools позволяют выставить breakpoint не на всю строку, а в какую-нибудь её часть:
Это может сэкономить вам кучу времени.
Имена собственные
Если вы используете sourceMaps, то код, которые на самом деле исполняется, и тот который вы видите перед глазами могут очень сильно отличаться. В частности это касается имён локальных переменных. Пример:
И как теперь это дебажить? А чёрт его знает. Но могу дать пару советов.
1-й: поищите настоящие имена вот здесь:
upd от @extempl: не всегда новые наименования это одна\две буквы. К примеру для поддержки ES6 Import/Export webpack даёт вот такие длинные названия:
2-й: отключите sourceMaps (это можно делать live, без перезагрузки страницы):
SourceMap очень часто усложняют отладку до уровня nightmare. У @vintage где-то (где кстати?) была хорошая статья по этому поводу. Там объясняется почему SourceMap такие плохие, когда дело касается отладки. Я сам то и дело включаю\выключаю эту галочку, в зависимости от обстоятельств.
BreakPoint-ы и PrettyPrint
Минифицированный код можно отформатировать так, чтобы с ним можно было работать:
Но очень часто даже после этого с ним невозможно работать. BreakPoint-ы ставятся куда попало (куда не кликай он появляется либо вначале файла, либо в его конце). Отладка просто сходит с ума (к примеру всегда указывает на первую строку файла).
Открыть этот локальный файл в редакторе
Отформатировать код файла (например Prettier-ом)
Сохранить (да, даже если это сторонняя библиотека)
Убедиться что пересборка webpack\rollup\whatever учла это изменение
Теперь вам не нужен DevTools-ий pretty print. Можно debug-ить напрямую.
Перехват запросов
Что делать если вы ковыряете чужой ресурс и хотите перехватить запрос. Я думаю, тут есть много рецептов. Здесь я опишу такой, который не требует никаких сторонних расширений\приложений.
Находим нужный запрос в network-вкладке и наводим на него мышью:
Кликаем по 1-й (не обязательно) из ссылок, попадая в то место, где этот запрос был вызван. Ставим точку останова. Воспроизводим нужные действия в UI, чтобы этот запрос перевызвать.
В этом месте мы можем подправить параметры ещё до того как запрос ушёл на сервер. Отсюда же можно отследить то место, где будет обработан результат запроса:
Наверняка есть и более удобные способы перехватить запрос. Поделитесь вашим рецептом в комментариях!
Race Condition
Что делать, если у вас есть сложная многостадийная асинхронная логика и с ней что-то не так. Например у вас race condition. Как проще всего воссоздать условия для его обнаружения? Я думаю, тут есть множество рецептов. Здесь я остановлюсь только на одном из них. В network вкладке есть такой dropdown:
Наверняка многие из вас им уже пользовались. Offline режим позволяет отловить ошибки при проблемах с сетью. Slow 3G проследить как быстро грузится ваш сайт при медленном интернете. Но обратите также внимание на секцию «Custom». Это заданные вручную режимы. Просто нажмите «Add» (внизу списка), чтобы добавить свой.
Какие режимы использую я?
Never: максимальная задержка. Просто выставите огромное число. Например сутки. Теперь любой запрос повисает до тех пор, пока вы не выключите этот режим. Запросы не «умирают», а именно повисают. Это даёт вам неограниченное время для отладки какой-нибудь промежуточной стадии вашей зубодробительной логики.
2\5\30sec latency: просто большая задержка. Актуальна когда вы отлаживаете «плавающий» баг. То он есть, то его нет. Или, скажем, когда вам нужно успеть сделать какое-нибудь быстрое действие мышью между двумя запросами. Или более пристально проследить что происходит, как бы в режиме slow-mo.
Disable cache
Думаю большинство из нас знакомы с этой галочкой:
Здесь я хотел бы отметить, что не стоит на постоянной основе ей пользоваться. Дело в том, что такое поведение браузера очень далеко от нормального. Браузер перестаёт пользоваться не только старым кешем, оставшимся от предыдущей страницы, но и новым. Если покажете картинку, удалите её, а потом снова создадите с тем же SRC, то у вас будет два запроса.
Если на постоянной основе всё тестировать без кеша, то многие хитрые баги, которых просто не будет при отключённом кешировании, уйдут в production. И вот там их обнаружить и отладить может быть уже не тривиально.
В целом рекомендую поглядывать на запросы во вкладке network. Например можно случайно обнаружить, что отключён gzip/brotli. Или что CDN перестал присылать cache-control заголовок. Или что ещё вчера страница загружала 1 MiB, а сегодня 12 MiB (например какой-нибудь серверный endpoint стал присылать тонны JSON-а).
HI-DPI
Что делать, если у вас обычный монитор, а клиенты жалуются на мыло на мобильных устройствах\retina экране? Для начала активируйте нужный DPR режим:
Теперь браузер имитирует HI-DPI. И всё стало таким угловатым (нюансы сглаживания при resize). Но как проверить настоящую картинку?
Открываем палитру команд ( Ctrl+P )
Ищем: capture area screnshoot
Выделяем мышью нужную область экрана, сохраняем в файл
Открываем файл и наслаждаемся огромной картинкой. Смотрим правда ли она «мыльная»?
Обычными системными скриншотами, разумеется, этого не достичь. Полагаю этот же рецепт работает и в обратную сторону (имитация 1х экрана).
Это всё?
Если вы нашли синтаксическую\стилистическую ошибку (или тонну таких ошибок) прошу обращаться в личку (а не в комментарии).
