Что нам стоит сайт построить? Ускоряемся!

Проблема ускорения web-страниц волнует каждого опытного сайтостроителя. При этом под «ускорением», как правило, понимают среднее время между запросом пользователя и отдачей ему готовой страницы. Если речь идёт о движках (CMS), то все усилия по оптимизации обычно бывают направлены на повышение скорости генерации страниц, а вот о скорости непосредственной передачи их пользователю чаще всего забывают. Между тем, даже в наш век скоростного интернета, этот параметр может существенно влиять на комфортность работы с вашим сайтом. Согласитесь, мало кто из пользователей согласиться ждать загрузки страницы больше минуты.
В очередной статье цикла мы поговорим о методах, которые позволяют «ускорить» сайт именно с этой точки зрения.

Для начала давайте разберёмся, какие аспекты влияют на скорость загрузки страницы. Прежде всего, это собственно объём HTML-кода. Главный совет здесь один: чем проще, тем лучше. Не стоит мудрить с HTML-конструкциями без реальной необходимости. Также могу порекомендовать использовать DIV’ ы везде, где нет реальной нужды в таблицах. В принципе, не лишним будет проверить вашу вёрстку на валидность. О необходимости этой процедуры спорят уже давно и очень часто решающим аргументом против валидности бывает пресловутое «а валидным кодом такой макет не сделать». Что тут скажешь? Было бы желание — сделать можно всё. Но мы сегодня говорим о скорости сайта. С этой точки зрения от валидности тоже может быть польза. Любой уважающий себя браузер должен точно следовать спецификациям консорциума W3, а значит при анализе кода загружаемой страницы программа в первую очередь ищет синтаксически правильные конструкции. Если таковые найдены — страница отрисовывается на экране. А вот если код содержит ошибки — возможны два варианта. Скорее всего мелкие ошибки (например, отсутствие кавычек в параметрах HTML-тегов) будут просто проигнорированы (хотя парсинг при этом займёт лишнее время — ведь сперва ищется правильный код). Более серьёзные ошибки (например, путаница во вложенных тегах типа table/tr/td или div) в теории должны привести к ошибкам в отображении страницы, но на практике очень многие браузеры (особенно этим отличается Opera) пытаются исправить ошибки, что, как вы понимаете, отнимает у них некоторое время. Конечно, доли секунды, которые браузер тратит на исправление ошибок — это капля в море, но если ошибок много — доли могут превратиться в секунду или две, и кто знает — не станут ли эти секунды той каплей, что переполнит чашу терпения ваших пользователей.

Официальный Validator от W3

Официальный Validator от W3

Следующий элемент, на который стоит обратить внимание — CSS. Без каскадных таблиц стилей сейчас не обходится ни один серьёзный сайт. Применять их можно двумя способами: путём непосредственной вставки стилей в параметры тегов (style=''***'') или же созданием единого файла стилей (style.css) и подключением его к вашей странице посредством конструкции link rel=»stylesheet» в блоке head. C точки зрения скорости оптимальнее — второй вариант. Вынесенные в отдельные файлы стили будут кэшироваться браузером, а значит пользователю не придётся каждый раз ждать их загрузки, тогда как при использовании параметра style стили, так же как и весь прочий код, будут подгружаться каждый раз заново.
Помимо всего прочего, не стоит забывать, что файлы стилей тоже имеют свой вес, а значит нуждаются в отдельной оптимизации. Сжатие CSS – палка о двух концах. Основной его метод — удаление их файла всего форматирования и комментариев, в результате чего стили теряют в весе, но становятся совершенно неудобочитаемыми с точки зрения самого разработчика. По сему — совет один: сжимайте только окончательный вариант стилевых файлов, в который не предполагается вносить правки. Кроме того, не забывайте о сохранении оригиналов — на всякий случай.
Собственно «сжатие» CSS можно выполнить двумя способами — руками (для любителей долгой монотонной работы) или с помощью специальных сервисов. Самый известный из них — CleanCSS. На входе вы передаёте сервису ссылку на css-файл или непосредственно его код, а на выходе получаете сжатый CSS (даже более или менее читаемый). Помимо всего прочего у этого сервиса есть куча настроек (к примеру, в можете сохранить комментарии).
Если читаемость CSS совершенно не принципиальна, можно также попробовать сервис Robson CSS Compressor. Сжимает он немного лучше, чем CleanCSS, но код при этом превращается в жуткую кашу.

Переходим к следующему шагу — JavaScript. Большинство современных CMS (даже самописных) широко используют этот язык, позволяющий значительно повысить удобство пользовательских web-интерфейсов. При его использовании есть, однако, тонкости, о которых обычно забывают. Во-первых, обработка JS занимает у браузеров куда больше времени, чем рендеринг HTML/CSS. Как следствие, хаотично расставленные в коде сценарии замедляют загрузку страницы. Совет прост: постарайтесь собрать все скрипты в один файл и добавить его вызов в самый конец HTML-страницы. В этом случае браузер сначала отобразит пользователю содержимое страницы (и да возрадуется юзерское сердце!), а уже потом примется за выполнение сценариев. Фактически полное время обработки страницы мы таким способом не изменим, но субъективно пользователю будет казаться, что сайт работает быстрее. Кроме того, вынося скрипты в отдельный файл, мы — как и в случае с CSS – позволяем браузеру с чистой совестью их закэшировать. О плюсах такого подхода мы уже сказали.

YUI

