Главная страница Публикации Статьи Время — деньги. Поговорим о решениях. Тамми Эвертс

Время — деньги. Поговорим о решениях. Тамми Эвертс

«Поговорим о решениях» (Тамми Эвертс)

Перевод подготовлен:
Лавлинский Д. Е., генеральный директор ООО «Метод Лаб»
к.э.н. Лавлинский Н. Е., технический директор ООО «Метод Лаб»

Глава 4. Поговорим о решениях

Озабоченность вопросами скорости в вебе не нова. Давайте прыгнем в машину времени и ненадолго посетим 1999 год, когда компания Zona выпустила отчет("The Economic Impacts of Unacceptable Web-Site Download Speeds," Zona Research, April 1999), где предупредила интернет-магазины о риске потери 4.35 миллиардов долларов в год, если они не займутся оптимизацией скорости своих сайтов. (Также интересно, что в Zona рекомендовали 8 секунд как оптимальное время загрузки страницы для интернет-коммерции. Времена определённо изменились. На текущий момент мы знаем, что для большинства электронных магазинов оптимум времени загрузки находится около 2.5 секунд. После 4 секунд загрузки коэффициенты конверсии резко снижаются.)

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

Наша цель здесь в том, чтобы показать как эти решения развились от достаточно простых (например, добавления серверов) до всё более сложных и тонких по мере того, как мы раскрывали истинные причины плохой скорости сайтов и способы борьбы с низкой производительностью.

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

  • Сетевые задержки (количество времени, которое требуется на передачу пакета данных из точки А до точки Б).
  • Миф о том, что современные сети насколько быстрые, что больше не нужно думать о задержках.

Что такое задержки и почему вы должны о них беспокоиться?

Прежде чем говорить о решениях, будет полезно выделить некоторые основные проблемы. Если вы попросите кого-нибудь из индустрии веб-производительности назвать главные препятствия для быстрых приложений, «задержки» скорее всего будет в тройке самых популярных ответов.

Вот значительно упрощённое понятие задержек: когда вы заходите на страницу в вебе, ваш браузер отправляет множество запросов ко всем серверам, на которых хранятся ресурсы страницы (изображения, скрипты JS, сторонний контент и т. д.), чтобы сформировать её. Задержки — это время, требующееся для доставки всех этих ресурсов по каналам Интернета до вашего браузера.

Давайте посмотрим, что это значит на практике. Допустим, вы посещаете страницу, которая состоит из 100 ресурсов. Ваш браузер должен сделать 100 отдельных запросов к серверу сайта (скорее всего, к нескольким серверам), чтобы получить эти объекты. Каждый из этих запросов будет иметь задержку около 75-140 мс. Возможно, это звучит не очень страшно, но все эти задержки очень быстро накапливаются и создают проблемы. Например, когда страница может содержать 300 и более ресурсов, а задержки могут составлять до секунды для мобильных пользователей, становится понятно, когда задержки превращаются в главную проблему скорости.

Самое неприятное в задержках то, что они непредсказуемы и постоянно меняются. На них может влиять что угодно: от погоды до нагрузки на канал у соседей.

Сокращение задержек это приоритетная задача для индустрии веб-производительности. Есть несколько путей выполнения этой задачи:

  • Снизить сетевые задержки до сервера за счет размещения контента ближе к пользователям.
  • Сократить общее количество отправок пакетов туда-обратно.
  • Увеличить количество параллельных запросов от браузера к серверу.
  • Эффективно использовать кэш браузера, чтобы файлы сохранялись в нём для просмотра нескольких страниц во время визита и использовались при повторных визитах.

Задержки это не единственный вызов для скорости в вебе, но один из основных. В остальной части главы я покажу, как различные технологии ускорения борятся с задержками (и другими проблемами).

Сетевая инфраструктура (или, почему пропускная способность это не решение)

Разговор о технологиях ускорения не может состоятся без признания огромных достижений и прогресса, которых достигла инфраструктура самого Интернета.

Много воды утекло с тех пор, как в 1993 году была запущена Всемирная паутина (WWW). Тогда мы были слишком восторженны самим фактом наличия Интернета, чтобы жаловаться на его скорость. Ускорение магистральных каналов вряд ли могло бы сильно изменить восприятие веба. Для большинства из нас доступ в Интернет давал модем, работавший по телефонным линиям и обеспечивавший максимум 56 Кбит/c скорости.

Не удивительно, что даже минималистичные веб-страницы того времени, когда страница весила коло 14 КБ и содержала всего 2 ресурса, могли загружаться долго. Реальный случай: у меня есть подруга, которая училась игре на гитаре, пока ожидала загрузки страниц в вебе.

Сегодня будет простительно думать, что скоростные сети и доступные скорости подключения решили все ранние проблемы веб-производительности, но на самом деле это не так. Современные веб-страницы легко достигают 3 или 4 МБ в размере. Когда я слышу обоснование того, что такой вес страниц не проблема, основным аргументом является вера в то, что быстрая сеть смягчает все потери в скорости.

Действительно ли быстрые сети ускоряют загрузку страниц?

При том, что действительно, сети и возможности подключения значительно улучшились, есть большие заблуждения о реальной значимости этого прогресса на практике. Для примера, давайте проведём серию измерений скорости сайта Etsy. com используя систему WebPagetest. org, синтетический инструмент для измерения скорости, который эмулирует различные скорости подключения и задержки. (Если вы хотите посмотреть выводы, переходите сразу к концу этого раздела.)

Выбранная страница была протестирована с использованием 5 видов подключений, как мобильных, так и стационарных. (RTT означает roud-trip time — минимальное время, которое необходимо для отправки пакета и получения ответа, другими словами «задержка» в сети):

  • FIOS (оптика) — 20/5 Мбит/с, 4 мс RTT;
  • Cable (выделенное подключение) — 5/1 Мбит/с, 28 мс RTT;
  • DSL — 1500/384 Кбит/сб 50 мс RTT;
  • Мобильное 3G (быстрое) — 1600/768 Кбит/с, 150 мс RTT;
  • Мобильное 3G (медленное) — 780/330 Кбит/с, 200 мс RTT.

Даже при беглом взгляде на рисунок 4-1 можно заметить, что голубые столбики, означающие время загрузки, различаются гораздо меньше чем синие, которые показывают пропускную способность (ПС).

Рисунок 4-1

Рисунок 4-1. Медианные времена загрузки главной страницы Etsy. com с использованием различных типов подключений.

Рисунок 4-2 это другое представление тех же данных. Если бы предположение о том, что пропускная способность пропорциональна времени загрузки, было верным, два графика были бы зеркальными. Очевидно, что это не так.

Рисунок 4-2

Рисунок 4-2. Альтернативное представление скорости загрузки Etsy. com для различных подключений. Если бы увеличение пропускной способности пропорционально ускоряло загрузку, две части изображения были бы зеркальными.

Несколько наблюдений:

  • Хотя пропускная способность для FIOS больше на 300% по сравнению с Cable, время загрузки только на 24.6% быстрее.
  • Разница становится еще более явной, если сравнить DSL и FIOS. Пропускная способность на 1233% больше у FIOS, при этом время загрузки только на 55% меньше.
  • При том, что DSL и «3G — быстрое» имеют сравнимые значения пропускной способности, 3G на 32.5% медленнее. Основная разница между этими типами — задержки, а не пропускная способность. Для 3G это 150 мс, а для DSL — 50 мс.
  • Можно посмотреть кумулятивный эффект задержек и пропускной способности при сравнении быстрой и медленной версий 3G соединения. Быстрый вариант имеет ПС на 105% больше, однако время загрузки меньше только на 38.5%.

СД;НЧ

Увеличение пропускной способности на 1233% ускорило загрузку страниц только на 55%, что означает невозможность решения всех проблем производительности за счет быстрых сетей, хотя некоторые в это верят.


Сколько людей на самом деле имеют быстрый доступ в Интернет?

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

В 2015 году организация FCC (в США) изменила определение для широкополосного доступа (ШПД) с 4 до 25 Мбит/с. Согласно этому новому определению получилось, что каждый пятый пользователь (примерно 50 миллионов) в США не имеет широкополосного доступа.

