Как получить быстрый сайт — оптимизация (сжатие) изображений и скриптов, а так же уменьшение числа Http запросов

9 Январь, 2011

Здравствуйте, уважаемые читатели блога KtoNaNovenkogo.ru. Низкая скорость загрузки страниц сайта может негативно отразиться на популярности вашего проекта (особенно к этому критично относятся пользователи с высокой скоростью интернета, которые не привыкли ждать).

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

С помощью Page Speed мы попробуем максимально осуществить сжатие изображений, скриптов и CSS файлов. Хотя про сжатие CSS с помощью Page Speed мы уже говорили, а значит осталось осуществить сжатие картинок и различных скриптов, которые подгружаются в браузер пользователя с вашего сервера.

Но давайте для начала я напомню то, о чем мы говорили в первых статьях по созданию быстрого сайта:

  1. Как измерить скорость загрузки сайта онлайн, а потом ее увеличить с помощью советов в Page Speed
  2. Оптимизация (сжатие) CSS в Page Speed
  3. Gzip сжатие для ускорения загрузки сайта

Чистим фоновую графику для снижения числа http запросов


Насчет картинок сразу стоит оговориться — прежде, чем приступить к их оптимизации, вам, пожалуй, следует решить, а нужны ли они у вас на сайте?! Дело в том, что в шаблоне вашего ресурса могут быть описаны в CSS файле фоновые изображения для отображения различных элементов дизайна, но при этом их вы по тем или иным причинам не используете.

Вообще, изображения на сайте могут выводиться двумя способами: с помощью Html тега IMG (тут и тут читайте подробнее), а так же с помощью CSS свойств «background» или «background-image», которое может выглядеть, например, так:

