С приближением праздников компании наращивают расходы на SEM, уделяя пристальное внимание SEO и обновляя целевые страницы. Тем не менее, все это время, усилия и деньги, необходимые для максимизации праздничных продаж, могут оказаться напрасными, если увеличение посещаемости сайта в праздничные дни приводит к замедлению работы сайта или даже его снижению.
Не секрет, что производительность важна для пользователей. Скорость сайта напрямую влияет на показатель отказов, коэффициент конверсии, доход, удовлетворенность пользователей, SEO (явно в рейтинге Google Page Rank и косвенно на популярность сайта) и практически на все остальные показатели, которые стоит отслеживать. Пользователи покидают медленные сайты, и многие из них не вернутся.
Не так давно восемь секунд были названы переломным моментом, после которого пользователи могут отказаться от веб-сайта. Тогда было шесть секунд. Тогда четыре. Теперь эмпирическое правило составляет две секунды. Бар высокий, и он все время поднимается.
Небольшие изменения производительности могут оказать большое влияние
Терпение пользователя не является линейным. Почти никто не покидает сайт за медлительность в течение первой секунды. Но после этой первой секунды отсутствует какая-либо обратная связь (например, строка заголовка браузера, показывающая заголовок страницы), и пользователи начинают подпрыгивать с ускоряющейся скоростью. Через три или четыре секунды типичный сайт может потерять половину своих потенциальных посетителей. Конечно, конкретные пороговые значения варьируются в зависимости от веб-сайта, действий пользователя и намерений и других факторов … но принцип остается тем же.
Узкое место
Быстрый тест: какой процент времени пользователь тратит на ожидание загрузки вашей страницы после того, как HTML возвращается в браузер? Если вы не являетесь членом сообщества веб-разработчиков или оптимизации производительности, ответ может вас удивить или даже удивить. Обычно это более 90%. Большая часть времени, которое пользователи тратят на ожидание на вашем сайте, тратится после того, как HTML-страница была найдена их браузером. Почему это так?
Извлечение HTML это только начало
Серьезный анализ того, как работают браузеры, здесь выходит за рамки, но в двух словах браузеры анализируют HTML вашей страницы, последовательно обнаруживая ее ресурсы (такие как скрипты, таблицы стилей и изображения), запрашивая, а затем анализируя и выполняя их или отображая их по мере необходимости.
Но эти активы не просто извлекаются сразу. Вместо этого браузер открывает ограниченное количество подключений к серверам, на которые ссылается страница. При установлении соединений TCP и HTTP возникают накладные расходы, а также некоторая неизбежная задержка при передаче байтов запросов и ответов назад и вперед по сети.
Так что, в общем, поездки между браузером и сервером обходятся дорого. Структура HTML-разметки, количество и порядок ее активов являются абсолютно критическими факторами в ее производительности.
Прежде чем мы перейдем к сердцу праздничного трафика сайта, уделите несколько минут рассмотрению семи самых крупных ошибок, которые делают веб-разработчики и владельцы сайтов в отношении производительности сайта, и предложат способы их устранения или исправления.
1. Слишком много HTTP-запросов
Это самый большой источник проблем с производительностью на большинстве веб-страниц. Многие из наиболее эффективных методов WPO относятся к решению этой проблемы, хотя и весьма разными способами. Вот несколько решений:
Объединение скриптов и таблиц стилей
Просто объедините (объедините) несколько файлов скриптов в один. То же самое для таблиц стилей; просто включите содержимое последующих файлов .css в одну объединенную таблицу стилей. Есть расходы на техническое обслуживание для этого вручную, но автоматические решения имеются в большом количестве.
Объедините изображения со спрайтами
CSS-спрайтинг стал основной техникой. Идея состоит в том, чтобы поместить много общих изображений (например, всю графику для шаблонов вашего сайта, тем или навигации) в один большой файл изображения. Затем вы используете CSS для точного позиционирования и выборочного отображения только соответствующей части изображения спрайта в каждом месте, где требуется изображение. Таким образом, вместо десятков изображений, у вас есть только один.
Предупреждаю, что затраты на обслуживание для этого метода могут быть значительными, поскольку даже незначительные изменения обычно требуют обновления изображений и CSS, и даже HTML. К счастью, появились инструменты для автоматизации CSS-спрайтов, помогающие справиться с этим бременем обслуживания, такие как SpriteMe , Compass и Yottaa .
Используйте меньше изображений
Слишком много изображений на странице является эндемической проблемой, примерно такой же старой, как тег <img>. Решения попадают в два ведра. Один из них технический: замените файлы изображений на CSS (например, для цветов фона, границ, кнопок, эффектов наведения и стилизованного текста) или даже встроите их, используя « URI данных » для небольших изображений.
Вы также можете рассмотреть нумерацию страниц в тех случаях, когда изображения необходимы для целей страницы, например, в каталоге электронной коммерции.
Другое решение может быть более сложным: работать с дизайнерами вашего сайта и владельцами продуктов, чтобы создать более простые страницы, которые не используют столько изображений.
2. Минимальная обработка на стороне клиента
Многие сайты не могут использовать возможности клиента, вместо этого перенося всю работу на сервер. Один простой пример — проверка формы. Отправка данных формы на сервер, проверка их там и отправка сообщения об ошибке (не говоря уже о целой странице) невероятно неэффективны.
Подтвердить на клиенте
Вместо этого проверьте правильность ввода пользователя на странице, там, где происходит ввод. По соображениям безопасности веб-приложения также должны всегда проверяться на стороне сервера; Правило № 1 веб-безопасности заключается в том, что пользовательскому вводу нельзя доверять. Таким образом, проверьте на клиенте по соображениям производительности и UX, и проверьте на сервере по соображениям безопасности.
Используйте веб-стандарты и разделение MVC
Использование веб-стандартов имеет решающее значение для создания поддерживаемых, доступных и перспективных веб-сайтов. Отличный побочный эффект — это также лучшая основа для максимальной производительности. Использование современных веб-стандартов поощряет разделение контента (HTML), стиля (CSS) и поведения (JavaScript).
Иными словами, почтенный шаблон проектирования «MVC» [Модель / Представление / Контроллер] играет роль на уровне клиента кода вашего веб-сайта.
Думайте о HTML (на самом деле, о DOM) как о модели, о CSS как о представлении и о JavaScript как о контроллере. Такое разделение имеет тенденцию делать код более эффективным и поддерживаемым, и делает многие методы оптимизации более практичными для применения.
Вставить код презентации на уровень клиента
В дополнение к примеру проверки формы, отмеченному ранее, многие другие сценарии требуют от клиента большего. Диаграммы и графики — любой вид симпатичной визуализации данных — раньше были единственной областью сервера.
Больше не надо. Теперь часто имеет смысл передавать только необработанные данные с сервера на клиент (например, в формате JSON) и использовать JavaScript и CSS для создания симпатичных графиков, диаграмм и визуализаций прямо в браузере. Таким образом, многие пользовательские взаимодействия могут вообще избежать попадания на сервер.
И, только отправляя данные, вы экономите на ЦП сервера, сокращаете время ожидания и используете неиспользуемые ресурсы, доступные каждому клиенту. Существует множество отличных инструментов для обработки данных, включая Processing , D3 и Flot .
Используйте методы Ajax
Требуя изменения только небольших частей страницы в ответ на действия пользователя, вы делаете свой сайт или веб-приложение намного более отзывчивым и эффективным. Существуют разные допустимые подходы (например, выбор HTML против скрипта против данных). Но не обновляйте всю страницу, если вам это не нужно! Если вы опоздали на вечеринку Ajax, этой книге уже несколько лет, но она все еще является отличным обзором.
3. Низкое количество параллельных запросов
Извлеките сценарий, проанализируйте и выполните его, затем выберите другой. Промыть и повторить. Затем загрузите несколько изображений с того же сервера, используя все доступные соединения. Затем, как только они загрузятся, принесите еще. Звук эффективен? Это не. Пропускная способность соединения пользователя не является ограничивающим фактором в большинстве случаев; скорее это неэффективная разметка, которая не учитывает поведение браузера.
Есть некоторые вещи, которые вы можете сделать с вашим HTML, чтобы практически любой браузер мог делать много запросов одновременно, что имеет огромное влияние на задержку.
Использовать соответствующий браузеру шардинг домена
Некоторые старые, но все еще популярные браузеры, такие как IE 7, извлекают большую выгоду из «шардинга домена» — практики использования разных псевдонимов имен хостов для одного и того же веб-сервера, чтобы обойти крошечные ограничения на одновременное подключение к серверу. Использование img1.foo.com и img2.foo.com для указания на одно и то же место требует дополнительных затрат на поиск в DNS, но позволяет эффективно удвоить количество параллельных загрузок. Обратите внимание, что важно не применять эту технику к новым браузерам, которые поддерживают множество параллельных подключений, потому что тогда вы несете затраты на DNS без какой-либо выгоды. Гуру WPO Стив Соудерс делает хорошую работу, объясняя здесь компромиссы.
Используйте интеллектуальную загрузку скрипта
Произошел взрыв загрузчиков сценариев, которые помогают минимизировать влияние нескольких сценариев на производительность. В некоторых случаях объединять определенные файлы неудобно или нецелесообразно, а интеллектуальная загрузка сценариев может значительно снизить стоимость несогласованных файлов сценариев.
Эти загрузчики обычно загружают сценарии асинхронно (чтобы обойти проблему их блокирующего поведения) и также могут сохранять порядок выполнения без необходимости последовательной загрузки. Обслуживание сцепленного асинхронного JavaScript по-прежнему является лучшим (и самым простым) подходом, но использование хорошего загрузчика сценариев может привести к серьезным результатам, если вы не можете или не можете объединить свой JavaScript (и преобразовать его в асинхронный). Вот список загрузчиков скриптов .
Кредитное плечо Keep-Alive
Это просто: убедитесь, что ваш веб-сервер не переопределяет поведение по умолчанию для HTTP 1.1, то есть повторное использование одного и того же TCP-соединения для нескольких циклов HTTP-запросов / ответов. Существуют исключения (например, для специализированных серверов изображений), но для обычного сайта это не составляет труда: используйте его, и ваши страницы будут работать быстрее.
4. Неспособность использовать кеш браузера / локальное хранилище
Кто-то сказал: «В компьютерных науках есть две серьезные проблемы: кеширование, присвоение имен и ошибки« один на один »(ха). Серьезно, самый быстрый способ загрузить актив из локального кэша. Неспособность использовать то, что уже есть в браузере, является распространенной, но решаемой проблемой.
Используйте правильные заголовки
Установка заголовков кеша в будущем для статических ресурсов, особенно тех, на которые есть ссылки на нескольких страницах, — отличный способ повысить производительность. Поскольку явная аннулирование клиентских кэшей невозможно, способ обработки обновлений кэшированного содержимого — это изменение имени файла (переименование ресурса и обновление ссылок на него).
Это еще один метод, который требует больших затрат на обслуживание, если вы делаете это вручную, но автоматизация (например, с помощью сценариев сборки) делает это несложно. Используйте заголовок « Expires » для этого подхода. Для часто обновляемого содержимого используйте заголовки ответа « Last-Modified », чтобы инициировать условные запросы « If-Modified-Since » из браузера. Условные запросы, очевидно, медленнее, чем поиск в локальном кэше, но все же намного лучше, чем полный обход.
Вот отличный обзор кеша HTTP .
Использование локального хранилища
Более новое оружие в арсенале WPO — локальное хранилище HTML5. Для браузеров, которые его поддерживают, он позволяет явно, гораздо больше, явно храниться на клиенте, чем файлы cookie, и в отличие от файлов cookie он не влияет на каждый запрос.
5. Сторонние виджеты
Сторонние виджеты — проклятие жизни каждого оператора, который заботится о производительности.
Избегайте сторонних виджетов!
Не используйте их, если можете помочь. Часто необходимы пара плагинов для социальных сетей и интеграция с аналитикой, но избегайте их, как чумы, если можете.
Используйте асинхронные реализации
Попробуйте использовать виджеты, которые предоставляют асинхронные реализации, так что их неизбежно ужасная производительность влияет на их виджет, не затягивая с ним весь ваш UX.
Измерьте производительность (и прекратите использовать медленные)!
Внимательно следите за ними и настаивайте на SLA, переключайте поставщиков виджетов или найдите способ обойтись без виджета. (Этот пункт об измерении относится ко всем аспектам производительности. У измеряемых вами вещей есть забавная тенденция улучшаться, и вы не можете оптимизировать то, что не измеряете.)
6. Слишком много байтов
Как и «Too Many HTTP Requests», это проблема высокого уровня, решаемая многими различными методами WPO. Есть много способов сделать ответы (и даже запросы) меньше:
компрессия
Одно очевидное, но важное решение — ввести сжатие (а-ля gzip). Небольшое снижение производительности при декомпрессии на клиенте обычно сводится к минимуму из-за уменьшенной задержки с меньшим количеством байтов, передаваемых по проводам. На стороне сервера предварительное сжатие статических ресурсов помогает снизить нагрузку на процессор. Решения на стороне сервера, такие как mod_deflate Apache, mod_deflate сжатие динамического содержимого и гарантируют, что сжатый контент отправляется только тем клиентам, которые могут его обработать (как указано в заголовке запроса, например « Accept-Encoding: gzip, deflate »).
Следует обратить внимание на сжатие в сочетании с кэшированием: убедитесь, что используется заголовок « Vary: Accept-Encoding », чтобы кэши отвечали содержимым, соответствующим запросу.
Другие методы включают в себя:
- Более безжалостное редактирование контента
- Оптимизация изображения (а-ля http://www.smushit.com/ysmush.it/)
- JavaScript и CSS рефакторинг и минификация
- Повторное использование кода уровня клиента
- пагинация
- Ajax
- Домены без файлов cookie (для изображений и других статических ресурсов)
7. Неспособность использовать глобальную сеть
Одна очень распространенная ошибка — игнорировать географию. Если ваш сайт размещен в центре обработки данных в Нью-Йорке, существует огромная разница в задержке для пользователей в Бостоне и пользователей в Калифорнии (не говоря уже о Азии). Обслуживание контента с края — это роль традиционного CDN. Использование облачного провайдера для распространения вашего контента в еще большем количестве мест, чтобы пользователи всегда получали доступ к ближайшему серверу, стало еще лучше.
Передовые сервисы оптимизации производительности сети, такие как Yottaa, которые могут направлять запросы нескольким облачным провайдерам и распространять ваши страницы и их содержимое среди пользователей по всему миру, представляют собой следующее поколение решений для оптимизации для географически разнообразной аудитории.
Производительность имеет значение, особенно в праздничные дни. Прежде чем перейти к «Черной пятнице», «Киберпонедельнику» и последующим мерам, измерьте эффективность своего сайта, а затем улучшите его.
Делаете ли вы это вручную, во время сборки, во время развертывания, на сервере или во время запроса, или в облаке с вашей любимой службой оптимизации производительности в Интернете … просто сделайте это!
Дальнейшее чтение и другие ресурсы:
поджигатель
YSlow
WPT
dynaTrace
Yottaa
Высокопроизводительные веб-сайты
Еще быстрее веб-сайтов
Книга скорости
Web2.0 Expo
Скоростная конференция