Некоторые из выводов исследования FCC («FCC Finds U. S. Broadband Deployment Not Keeping Pace,» Federal Communications Commission, February 4, 2015) (Рисунок 4-3):

  • Более половины сельских жителей лишены ШПД, а 20% не имеют даже 4 Мбит/с.
  • 63% жителя племенных земель в США не имеют ШПД.
  • 35% школ в США не имеют скоростного оптического канала для нужд современного цифрового обучения.
  • В целом, насыщение ШПД возросло всего на 3% в сравнении между 2014 и 2015 годом.
  • При доступности ШПД, городские и сельские жители осваивают его с одинаковой интенсивностью.
Рисунок 4-3

Пользователи без широкополосного доступа


Рисунок 4-3

Сельские жители США без доступа даже в 4 Мбит/с


Рисунок 4-3

Жители племенных земель США без ШПД


Рисунок 4-3

Школы в США без скоростного оптического канала для современного цифрового обучения

FCC, 2015 Broadband Progress Report

Рисунок 4-3. По данным FCC, значительная часть населения США лишена любого подобия скоростного доступа к Интернет.

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


Мы изобрели Интернет. Мы можем решать амбициозные задачи, если будем ставить высокие цели, поэтому я думаю следующей планкой будет 100 Мбит/с. Всё, что меньше будет ограничивать наших детей, нашего будущего и нашу новую цифровую экономику.

— Jessica Rosenworcel, сотрудник FCC,
2015 Broadband Progress Report


Серверы

Большую часть существования Интернета в проблемах со скоростью обвиняли серверное оборудование. «Сервер перегружен» было основной причиной любой проблемы от медленного времени ответа до плохого рендеринга страниц. Отсюда появилось лекарство от всех болезней скорости: просто добавьте серверов.

Миф о серверной нагрузке как главной причине проблем со скоростью начал развеиваться в 2007 году с выходом книги Стива Саудерса «High performance web sites» — которая до сих пор остаётся библией для фронтэнд-разработчиков и специалистов по скорости. В 2007 году Стив написал знаменитую фразу:

80%-90% времени загрузки сайта для пользователя тратится на клиентскую часть (фронтэнд). Начните с этого.

Этот постулат находит подтверждение уже много лет. Для большинства сайтов только 10%-20% времени загрузки приходится на работу сервера (бекэнда). На рисунке 4-4 наглядно показана пропорция серверного (синее) и клиентского (зелёное) времени. В этом случае 86% времени загрузки приходится на клиентскую часть.

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

Рисунок 4-4

Рисунок 4-4. Клиентская (зелёный) и серверная (синий) составляющие времени загрузки популярного интернет-магазина.

Балансировщики нагрузки и контроллеры доставки контента (ADC)

Большим достижением 1990-х годов можно считать понимание инженерами того, что по аналогии с роутингом, который позволил передавать больше данных по проводам, балансировка нагрузки может использовать больше серверов для обработки растущего количества запросов. Отдельные веб-серверы сменились серверными кластерами и дата-центрами. Эти кластеры были снабжены балансировщиками нагрузки — технологией, которая, как следует из названия, балансирует трафик между множеством серверов, предотвращая перегрузку при пиках посещаемости.

К 2007 году балансировщики нагрузки эволюционировали в сложные контроллеры доставки контента (ADC). Стоит заметить, что утверждение о происхождении ADC из балансировщиков нагрузки спорное и многие уверены в том, что ADC это намного больше, чем продвинутые балансировщики нагрузки. Но для наших целей достаточно знать, что эти технологии часто связаны, даже если их разделяют долгие годы эволюции и развития.

Кроме обычной балансировки нагрузки, современные ADC могут оптимизировать запросы к БД, ускоряя сборку динамических страниц. ADС также занимаются мониторингом состояния серверов, реализуют продвинутые техники роутинга и разгружают сервера от задач типа обработки SSL-соединений и управления TCP-коннектами.

Сети доставки контента (CDN)

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

Решая такие проблемы производительности, как глобальная доступность и сокращение нагрузки на каналы, главная проблема, с которой могут помочь CDN это сетевые задержки: сумма времени для получения, обработки и отправки результата запроса на ресурс страницы (CSS, JS, изображения и т.д.). Задержки в основном зависят от расстояния между клиентом и сервером и включаются в каждый запрос на ресурс страницы.

