Как ускорить загрузку страницы (howto для вебмастера) : Создание сайтов и поисковая оптимизация (SEO)

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

Для того, чтобы проанализировать удобство и скорость загрузки ресурсов сайта, необходимо пользоваться комплексом многочисленных инструментов, собственными оценками и оценками пользователей. При оценке необходимо учитывать не только скорость загрузки ресурсов, но и возможность их обработки различными браузерами. Например, у меня достаточно длинный перечень файлов одной из страничек выдавался через js. Я и не догадывался, что на IE9 эта страничка просто умирала на пару минут, поскольку на Chrome это не было заметно вообще. Не поленитесь в разделе вашего ресурса, где бывают отзывчивые пользователи, поинтересоваться, как им сайт в целом. Обязательно указывайте линк для связи с вебмастером! Впрочем, ничто не мешает замкнуть его на первую линию техподдержки, поскольку неадекватных людей гораздо больше нормальных. Но обратную связь лучше всегда демонстрировать, если ваш сайт выше сложностью, чем одна страничка на чистом HTML

Итак, при ежедневном осмотре сайта вам показалось, что что-то тормозит, либо перед вами стоит задача провести аудит скорости загрузки сайта. На глазок можно определить только тормоза загрузки какого-то большого включения, а, возможно, еще и ошибиться при этом. Могу порекомендовать запустить Chrome и, либо нажать Shift-Ctrl-I, либо в "Дополнительных инструментах" меню выбрать "Инструменты разработчика". В данный момент нас интересует закладка Network. Ее и нужно выбрать, после чего перечитать содержимое. Не буду подробно останавливаться на этом инструменте, все интуитивно понятно. С длинными полосками нужно бороться.




Обратите внимание, что в этом же инструменте можно посмотреть, как выглядит ваш сайт на мобильном устройстве.

На втором месте сторонний инструмент WebPagetest [ ➜ ] , который, в принципе, выполняет те же самые проверки, что мы проводили выше из Chrome, только с возможностью проверить ваш сайт уже с географически удаленных точек. Не столько аналитический, сколько диагностический. Дело в том, что у меня складывается впечатление о влиянии каких-то сторонних факторов на этот инструмент. В любой момент времени вы можете получить отличающиеся результаты на одном и том же ресурсе, с одной и той же точки. Однако, сравнивать показатели и тестировать сайт после каких-то изменений его параметров настоятельно рекомендую именно через этот ресурс. Обычно я задаю три теста с No traffic shaping и с ближайшего ко мне города. Это помогает больше диагностировать проблемы сервера и последней мили, а не всех каналов мира. Думаю, что на ресурсе с минимумом картинок результат не должен превышать полутора секунд. И сразу предостерегу от того, чтобы протестировать главную и успокоиться. Тестируйте все типы страниц, которые предназначены для индексирования! Обращайте внимание не только на популярные страницы, возможно, что какие-то страницы непопулярны в силу своих тормозов.




Для оценки скорости загрузки сайта в сравнении, рекомендую пользоваться Google Analytics. Не все знают, что в разделе "Поведение" есть подраздел "Скорость загрузки сайта", в котором собирается статистика по различным клиентам, с различных точек земного шара. Ценность этой статистики в объеме и разнообразии выборки. Особо долго останавливаться на этом инструменте тоже не буду, но подчеркну его важность и возможность сравнивать срезы текущего дня и прошлого. Изучите его возможности - пригодится.




Не забуду и еще один бесплатный инструмент для накопления статистики по скорости сайта - график статистики сканирования в Search Console [ ➜ ] на этот раз речь идет исключительно про скорость отдачи ресурсов боту, без учета рендера страниц. Полагаю, что если у вас все хорошо со скоростью на сайте, то график не будет подниматься выше полусекунды. Обратите внимание, что, если графики количества загруженных страниц и скорости их загрузки поднимаются одновременно, то есть повод задуматься о готовности сервера выдерживать нагрузку чуть выше своей средней. В свете этого рекомендую обратить внимание на вопросы кеширования и поддержку If-Modified-Since, т.е. кода HTTP 304, позволяющего не заниматься передачей одних и тех же данных.




И, наконец, перейдем к фетишу сегодняшних веб-мастеров, инструменту PageSpeed Insights [ ➜ ]
Инструмент действительно полезен в оценке, опять же, каждого из типов страниц движка вашего сайта, а не только главной. Но, обязательно применяйте полушария своего серого вещества перед тем, как выполнять рекомендации. Не забывайте, что оценка автомата и пользователей может достаточно сильно различаться и на одном ресурсе после выполнения требований PSI, я получил несколько замечаний от пользователей по поводу рваной загрузки сайта.

Как исправлять основные замечания от PageSpeed Insights:

"Используйте кеш браузера": наиболее любимый новичками вопрос - как им быть, потому, что практически у каждого в этих замечаниях торчат скрипты гугл-аналитики или яндекс-метрики, а то и рекламных сетей на сторонних ресурсах. Можете не переживать, во-первых, потому, что сделать ничего не сможете (если только не соберетесь убрать эти скрипты вообще), во-вторых, скрипты аналитики и метрики никак не сказываются на ресурсах вашего сервера или на отображении сайта пользователю. Для всего остального подразумевается общее правило, что ресурс должен кешироваться минимум на одни сутки, что, конечно, не относится к динамическим ресурсам.

