Как я ускорил блог в 10 раз Спонсор поста: поисковое продвижение сайтов от SeoProfy. Думаю, мало кто из постоянных читателей мог не заметить того, что страницы моего блога теперь стали грузиться намного быстрее. Я и сам, признаться, не особо верил, что значительное увеличение скорости вообще возможно на моем блоге, т. к. хостер у меня один из самых “доступных” среди украинских, сервера у него забиты, думаю, уже до упора, а потому и качество услуг соответствующее. Как-то раз своим возмутительным поведением хостер даже вынудил меня написать им не самый приятный отзыв, однако это в прошлом, и ребята с тех пор исправились, чем на сегодняшний день заслужили мое уважение. Буквально месяц назад продлил у них хостинг еще на год, и не жалею. Однако, факт оставался фактом – страницы блога могли грузиться быстро, а могли и по 30 секунд. После статьи об ущербности отказа от ie6 для SEO, где я также рассказывал о важности поведенческих параметров вашего сайта для ранжирования, я решил начать оптимизировать скорость загрузки своих сайтов.
Первым в очереди стоял блог.
Ускоряем блог в 10 раз за 10 шагов
1. Самым первым делом я обратился к корифею дела оптимизации скорости сайта – сервису webo. in. ua, где я выяснил, что мой блог возможно ускорить на 35%, сжать размер отдаваемых страниц на 60% и получил рекомендации по тому, что нужно для этого предпринять. 2. Святое дело для любого движка – отключить тормознутые плагины. К примеру, на моем блоге стоял topsy retweet, который, хорошо чувствовалось, затягивал в начале скорость загрузки страницы, а затем еще и долго-долго выполнял свой скрипт на уже загруженной странице. Причем это чудо-юдо, как я позже разобрался, в начале подключало в секцию head страницы ЦЕЛЫХ 3 или 4 js файла (вроде бы даже некоторые со сторонних серверов), а затем еще и хрен знает сколько выполняло свои скрипты на загруженной страницы. Естественно, вся эта криворукость была снесена одним махом, и я поставил чуть менее функциональный tweetmeme, который не подключал ни единого стороннего файла и вообще никак не отражался на скорости загрузки страницы. 3. Не лишним также будет убрать и вывод таких ненужных в большинстве случаев вещей, как календарь и архивы на блоге. Все это только лишнее время на обработки запросов. Календаря у меня нет и никогда не будет, а вот архивы я снес. Сам ими за 2 года в жизни не воспользовался и, думаю, мои читатели тоже. 4. Дальше я начал с простого – банальное выпиливание лишнего кода из секции шаблона. К примеру, в этой секции у меня зачем-то были 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-файлик с текстом, залив этот файлик куда-нибудь на хостинг и запустив его из адресной строки браузера. В результате вы получите полнейшее описание всех возможностей вашего хостера. Отыщите строки zlib или gzip, и вам скорее всего интуитивно станет понятно, что из этого можно включить. Затем либо ищите кнопочку включения этих функций в панели хостера (у меня так), либо просите саппорт врубить одну из этих технологий. У меня на хостинге работает php5, и используется технология zlib, потому в свой header. php в самое-самое начало еще до “