Например, если все ресурсы страницы размещены в серверном кластере где-нибудь в Айове, а пользователь находится в Берлине, то каждый запрос должен проделать долгий путь от Берлина до Айовы и обратно. Если на вашей странице 100 ресурсов (что составляет минимум для обычных сайтов), то ваш браузер должен сделать 100 отдельных запросов к серверу для их получения.

Сети доставки контента кэшируют статические ресурсы на распределённых серверах (пограничный кэш, точки присутствия) в рамках региона или по всему миру, тем самым приближая ресурсы к пользователям и сокращая сетевые задержки (Рисунок 4-5).

Как и другие технологии, CDN развивались с течением времени. Сети первого поколения, которые появились в конце 1990-х годов, просто кэшировали статический контент. Более современные версии дают возможность кэшировать динамику и даже вести разработку на серверах CDN.

Хотя использование CDN обязательно для некоторых проектов, они не требуются для всех сайтов. Например, если вы размещаете сайт в своём регионе и там же находятся ваши пользователи, CDN не даст вам заметного ускорения (разве что сократит нагрузку на канал).

Рисунок 4-5

Рисунок 4-5. Упрощённая схема работы CDN с пограничными (edge) серверами, которые приближают контент к пользователям.

Сети доставки контента не являются универсальным решением всех проблем скорости. Есть ряд проблем, которые они не могут решить.

  • Серверная производительность.
  • Сторонние скрипты, которые блокируют рендеринг страниц.
  • Деоптимизированные страницы, на которых сначала виден второстепенный контент.
  • Неоптимизированные изображения (несжатые, несобранные в спрайты, неправильного формата).
  • Неминифицированный код.

Ваш CDN не решит эти проблемы. Вот здесь появляется клиентская оптимизация.

Клиентская оптимизация

Построение высокоскоростных сетей, балансировка нагрузки в дата-центре, сокращение сетевых задержек за счет CDN — все эти решения эффективны, но их недостаточно.

CDN нацелены на решение промежуточной проблемы приближения ресурсов к пользователям — сокращением сетевых задержек, тем самым ускоряя загрузку страниц. Клиентская оптимизация занимается скоростью фронтэнда, чтобы страницы быстрее отображались в браузере.

Клиентская оптимизация занимается скорость на уровне браузера и стала крайне эффективной мерой по развитию успеха серверной оптимизации и CDN. Один из методов победить задержки это объединение ресурсов в сборки. Чем меньше сборок нужно загрузить, тем меньше влияют задержки в сети. Также клиентская оптимизация использует кэширование в браузере, что позволяет сохранять ресурсы у пользователя, чтобы не делать повторные запросы к серверу.

Основные четыре стратегии клиентской оптимизации:

  • Сокращение HTTP-запросов для страницы (путём объединения ресурсов).
  • Сокращение размера ресурсов (за счёт сжатия).
  • Оптимизация приоритетов загрузки и исполнения кода (чтобы критические ресурсы загружались первыми, а остальные во вторую очередь).
  • Использование индивидуальных возможностей браузеров (например, специфических способов кэширования контента).

Все эти стратегии требуют изменений в HTML-коде страниц и оптимизации ресурсов, из которых они состоят.

Стив Саудерс обратил внимание на клиентскую оптимизацию в своей книге «High Performance Web Sites». В то время оптимизировать страницы можно было только руками, за счет привлечения очень способных разработчиков. С годам, клиентская оптимизация стала сложным набором практик, некоторые из которых могут быть применены только с использованием аппаратных или программных решений.

Хотя клиентская оптимизация может быть проведена разработчиками вручную, многие владельцы сайтов используют продукты и сервисы, которые автоматизируют процесс оптимизации страниц. Эти инструменты внедряют лучшие практики клиентской оптимизации путём автоматического изменения HTML в реальном времени в процессе передачи кода кленту. Некоторые CDN предлагают сервис по ускорению в качестве дополнительной услуги.


Автоматическая предзагрузка: продвинутая клиентская оптимизация

Автоматическая предзагрузка ресурсов (не путать с предзагрузкой в браузерах) это сложная техника клиентской оптимизации. В то время как предзагрузка в браузере запускается самим браузером и концентрируется на текущей странице, автопредзагрузка происходит на сервере и направлена на следующие страницы в пути пользователя по сайту или приложению.

