Намедни узнал, что Google считает за время загрузки страницы не время, за которое сервер отдаёт содержимое оной, а время с момента отправки запроса к серверу и до наступления события window.onload. Проверка показала, что на одном из моих сайтов, занимающих 3-7 места по нескольким ВЧ-СК запросам, средняя скорость загрузки составляет 17,5 секунд, что медленнее, чем 99% сайтов, а для одной из его страниц — 30,7 секунд. Для уменьшения этих огромных чисел, мною был предпринят ряд мер, о которых и пойдёт речь в этом посте.

По-белому

Для получения общих рекомендаций по увеличению скорости загрузки страницы можно воспользоваться плагином Page Speed от Google, который даёт достаточно полное представление об оптимизации, вплоть до использования рациональных селекторов CSS, что не столь существенно при современных мощностях компьютеров. Также небольшой прирост даст и вынос статических элементов страницы на другой домен (для экономии времени на передачи cookies), по крайней мере для WordPress. Но есть несколько существенных моментов:

Минимизация кода состоит в удалении лишних пробелов, переводов строки и т.п. из кода HTML, CSS, JavaScript. В WordPress эту работу можно автоматизировать при помощи плагина Autoptimize.

GZIP компрессия существенно экономит трафик для больших страниц. Помниться раньше, в WordPress была встроенная возможность сжатия. Сейчас её  можно добавить плагином GZIP Enable.

Кэширование на стороне сервера экономит время на «сборке» страницы, что особенно важно для сайтов, работающих под большой нагрузкой. Не так критично для WordPress, как например, для Drupal. Для первой существует несколько плагинов, мне нравится WP Super Cache.

Кэширование на стороне клиента и прокси-серверов позволяет экономить время при повторном обращении к сайту, что обычно не характерно для поискового трафика. Суть заключается в отправке заголовков Expires и Cache-Control для кэшируемых элементов. Подробнее в этой статье.

Gravatar и пользователи без автарок в этой системе способствуют загрузки стандартной картинки (одной и той же для пользователей без аватаров) через редирект. Для получения изображения с Gravatar, в него отправляется хэш-код почты и адрес изображения для пользователей без аватаров. В случае, если система не находит хэш в базе, происходит редирект на стандартное изображение. Редиректа можно избежать, не отправляя адрес своей стандартной аватарки (тогда будет загружаться стандартная от Gravatar: сине-белая), но запрос одного и того же изображения по разным адресам, по-прежнему нерационально тратит ресурсы. Решение видится в кэшировании аватарок на своём сервере. Рабочих плагинов для WP 3.0 я не нашёл и просто отказался от использования Gravatar.

По-чёрному

Вышеописанные методы дают «честный» прирост скорости — и для Гугла и для пользователя. Однако можно увеличить скорость загрузки страницы в глазах Гугла, вынеся всё что можно (кроме того, что должно быть проиндексировано) в обработчик события window.onload. Это могут быть и картинки, и флэш-баннеры, и даже JS-скрипты и CSS-разметка.

Пример:


function load_ads() {
var adHTML = document.getElementById('adHTML');
if (adHTML) {
adHTML.innerHTML = '<div>ololo</div>';
}

var adJS = document.createElement('script');
if (adJS) {
adJS.src = 'http://zloy-tony.ru/adJS.js';
adJS.type="text/javascript";
document.getElementsByTagName('head')[0].appendChild(adJS);

var adCSS = document.getElementById('adCSS'); // <link  id="adCSS" rel="stylesheet" type="text/css" href="" />
document.getElementById('adCSS').href = 'http://zloy-tony.ru/adCSS.css';
}
window.onload = load_ads();

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