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

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

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

Официальный 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

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

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

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

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

  1. От Viking

    Ответить

  2. Ответить

  3. От Caustikk

    Ответить

  4. Ответить

  5. От Vlad

    Ответить

  6. Ответить

  7. От Caustikk

    Ответить

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

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