Как я ускорил блог в 10 раз

Воскресенье, 05 Дек 2010 14:00

Как я ускорил блог в 10 раз

Как я ускорил блог в 10 раз

Спонсор поста: поисковое продвижение сайтов от SeoProfy.

Думаю, мало кто из постоянных читателей мог не заметить того, что страницы моего блога теперь стали грузиться намного быстрее. Я и сам, признаться, не особо верил, что значительное увеличение скорости вообще возможно на моем блоге, т.к. хостер у меня один из самых «доступных» среди украинских, сервера у него забиты, думаю, уже до упора, а потому и качество услуг соответствующее. Как-то раз своим возмутительным поведением хостер даже вынудил меня написать им не самый приятный отзыв, однако это в прошлом, и ребята с тех пор исправились, чем на сегодняшний день заслужили мое уважение. Буквально месяц назад продлил у них хостинг еще на год, и не жалею. Однако, факт оставался фактом — страницы блога могли грузиться быстро, а могли и по 30 секунд. После статьи об ущербности отказа от ie6 для SEO, где я также рассказывал о важности поведенческих параметров вашего сайта для ранжирования, я решил начать оптимизировать скорость загрузки своих сайтов. Первым в очереди стоял блог.

Ускоряем блог в 10 раз за 10 шагов

1. Самым первым делом я обратился к корифею дела оптимизации скорости сайта — сервису webo.in, где я выяснил, что мой блог возможно ускорить на 35%, сжать размер отдаваемых страниц на 60% и получил рекомендации по тому, что нужно для этого предпринять.

2. Святое дело для любого движка — отключить тормознутые плагины. К примеру, на моем блоге стоял topsy retweet, который, хорошо чувствовалось, затягивал в начале скорость загрузки страницы, а затем еще и долго-долго выполнял свой скрипт на уже загруженной странице. Причем это чудо-юдо, как я позже разобрался, в начале подключало в секцию head страницы ЦЕЛЫХ 3 или 4 js файла (вроде бы даже некоторые со сторонних серверов), а затем еще и хрен знает сколько выполняло свои скрипты на загруженной страницы. Естественно, вся эта криворукость была снесена одним махом, и я поставил чуть менее функциональный tweetmeme, который не подключал ни единого стороннего файла и вообще никак не отражался на скорости загрузки страницы.

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

4. Дальше я начал с простого — банальное выпиливание лишнего кода из секции <head> шаблона. К примеру, в этой секции у меня зачем-то были 2 редкостных мета-тега, даже описание которых найти было трудно, и мета-тег generator, отвечающий за вывод названия и версии движка. Все это лишний код, который нужно убирать из шаблонов по максимум, чтобы ваши странички весили как можно меньше. Кроме того, поочередно подключались сразу 2 разные версии jquery — одна по умолчанию WordPress, другая грузилась плагином с серверов Google. В некоторых случаях это давало сбой работы js на странице.

5. То же было проделано и для других файлов: index.php, home.php, archive.php, sidebar.php, single.php, search.php и т.д. Наличие этих файлов зависит от специфики вашей темы. В этих файлах я удалял  в основном давно ненужные закомментированные куски кода и огромное множество пустых строк в коде. На более серьезные манипуляции не решился, т.к. хотел оставить файлы в пригодном для редактирования виде.

6. Когда с мелочами было покончено, встал вопрос о количестве подключаемых к вашей теме файлов, и вот здесь-то начинается интересная и кропотливая работа. Как известно, каждый плагин WP норовит добавить в секцию head вашей темы все необходимые для него файлы, как правило, это скрипты JS и файлы стилей CSS. Даже 3 плагина могут уже сделать десяток таких подключений, и нагрузка, естественно, возрастает очень заметно. Каждый подключаемый отдельно файл — это очередной запрос к серверу, чтобы этот файл получить. А количество запросов к серверу также заметно отражается на скорости загрузки вашего сайта. Задача стоит по сути следующая: необходимо по возможности снизить число подключаемых к теме файлов, грубо говоря, сгруппировать все скрипты и файлы стилей в 1 файл скриптов и 1 файл стилей. Я делал это не совсем правильно, так бы сказать, «в лоб». Смотрел, какой плагин какой скрипт или файл css подключает, открывал код самого плагина и выпиливал строки, отвечающие за подключение, а затем копировал весь код скрипта или весь файл css, подключаемых этим плагином, и вставлял их, соблюдая очередность, в свои основные script.js и style.css. Безусловно, правильнее было бы отключать файлы js и css плагинов при помощи functions.php, однако в моем случае, когда я не обновлял ни сам двиг, ни плагины вот уже около года, и, честно скажу, еще долго не собираюсь этого делать, я посчитал и это подходящим вариантом. Конечно же и это стоит делать с умом и смотреть, ко всем ли страницам блога подключаются плагином файлы .js и .css. Потому что, если в записи у вас не используется page-navi, то нет большого смысла вставлять его css в основной style.css, а стоит подключать page-navi.css отдельно только для single.php. Хотя, с другой стороны, кода там всего на 700 байт, потому данный пример не особо удачен. А вот в случае с более тяжелыми файлами это в принципе имеет смысл, и собирать тогда файлы вместе стоит по принципу страниц, к которым они подключаются, т.е., к примеру, single.css и category.js.

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

