Джейми Найт рассказывает о методах, которые BBC использует для ускорения работы своего сайта и помощи пользователям переходить с одной страницы на другую
В прошлом году во время сеанса пользовательского тестирования приложения BBC News один из пользователей оставил комментарий, который мне очень понравился. Они заявили: «Я люблю течь». Я не думаю, что можно лучше понять, что производительность значит для наших пользователей. В быстром приложении или веб-сайте пользователь может перемещаться, взаимодействовать и взаимодействовать с контентом.
Плавный опыт хорош и для владельцев сайтов. Быстро меняющийся опыт помогает пользователям достигать своих целей, а мы, в свою очередь, достигаем целей нашей организации. Amazon и другие продемонстрировали тесную связь между производительностью и активностью пользователя: по мере того, как время ожидания страниц уменьшается, количество времени и денег, которые тратит пользователь, увеличивается.
В этом уроке я собираюсь изучить некоторые из техник, которые мы использовали, чтобы сделать сайт BBC быстрым, а наши пользователи - легко перемещаться. Сначала я рассмотрю сохранение потока, а затем более подробно рассмотрю кеширование.
Ключевые цели
Сохранение потока внутри сайта поможет удовлетворить потребности разных пользователей. Следует иметь в виду две цели:
- Минимизируйте паузы. Задержки уменьшают внимание пользователя и вызывают переключение в контексте.
- Приоритет содержания: загружайте в первую очередь то, что больше всего интересует пользователя.
Для достижения обеих целей мы должны рассматривать производительность веб-сайта в целом. Производительность - это больше, чем просто время, необходимое для загрузки страницы - чтобы сохранить поток пользователей, нам нужно учитывать общий опыт и то, где лежат паузы; затем подумайте, какие компромиссы мы должны сделать, чтобы получить лучший опыт.
Иногда можно разработать общие паузы, если мы понимаем, как наши пользователи потребляют наш контент. Например, если у нас есть интерфейс с вкладками и мы знаем, что одна вкладка популярна, загрузка содержимого вкладки вместе с остальной страницей может дать лучший общий опыт, чем ленивая загрузка ее по запросу. Загрузка первой страницы будет замедлена, но «мгновенная» загрузка вкладки сделает взаимодействие более плавным.
Сеть
Независимо от того, как мы его разрезаем, нам необходимо передавать контент по сети с наших серверов пользователю. Сеть является одной из основных проблемных областей, вызывающих паузы, поэтому это хорошее место для поиска, чтобы улучшить поток наших пользователей. Существует множество методов оптимизации работы с сетью - два наиболее распространенных - это уменьшение веса страницы и уменьшение количества запросов. Чем меньше мы используем сеть, тем меньше пауз мы делаем для наших пользователей. Однако все эти оптимизации происходят после первого запроса файла HTML.
Запрос HTML-файла является нижней границей производительности страницы. Ничего не происходит, пока он не будет завершен, так что это хорошее место для оптимизации. Кеширование - это мощный инструмент, потому что он работает с HTML-запросом. Плюс ко всему, это усиливает все наши другие оптимизации использования сети.
Кеширование
Кеши создаются, когда небольшое количество чего-либо хранится ближе к месту, где это необходимо, обычно для предотвращения переделки. Например, если я ем кегли, я обычно наливаю немного себе в руку, а затем ем оттуда. По сути, я создаю кучу кеглей в руке, потому что так их съесть быстрее, чем вернуться к пачке.
Этот же образец используется в технике. Мы должны рассмотреть три кеша:
- Серверные кеши. Кэшированные данные на сервере, например результаты запросов к базе данных.
- Сетевые кеши. Кеши, встроенные в сеть, иногда оператором сайта (известный как кеш обратного прокси), но чаще интернет-провайдерами или другими поставщиками сетевых услуг.
- Кеш браузера: браузер сохраняет файлы на жестком диске пользователя для их повторного использования.
Кэширование может значительно улучшить производительность; на BBC я видел, как кеширование увеличивает производительность в производственном коде более чем в 20 раз. Это выгодно и операторам сайтов. При кэшировании большее количество пользователей может поддерживаться одним и тем же оборудованием, или меньшее количество оборудования может использоваться для поддержки определенного количества пользователей. Это снижает стоимость оборудования на пользователя и, следовательно, снижает эксплуатационные расходы веб-сайта.
Дизайн для кеша
Чтобы это было эффективно, мы хотим как можно больше использовать кэшированные данные. Если продолжить аналогию со Скиттлз, если я хочу синий кегли, но у меня в руке нет синих кеглей (иначе говоря, мой тайник), мне придется вернуться к пакету. Это известно как «процент попаданий». Это «попадание», когда элемент находится в кеше, и «промах», когда его нет. Нам нужна высокая частота попаданий, чтобы кеш брал на себя большую часть нагрузки.
Один из простейших способов увеличить процент попаданий - уменьшить вариативность. Немного растягивая мою аналогию со Skittles, представьте, если бы все Skittles были красными. Таким образом, любой кегель в моей руке будет хитом кеша; Мне бы никогда не пришлось возвращаться к пакету. Применяя это к сети, если мы можем предоставить одну и ту же страницу как можно большему количеству пользователей, кеш станет более эффективным, поскольку в кеш попадет больше запросов.
Кеширование HTML
Такова теория, давайте перейдем к практике. Во-первых, нам нужно сообщить миру, что наши страницы можно кэшировать. Затем нам нужно посмотреть, как наилучшим образом использовать кешированные страницы для повышения производительности без потери функциональности. В этом глубоком погружении я сосредоточусь на кэше сети и браузера.
Начнем с кеширования запроса HTML. Кеширование всех типов файлов контролируется с помощью заголовков HTTP. Заголовки - это метаданные (данные о данных), отправляемые с сервера в браузер и видимые для всего сетевого оборудования между ними. Чтобы сообщить миру, что у него есть разрешение на кэширование наших страниц и совместное использование этого кеша между пользователями, мы устанавливаем следующий заголовок:
Cache-Control: public, max-age=30
Здесь мы также установили ограничение по времени: максимальное время, в течение которого кеш должен повторно использовать эту страницу, в секундах. В этом примере я установил 30 секунд. Изучите поле «Дополнительная литература» слева для получения дополнительных ресурсов по настройке времени кеширования.
Если для страницы установлено значение общедоступно, браузер пользователя (и любое другое оборудование) сохранит копию. Таким образом, первая загрузка страницы будет делать запрос, но все страницы, загружаемые после этого, будут повторно использовать исходный ответ, пока не будет достигнут предел времени.
Влияние сетевого оборудования может быть очень серьезным. Многие крупные сети (например, интернет-провайдеры) будут иметь общий кеш-память между пользователями. Операторы мобильной связи также активно используют этот метод - например, для кэширования и повторного сжатия изображений, передаваемых через 3G. Операторы сайта также могут размещать HTTP-кеш перед своим сервисом. Это то, что мы сделали на BBC.
Кешировать статические активы на долгие годы
Техника, которую мы часто используем на BBC, заключается в том, чтобы обрабатывать статические ресурсы (например, изображения, CSS и скрипты) иначе, чем мы обрабатываем страницы. Кэшированные элементы идентифицируются с помощью URL-адреса. Есть способы «перепроверить» кэшированный контент, но в простейшем случае один URL означает одну запись в кеше, поэтому слишком долгое кеширование HTML-страниц может привести к тому, что пользователи пропустят обновления контента.
Однако мы можем воспользоваться этим поведением, когда дело касается статических ресурсов. На BBC мы отправляем все статические ресурсы с максимальным возрастом 31 536 000 секунд, установленным в заголовке кеша. Это гарантирует, что активы кэшируются в течение 365 дней. Фактически активы запрашиваются только один раз. Это хорошо для производительности, но плохо для гибкости, поскольку изменения в этом активе потребуют много времени, чтобы добраться до пользователя.
Чтобы обойти это, каждый раз, когда мы выпускаем новую версию страницы, мы меняем URL-адрес, в котором хранятся ресурсы. Этот трюк означает, что новые изменения сразу же доводятся до сведения пользователей, но мы по-прежнему получаем те же преимущества в производительности.
Вариант на стороне клиента
Как мы уже отмечали ранее, ключевое значение имеет предоставление пользователю правильного контента. Например, BBC будет показывать пользователям, вошедшим в систему, их имя пользователя на каждой странице. Люди посещают BBC не для того, чтобы посмотреть свое имя пользователя, поэтому это не приоритетный контент.
Если бы он был реализован на стороне сервера, этот вариант был бы ужасным, поскольку у каждого вошедшего в систему пользователя были бы уникальные страницы без кеша. Вместо этого мы предоставляем всем пользователям, вошедшим в систему, одну страницу, а затем меняем имя пользователя на место на стороне клиента. Это хороший пример использования прогрессивного улучшения для повышения производительности. Это тонкий прием, но он дает огромный прирост производительности.
Заключительные слова
В этой статье мы рассмотрели использование кеширования для повышения производительности веб-сайта. Повышенная производительность, в свою очередь, снизит эксплуатационные расходы для наших веб-сайтов и сохранит поток наших пользователей, что приведет к отличному пользовательскому опыту.
Дальнейшее чтение
Существует множество статей, которые помогут вам расширить свои знания о методах кэширования. Вот некоторые из лучших, с чего можно начать:
Отличное руководство для более глубокого изучения того, как работают заголовки кеша, и того, как применять их в вашем проекте.
Хороший пример использования заголовков элементов управления кешированием с PHP.
Рэйчел Эндрю предоставляет отличное пошаговое руководство, которое поможет вам начать работу с HTTP-кешированием.
Подробный обзор других форм кеширования, доступных разработчикам, для более современных вариантов использования, таких как автономные приложения.
Подробное описание того, как мы использовали кэширование varnish и отказоустойчивость CDN с вариациями на стороне клиента.
Джейми - старший специалист по доступности в BBC Future Media и бывший руководитель фронтенда iPlayer Radio. У него легкий аутизм, и у него есть плюшевый компаньон по имени Лев
Эта статья впервые появилась в 279-м номере журнала net magazine
