Оптимизация PageSpeed помогает сайту быстрее загружаться, поддерживать удобство пользователя и усиливать SEO. Google PageSpeed Insights измеряет Core Web Vitals на мобильных устройствах и компьютерах. Для ранжирования важна общая полезность страницы, а скорость загрузки входит в оценку качества. Сервис PageSpeed Insights предоставляет информацию о том, как сайт воспринимается в интернете поисковыми системами и пользователями. Проверка сайта в Google PageSpeed Insights помогает понять, какие факторы дают наибольшее значение для роста трафика и повышения видимости в поиске. Google PageSpeed Insights полезный инструмент для первичного анализа: показатели Google PageSpeed и показатели PageSpeed Insights отражают разные стороны производительности. Эта информация по сравнению с одиночным замером позволяет увидеть факторы, которые требуют внимания; в статье далее рассмотрим принципы приоритизации. В тексте статьи внимание уделено набору факторов, которые определяют видимость, повышение скорости и условия для увеличения трафика компании. Стабильная скорость страницы сокращает время ожидания и помогает посетителю быстрее перейти к следующему действию.
Содержание
- Ключевые выводы
- Что такое PageSpeed и почему это важно для сайта
- Ключевые метрики и показатели PageSpeed: как читать баллы и оценки
- Оптимизация изображений — быстрый способ значительно ускорить загрузку страницы
- Оптимизация кода HTML, CSS и JavaScript для ускорения сайта
- Настройки сервера и хостинга для ускорения загрузки страниц
- Дополнительные техники оптимизации PageSpeed
- Практический чеклист: проверка и улучшение PageSpeed сайта
- Часто задаваемые вопросы об оптимизации PageSpeed
- Источники
Ключевые выводы
- Google PageSpeed Insights бесплатно анализирует страницу.
- Core Web Vitals учитываются системами ранжирования Google.
- Приоритетны сжатие изображений, кэширование и оптимизация кода.
- Мобильные и десктопные показатели проверяются отдельно.
- Цель работ — зеленая зона Core Web Vitals.
Что такое PageSpeed и почему это важно для сайта
PageSpeed — скорость загрузки и отклика страницы сайта. Google подтверждает: Core Web Vitals используются системами ранжирования. Бесплатный сервис Google PageSpeed Insights помогает оценить пользовательский опыт, производительность и приоритеты SEO. Сервис PageSpeed работает с URL и позволяет начать проверку без установки программы. Чтобы понять, как работает PageSpeed для разных страниц, необходимо учитывать тип продукта, целевые запросы, объем контента и сравнение с условиями конкурентов. Компания получает основу для решения, когда сопоставляет целевые показатели с реальным поведением посетителей. На коммерческих страницах скорость страницы влияет на восприятие каталога, формы и контактов.
Google PageSpeed Insights: как работает инструмент и что он анализирует
Google PageSpeed Insights — инструмент, который анализирует веб-страницы в двух режимах. Field Data показывает показатели реальных пользователей из Chrome UX Report, а Lab Data воспроизводит контролируемую проверку Lighthouse. В начале аудита специалисты сопоставляют полевые данные, оценку производительности и причины задержек в отчете URL. PageSpeed Insights использует информацию Chrome UX Report и Lighthouse, поэтому Field Data показывает картину на основе реального трафика, а Lab Data полезен для отладки нового кода. Такой анализ позволяет найти моменты, в которых медленно отображаются элементы, и получить список параметров для дальнейших действий. Программа Lighthouse дает наглядную картину для отладки; к примеру, по ее данным можно начать изучение самых тяжелых ресурсов. После публикации изменений скорость страницы проверяют на целевом URL и типовых шаблонах.
Как читать разделы отчёта PageSpeed Insights: рекомендации, диагностика и пройденные проверки
Раздел «Рекомендации» показывает, что исправить и сколько секунд можно сэкономить. «Диагностика» объясняет слабые места. «Пройденные проверки» фиксируют качественные настройки. Чтобы интерпретировать аудит, приоритизация начинается с рекомендаций с наибольшей экономией времени. В рекомендациях PageSpeed Insights сначала рассматривают пункты по величине потенциальной экономии. Затем проверяют описание, комментарии и пройденные проверки: такой порядок помогает объединять технические решения без лишних изменений. Приоритизация подсказывает, какая скорость страницы необходима для первого экрана и для второстепенного контента.
Влияние скорости загрузки на SEO, позиции и удобство пользователя
Core Web Vitals используются Google в ранжировании с 2021 года. Медленная загрузка влияет на конверсии: Akamai связывает 100 мс задержки со снижением на 7%. Влияние определяется не только скоростью: поисковые системы учитывают качество контента, технический уровень, удобство и вероятность отказов. В результате оптимальное время загрузки способствует увеличению целевого трафика, росту конверсии и видимости в выдаче. Скорость страницы в сочетании с качеством материалов уменьшает вероятность возврата пользователя в поисковую выдачу.
- SEO: Google ранжирует качество.
- Яндекс: качество и удобство.
- Индексация: робот быстрее обходит.
- Выдача: позиции среди конкурентов.
Ключевые метрики и показатели PageSpeed: как читать баллы и оценки
Метрики — язык, которым Google PageSpeed Insights сообщает о производительности. Core Web Vitals отражают опыт пользователя, Lighthouse формирует лабораторные данные. Показатели PageSpeed Insights дают основу для сравнения разных версий и помогают понять, какой параметр становится приоритетным. Измерения проводят по шкале, а цифры рассматривают вместе с данными реальных посетителей. Оценка показывает, насколько скорость страницы соответствует условиям мобильной сети и мощности устройства.
Core Web Vitals: LCP, INP и CLS — что означают метрики пользователя
LCP, Largest Contentful Paint, показывает, когда отобразился элемент контента; цель — до 2,5 секунды. INP измеряет задержку отклика после клика, как ответ кассы; цель — до 200 мс. CLS, Cumulative Layout Shift, фиксирует сдвиг блоков; до 0,1 означает стабильное отображение. Они определяют оценку Core Web Vitals. Значение каждой метрики зависит от типа страницы: для фотографии, видео или крупного блока товара LCP может быть главным ограничением. Важно учитывать размер пространства, которое резервируется под медиа, чтобы не допускать смещений при отображении. Для карточки товара скорость страницы зависит от веса главного изображения, шрифтов и внешних скриптов.
Метрики лабораторных данных PSI: FCP, Speed Index, TTI и TBT
FCP, First Contentful Paint, отмечает первый текст или изображение; ориентир — до 1,8 секунды. Speed Index оценивает заполнение экрана; до 3,4 секунды, а задержка при хорошем LCP часто связана со стилями или шрифтами. TTI, Time to Interactive, показывает готовность к взаимодействию и исключён из баллов Lighthouse 10; ориентир — до 3,8 секунды. TBT, Total Blocking Time, до 200 мс: высокий показатель указывает на тяжёлый JavaScript. Это диагностика причин, не сигнал ранжирования. При изучении отчета полезно сопоставить TBT с количеством запросов и тяжёлых библиотек. Такой механизм диагностики показывает, на каком этапе выполнение скриптов мешает получить быстрый отклик. Скорость страницы становится стабильнее, когда медиа и блоки интерфейса имеют заранее заданные размеры.
- FCP. Первый текст или изображение появляется на экране; ориентир — до 1,8 секунды.
- Speed Index. Оценивает визуальное заполнение экрана; ориентир — до 3,4 секунды.
- TTI. Показывает готовность к взаимодействию; в Lighthouse 10 не влияет на итоговый балл.
- TBT. Показывает время блокировки основного потока; ориентир — до 200 мс.
Как интерпретировать оценку PageSpeed: от 0 до 100 баллов
0–49 баллов — красная зона, 50–89 — оранжевая, 90–100 — зелёная. Оценка Lighthouse меняется между запусками из-за сетевой симуляции. Сайту не требуется 100: аналитика, реклама и внешние сервисы влияют на результаты. Зеленая зона служит ориентиром, однако добиться одинаковых цифр во всех запусках невозможно. На результат в разной степени влияют мощность оборудования, провайдер, кеширование, география, время измерения и состояние внешних ресурсов. При повторной проверке скорость страницы сопоставляют с предыдущими результатами, а не с единичным замером.
| Баллы | Зона | Значение |
|---|---|---|
| 0–49 | Красная | Низкая производительность |
| 50–89 | Оранжевая | Есть потенциал для улучшения |
| 90–100 | Зелёная | Хороший лабораторный результат |
Разница между показателями для мобильных устройств и компьютеров
Мобильные показатели ниже: сервис моделирует медленный процессор и ограниченную 4G-сеть. При mobile-first индексировании Google использует мобильную версию страницы для индексации и ранжирования, поэтому мобильный аудит имеет приоритет. Приоритет мобильной версии особенно заметен в поисковиках, где алгоритм оценивает доступность на небольшом экране. Для проверки используют несколько устройств и сохраняют запись результатов, чтобы увидеть динамику после обновления. Мобильная скорость страницы требует отдельного контроля после обновления CMS, шаблона и подключаемых модулей.
Оптимизация изображений — быстрый способ значительно ускорить загрузку страницы
На визуально насыщенных страницах изображения нередко составляют 60–80 % общего веса, поэтому их оптимизация быстрее всего сокращает загрузку и улучшает LCP. Для большинства сайтов именно фотографии каталога, баннеры и видео формируют основной объем данных. Их уменьшение часто дает максимальный эффект уже на первом этапе. Скорость страницы растет после уменьшения размера баннеров и приоритизации LCP-изображения.
Переход на современные форматы изображений: WebP, AVIF и другие альтернативы
WebP обычно легче JPEG на 25–35 % при сопоставимом качестве, AVIF часто ещё на 20 % компактнее WebP. Конвертировать файлы помогают Squoosh, Convertio и ShortPixel. Для старых браузеров задают JPEG-резерв через picture. Выбор формата зависит от назначения: PNG остается полезным для графики с прозрачностью, JPEG — для некоторых фотографий, WebP и AVIF — для большей части веб-контента. Современные технологии конвертации позволяют сохранить оптимальное соотношение размера и качества. Для страницы каталога скорость страницы улучшается, когда фотографии загружаются в подходящем для устройства размере.
| Формат | Подходит для | Поддержка | Практическое применение |
|---|---|---|---|
| JPEG | Фотографии без прозрачности | Широкая поддержка | Базовый формат для фото |
| PNG | Графика и прозрачный фон | Широкая поддержка | Больше вес при сложных фотографиях |
| WebP | Фото, графика, прозрачность | Поддерживают современные браузеры | Обычно компактнее JPEG |
| AVIF | Фото и сложная графика | Поддержка современных браузеров | Часто даёт дополнительное уменьшение размера |
Сжатие изображений без потери качества: инструменты и настройки
TinyPNG/TinyJPG, Squoosh и ImageOptim подойдут для ручной обработки; ShortPixel и Smush — для WordPress. Lossy уменьшает размер с небольшой потерей детализации, lossless сохраняет качество, но весит больше. Практичный старт — 75–85 % lossy; PageSpeed Insights показывает потенциальную экономию в КБ. Перед публикацией рекомендуется сжать исходник и проверить итоговый объем на реальном устройстве. Инструмент позволяет установить настройки по умолчанию, но для карточки продукта и главного баннера лучше делать отдельную проверку. Скорость страницы повышается при сжатии исходников до публикации и проверке результата на реальном устройстве.
Отложенная загрузка и правильный размер изображений для каждого устройства
Атрибут loading="lazy" откладывает загрузку картинок вне первого экрана. srcset и picture отдают подходящий размер для мобильных устройств. Важно: не применяйте lazy load к LCP-изображению или элементам первого экрана — это замедлит отображение. Для изображений ниже первого экрана lazy load снижает количество одновременных запросов. В верхней части необходимо заранее задать ширину и высоту, чтобы браузер резервировал пространство, а элементы не меняли положение. На длинных материалах скорость страницы поддерживают отложенной загрузкой медиа ниже первого экрана.
Оптимизация кода HTML, CSS и JavaScript для ускорения сайта
Настройка сборки и CMS ускоряет страницу: уменьшите файлы, снимите блокировки, разгрузите поток, удалите неиспользуемые ресурсы. Этот слой оптимизации часто можно реализовать без полного переписывания: достаточно правильно настроить сборщик, определить минимум обязательных файлов и проверить поддержку новой версии CMS. Структура страницы должна сохранять стабильное место для контента, карт и рекламных блоков.
Минификация и сжатие файлов HTML, CSS и JavaScript
Минификация убирает пробелы из кода, а сжатие уменьшает передачу. Для CMS подойдут Autoptimize и W3 Total Cache; для сборки — Webpack, Terser, CSSNano. Brotli на 15–20 % эффективнее Gzip. Для проекта на Vue Webpack помогает объединять и минимизировать модули, а для серверной части важно проверить, какие пакеты устанавливаются через apt. Такие настройки не заменяют анализ, но сокращают размер передачи.
Устранение блокирующих JavaScript и CSS-ресурсов
Обычный script останавливает построение страницы, пока браузер загружает и выполняет скрипт. Добавьте async или defer, перенесите файлы в body, критический CSS поместите в head, остальное подключайте через preload. В кейсе web.dev после defer, lazy loading и preconnect FCP снизился с 2,4 до 1 секунды. Критические ресурсы загружают в первую очередь, а менее важные — после отображения контента. Такой подход снижает риск долгого ожидания, когда основное действие пользователя зависит от стороннего кода. Для каждой страницы полезно фиксировать изменения сборки и дату повторной технической проверки.
Пример подключения JavaScript без блокировки отрисовки
<script src="/local/js/catalog.js" defer></script>
<script src="https://example-cdn.ru/widget.js" async></script>Минимизация работы в основном потоке браузера
Main Thread выполняет одну задачу за раз: задачи JavaScript свыше 50 мс увеличивают TBT и задержки отклика. Разбивайте выполнение через setTimeout, применяйте Web Workers и Code Splitting. Категории скриптов показывает Diagnostics PageSpeed Insights. При отладке в DevTools следует выделить самые длинные задачи и разделить их на фрагменты. Это позволяет браузеру отвечать между вычислениями и повышает эффективность интерфейса. Порядок загрузки страницы определяют по влиянию элементов на первый рендер и взаимодействие с пользователем.
Удаление неиспользуемого кода и лишних библиотек: практические рекомендации
Coverage в Chrome DevTools находит неиспользуемый CSS и JavaScript; удалите лишние exports через Tree Shaking при сборке. Перед изменением проверьте staging-версию: сценарий может задействовать библиотеку. Тяжёлый jQuery нередко заменяется нативным API браузера. Перед очисткой полезно изучить направления использования каждой библиотеки, ссылки из шаблонов и комментарии разработчиков. Никакой автоматический алгоритм не заменяет тест на staging, особенно в сервисах с динамическими сценариями. Перед очисткой страницы тестируют форму, фильтры, корзину и переходы к целевым действиям.
Настройки сервера и хостинга для ускорения загрузки страниц
Фронтенд на медленном сервере похож на отполированный автомобиль с неисправным двигателем: сначала устраняют задержки ответа, затем измеряют эффект в PageSpeed Insights. Качество хостинга определяет основу ответа: даже идеальный фронтенд не компенсирует долгую обработку на стороне сервера. Поэтому выбор провайдера и тарифа оценивают до изменения шаблонов. Для страницы с высокой посещаемостью хостинг проверяют под нагрузкой, близкой к реальному трафику.
Кэширование браузера и серверное кэширование: правильная настройка
Cache-Control сообщает браузеру, когда не загружать CSS, JavaScript и изображения повторно. Для статических ресурсов задают срок до года и добавляют хеш к имени при обновлении. Redis, Memcached и Varnish хранят готовые ответы; в WordPress помогают WP Rocket и W3 Total Cache. Кеширование браузера и кеширование на стороне сервера решают разные задачи. Для статических документов рекомендуется кэшировать данные максимально долго, а для динамических страниц задавать правила обновления по событию, например после изменения цены или наличия.
CDN для ускорения доставки контента пользователям
Без CDN все запросы идут к одному исходному серверу. Cloudflare, Fastly, BunnyCDN и AWS CloudFront выдают копии контента из ближайшего узла, сокращая сетевые задержки; у Cloudflare есть бесплатный тариф. CDN особенно полезен компаниям с посетителями из разных регионов: технология сокращает путь между пользователем и копией ресурса. При выборе услуги учитывают количество узлов, доступные контакты, поддержку, страницу «Политика конфиденциальности» и условия тарифа. Для страницы с видео и картами CDN уменьшает задержки при получении статического контента.
Время ответа сервера (TTFB): диагностика и сокращение задержек
Практический ориентир: TTFB до 200 мс даёт хороший запас, до 500 мс приемлемо, свыше 600 мс требует аудита. Причины: shared hosting, тяжёлый PHP, медленные запросы базы, нет кэша. Настройте page cache, оптимизируйте базу или перейдите на VPS. Для проектов на PHP, Oracle или других корпоративных платформах дополнительно проверяют очереди, медленные запросы и настройки базы. Важно сравнивать показатели до и после изменений, чтобы решение основывалось на данных, а не на предположениях. Время ответа страницы измеряют отдельно для главного URL, карточек товаров и страниц услуг.
Дополнительные техники оптимизации PageSpeed
После устранения главных рекомендаций Google PageSpeed Insights эти дополнительные техники формируют следующий уровень: они закрепляют улучшения и помогают превратить хорошую производительность страницы в отличную. Это направление применяют после базовых работ: оно помогает использовать возможности браузера, повысить скорость без отказа от нужных услуг и подготовить сайт к новым сценариям.
Оптимизация шрифтов и управление их загрузкой
FOIT — период, когда текст невидим до загрузки шрифта. font-display: swap сразу показывает системный вариант. Самостоятельное размещение WOFF2 вместо Google Fonts уменьшает внешние DNS-подключения и даёт полный контроль над кэшированием и версиями файлов. Это особенно полезно, когда очень тяжелые гарнитуры сильно влияют на первый рендер. Перед подключением нового гарнитурного набора следует проверить, насколько он влияет на LCP и какую поддержку имеет в старых версиях браузеров. Для проекта с большим количеством языков выбирают минимальный набор начертаний. Для новой страницы шрифты и внешние подключения оценивают до публикации изменений.
Влияние стороннего кода на производительность: Яндекс.Метрика, GTM и аналитика
Яндекс.Метрика, Google Analytics, GTM, пиксели социальных сетей и чаты зависят от внешних серверов, поэтому их отклик непредсказуем. Регулярно удаляйте неактивные скрипты, важные подключайте после первого контента, а GTM используйте для централизованного управления; вклад покажет PageSpeed Insights. Перед удалением тега необходимо найти его назначение в документах, GTM и отчетах аналитики. Некоторые скрипты связаны с формами, контактами, политикой конфиденциальности или источниками трафика, поэтому их использование оценивают по данным. На странице с аналитикой и формами оценивают вклад каждого внешнего тега в загрузку.
Предзагрузка ресурсов и настройка приоритетов загрузки контента
preload запрашивает текущий LCP-ресурс заранее, prefetch готовит ресурс для следующего перехода, preconnect открывает соединение с нужным доменом. Предзагрузка главной картинки, шрифта или ресурса CDN может улучшить LCP, однако её назначают только действительно приоритетным файлам после проверки. В зависимости от целевой страницы preconnect используют для CDN, а preload — для LCP-изображения, шрифта или CSS. Предзагрузка требует точности: лишний запрос конкурирует с контентом первого экрана и снижает эффективность.
Пример предзагрузки LCP-изображения и раннего соединения с CDN
<link rel="preload" as="image" href="/upload/hero.webp">
<link rel="preconnect" href="https://cdn.example.ru" crossorigin>
Работа с рекламой и виджетами без потери производительности
Фасад YouTube заменяет тяжёлый проигрыватель превью до клика. Для рекламы, карт и виджетов резервируют место: это предотвращает сдвиг интерфейса и снижает CLS. Фасад можно сделать для видео, карт и тяжелых рекламных блоков. Пользователь получает превью, а полнофункциональный виджет загружается по действию; таким образом сокращается начальный объем передачи.
Практический чеклист: проверка и улучшение PageSpeed сайта
Знания дают результат, когда их переводят в повторяемый процесс: сначала проверка, затем приоритизация и контроль изменений. Ниже приведен список действий, который позволяет перейти от общего отчета к понятному плану. Его удобно сохранять в закладки блога или технические документы проекта, чтобы возвращаться после каждого обновления.
Пошаговый аудит с помощью PageSpeed Insights и дополнительных инструментов
- Запустите Google PageSpeed Insights для мобильной версии.
- Сверьте результаты с GTmetrix.
- Изучите полевые данные Chrome UX Report.
- Откройте Performance в Chrome DevTools.
- Проверьте Coverage на лишний код.
- Запустите WebPageTest и изучите waterfall.
Частые причины медленной загрузки и способы устранения
| Ошибка | Решение | Ожидаемый эффект |
|---|---|---|
| Неоптимизированные изображения | WebP и сжатие | Меньше веса |
| Нет кэша | Cache-Control | Повторные визиты быстрее |
| Блокирующие CSS/JavaScript | defer | Ранний рендер |
| Большой DOM | Сократите элементы | Легче отрисовка |
| Лишние запросы | Объедините ресурсы | Меньше задержек |
| Нет Brotli/Gzip | Включите сжатие | Быстрее передача |
| Внешние скрипты | Загрузите позже | Ниже TBT |
Большинство замедлений повторяется на разных сайтах, поэтому сначала устраняют самые частые пункты. После каждого исправления проводят повторный анализ: это позволяет понять, насколько изменение улучшило результаты и какие параметры остались в конце списка.
Часто задаваемые вопросы об оптимизации PageSpeed
Нет. Оценка 100 — лабораторный результат Lighthouse, который меняется между запусками и не описывает весь опыт посетителя. Для коммерческой страницы важнее стабильно проходить Core Web Vitals, быстро показывать главный контент и сохранять рабочую аналитику. Балл 90+ полезен как ориентир, не как самоцель. Для оценки пользы смотрят на динамику LCP, INP и CLS, а также на то, как быстро пользователь может начать путь к целевому действию. Максимально высокий балл без полезного содержания и стабильной работы форм не является бизнес-целью.
Проверку проводят перед запуском, после изменений шаблона, плагинов, рекламы или аналитики, а затем не реже раза в месяц. Для крупных проектов полезен автоматический мониторинг. Полевые данные Chrome UX Report обновляются в скользящем 28-дневном окне, поэтому влияние доработок на пользователей оценивают не в день релиза. Частота зависит от количества релизов: после каждого нового шаблона, рекламной кампании или изменения условий хостинга необходимо повторить измерения. При стабильной версии достаточно контроля по расписанию, чтобы получать данные для дальнейшего изучения и принятия решений.
В Google хороший page experience и Core Web Vitals согласуются с тем, что стремятся поощрять основные системы ранжирования. Это один из множества сигналов, а не гарантия позиций. Яндекс также рекомендует сокращать блокирующие ресурсы и HTTP-запросы, оценивая полезность и удобство сайта для аудитории. Скорость сама по себе не заменяет релевантность, ссылки, экспертность и другие факторы. Однако в конкурентных направлениях техническое качество помогает поисковым роботам быстрее получать документы и пользователям реже возвращаться к поиску.
Для Google первична мобильная версия: переход на mobile-first indexing завершён, и Googlebot использует её для обхода и индексации. Поэтому мобильный отчёт PageSpeed Insights проверяют первым. Десктопную оценку также контролируют, поскольку она влияет на удобство посетителей и конверсию с компьютеров. Для решения полезно сравнить долю мобильного и десктопного трафика, но приоритет проверки остается за телефоном. Так компания получает более точную картину по большинству сценариев в интернете.
Часть задач доступна без разработчика: конвертация картинок в WebP, сжатие файлов, чистка неактивных плагинов, подключение кэширования через CMS и аудит внешних тегов. Однако оптимизация сервера, критического CSS, JavaScript и шаблонов требует тестирования, участия технического специалиста и проверки результатов после публикации. Без разработчика можно сделать базовые шаги, но любые правки кеша, шаблонов и серверной конфигурации должны проходить проверку. Исполнитель должен подготовить отчет, список рекомендаций и передать его техническому специалисту.
GTmetrix помогает сравнить показатели и увидеть приоритеты, WebPageTest показывает водопад запросов, Chrome DevTools раскрывает Long Tasks и Coverage. GTmetrix служит дополнительным аналогом лабораторной проверки, а исследования реального опыта дополняет Chrome UX Report. Lighthouse подходит для локальной диагностики, а Chrome UX Report фиксирует реальный пользовательский опыт. Вместе они объясняют, что замедляет страницу и где начинать оптимизацию. Для глубокого анализа используют несколько источников: результаты PSI, сетевые диаграммы, данные браузера и серверные логи. Такой подход дает возможность увидеть степень влияния каждого фактора, сравнить коэффициенты и выбрать оптимальное решение. Перед повторным запуском рекомендуется написать в рабочей записи URL, дату, устройство, версию, показатели и принятое решение.