Если предзагрузка в браузерах даёт около 20% ускорения, по данным Mozilla и Google, автопредзагрузка может ускорить сайт на 70%.

Автоматическая предзагрузка основана на двух вещах:

  • Развитие умной динамической веб-аналитики.
  • Количество времени, которое пользователь проводит на странице.

Система веб-аналитики получает и анализирует каждый путь по сайту всех посетителей ресурса. В результате получается огромное количество данных о поведении пользователей. Используя этот массив данных, система может предсказывать с высокой долей вероятности куда пользователь направится на основе данных о текущей и предыдущих страницах в пути сайта. Затем специальный программный код незаметно предзагрузит ресурсы для будущих страниц в пути в кэш браузера, где они будут ждать своего момента.

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


Мобильная оптимизация

Сегодня примерно один из четырёх человек во всём мире владеет смартфоном. Ожидается, что к 2020 году это значение вырастет до 4 из 5 (Рисунок 4-6). Это более 6 миллиардов мобильных устройств, подключенных к обширной инфраструктуре. Остановитесь на минуту и обдумайте этот факт.

К 2020 году 4 из 5 человек во всём мире будут владеть смартфоном

Рисунок 4-6

Рисунок 4-6. Ericsson, отчет по мобильным устройствам 2015 года.

Вместе с широким распространением мобильных устройств к нам пришёл целый класс новых проблем со скоростью: от маломощных устройств до медленных сетей.

Одной из главных проблем (не только для мобильных) является раздувание размера страниц. Мобильные версии страниц продолжают распухать за пределы возможностей сетей по передаче (Рисунок 4-7).

Рисунок 4-7

Рисунок 4-7. По данным HTTP архива, средний размер страницы для мобильных в 2015 перевалил за 1 Мб — в три раза больше, чем в 2011 году.

Несмотря на все ограничения, ожидания пользователей продолжают расти: типичный мобильный пользователь ожидает такой же (или даже более высокой) скорости на своём планшете или смартфоне по сравнению с обычным ПК.

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

  • Мобильные сети как правило медленнее, поэтому сокращение количества запросов и их объёма становится еще важнее.
  • Мобильные браузеры дольше анализируют HTML и выполняют JS-код, поэтому клиентские оптимизации крайне важны.
  • Кэш у мобильных браузеров намного меньше, поэтому требуются новые подходы к кэшированию ресурсов для повторного использования на сайте.
  • Небольшие экраны мобильных устройств предоставляют возможности по ускорению передачи и рендеринга за счет уменьшения размеров изображений, экономя на трафике, процессорном времени и объёме в кэше.

Использование мобильных устройств лавинообразно увеличивается. Наши требования к скорости бескомпромиссны. Современные сайты предъявляют все большие требования к мобильным сетям, устройствам и браузерам. Мобильная оптимизация вероятно, самая горячая часть индустрии скорости на данный момент.

Измерение скорости

Раньше способы измерения времени загрузки страниц были сложными, неточными и имели очевидные недостатки. В стародавние времена (где-то в 2005 году), если вы разрабатывали сайт, у вас не было абсолютно никакой возможности узнать скорость вашего сайта за пределами дата-центра. По мере развития веба, приложения становились всё более сложными. Изображения, видео и другой мультимедийный контент замедлял загрузку, в конце концов портя пользовательское впечатление.

К сожалению, раньше ни одну из этих проблем невозможно было выявить простыми измерениями на стороне сервера. Недостаток прозрачности в сфере скорости заставил владельцев сайтов найти другие пути измерения производительности. Всё это привело к появлению продвинутых инструментов для синтетического тестирования, а позже и мониторинга пользователей (RUM). В итоге, за счет применения всех этих инструментов, владельцы сайтов смогли увидеть реальную ситуацию со скоростью у своих конечных пользователей.

Решения по мониторингу скорости можно разделить на два типа: синтетическое тестирование и мониторинг пользователей (RUM). Каждый из этих типов предоставляет бесценные знания о скорости сайта, но ни один из них не может полностью ответить на все вопросы. Скорее, они отлично дополняют друг друга и вместе могут составить полную картину производительности.