"Включите сжатие": несмотря на то, что проблемы скорости каналов уходят в небытие, до сих пор передать ли 2Кб или 10Кб для многих клиентов имеет значение, особенно, если рассматривать суммарные размеры страниц. Многие движки позволяют включить сжатие средствами языка программирования, однако, рекомендую это не делать и включить сжатие на уровне веб-сервера (традиционно используется gzip). Получится быстрее, сможете исключить сжатие совсем маленьких файлов, которое ничего не даст, кроме потерь ресурсов процессора, а, если используете Nginx, то изучите и параметр gzip_static, который позволит сжать, например, скрипты один раз и в дальнейшем выдавать уже их сжатый вариант. Ни в коем случае не включайте сжатие одновременно и на сервере и в движке.
Самый симпатичный из инструментов проверки странички на сжатие, который мне попадался:

"Удалите код JavaScript и CSS, блокирующий отображение верхней части страницы": в большинстве случаев, если вы не разработчик движка сайта, то сделать что-либо не сможете, либо сделаете то, что придется переделывать при следующем обновлении версии движка заново. Все варианты решений сводятся в большинстве случаев к той или иной асинхронной загрузке скриптов и CSS, либо с помощью атрибутов async и defer, которые можно применять только к включаемым файлам скриптов, но не вставкам кода, причем, есть определенные ограничения, как со стороны стандартов языка, так и со стороны браузеров. В большинстве случаев берете свой код страниц и везде код
меняете на
если порядок скриптов обязателен, то async="async" меняете на defer. Однако, как я уже говорил, достаточно часто вставки java-кода непосредственно в код страницы рушат на корню идею с асинхронной загрузкой. Но, можете попробовать работоспособность сайта, откладывая скрипты последовательно, по одному. Если часть скриптов удастся загрузить асинхронно, то это уже будет плюсом для скорости загрузки сайта. Тщательно проверяйте функционал сайта, поскольку от подобных оптимизаций достаточно многое может развалиться. С CSS есть очень интересный вариант отложенной загрузки, при котором сначала CSS загружается с указанием media="bogus" в заголовке, а потом включается в код страницы, подгружаясь уже моментально из кеша браузера.
Будем надеяться, что улучшения в HTTP/2 решат большую часть этих проблем.

"Оптимизируйте изображения" : речь идет о разных видах оптимизации, во-первых, если вы в аватарочный размер элемента страницы (100х100) запихиваете фотографию с фотоаппарата на 7Мб, то это обозначает, что бедный пользователь будет качать эту фотографию целиком, чтобы посмотреть ее многократно масштабированную в минус. Это неоптимально с разных точек зрения. Поэтому, если есть возможность, уменьшите картинки до того размера, который вы показываете пользователям.
Второй нюанс заключается в том, что картинки часто не подготовлены для отображения в вебе и содержат разнообразную служебную информацию, которая в принципе никак не влияет на отображение в составе страницы (например, EXIF), зато занимает какие-то байты, которые в условиях передачи информации принято экономить. Соответственно, существуют утилитки, которые могут эту информацию вычищать. Я уже писал про это здесь: (Как уменьшить размер картинки без потери ее качества), не стал сильно заморачиваться, утилитки нормально работают поверх уже проделанной работы, поэтому я просто прогоняю их раз в некоторое время по каталогу загрузки, назначив задание в cron. Если такой возможности нет, то обрабатывайте изображение перед загрузкой на хостинг.

"Сократите CSS"/"Сократите HTML"/"Сократите Javascript": одни и те же по смыслу замечания, сводящиеся в большинстве к тому, чтобы итоговый код сжать, вырезав все форматирование и переносы строк. С точки зрения программиста потом становится совершенно нечитабельный код, однако, размер иногда в два раза сокращается. Подумайте, насколько вы готовы пойти в ущерб собственному удобству (придется держать две копии файлов, одну сжатую, другую - нет) или возиться с правкой шаблонов, которые хранятся, например, в базе.

И, завершающим штрихом, свод того, что можно и что не нужно делать на сервере, возьмусь предполагать, что у вас Linux. Для начала забудьте о том, что надо крутить гору параметров ядра, в том числе сетевые буферы. Если у вас не какой-то специфический хостинг, занимающийся раздачей видео-файлов, то в большинстве своем заморачиваться правкой конфига, который уже правили разработчики ядра, гораздо больше понимающие в сетевых транспортах, в общем, уберите руки и избавите себя от кучи глюков и разочарований. Просто отслеживайте, если вдруг будут исчерпываться лимиты по умолчанию, когда исчерпаются, тогда и добавите.
Мой конфиг (поверьте, там было в разы больше строк в 2010 году):
Как видите, практически ни в чем я с разработчиками ядра не спорю.
Что могу порекомендовать изучить в свете желания работать хорошо с разными по удаленности клиентами по сети - TCP Congestion control. Yeah работает очень неплохо по сравнению с кубиками.

И, наконец, если Apache не жизненно необходим для вашего кода, то избавьтесь от него в пользу Nginx. Монструозный, тяжелый и тупой Apache никогда не будет работать с той же легкостью, с какой работает Nginx. Добавьте fpm-php и вот он, хостинг с PHP, который выдержит значительно большую нагрузку, чем вы планировали (если планировали) выдержать с Apache. Обилие разнообразных модулей и разнообразные продукты, написанные индусами на школьной перемене, дадут индейцу еще не одно рождение, но для быстрого вебсервера это неправильный выбор.

Вот, собственно, "коротенько, минут на 40" то, что я хотел сказать по ускорению загрузки страницы. За бортом осталась настройка MySQL и еще какие-то нюансы, которые, если будут вопросы, я готов осветить. Спрашивайте. Отдельные темы заводите отдельно.