Секреты веб-производительности от BBC

Секреты веб-производительности от BBC

От автора: Джейми Найт рассказывает о том, как BBC ускоряет свой сайт и помогает пользователям перемещаться от одной страницы к другой.

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

Так называемый эффект «течения внимания» (flowing experience) также помогает и владельцам сайта. Сайт с быстрым течением помогает пользователям достигать цели, что соотносится с нашими целями. Amazon и другие сайты продемонстрировали сильную зависимость между производительностью и активностью пользователей. Если время загрузки страницы падает, то время, проведенное на сайте, и количество оставленных денег увеличивается.

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

Ключевые задачи

Непрерывный поток на сайте помогает удовлетворить потребности разных пользователей. Необходимо стремиться к двум целям:

Минимизация пауз: задержки снижают внимание пользователя, что позволяет переключиться на другой контекст;

Приоретизация контента: загружайте первым наиболее популярный контент.

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

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

Сеть

Не важно, как мы нарежем наш контент, нам необходимо доставить его по сети от серверов до пользователя. Одна из основных проблем, связанных с паузами – это сеть. В этой области и нужно стараться улучшить поток пользовательского внимания. Есть множество техник оптимизации работы с сетью. Две довольно распространенные методики – уменьшение веса страниц и снижение количества запросов. Чем меньше мы используем сеть, тем меньше пауз мы даем пользователю. Однако такая оптимизация начинает работать только после первого запроса к HTML файлу.

Запрос HTML файла – нижняя планка производительности страницы. Пока страница не загрузится, ничего не произойдет. Тут также можно подумать о производительности. Кэширование работает с HTML запросами, что сильно помогает ускорить сайт. Кроме того, кэширование существенно снижает потребление сети.

Кэширование

Кэш – небольшие файлы, которые создаются поближе к тому месту, где они будут использоваться для предотвращения перезагрузки. К примеру, когда я ем Skittles, я обычно кладу себе в руку несколько штук и потом беру из нее. По факту я создаю кэш Skittles в руке, потому что так можно быстрее их съесть и не лезть постоянно в пакетик. В кэшировании используется такой же принцип. Нам необходимо рассмотреть три типа кэша:

Кэш сервера: кэшированные данные на сервере, к примеру, результаты выполнения запросов к базе данных;

Сетевой кэш: кэш, встроенный в сеть. Зачастую так делают операторы сайтов (обратный прокси-кэш), но чаще всего так делают интернет-провайдеры;

Кэш браузера: браузер хранит файлы на жестком диске пользователя для повторного использования.

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

Проектирование модели кэширования

Чтобы наш подход был эффективным, нам необходимо использовать кэш по максимуму. Расширяя аналогию со Skittles, если я хочу достать синюю кофету, а в руке (кэше) их нет, я буду обязан найти ее в пакетике. Этот процесс называется коэффициентом кэш-попаданий. Если элемент есть в кэше, это хорошо, если нет – плохо. Чтобы кэш перенимал большую часть нагрузки, нам нужен высокий коэффициент.

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

Кэширование HTML файлов

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

Сперва рассмотрим кэширование запроса HTML файла. Кэширование файлов любого типа осуществляется через HTTP заголовки. Заголовки – это мета данные (данные о данных), посылаемые с сервера в браузер и видимые всему сетевому оборудованию на пути следования. Чтобы дать понять, что мы разрешаем кэшировать наши страницы и обмениваться кэшем с пользователями, необходимо указать следующий заголовок:

Мы также установили время жизни – максимальное время жизни в секундах, которое страница будет подгружаться из кэша. Мы задали 30 секунд. Слева вы найдете блок Дополнительные ссылки, где можно найти более подробную информацию по установке времени жизни кэша.

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

Эффект от кэширования страниц сетевым оборудованием по пути следования может быть очень большим. Множество больших сетей (интернет-провайдеров) будут распространять кэш своим пользователям. Мобильные операторы тоже постоянно пользуются этой техникой. К примеру, для кэширования и повторного сжатия изображений в сетях 3G. Операторы сайтов также могут предоставлять услуги по HTTP кэшированию. Мы занимались этим для BBC.

Максимальное время хранения статичных кэшированных файлов

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

Тем не менее, мы смогли извлечь пользу от кэширования статических файлов. На сайте BBC мы задавали максимальное время жизни статических файлов в 31,536,000 секунд через заголовки. Таким образом, все файлы кэшировались на 365 дней, что привело к тому, что статические файлы запрашивались всего один раз. Отличный шаг с точки зрения производительности, но шаг назад с точки зрения гибкости. В таком случае пользователь не подгружает изменения в этих файлах.

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

Вариации на стороне клиента

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

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

Заключительные слова

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

Автор: Jamie Knight

Источник: //medium.com/

Редакция: Команда webformyself.

Метки:

Похожие статьи:

Комментарии Вконтакте: