+7 (925) 507-98-19
Перевод подготовлен:
Лавлинский Д. Е., генеральный директор ООО «Метод Лаб»
к.э.н. Лавлинский Н. Е., технический директор ООО «Метод Лаб»
Пока мы концентрировались на монетарных преимуществах улучшения скорости веб-сайтов для клиентов. В этой главе давайте сменим фокус и обсудим ценность оптимизации скорости с использованием метрик, ориентированных на внутреннюю среду организации.
В исследовании 2008 года, проведенном Aberdeen Group («The Performance of Web Applications: Customers Are Won or Lost in One Second,» Aberdeen Group, 2008) выяснилось, что проблемы со скоростью могут сократить корпоративную выручку до 9%. Этот вывод относится не только к типичным целевым показателям, например конверсии и доход. Низкая скорость работы приложений может повредить компаниям множеством способов, включая следующие:
В этой главе мы обсудим все эти аспекты на базе реальных историй, которые показывают, как компании связывали улучшение производительности приложений с внутренними метриками.
Я на самом деле верю, что если мы собираемся привлекать людей для развития наших статей, они должны давать пользователям тот самый пользовательский опыт. Они должны быть не просто быстрыми, а удивительно быстрыми.
— Ori Livneh, главный инжеренер по разработке, Wikimedia foundation
[Клиентская оптимизация] значительно улучшает скорость работы нашего приложения, в результате мы не только повышаем продуктивность сотрудников, но и улучшаем финансовые показатели.
— Alan Ruth, управляющий директор, корпоративные приложения, Graebel
Вы когда-нибудь задумывались, сколько времени тратят люди в вашей компании, ожидая загрузки внутренних приложений?
В Graebel, глобальном поставщике услуг по перемещению сотрудников и бизнеса, задали этот вопрос внутри собственной компании, и ответ всех удивил. Они посчитали, что всего лишь в одном небольшом департаменте из 20 человек, сотрудники тратили 130 часов в месяц — другими словами, почти целый рабочий месяц одного человека — на ожидание загрузки страниц единственного внутреннего веб-приложения («For Graebel, a Faster Web Application Equals Happier, More Productive Employees,» Radware, 2013).
Сотрудников можно точно назвать «внутренними клиентами» вашего бизнеса. Если они ждут ответа от внутренних приложений более двух секунд, это снижает доходы вашей организации. Ещё в 1982 году в IBM (Ben Shneiderman, «Response Time and Display Rate in Human Performance with Computers,» Computing Surveys, Vol.16, No.3, September 1984) провели исследование, которое показало тесную связь между временем ответа приложения и продуктивностью работника. В одном исследовании, количество выполненных задач удвоилось, когда время ответа приложения сократилось всего на 2.7 секунды.
Также в IBM выяснили, что время ответа приложения влияет не только на количество выполненных задач, но «по мере увеличения отзывчивости приложения, работник становится экспоненциально продуктивнее».
Вспомните выводы эксперта по юзабилити Якова Нильсена о времени ответа и поведении человека: около 10 секунд задержки это предел возможности концентрации внимания на задаче в случае взаимодействия с системой. После 10 секунд даже самый эффективный сотрудник должен будет заставлять себя повторно сконцентрироваться на текущей задаче.
Как мы обсуждали в первой главе, постоянные прерывания — включая задержки на загрузку страниц, но не только — сильнейший разрушитель концентрации и, как следствие, продуктивности. Кроме потери продуктивности, низкая скорость приложений также влияет на боевой дух. Дело не только в том, что небольшие задержки быстро накапливаются в потери времени, но и в том, что пользователи — и внутренние, и внешние — должны на 50% сильнее концентрироваться при работе с медленными приложениями. При том, что большинство нас умеет достаточно хорошо справляться с повторяющимися задержками в короткой перспективе, это даётся большой ценой снижения общего удовлетворения и желания приступать к новым задачам.
Множество исследований доказали, что люди очень хорошо умеют убеждать себя в том, что мы понимаем что делает нас счастливыми, при этом мы вообще не знаем, что на самом деле влияет на наше счастье. Поэтому очень просто обманываться, что продуктивность это и есть эквивалент нашего счастья, особенно учитывая высокую ценность продуктивности в нашей системе ценностей.
Другими словами, мы можем убедить себя, что у нас всё в порядке — или, если вы работодатель, что ваши работники в порядке, хотя на самом деле это не так.
Ожидания сотрудников по скорости, надёжности и юзабилити установлены потребительскими веб-приложениями, которые мы используем каждый день. Мы, люди, не очень хорошо умеем разделять наши требования в зависимости от ситуации. Так как Twitter, Pinterest и Facebook работают быстро, мы ожидаем такой же скорости от других инструментов и систем: от CRМ до информационной системы компании.
Корпоративные ИТ должны соответствовать этим ожиданиям. Без должного внимания к пользовательскому опыту, многомиллионные затраты на ИТ могут уйти в корзину, по мере того как работники перестанут работать на медленных, сложных в использовании новых инструментах и вернутся к старым, изученным, более дорогостоящим путям выполнения задач.
Подводя итоги, улучшение скорости приложений помогает повысить продуктивность работников следующими способами:
Делать пользователей счастливыми это одна из человечных целей повышения отзывчивости приложений и веб-сайтов. В идеальном мире это было бы достаточным поводом для работы над производительностью, но если вас этим не убедить, есть огромный задел для реализации технических преимуществ за счет скорости, о котором мы поговорим в следующей части главы.
«Пропускная способность никого не волнует.»
Сложно поверить, но эта идея всё еще активно блуждает в кругах веб-разработчиков (хотя уже реже, чем это было раньше). С повсеместным проникновением быстрых каналов, люди наивного полагают, что вопрос трафика больше не важен. Отчасти это объясняется агрессивным маркетингом провайдеров Интернета: постоянно растущая пропускная способность в тарифных планах и сетях. Люди и СМИ цепляются за эти цифры, потому что они звучат круто. «Вдвое шире канал» звучит сказочно круто, если считать, что это значит «вдвое быстрее». (На самом деле нет. В реальности, увеличение канала на 1000% улучает время загрузки страниц только на 50% — но этого вам провайдер не скажет. Более подробно я остановлюсь на этом факте дальше.)
Даже если оставить скорость загрузки страниц, мобильный пользователь с ограниченным тарифным планом, который платит за трафик ежемесячно — скажет вам, что расход трафика очень даже важен сегодня.
Когда с вас регулярно снимают по $20 это неприятно и раздражает, но это всё капля в море по сравнению с затратами на передачу тяжелых страниц для бизнеса. Канал в Интернет все ещё ценный ресурс. Для высоконагруженных сайтов затраты канал могут стать основным источником затрат, легко опережая затраты на хостинг и хранение данных.
Раздутые страницы часто являются пожирателями трафика, при этом они становятся всё жирнее. В 2015 году средняя веб-страница весила около 2 Мб (по данным HTTP Archive, который собирает данные по 500 000 самых посещаемых ресурсов по всему миру). Это рост с 1 до 2 Мб всего за три года. В 2012 году многие были бы шокированы размером страницы в 1 Мб. Удивительно, как мы быстро привыкаем к таким значениям.
Важно понимать, что все эти цифры являются усреднёнными значениями. Хотя многие страницы весят меньше 2 Мб, часто можно встретить страницы больше 5 или даже 10 Мб.
С такими темпами роста, может ли средняя страница в 2017 году весить 3 Мб? Время покажет, но одно точно понятно: рост веса страниц неизбежен (См. рисунок 3-1).
Рисунок 3-1. Если нарисовать график изменения веса страниц, используя данные HTTP Archive, ясно, что средняя страница может перевалить за 3 Мб к концу 2017 года.
Современные страницы состоят из множества ингредиентов: JS-скриптов, файлов стилей, видео, шрифтов и все эти ингредиенты вносят свой вклад в прогрессирующее ожирение современного веба. Но самый значимый ингредиент это картинки, на которые приходится более 60% среднего веса страниц (на сайте, насыщенном изображениями может быть даже 85%!)
По иронии судьбы «wiki» на гавайском языке означает «быстрый», при этом Wikimedia Foundation умудрились довести свой сайт до такого состояния, когда среднее время сохранения страницы для редакторов составляло 7.5 секунд.
Как знает каждый пользователь Википедии, редакторы это кровь и плоть сайта. Они главные создатели и кураторы контента. В то время, как большинство пользователей Википедии получают страницы относительно быстро с узлов CDN, для редакторов страницы отдаются напрямую с серверов MediaWiki, что значительно замедляет загрузку. То есть, обычные посетители Википедии загружали быстрые версии страниц из кэша, редакторы получали постоянное замедление скорости работы Википедии.
Чтобы разобраться с этой проблемой, Wikimedia Foundation внедрили новую технологию HipHop Virtual Machine или HHVM, которая ускоряла MediaWiki, то есть PHP-код за счет которого работает Википедия. HHVM сократила медианное время сохранения страницы с 7.5 до 2.5 секунд (Рисунки 3-2, 3-3 и 3-4).
Рисунок 3-2. В Википедии сократили медианное время сохранения страницы с 7.5 до 2.5 секунд.
Рисунок 3-3. Среднее время загрузки страниц Википедии сократилось с 1.3 до 0.9 секунды.
Рисунок 3-4. В результате оптимизации загрузка ЦПУ для Википедии сократилась с 50% до 10%.
В результате внедрения HHVM, для Википедии были получены сразу несколько улучшений метрик для пользователей и бекэнда (Ori Livneh, «How we made editing Wikipedia twice as fast,» Wikimedia Blog, December 29, 2014), например:
Hydro-Québec, главный поставщик электроэнергии с ГЭС в Квебеке (Канада), испытывал серьёзные проблемы с производительностью CAD-приложения, которое использовалось через корпоративную сеть и Интернет. В компании использовалось CAD-приложение под названием CATIA, в котором создавались цифровые модели размером до 600 Мб. В компании начались серьёзные проблемы со скоростью работы приложения, когда они попытались перейти на процесс одновременной разработки из разных офисов, который подразумевает почти мгновенный доступ к общим файлам проектов.
«Время отклика было отвратительным», так оценивал ситуацию Daniel Brisebois, консультант компании по ИТ. При замере скорости работы в компании выяснили, что открытие небольшого файла CATIA на 14 Мб занимает более 15 минут по стандартному каналу 10 Мбит/с с задержками 15 мс. Кроме того, люди в удалённых офисах не могли нормально работать в CATIA из-за задержек от 30 до 60 секунд после каждого клика мышью.
Главным преимуществом одновременной работы над проектами являлась совместная работа в реальном времени, но с такими проблемами по скорости это было практически невозможно.
После оптимизации своей корпоративной сети и каналов в Интернет, в Hydro-Québec получили множество преимуществ («Concurrent Engineering Is Possible over a WAN,» Riverbed Case Study, 2011), например сокращение количества ошибок, более короткий цикл разработки и повышение целостности данных. К примеру, файл в 17 Мб раньше загружался за 85 секунд, теперь уже загружается за 8 секунд после оптимизации сети. Другие достижения включали следующее:
С точки зрения сокращения издержек, оптимизация сети позволило компании внедрить одновременную разработку на 50% дешевле, чем при другом подходе с покупкой выделенных серверов и дополнительных лицензий на ПО. В компании также подсчитали, что за счет консолидации (поддержке единственного сервера в головном офисе) они сэкономили около 1.5 миллиона долларов затрат на ИТ.
Если вы хотите сделать свои страницы быстрее, ваша цель должна быть в сокращении их размера и сложности. Это значит удаление лишних ресурсов и обеспечении их минимального размера при передаче. Таким образом вы не только ускорите загрузку страниц, но и сократите затраты на трафик.
Одной из простейших и в то же время эффективных оптимизаций является сжатие текстовых компонентов с помощью gzip. На это не требуется тратить время разработчиков, нужно всего лишь включить настройку веб-сервера.
Когда Bill Scott, глава разработки интерфейсов в Netflix начал работать в компании, он заметил, что gzip был отключён. Естественно, он включил его (Bill Scott, «Improving Netflix Performance,» June 23, 2008). Как видно на рисунке 3-5, результатом стало резкое сокращение исходящего трафика.
Рисунок 3-5. Включение gzip в Netflix.
Сокращение исходящего трафика принесло несколько выгод, включая:
Компания Shopzilla (сейчас Connexity) это ведущий сервис по сравнению интернет-магазинов, который стал символом оптимизации производительности в интернете после публикации впечатляющего кейса в 2009 году.
Сайт накопил года технического долга по мере того, как сеть сайтов компании становилась всё более монолитной. В компании решились на очень рискованный проект по радикальной переработке архитектуры всех сервисов с целью сокращения инфраструктуры и улучшения производительности.
После 16-месячного реинжиниринга, в Shopzilla ускорили среднюю загрузку страниц с 6 до 1.2 секунд и получили дополнительные выгоды (Phil Dixon, «Shopzilla Site Redesign: We get what we measure,» 2009) в различных бизнес-метриках:
Hilton Grand Vacations Club это отделение компании Hilton, которое занимается продажей таймшеров клиентам по всему миру. В компании были серьёзные проблемы с задержками до 30 минут при использовании критичного для бизнеса приложения по работе с договорами.
Старший директор по технологиям Hilton сказал следующее:
Подтверждение договоров это затратный по времени процесс, который включает в себя отправку большого количества данных в наш центральный офис в Орландо. В Азии процесс заключения договора намного сложнее и требует больше трафика, чем в США. Так как мы не могли продублировать наши основные бизнес-системы и процесс в Японии, мы тратили до 30 минут на техническую часть заключения договора.
Как понимаете, ситуация, когда клиент сидит перед вами, ожидая ответа компьютера, далеко не самая приятная. Когда вы работаете с договором, время решает. Вы не хотите вносить задержки из-за технических проблем.
В Hilton решили внедрить технологию оптимизации Интернет-канала, которая ускорила приложение по работе с договорами. После этого ускорения процесс заключения договора сократился с 30 до 1–2 минут. В результате оптимизации получены следующие преимущества:
Если вы запомните только один тезис из этой главы, надеюсь он будет следующим: скорость не просто влияет на технологические и поведенческие метрики, между ними существует неразрывная связь. Практически любое изменение в технологической части влияет на людей, которые её используют.
Или давайте перефразирую мысль: неважно, что вы бессердечный Скрудж Макдак и вас волнует только сокращение издержек на инфраструктуру и стоимость интернет-канала. Если вы будете заниматься производительностью с этими целями, вы всё равно сделаете своих пользователей значительно счастливее. (Извини, дядя Скрудж!)