Сжатие JS-файлов также момент немаловажный. Оно, опять-таки, осуществляется за счёт удаления форматирования и комментариев, а кроме того — за счёт замены имён переменных на более короткие (в стиле a1, а2, a3 и т. п.). Упаковать JS можно с помощью онлайн-сервисов (например, этого) или локальной программой Yui Compressor. О последней стоит рассказать чуть подробнее.
Программа эта по сути представляет собой сценарий Java, а значит для её использования необходимо наличие в системе установленной виртуальной Java-машины (её можно найти в дистрибутивах Opera и OpenOffice). Чтобы сжать с помощью Yui Compressor свой сценарий, вам придётся выполнить консольную команду примерно такого вида (myscript.js и myscript-min.js — это, соответственно, исходный и сжатый файлы сценариев):

java -jar yuicompressor-x.y.z.jar myscript.js -o myscript-min.js

На этом со сжатием JS можно закончить и перейти к ещё одному техническому нюансу, который уже был неявно упомянут выше. Как вы заметили, я рекомендую собирать CSS и JavaScript в единые файлы. С точки зрения объёма данных количество файлов абсолютно не принципиально — два CSS-файла по 10 Кбайт и один файл «весом» в 20 Кбайт будут переданы с одинаковой скорость. Однако же, не всё так просто. Дело в том, что при каждом обращении за каким-либо файлом хост-сервер производит ряд операций (определяет тип, решает, необходимо ли обработать файл перед отправкой и т. п. — в рамках данной статьи это не суть важно). И вот здесь разница между 1 файлом и несколькими становится очевидной. На каждом конкретном файле экономия, опять-таки небольшая, но в сумме… К тому же не стоит забывать, что одновременно к серверу могут обращаться сотни пользователей, а значит облегчив ему жизнь по мелочам, мы, в итоге, можем существенно ускорить отдачу наших файлов и страниц.

Наконец, мы добрались до последней составляющей web-страниц — графики. Оптимизировать скорость загрузки изображений можно двумя способами — непосредственным их сжатием и уменьшением количества файлов.
В первом случае возможны два варианта: выбор более «сжатого» формата или «выжимка» уже имеющихся изображений. Разумеется, в любом случае речь должна идти ещё и сохранении исходного качества графики. Добиться уменьшение размеров файлов изображений можно несколькими методами:

  • использовать другой тип сжатия (другой формат файла или более агрессивные параметры сжатия);
  • удалить из файлов «лишнюю» информацию (к примеру, теги, оставляемые некоторыми программами-редакторами);
  • оптимизировать палитру (например, для не слишком цветастых изображений абсолютно безболезненным будет переход от PNG32 с его 4 байтами на пиксель, к формату PNG16 с 4 битами на пиксель).

Применение такого подхода, при кажущейся простоте, затруднено тем, что для оптимизации разных типов графических файлов используются разные программы, не говоря уже о необходимости конвертации между ними. Выход, впрочем, есть. К примеру, онлайн-сервис Yahoo! Smush.it. Правда, при всех своих достоинствах, сервис этот не очень удобен при работе с большим числом файлов. Альтернативой ему может стать программа PictureBeaver. Она умеет оптимизировать графику в форматах PNG, GIF и JPEG, удалять «лишние» данные, а также конвертировать GIF (без анимации) в PNG (если это позволяет уменьшить размер файла). По сути своей эта программа является оболочкой для консольных утилит OptiPNG, jpegtran и Gifsicle (о том, как использовать эти утилиты в Linux, можно почитать здесь).
Пользоваться PictureBeaver предельно просто — достаточно передать её в качестве параметра командной строки путь к папке или файлу, и через некоторое время вы получите папку Optimized с результирующими графическими файлами и отчёт в формате HTML.
Эксперимента ради я обработал с помощью этой программы основной набор графики нашего сайта. Всего было обработано 46 файлов в формате PNG общим размером 208 669 байт (203,8 Кбайт). На выходе я получил абсолютно идентичные с визуальной точки зрения изображения общим размером 201 201 байт (196,5 Кбайт). Таким образом, экономия составила 3,6%. И это при том, что все изображения уже были сохранены в «web-формате», оптимальном с точки зрения GIMP. На неоптимизированных изображениях эффект бы бы более заметным.

Пример отчёта программы PictureBeaver

Пример отчёта программы PictureBeaver

От «сжатия» изображений перейдём к уменьшению их числа. Что такой метод оптимизации даст — мы уже разобрались (я надеюсь, вы читаете статью внимательно?), но как уменьшить число графических файлов? Очень просто — можно применить CSS-фреймы. Суть проста: «парные» изображения (например, кнопки в обычном и «нажатом» состояниях) монтируются в один файл (скажем, друг под другом), а в стиле задаются координаты конкретной части изображения. Теоретически таким способом можно даже свести все картинки в один файл, но это затруднит его изменение. Поэтому, я рекомендую, как уже было сказано выше, применять фреймы для «парных» изображений (они, как правило, меняются одновременно).

На этом основная часть нашего ликбеза подошла к концу. В заключение напомню ещё об одном методе ускорения — сжатие данных на стороне сервера по алгоритму GZip. Эту возможность обеспечивает ПО большинства web-серверов, но далеко не всегда сжатие бывает включено по умолчанию. Совет здесь один: поинтересуйтесь у вашего хостера (или проверить настойки в панели управления хостом, если таковая у вас имеется). Не забывайте, что сжатие позволяет в ряде случаев уменьшить объём HTML-страниц на 80-90%.

zip

Если у вас остались какие-либо вопросы по теме данной статьи — спрашивайте, постараюсь ответить. А пока — удачи вам в оптимизации ваших сайтов!

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

  1. От Viking

    Ответить

  2. Ответить

  3. От Caustikk

    Ответить

  4. Ответить

  5. От Vlad

    Ответить

  6. Ответить

  7. От Caustikk

    Ответить

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *