Как минимум, она интересует Google.
В 2010 Google открыто заявили, что они теперь учитывают скорость сайта в своих рейтингах.
Возможно, вы слышали, что в Google мы одержимы скоростью наших продуктов и Сети в целом. В рамках этих условий, сегодня мы начали учитывать в нашем рейтинге поисковых алгоритмов скорость работы сайтов.
В ходе аудита скорости загрузки Amazon.com выяснили, что каждые дополнительные 100 мс. загрузки их сайта снижали продажи на 1% . А это, как вы понимаете, плохой показатель.
Если зависимость отказов будет хотя бы близка к прямопропорциональной, то открытие сайта за 11 секунд может привести к полнейшей потере аудитории (но зависимость, к счастью, не прямая. Есть небольшая корреляция). В своей практике я видел небольшие коммерческие сайты, открывающиеся за 10-12 секунд. Учитывая меньшую аудиторию конверсии, их владельцы могут об этом только мечтать.
Сами специалисты гугла тоже экспериментировали со скоростью отдачи веба, в ходе чего выяснили, что с увеличением числа отображаемых результатов в поиске — с 10 до 30-ти- скорость изменилась с 0.4 до 0.9 сек. Это привело к снижению трафика и доходов в adwords на 20% .
В ходе исследований компании Google выяснилось, что задержка в 0.4 сек. может отнять около процента посетителей сайта. И да, после устранения проблемы 20% ушедших больше никогда не возвращались. Очевидно, что даже одна секунда может лишить вас дохода.
Даже шедевральную серверную оптимизацию самого правильного приложениям может перечеркнуть бездарная верстка. Back-end и front-end влияют на время загрузки страницы в соотношении 15/85.
Около 80% загрузки страницы ориентировано на загрузку компонентов страницы: скриптов, фотографий, файлов CSS.
Спецификация HTTP/1.1 советует параллельно загружать не более 2-х компонентов веб-страницы с одного хоста. Не то что бы этого правила необходимо придерживаться, со времен написания спецификаций многое изменилось, но контент лучше забирать с небольшого количества внешних хостов. Уменьшив количество запросов к внешним хостам, уменьшится время загрузки сайта.
Существует несколько хороших практик по уменьшению запросов.
• Использование CSS-спрайтов. CSS-спрайт – это комбинированное изображение, которое содержит в себе несколько маленьких изображений. Позиционируются они средствами CSS так, что выглядят абсолютно идентично маленькому изображению, но загружаются в один запрос.
• Использование Inline-изображений. Inline-картинки используют URL-схему data: встраивая такие изображения в CSS, файл позволяет вообще не делать ни одного запроса для загрузки графики.
• Объединение нескольких файлов в один. Если у Вас на страничке подключается больше одного css- или js-файла, то Вы можете объединить их в один. Это очень простой, но действенный способ уменьшения количества http-запросов на сервер.
Как я уже говорил Выше, согласно спецификации HTTP/1.1 на браузеры накладываются ограничения на количество одновременно загружаемых компонентов сайта, а именно — не более 2-х компонентов с одного хоста. В случае если на сайте много графики, целесообразно разнести изображения по разным хостам, но стоит помнить что использовать чрезмерно большое количество уникальных хостов — плохо, так как каждый запрос к этому уникальному хосту несет за собой накладные расходы (от 20 до 120 миллисекунд) на обращение к DNS серверу.
При использовании дополнительных потоков-хостов и подключении внешних ресурсов важно соблюдать баланс между необходимостью их использования и скоростью загрузки сайта.
Существует множество причин использовать редиректы, но стоит понимать, что он влияет на производительность сайта и на его скорость, так как по факту существует два запроса там, где достаточно одного.
Никогда не делайте более одного редиректа для достижения необходимого ресурса. Это примерно то же самое, что и неверная ссылка на ресурс. Сначала запрашивается файл, потом обрабатывается статус ошибки HTTP-запроса и уж потом все это интерпретируется браузером. Не всегда это происходит верно. Часто встречаются синтаксические ошибки. Да и вообще следует убедится в том, что все ресурсы, на которые ссылается страница, доступны.
Оптимизируйте порядок вызова стилей и скриптов. Последовательность должна быть примерно такой: сначала внутренние стили (локальные), после внешние (расположенные на других доменах), скрипты подключаются в последнюю очередь по возможности как можно ближе к закрывающему тегу body. Это не обязательные правила, но они рекомендованы google pagespeed, а это значит, что они действенны.
Что происходит дальше?
Браузер, начиная рендерить страницу, отрисовывает структуру html, параллельно загружая с того же домена файл стилей. В это время в окне браузера уже начинает отображается что-то похожее на сайт, что субъективно дает ощущение более быстрой загрузки. По окончании полной отрисовки страницы подключаются файлы сценариев, уже не блокируя загрузку каких-либо элементов.
Но как быть в ситуациях, когда скрипты по каким-либо причинам подключаются или уже подключены в head страницы?
Именно на этот случай предусмотрен html атрибут — async. Он позволяет подключать скрипты независимо от их положения на странице. При этом не блокируя её загрузку. На сегодняшний момент все современные браузеры, включая мобильные и internet explorer, уже поддерживают этот атрибут.
Подводя итоги, выделю несколько важных позиций:
1. Оптимизация скорости загрузки сайта — очень индивидуальное дело, которое требует профессиональной работы всей команды разработчиков, а иногда и контент-менеджеров.
2. Оно того безусловно стоит, как так быстрые сайты лучше ранжируются поисковыми системами и они более конверсионны.