Синтетическое тестирование скорости

Синтетическое тестирование скорости (иногда его называют «активный мониторинг») это искусственная проверка вашего сайта. Вы программируете сценарий, эмулирующий какое-то действие или путь по сайту потенциального посетителя и снимаете показания через заданные промежутки времени.

Что синтетическое тестирование может рассказать

Синтетические тесты скорости имеют уникальные возможности, которые отлично стыкуются с пользовательским мониторингом (RUM). Кроме диагностики на уровне страницы, синтетические системы предоставляют дополнительные метрики, например, время ответа, время загрузки, количество ресурсов и размер страницы и всё это для различных условий подключений. Также вы можете протестировать сайт в процессе разработки и на боевых серверах до того, как проблему увидят пользователи.

Вот несколько вопросов, на которые может дать ответ синтетическое тестирование:

  • Как ваш сайт выглядит по сравнению с конкурентами?
    • В отличие от RUM, синтетическое тестирование можно провести для любого сайта, не только для своего. (Рисунок 4-8)
  • Как дизайн сайта влияет на его скорость?
    • Синтетическое тестирование даёт детализацию до уровня отдельных ресурсов страницы, что позволяет подробно изучить дизайн и вёрстку страницы в контролируемом окружении.
  • Как новая версия сайта работает по сравнению с предыдущими?
    • Проводите тесты скорости до и после запуска обновлений для выявления причин ускорения или замедления страниц.
Рисунок 4-8

Рисунок 4-8. Синтетические тесты скорости показывают сравнение нескольких популярных сайтов СМИ.

Что синтетическое тестирование вам не расскажет

Синтетические тесты дают подробные сведения о том, из чего состоит страница, но есть пробелы в общей картине скорости, которые ими не освещаются.

  • Они дают серию точечных тестов скорости, а не целостную картину. Синтетические тесты запускаются по расписанию, не проводятся постоянно, поэтому вы можете пропустить изменения, которые произошли между тестами.
  • Из-за того, что вам нужно программировать тесты, есть ограничения по количеству путей, которые измеряются. Большинство владельцев сайтов используют всего несколько типичных путей по сайту.
  • Синтетические тесты не могут выявить изолированные или временные проблемы со скоростью (например, они не скажут, как будет влиять пик посещаемости сайта или временная недоступность и торможение внешних сервисов).

Мониторинг пользователей (RUM)

Мониторинг скорости у пользователей это вид пассивного мониторинга, который «слушает» весь трафик на сайте и учитывает все действия пользователей на нём. Так как RUM не никогда не спит, он собирает данные от всех пользователей, всех браузеров на всех сетях, сразу по всему миру. Мы говорим о петабайтах данных, собранных с посещений миллиардов страниц.

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

Технология RUM собирает метрики скорости сайта напрямую из браузера конечного пользователя. Вы устанавливаете маячок на JavaScript на все страницы сайта. Этот маячок собирает данные для каждого посетителя страницы и отправляет их в систему для последующего анализа.

Что мониторинг пользователей может вам рассказать

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

Вот список вопросов, на которые может ответить мониторинг пользователей:

  • Что происходит с сайтом в часы пиковой нагрузки? Есть ли деградация скорости со временем?
  • Какой софт и оборудование используют ваши посетители? Какие браузеры, устройства и операционные системы у них популярны?
  • Как посетители ходят по вашему сайту? Люди редко перемещаются по прямым маршрутам. RUM даёт возможность измерить скорость любого маршрута пользователя, который встречается в реальности (Рисунок 4-9).
  • Как работают сторонние сервисы на самом деле?
  • Какое влияние оказывает скорость на ваш бизнес? RUM даёт возможность связать скорость сайта и такие UX/бизнес-метрики, как процент отказов, просмотры страниц, время на сайте, конверсия и выручка. Он также покажет те страницы, которые наиболее страдают от замедления, что можно использовать как руководство к действию при выборе страниц для оптимизации.
Рисунок 4-9

Рисунок 4-9. На этой диаграмме, созданной на основе RUM-данных, показаны основные пути по сайту.

Что мониторинг пользователей может вам не расскажет