background:url(http://ktonanovenkogo.ru/wp-content/themes/Organic/images/spriteme3.png) no-repeat;

При загрузке страниц происходит и подгрузка картинок, заданных как через IMG, так и фоновых изображений, описанных свойствами «background» в CSS файле. Посмотреть все подгружаемые в браузер пользователя графические файлы можно в нашем средстве для получения быстрого сайта — Page Speed на вкладке «Resources»:

В колонке «Type» для графики, вставленной через IMG, будет прописано «image», а для фоновых картинок, вставленных через CSS — «cssimage». Поэтому при помощи Page Speed вам будет достаточно просто их различить, к тому же, подведя курсор мыши к строчке с интересующим вас изображением, вы увидите его превьюшку:

К чему я все это говорю? Дело в том, что когда я дошел до сжатия (оптимизации) изображений, желая создать максимально быстрый и шустрый блог, то прежде всего внимательно изучил всю подгружаемую с моего web сервера в браузеры пользователей графику и пришел к неутешительному выводу.

Во-первых, объектов было слишком много (около 70), что совсем не здорово, ибо для передачи каждого из них формируется отдельный http запрос. 70 http запросов тратилось только на загрузку графики — это недопустимо много, т.к. сильно снижает быстроту сайта. Следовательно, одним из самых действенных способов может быть уменьшение числа http запросов при загрузке страницы вашего ресурса.

Во-вторых, меня озадачило то, что среди подгружаемых изображений (при открытии любой страниц моего блога) было много картинок, которые не использовались в его оформлении. Взялись эти левые картинки из CSS файла используемой мною темы WordPress, об устройстве который читайте тут.

При первоначальной настройке темы под свои нужды, я не очень корректно убрал эти изображения из оформления, забыв удалить соответствующие им CSS свойства («background») из файла стилевого оформления темы (style.css), который обычно расположен по следующему пути:

/wp-content/themes/Organic/style.css

Кроме этого нашлось несколько картинок, которые практически не играли никакой роли в дизайне блога, но зато требовали дополнительные запросы для их загрузки. Поэтому самым первым действием, призванным сделать сайт быстрым, была чистка style.css от лишних фоновых изображений, загрузка которых не являлась необходимой.

К слову сказать, таким образом мне удалось сэкономить до 20 http запросов при загрузке любой страницы моего блога, удалив, соответственно, из style.css около 20 записей о подгрузке фоновых изображений (ненужных или малозначительных). Для проведения подобной операции вам нужно будет подключиться к своему ресурсу через FTP клиент и открыть на редактирование файл стилей из указанной выше папки.

Далее вы производите поиск по нему с помощью средств того редактора, в котором вы его открыли. Искать следует по названию того графического файла, который вы желаете удалить. Находите строчку со свойством «background», из-за которой подгружается это фоновое изображение и удаляете ее. Проверяете через Page Speed корректность проведенных вами действий.

Таким образом вы проведете начальный этап оптимизации графики для сайта, пока еще без сжатия. На втором этапе ускорения вам нужно будет уже поработать с теми картинками, которые вы все-таки решите оставить.

Сжатие и оптимизация изображений на быстром сайте


Тут можно сделать две вещи — оптимизировать размер каждого отдельного изображения через Page Speed, а так же объединить некоторые фоновые картинки из файла стилевого оформления в так называемые CSS спрайты.

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

Мне очень нравится онлайн сервис PunyPNG, который просто великолепно сжимает графику формата PNG (я уже писал тут, когда лучше использовать формат PNG, когда JPG, а когда и GIF):

Очень неплох был и Яховский Smush.it:

Но для работы с графикой шаблона проще будет воспользоваться возможностями самого Page Speed (ну, или на худой конец FastStone Image Viewer, описанного здесь), тем более, что он сжимает графику очень эффективно и без потери качества (иногда даже в пару раз уменьшает размер и, соответственно, и убыстряет сайт).

Что же касается CSS спрайтов, то это такой способ объединения нескольких фоновых изображений в один единственный графический файл, а затем уже с помощью прописанных свойств можно настроить показ только определенного участка этого большого спрайта в нужном месте сайта. Он может выглядеть, например, так:

Догадайтесь, кому он может принадлежать (подсказываю — поисковой системе Google.ru, о которой речь шла тут). В принципе, создавать CSS спрайт с нуля в каком-либо графическом редакторе очень сложно, ибо потом нужно будет в style.css очень четко описать позиции того или иного рисунка на большом изображении.

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

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

Да, в принципе, точно так же, как и чуть ранее сжимали CSS средствами Page Speed. Только проделать все тоже самое нужно будет для другой строчки под названием «Optimize images». Щелкаете по плюсику рядом с этой строкой и просматриваете список тех картинок на открытой в браузере странице, которые по мнению этого плагина можно оптимизировать:

Далее вам нужно будет щелкнуть по"Save as" и скачать уже сжатое изображение на свой компьютер. В первую очередь стоит оптимизировать те, которые входят в состав вашего шаблона, и, следовательно, подгружаются на каждой странице.

Даже немного оптимизировав графику шаблона, вы сможете повлиять на общую скорость загрузки всего сайта. К тому же они, как правило, сжимаются очень сильно (до нескольких раз, во всяком случае для моей темы WordPress).

Сжатие скриптов для получения быстрого сайта

Кроме изображений с помощью Page Speed вы можете так же сжать скрипты (JavaScript, jQuery), которые подгружаются в браузеры пользователей с вашего web сервера. Сделать это можно в строке под названием «Minify JavaScript»:

Очень здорово было бы предварительно объединить все внешние скрипты в один файл (это нам советует сделать сам плагин в строке «Combine external JavaScript»), по аналогии с тем, как мы это сделали чуть ранее для CSS.

Для блога на WordPress отключить ненужные внешние скрипты, после их объединения в один большой файл, можно опять же по аналогии с описанным мною ранее случаем.

Правда, в файл functions.php, о котором мы говорили тут (живет он в папке /wp-content/themes/название темы WordPress/), нужно будет прописать несколько другой код с указанием регистров плагинов:

add_action( 'wp_print_scripts', 'my_deregister_javascript', 100 );
function my_deregister_javascript() {
	wp_deregister_script( 'регистр 1-го WordPress плагина, отвечающий за подключение скрипта' );
        wp_deregister_script( 'регистр 2-го WordPress плагина' );
        wp_deregister_script( 'регистр 3-го WordPress плагина' );
}

Отключить загрузку внешних скриптов различных плагинов в WordPress мне удалось без проблем, посредством описанного выше кода, но вот после объединения их кода у меня плагины почему-то не работали. К сожалению, мои познания в JavaScript и jQuery сводятся только к тому, что нельзя объединять эти два вида скриптов в одном файле.

Поэтому после нескольких попыток я признал свое поражение и полную некомпетентность в этом вопросе. Если кто знает нюансы, которые важно учесть при объединении внешних JavaScript и jQuery скриптов, то буду очень признателен за подсказку.

Еще оной проблемой, которая была помечена в Page Speed красным цветом, как очень важная для скорости загрузки моего сайта, являлась подгрузка всех объектов с одного хоста (ktonanovenkogo.ru) — «Parallelize downloads across hostnames». По мнению этого инструмента лучше было бы распараллелить загрузку объектов с разных хостов, увеличив тем самым общую скорость.

Я внял этому совету и перенес все баннеры и еще некоторые картинки своего блога на другой сервер того же самого хостинга, где был размещен еще один мой проект, не имеющий высокой посещаемости и, следовательно, не создающий существенной нагрузки на сервер.

Переместив графические файлы я, соответственно, поменял пути до них в коде шаблона. Но можно было бы перенести и все используемые на блоге изображения на альтернативный хостинг и при этом даже не менять пути. Для этих целей очень удобно использовать 301 редирект, о котором я уже писал в этой статье про редирект с WWW на без WWW и, наоборот.

Я даже попробовал такой вариант 301 редиректа и он прекрасно работал, вот только для альтернативного хоста использовал не полноценный сервер, а, так называемый, сервер для статических объектов. Мой хостер предлагает бесплатно в качестве дополнения такую вещь, как дисковое пространство под статические объекты (изображения, видео и т.п.) на отдельном сервере, для снижения нагрузки на основной.

Вещь достаточно удобная с точки зрения теории, но на практике, когда я перенес часть изображений из определенной папки в это хранилище для статических объектов и прописал в файле .htaccess (подробности о .htaccess можно посмотреть здесь) редирект со старой папки картинок (на основном web сервере) на новую (для статических объектов) такого вида:

Redirect 301 /image http://images.ktonanovenkogo.ru

Здесь /image"" — каталог с картинками на основном хосте (где и прописывается код 301 редиректа в .htaccess), а http://images.ktonanovenkogo.ru"" новое месторасположение на альтернативном хосте. Но оказалось, что, во-первых, скорость работы специализированного хоста достаточно низкая, а во-вторых, при этом перестало работать кэширования статических объектов в браузерах пользователей.

Page Speed сразу же выделил красным строку «Leverage browser caching». Причем прописывание в файл .htaccess на новом хосте нужных директив результата не дало. Скорее всего тот сервер просто-напросто эти директивы не был способен выполнить.

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

Удачи вам! До скорых встреч на страницах блога KtoNaNovenkogo.ru

Еще:

Рубрики :Полезные программы ¦ Скорость загрузки сайта

Комментарии и отзывы

armid

Как жу тогда Google Paga Speed говорит что с Parallelize downloads across hostnames все ОК. Если вы говорите, что у вас не получилось?

ma3cs

Спасибо за серию статей, очень познавательно и точно пригодится при отладке своего сайта, но у меня вот какой вопрос:

Зачем нужно было проводить внутреннюю оптимизацию под CSS спрайты если толком информации по ним 0 в этой статье? Или это уже в привычку входит? Или есть какая-то хитрость? Мне лично не понятен этот момент...

Дмитрий

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

ma3cs: думал написать подробно про css спрайты именно в этой статье, но не сложилось. Сегодня будет последняя часть из серии оптимизации скорости загрузки и именно по спрайтам.

armid

Еще один вопросик. Для Parallelize downloads across hostnames вы редактировали записи CNAME для домена?

Александр

Большое спасибо за Ваши статьи! Давно подписался на Вашу рассылку, очень много дельных рекомендаций. Сейчас столкнулся в Page Speed с такой штукой: если сайт анализировать с www, то появляется ошибка Parallelize downloads across hostnames и результат 82/100, а если без www — ошибки этой нет и 87/100. В чем может быть дело?

Андрей

CSS спрайты — вот это интересно будет, жду с нетерпением.

А что по поводу «Serve static content from a cookieless domain», или я что-то пропустил ?

armid

Дмитрий говорит, что:

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

Дмитрий, вы затронули очень важные темы. Спасибо за Ваш труд.

А как же тогда в том же google page speed на вклдаке resources, я не вижу что бы что-то грузилось со сторонних серверов?

Евгений

Html-запросы — это что-то новенькое. Дмитрий, вы наверное все-таки имели ввиду http-запросы.

Дмитрий

Евгений: спасибо за замечание, глаз замылился.

armid: пока не делал.

mixac

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

LEGION

Здравствуйте. Вот если бы вы еще подсказали как отключит конкретный скрипт на конкретной странице. Для примера, есть такой красивейший плагин обратной связи — Simple Modal Contact Form, плавно раскрывающийся лайтбокс поверх основной страницы с ее затемнением. Все бы замечательно, но он нужен только на одной странице — «Обратная связь», а свои стили и скрипты впихивает буквально на каждую (и страницу и пост), соответственно и создает ненужную нагрузку при обновлении каждой страницы.

По поводу объединения JS и jQuery — в первый раз слышу чтоб это было проблемой. Только сегодня редактировал qipSmiles, а там JS-скрипты прописаны в файле qips-js.php (php!), причем кусок JQ-кода, отвечающий за плавное изменение opacity при наведении мыши, удалось вставить без проблем.

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

Максим

>>Page Speed сразу же выделил красным строку «Leverage browser caching». Причем прописывание в файл .htaccess на сервере для статических данных нужных директив результата не дало. Скорее всего тот сервер просто-напросто эти директивы не был способен выполнить.

На сервер для статических объектов скорее всего не установлен Apache, поэтому .htaccess и не принес должного эффекта.

Для решения возникшей проблемы нужно включить кэширование на том веб сервере, который реально установлен (скорее всего nginx).

Наверное Вас не заинтересует это решение, т.к. Вы уже воспользовались другим способом, но все же...

rasse1

Здравствуйте. Не подскажите как отложить синтаксический анализ Javascript. В ошибках pagespeed у меня есть это правило , нигде не могу найти ответ на этот вопрос. Заранее спасибо.

Вячеслав

Тоже интересует, как отложить синтаксический анализ Javascript. Какой код и в какую часть шаблона он вставляется?

Артур

Я иначе поступал. Если главная, то грузить скрипт для карусели картинок. Потом ассинхронный код есть. В итоге не плохо получилось. JS не наваливаются, а подгружаются.

CSS нету толка скидывать в один файл. Он будет большой. Также решается где какой CSS использовать в каком браузере.

Подписаться не комментируя