7. Раз снижаем количество подключаемых файлов, то самое время подумать и о графике самого шаблона. Ключевое слово здесь — спрайты. К примеру, вот мой спрайт: blogto4ka.ru/wp-content/themes/aquanova/images/sprite-1.png, в котором я собрал 12 типичных для всех страниц моего блога изображений, снизив таким образом число обращений к серверу на 11, и суммарный вес всей этой графики на 3Кб. Совсем чуточку была подправлена верстка под все это дело. И конечно же не забывайте про отдельные правила для ie6, который не поддерживает альфа-канал png-24 изображений.

8. Теперь, когда в css и js файлах больше не намечается исправлений, самое время оптимизировать их. css я всегда оптимизирую с помощью http://cleancss.com/, а для сжатия js в этот раз я воспользовался тулзой Гугла: http://code.google.com/intl/ru/closure/compiler/docs/gettingstarted_ui.html. Я стараюсь пользоваться режимами, в которых в код вносятся минимальные, т.е. наиболее безопасные изменения. Так в css были убраны лишние пробелы и заменены некоторые свойства на аналоги, чуть быстрее обрабатываемые браузерами, а в js просто убрана ненужная пустота. В итоге файлы стали весить меньше, css же стал заметно быстрее обрабатываться браузером.

После этого этапа я уже заметил значительное ускорение своего блога.

9. Давно слышал о таких понятиях как gzip/zlib сжатие, когда файлы отдаются сервером в сжатом виде, что позволяет пользователю получить в свой браузер, к примеру, 500 Кб вместо 700 Кб, а затем уже самим браузером разжимаются до первоначального размера. Причем большинство современных браузеров поддерживают оба вида сжатия, потому включать их вполне логично для любого сайта. Теперь я наконец разобрался с этими понятиями и даже опробовал их на себе. Все оказалось крайне банально. В начале нужно выяснить, какую из технологий поддерживает хостер: сделать это можно создав php-файлик с текстом <?php phpinfo (); ?>, залив этот файлик куда-нибудь на хостинг и запустив его из адресной строки браузера. В результате вы получите полнейшее описание всех возможностей вашего хостера. Отыщите строки zlib или gzip, и вам скорее всего интуитивно станет понятно, что из этого можно включить. Затем либо ищите кнопочку включения этих функций в панели хостера (у меня так), либо просите саппорт врубить одну из этих технологий. У меня на хостинге работает php5, и используется технология zlib, потому в свой header.php в самое-самое начало еще до «<!DOCTYPE» я добавил строки:

1
2
3
4
<?php
ini_set('zlib.output_compression', 'On');
ini_set('zlib.output_compression_level', '1');
?>

Аналог этих строк для gzip сжатия найдете где-то в google.

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

10. Закономерной кульминацией любой оптимизации скорости загрузки сайта является включение кеширования. Работает это следующим образом: при первой загрузке страницы за указанный период существования кеша пользователю загружается страница с сервера как обычно, при этом статичный ее вариант сохраняется там же на сервере, и уже второму посетителю, запросившему эту страницу, отдается обычный статичный вариант html-странички, практически полностью освобождая таким образом сервер от нагрузки (выполнение кода шаблона и т.п.).

Есть 2 очень известных для этого дела плагина — WP Super Cache и hyper cache, но как и любой плагин они увеличивают нагрузку на сервер, а прошлая выходка моего хостера до сих пор свежа в моей памяти, потому я воспользовался скриптом кеширования от centavrus-opti.ru. Этот скрипт очень прост в установке, имеет множество гибких настроек, в т.ч. и время существования кеша, дополнительно минимизирует .js и .css файлы, отлично работает с включенным zlib сжатием и математической капчей. Судя по описанию, этот плагин является чуть ли не полным бесплатным аналогом платного скрипта кеширования от автора Maxsite CMS. 30$ отвалить Максу за этот скрипт дороговато. Как он сам утверждает — копит на квартиру :) . В общем, сделал донейт в половину от этой суммы автору centavrus-opti.ru, и имею похожий скрипт, но без ограничения на количество сайтов, чего и вам желаю. Скрипт этот постоянно дорабатывается и улучшается, автор — любезнейший человек, принимающий багрепорты прямо по аське.

Недостатки скриптов кеширования