Как и у синтетического тестирования, у мониторинга пользователей есть свои достоинства и недостатки.

  • Из-за способа реализации (маячки на JS), RUM не может измерить скорость на сайтах конкурентов и сравнить с вашим.
  • RUM работает на боевых версиях сайта, поэтому не может измерить скорость на сайте в разработке.
  • Хотя RUM предоставляет некоторые данные по диагностике проблем, многие системы сегодня не дают глубокого разбора проблем скорости.

СД;НЧ

Нет такого понятия, как «средний пользователь». Каждый визит уникален. И каждый сайт даёт как отличные, так и ужасные впечатления пользователям каждый день.

Мониторинг пользователей замеряет широкий спектр визитов на сайт. Синтетическое тестирование даёт точечные замеры скорости в рамках строго заданных параметров. Понимание возможностей каждого типа инструментов для оценки скорости является ключевым для их максимально эффективного применения.


Спасёт ли нас эволюция браузеров?

Мне бы не простили, если эта глава осталась без упоминания о производительности браузеров. На протяжении всей истории WWW, незаметно для обывателей разработчики в поте лица создавали главное приложение — браузер, — без которого никто из нас не смог бы получить доступ в Интернет в том виде, который есть сейчас.

Быть разработчиком браузера это неблагодарная работа. Когда у нас тормозит что-то в Интернете, мы проклинаем посещаемые сайты, сети и наших бедных, браузеров-трудяг. Возможно, браузеры сделали больше, чем все остальные технологии для преодоления проблем скорости корявых и неоптимизированных сайтов. (Давайте не забывать о товарищах из Google, которые первыми разрабатывали практики ускорения сайтов, в то время как для остальных эта проблема еще не появилась на горизонте.)

Как минимум с середины 2000-х годов производители браузеров улучшали производительность в каждом новом релизе, направляя усилия на постоянный рост скорости год за годом.

Относительно недавно браузеры получили целый набор апгрейдов по скорости, таких как:

  • W3C API для маячков
    • Использование маячков на сайте может вызывать проблемы. Количество данных сильно ограничено, а сама посылка данных может замедлить работу браузера. С новым API для маячков, который поддерживается почти везде, данные могут отсылаться по событию unload, что быстро и не блокирует работу браузера.
  • HTTP/2
    • Все основные браузеры поддерживают HTTP/2, который даёт несколько улучшений по скорости, например мультиплексирование и параллелизм (несколько запросов могут посылаться один за другим по одному TCP-соединению, ответы могут приходить в любом порядке); зависимость потоков (клиент может указать серверу те ресурсы, которые наиболее важны); и server push (сервер может посылать ресурсы до запроса их клиентом).
  • Service workers
    • Service worker это скрипт, который работает в фоне, отдельно от страницы, открывающий возможности, которые не требуют взаимодействия со страницей или пользователем. Есть огромное количество способов использования SW для ускорения сайтов: например, предзагрузка ресурсов на будущее, таких как изображения товаров со следующих страниц интернет-магазина.

Рабочая группа по производительности из W3C также разработала несколько стандартов для мониторинга пользователей (например, navigation timing, resource timing, user timing) для диагностики проблем через браузер. Всё это даёт беспрецедентные возможности для владельцев сайтов для сбора гораздо более детальных данных о скорости сайта на основе поведения реальных пользователей.

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

Выводы

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

Закон Вирта был сформулирован в 1995 году, но он вполне точно отражает состояние дел в головоломке веб-производительности. Не важно, сколько денег мы вложим в инфраструктуру Интернета, задержки, по крайней мере в обозримом будущем, будут одним из величайших препятствий на пути к хорошей веб-производительности. Для этого есть несколько причин:

  • Безудержный рост размера страниц и их сложности.
  • Для каждого потенциально тормозного типа ресурсов, выпадающего из использования (например, Flash), находятся новые, занимающие его место (например, сторонние скрипты). И конечно, новый тип может сделать всё еще медленнее, чем было со старым ресурсом.

Веб-страницы скорее всего не станут меньше и проще, поэтому замечательно, что появилась огромная быстрорастущая индустрия, призванная сделать веб быстрее.

Экспертное ускорение сайтов

Ускорение сайтов

Цена от 48 900 Р