+7 (925) 507-98-19
Перевод подготовлен:
Лавлинский Д. Е., генеральный директор ООО «Метод Лаб»
к.э.н. Лавлинский Н. Е., технический директор ООО «Метод Лаб»
Озабоченность вопросами скорости в вебе не нова. Давайте прыгнем в машину времени и ненадолго посетим 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 — минимальное время, которое необходимо для отправки пакета и получения ответа, другими словами «задержка» в сети):
Даже при беглом взгляде на рисунок 4-1 можно заметить, что голубые столбики, означающие время загрузки, различаются гораздо меньше чем синие, которые показывают пропускную способность (ПС).
Рисунок 4-1. Медианные времена загрузки главной страницы Etsy. com с использованием различных типов подключений.
Рисунок 4-2 это другое представление тех же данных. Если бы предположение о том, что пропускная способность пропорциональна времени загрузки, было верным, два графика были бы зеркальными. Очевидно, что это не так.
Рисунок 4-2. Альтернативное представление скорости загрузки Etsy. com для различных подключений. Если бы увеличение пропускной способности пропорционально ускоряло загрузку, две части изображения были бы зеркальными.
Несколько наблюдений:
Увеличение пропускной способности на 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):
Пользователи без широкополосного доступа
Сельские жители США без доступа даже в 4 Мбит/с
Жители племенных земель США без ШПД
Школы в США без скоростного оптического канала для современного цифрового обучения
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. Клиентская (зелёный) и серверная (синий) составляющие времени загрузки популярного интернет-магазина.
Большим достижением 1990-х годов можно считать понимание инженерами того, что по аналогии с роутингом, который позволил передавать больше данных по проводам, балансировка нагрузки может использовать больше серверов для обработки растущего количества запросов. Отдельные веб-серверы сменились серверными кластерами и дата-центрами. Эти кластеры были снабжены балансировщиками нагрузки — технологией, которая, как следует из названия, балансирует трафик между множеством серверов, предотвращая перегрузку при пиках посещаемости.
К 2007 году балансировщики нагрузки эволюционировали в сложные контроллеры доставки контента (ADC). Стоит заметить, что утверждение о происхождении ADC из балансировщиков нагрузки спорное и многие уверены в том, что ADC это намного больше, чем продвинутые балансировщики нагрузки. Но для наших целей достаточно знать, что эти технологии часто связаны, даже если их разделяют долгие годы эволюции и развития.
Кроме обычной балансировки нагрузки, современные ADC могут оптимизировать запросы к БД, ускоряя сборку динамических страниц. ADС также занимаются мониторингом состояния серверов, реализуют продвинутые техники роутинга и разгружают сервера от задач типа обработки SSL-соединений и управления TCP-коннектами.
По мере роста конкуренции сайтов за внимание посетителей, контент стал меняться с чисто текстового на мультимедийный, насыщенный графикой и видео. Поддержка таблиц стилей и клиентских скриптов добавило новые объекты для загрузки браузером при отрисовке страницы. Растущее количество запросов на странице также увеличило влияние сетевых задержек, что в конечном счет привело к следующей большой инновации: сетям доставки контента (CDN).
Решая такие проблемы производительности, как глобальная доступность и сокращение нагрузки на каналы, главная проблема, с которой могут помочь CDN это сетевые задержки: сумма времени для получения, обработки и отправки результата запроса на ресурс страницы (CSS, JS, изображения и т.д.). Задержки в основном зависят от расстояния между клиентом и сервером и включаются в каждый запрос на ресурс страницы.
Например, если все ресурсы страницы размещены в серверном кластере где-нибудь в Айове, а пользователь находится в Берлине, то каждый запрос должен проделать долгий путь от Берлина до Айовы и обратно. Если на вашей странице 100 ресурсов (что составляет минимум для обычных сайтов), то ваш браузер должен сделать 100 отдельных запросов к серверу для их получения.
Сети доставки контента кэшируют статические ресурсы на распределённых серверах (пограничный кэш, точки присутствия) в рамках региона или по всему миру, тем самым приближая ресурсы к пользователям и сокращая сетевые задержки (Рисунок 4-5).
Как и другие технологии, CDN развивались с течением времени. Сети первого поколения, которые появились в конце 1990-х годов, просто кэшировали статический контент. Более современные версии дают возможность кэшировать динамику и даже вести разработку на серверах CDN.
Хотя использование CDN обязательно для некоторых проектов, они не требуются для всех сайтов. Например, если вы размещаете сайт в своём регионе и там же находятся ваши пользователи, CDN не даст вам заметного ускорения (разве что сократит нагрузку на канал).
Рисунок 4-5. Упрощённая схема работы CDN с пограничными (edge) серверами, которые приближают контент к пользователям.
Сети доставки контента не являются универсальным решением всех проблем скорости. Есть ряд проблем, которые они не могут решить.
Ваш CDN не решит эти проблемы. Вот здесь появляется клиентская оптимизация.
Построение высокоскоростных сетей, балансировка нагрузки в дата-центре, сокращение сетевых задержек за счет CDN — все эти решения эффективны, но их недостаточно.
CDN нацелены на решение промежуточной проблемы приближения ресурсов к пользователям — сокращением сетевых задержек, тем самым ускоряя загрузку страниц. Клиентская оптимизация занимается скоростью фронтэнда, чтобы страницы быстрее отображались в браузере.
Клиентская оптимизация занимается скорость на уровне браузера и стала крайне эффективной мерой по развитию успеха серверной оптимизации и CDN. Один из методов победить задержки это объединение ресурсов в сборки. Чем меньше сборок нужно загрузить, тем меньше влияют задержки в сети. Также клиентская оптимизация использует кэширование в браузере, что позволяет сохранять ресурсы у пользователя, чтобы не делать повторные запросы к серверу.
Основные четыре стратегии клиентской оптимизации:
Все эти стратегии требуют изменений в HTML-коде страниц и оптимизации ресурсов, из которых они состоят.
Стив Саудерс обратил внимание на клиентскую оптимизацию в своей книге «High Performance Web Sites». В то время оптимизировать страницы можно было только руками, за счет привлечения очень способных разработчиков. С годам, клиентская оптимизация стала сложным набором практик, некоторые из которых могут быть применены только с использованием аппаратных или программных решений.
Хотя клиентская оптимизация может быть проведена разработчиками вручную, многие владельцы сайтов используют продукты и сервисы, которые автоматизируют процесс оптимизации страниц. Эти инструменты внедряют лучшие практики клиентской оптимизации путём автоматического изменения HTML в реальном времени в процессе передачи кода кленту. Некоторые CDN предлагают сервис по ускорению в качестве дополнительной услуги.
Автоматическая предзагрузка ресурсов (не путать с предзагрузкой в браузерах) это сложная техника клиентской оптимизации. В то время как предзагрузка в браузере запускается самим браузером и концентрируется на текущей странице, автопредзагрузка происходит на сервере и направлена на следующие страницы в пути пользователя по сайту или приложению.
Если предзагрузка в браузерах даёт около 20% ускорения, по данным Mozilla и Google, автопредзагрузка может ускорить сайт на 70%.
Автоматическая предзагрузка основана на двух вещах:
Система веб-аналитики получает и анализирует каждый путь по сайту всех посетителей ресурса. В результате получается огромное количество данных о поведении пользователей. Используя этот массив данных, система может предсказывать с высокой долей вероятности куда пользователь направится на основе данных о текущей и предыдущих страницах в пути сайта. Затем специальный программный код незаметно предзагрузит ресурсы для будущих страниц в пути в кэш браузера, где они будут ждать своего момента.
Учитывая факт, что типичная веб-страница может содержать десятки изображений, которые могут занимают до половины объёма страницы, легко понять, почему методика автопредзагрузки изображений в кэш может заметно ускорить сайт. Это прекрасный способ бороться с проблемой сетевых задержек, которая находится в первых рядах врагов скорости.
Сегодня примерно один из четырёх человек во всём мире владеет смартфоном. Ожидается, что к 2020 году это значение вырастет до 4 из 5 (Рисунок 4-6). Это более 6 миллиардов мобильных устройств, подключенных к обширной инфраструктуре. Остановитесь на минуту и обдумайте этот факт.
К 2020 году 4 из 5 человек во всём мире будут владеть смартфоном
Рисунок 4-6. Ericsson, отчет по мобильным устройствам 2015 года.
Вместе с широким распространением мобильных устройств к нам пришёл целый класс новых проблем со скоростью: от маломощных устройств до медленных сетей.
Одной из главных проблем (не только для мобильных) является раздувание размера страниц. Мобильные версии страниц продолжают распухать за пределы возможностей сетей по передаче (Рисунок 4-7).
Рисунок 4-7. По данным HTTP архива, средний размер страницы для мобильных в 2015 перевалил за 1 Мб — в три раза больше, чем в 2011 году.
Несмотря на все ограничения, ожидания пользователей продолжают расти: типичный мобильный пользователь ожидает такой же (или даже более высокой) скорости на своём планшете или смартфоне по сравнению с обычным ПК.
Разработка специальных методик оптимизации сайтов под мобильные устройства сейчас самое актуальное направление клиентской оптимизации. Вот лишь некоторые из сложностей и возможностей, которые учитываются в мобильной оптимизации:
Использование мобильных устройств лавинообразно увеличивается. Наши требования к скорости бескомпромиссны. Современные сайты предъявляют все большие требования к мобильным сетям, устройствам и браузерам. Мобильная оптимизация вероятно, самая горячая часть индустрии скорости на данный момент.
Раньше способы измерения времени загрузки страниц были сложными, неточными и имели очевидные недостатки. В стародавние времена (где-то в 2005 году), если вы разрабатывали сайт, у вас не было абсолютно никакой возможности узнать скорость вашего сайта за пределами дата-центра. По мере развития веба, приложения становились всё более сложными. Изображения, видео и другой мультимедийный контент замедлял загрузку, в конце концов портя пользовательское впечатление.
К сожалению, раньше ни одну из этих проблем невозможно было выявить простыми измерениями на стороне сервера. Недостаток прозрачности в сфере скорости заставил владельцев сайтов найти другие пути измерения производительности. Всё это привело к появлению продвинутых инструментов для синтетического тестирования, а позже и мониторинга пользователей (RUM). В итоге, за счет применения всех этих инструментов, владельцы сайтов смогли увидеть реальную ситуацию со скоростью у своих конечных пользователей.
Решения по мониторингу скорости можно разделить на два типа: синтетическое тестирование и мониторинг пользователей (RUM). Каждый из этих типов предоставляет бесценные знания о скорости сайта, но ни один из них не может полностью ответить на все вопросы. Скорее, они отлично дополняют друг друга и вместе могут составить полную картину производительности.
Синтетическое тестирование скорости (иногда его называют «активный мониторинг») это искусственная проверка вашего сайта. Вы программируете сценарий, эмулирующий какое-то действие или путь по сайту потенциального посетителя и снимаете показания через заданные промежутки времени.
Синтетические тесты скорости имеют уникальные возможности, которые отлично стыкуются с пользовательским мониторингом (RUM). Кроме диагностики на уровне страницы, синтетические системы предоставляют дополнительные метрики, например, время ответа, время загрузки, количество ресурсов и размер страницы и всё это для различных условий подключений. Также вы можете протестировать сайт в процессе разработки и на боевых серверах до того, как проблему увидят пользователи.
Вот несколько вопросов, на которые может дать ответ синтетическое тестирование:
Рисунок 4-8. Синтетические тесты скорости показывают сравнение нескольких популярных сайтов СМИ.
Синтетические тесты дают подробные сведения о том, из чего состоит страница, но есть пробелы в общей картине скорости, которые ими не освещаются.
Мониторинг скорости у пользователей это вид пассивного мониторинга, который «слушает» весь трафик на сайте и учитывает все действия пользователей на нём. Так как RUM не никогда не спит, он собирает данные от всех пользователей, всех браузеров на всех сетях, сразу по всему миру. Мы говорим о петабайтах данных, собранных с посещений миллиардов страниц.
Слово «пассивный» не очень отражает суть, потому что современный RUM какой угодно, но не пассивный. Сегодня, лучшие системы RUM имеют мощные аналитические инструменты, которые дают возможность изучать ваши данные в любой комбинации параметров.
Технология RUM собирает метрики скорости сайта напрямую из браузера конечного пользователя. Вы устанавливаете маячок на JavaScript на все страницы сайта. Этот маячок собирает данные для каждого посетителя страницы и отправляет их в систему для последующего анализа.
В дополнение к обычных метрикам, например, времени загрузки страницы, мониторинг пользователей может поведать много интересного о том, как посетители пользуются вашим сайтом, открывая подробности, которые скрыты от других инструментов.
Вот список вопросов, на которые может ответить мониторинг пользователей:
Рисунок 4-9. На этой диаграмме, созданной на основе RUM-данных, показаны основные пути по сайту.
Как и у синтетического тестирования, у мониторинга пользователей есть свои достоинства и недостатки.
Нет такого понятия, как «средний пользователь». Каждый визит уникален. И каждый сайт даёт как отличные, так и ужасные впечатления пользователям каждый день.
Мониторинг пользователей замеряет широкий спектр визитов на сайт. Синтетическое тестирование даёт точечные замеры скорости в рамках строго заданных параметров. Понимание возможностей каждого типа инструментов для оценки скорости является ключевым для их максимально эффективного применения.
Мне бы не простили, если эта глава осталась без упоминания о производительности браузеров. На протяжении всей истории WWW, незаметно для обывателей разработчики в поте лица создавали главное приложение — браузер, — без которого никто из нас не смог бы получить доступ в Интернет в том виде, который есть сейчас.
Быть разработчиком браузера это неблагодарная работа. Когда у нас тормозит что-то в Интернете, мы проклинаем посещаемые сайты, сети и наших бедных, браузеров-трудяг. Возможно, браузеры сделали больше, чем все остальные технологии для преодоления проблем скорости корявых и неоптимизированных сайтов. (Давайте не забывать о товарищах из Google, которые первыми разрабатывали практики ускорения сайтов, в то время как для остальных эта проблема еще не появилась на горизонте.)
Как минимум с середины 2000-х годов производители браузеров улучшали производительность в каждом новом релизе, направляя усилия на постоянный рост скорости год за годом.
Относительно недавно браузеры получили целый набор апгрейдов по скорости, таких как:
Рабочая группа по производительности из W3C также разработала несколько стандартов для мониторинга пользователей (например, navigation timing, resource timing, user timing) для диагностики проблем через браузер. Всё это даёт беспрецедентные возможности для владельцев сайтов для сбора гораздо более детальных данных о скорости сайта на основе поведения реальных пользователей.
В отдельности, каждое улучшение решает важную проблему производительности. Вместе же эти улучшения в браузерах могут значительно продвинуть прогресс в деле скорости сайтов.
Большинство людей знакомы с законом Мура: наблюдением, что вычислительная мощность компьютеров удваивается примерно каждые два года. Но мало кому известен знаком закон Вирта, который гласит, что софт становится медленнее с большим темпом, чем ускоряется железо.
Закон Вирта был сформулирован в 1995 году, но он вполне точно отражает состояние дел в головоломке веб-производительности. Не важно, сколько денег мы вложим в инфраструктуру Интернета, задержки, по крайней мере в обозримом будущем, будут одним из величайших препятствий на пути к хорошей веб-производительности. Для этого есть несколько причин:
Веб-страницы скорее всего не станут меньше и проще, поэтому замечательно, что появилась огромная быстрорастущая индустрия, призванная сделать веб быстрее.