Однако, как я выяснил, использование скриптов кеширования накладывает некоторые ограничения на их пользователей. К примеру, хотя подобные скрипты зачастую сбрасывают кеш страницы, когда на ней оставлен новый комментарий, но если возникает ситуация, что комментарий попадает на модерацию, то после того, как вы его промодерируете, кеш страницы, естественно, не сбросится, и пользователь не увидит там своего уже промодерированного вами комментария аж пока не спадет кеш. Здесь вы либо будете ручками сбрасывать кеш такой страницы, либо убирать модерацию комментариев, либо уменьшать период сброса кеша, в общем, идти на компромисы. Точно также будут вести себя и другие интерактивы через php. К примеру, плагин wp-polls по идее отработает, засчитает голос посетителя и даже покажет ему результаты голосования, но при перегрузке страницы опрос будет выглядеть так, будто бы пользователь и не голосовал, т.к. страница загрузится из кеша. Устранение этих недостатков требует так званого «поблочного кеширования», и, соответственно, реализации на уровне плагина, что в свою очередь упирается в нагрузку на сервер. Меня лично пока что вполне устраивают компромиссные варианты с использованием скрипта кеширования, но это может быть в корне неподходящий для вашего проекта вариант, потому хорошо подумайте, возможно вам больше подойдет плагин вроде WP Super Cache.

Результаты работы

Установка скрипта кеширования стала финальной точкой в ускорении моего блога. Я более чем доволен результатом: морда из кеша отдается за сотые доли секунды, полностью сформированную страницу после загрузки всех картинок и отработки js-скриптов на ней пользователь видит уже через 2-5 секунд, при отдаче страницы с сервера это время обычно 3-6 секунд, визуально все происходит мгновенно, и, полагаю, в скором времени это найдет свое отражение в улучшении поведенческих параметров сайта и ранжировании моего блога в ПС. Сервис webo.in утверждает, что все еще способен ускорить мой блог на 13% и сжать все файлы еще на 3%, хотя теперь я вполне могу это сделать и без него, но необходимости в этом явно нет. Хостер будет мне крайне признателен за сумасшедшие экономию трафика и снижение нагрузки на сервер после проделанной работы :) .

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

Успехов!
Ваш Перспективный блоггер

http://blogto4ka.ru

RSS комментариев

8 комментариев Упоминаний: 2 Комментировать

  1. Klerik пишет:

    05 Дек 2010 в 18:03 Reply to this comment

    1

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

  2. BloggerMen пишет:

    06 Дек 2010 в 6:00 Reply to this comment

    2

    Отличные результаты.

    Только с плагинами кэширования нужно быть осторожнее. Когда-то я ставил себе hyper cache, но он начал с чем-то конфликтовать, в результате вылетело из индекса 60-70% страниц. Пришлось даже платонам писать.

  3. Завраб пишет:

    08 Дек 2010 в 11:24 Reply to this comment

    3

    спрайты это неплохо, сам хочу их попробовать, но лень размеры картинок вычислять

    насчет кеширования — сам не стал включать, потому что у меня есть динамика на сайте, да и кеширующие плагины глючат иногда и не совместимы с некоторыми из плагинов

  4. wat пишет:

    08 Дек 2010 в 14:59 Reply to this comment

    4

    Познавательно, спасибо! Буду и свой ускорять!

  5. Koreps пишет:

    09 Дек 2010 в 15:03 Reply to this comment

    5

    Расскажи поподробнее что и как делал в 7 пункте.

  6. nikolas_sharp пишет:

    09 Дек 2010 в 15:15 Reply to this comment

    6

    Ну, спрайты, это чисто тема верстальщиков. Вряд ли будет понятно, если нет никакого опыта верстки. Наверное резонно будет хорошенько погуглить, тогда и разберешься. Но вкратце все же попробую на пальцах объяснить. Значится, так званая верстка дивами (html тегами <div>) — это верстка, базовый элемент которой <div> представляет из себя по сути блочный прямоугольник заданных размеров, которому можно задать фон. Причем в качестве фона блочного элемента <div> можно задать абсолютно любое изображение и, более того, спозиционировать это изображение заданием координат от левого верхнего угла <div>'a. Таким образом <div>'у в качестве фона можно задать абсолютно любого размера картинку, а затем спозиционировать эту картинку так, чтобы в самом <div>'e была видна только нужна тебе часть огромной картинки. Собственно, это я и сделал: собрал 12 использующихся на всех страницах моего блога картинок в 1 большую картинку (спрайт), а затем позиционировал эту картинку на фоне различных блочных элементов, чтобы получить нужный мне фон у этих блочных элементов. Вместо 12 картинок получилась 1, но большая, соответственно вместо 12 запросов к серверу получился всего 1. Верстку даже менять практически не пришлось, просто перепрописать некоторым блочным элементам старую картинку на новую (большую, она же «спрайт») и правильно задать ей координаты. Ну, понятно хоть что-либо? :)

  7. Peshexod пишет:

    09 Янв 2011 в 16:25 Reply to this comment

    7

    ну не webo.in.ua (домен свободен), а webo.in :)

  8. semen пишет:

    15 мая 2011 в 23:36 Reply to this comment

    8

    А какой у вас показатель средней загрузки страниц блога по Гугл-инструментам?

Оставьте свой комментарий о материале
(Комментарии со ссылками попадают на модерацию. Остальные не попадают, но я могу удалять те, которые посчитаю бесполезными, не несущими смысловой нагрузки)