Любой веб-верстальщик, веб-дизайнер, веб-разработчик или даже попросту любитель «поделать сайтики» знает, что его деятельность – постоянная нелегкая битва. Обычно изучения разметки, таблиц стилей и серверной составляющей недостаточно, чтобы создать такой сайт, который сможет реально конкурировать на рынке услуг и предложений. Но ведь для этого и создается любой сайт – для конкуренции. В то же время каждый из нас может создать красивый сайт с множеством современных технологий и невероятно функциональный в большинстве браузеров. Иии…, он может быть очень медленным. Он может очень долго загружаться в целом. Картинки прогрузятся, текст появится, а функционал (скрипты и прочие сопутствующие вещи) будет еще грузиться и грузиться. И это даже на высоких скоростях интернета. Поэтому, работая над сайтом, необходимо уделять внимание оптимизации.
Если в двух словах, то целью оптимизации является снижение времени загрузки страницы. Некоторые шаги могут уменьшить время загрузки на весьма заметные секунды, обеспечивая тем самым более удобное взаимодействие сайта и пользователя; но также и некоторые другие шаги могут только на несколько миллисекунд уменьшить скорость работы. Тем не менее, каждый шаг важен.
Резонный вопрос: «Почему я должен заботиться о миллисекундах?» Это нечто большее, чем просто время. О важности каждого шага мы расскажем ниже отдельно, но вот вам сейчас такой пример. Одной из целей оптимизации веб-страницы является уменьшение количества HTTP-запросов, которые и совершает эта самая страница. Каждый запрос занимает приблизительно 50 миллисекунд, чтобы установить соединение с сервером, за исключением времени, которое требуется для загрузки запрошенного файла. Пятьдесят миллисекунд не очень важны. Целью снижения запросов является снижение нагрузки на сервер и повышение производительности сервера.
В частности мы поговорим об уменьшении размера файлов (файла одной страницы). Это не только снижает время загрузки на стороне пользователя, но и экономит пропускную способность сервера. Это можно сделать в несколько простых шагов.
Начнем с простого и многим знакомого, но важного всегда.
Не масштабировать изображения в HTML
Не стоит менять размер изображения в браузере. Некоторые веб-программисты, желая получить маленькое изображение (миниатюру), используют атрибуты высоты и ширины изображения (через HTML или CSS) для изменения размера бОльшего изображения. Да, это экономит время и место на дисках, поскольку вам не нужно создавать или сохранять много файлов изображений (большой и маленький). Отличная идея, не так ли? Ни за что. Эта практика сопровождается двумя основными негативными факторами, которые необходимо учитывать.
Для примера возьмем сайт с обоями для рабочего стола РС, где на каждой странице размещено множество миниатюр больших изображений. Сайтов таких много (bigpicture.ru, zastavok.net), все они разные, но на них такое найти можно и часто. Или сайты любой иной тематики, где также можно обнаружить изображения, сжатые браузером.
Время загрузки
Полноразмерное изображение может не отображаться (вместо него на странице использована миниатюра), но пользователю все равно придется ждать его загрузки. Для одного изображения при мобильном интернете или скоростном могут потребоваться 10-13 секунд. А если вы масштабируете несколько полноразмерных изображений на странице, есть более заметная разница во времени загрузки. Коллекция из 10 обоев на странице с заранее созданными эскизами (отдельным файлом) займет всего 50 КБ (размер загружаемой страницы). Как результат, почти мгновенная загрузка для пользователя при средних скоростях Интернета. Но в противовес этому для обоев, масштабированных в HTML, потребуется скачать 2 МБ (если обои сами не великого размера)! Это заметная разница в загрузке страницы.
Время анализа
Время синтаксического анализа (чтение кода) также зависит от встроенного масштабирования. Снова обратимся к использованию атрибутов ширины и высоты изображения. Установив их, браузер должен вычислить и изменить размер изображения бОльшего размера, чтобы создать миниатюру. Это драгоценные миллисекунды, потраченные на каждую загрузку изображения для каждого пользователя! Что уж говорить о нагрузке на сервер и на трафик.
Но ведь хлопот... вам, как разработчику сайта, придется открывать каждый файл в любимом редакторе изображений, масштабировать его, загружать, расставлять ссылки на этот новый файл и так далее. Благодаря современным серверным языкам программирования (скрипты), этот процесс может быть автоматизирован – нет графических редакторов, нет работы с изображениями, без загрузки, без добавления ручных ссылок. В то же время имейте в виду «стоимость» масштабирования изображений для сервера и пользователей, и пусть появится привычка не делать этого.
Мини-код JavaScript
Быстрый и простой способ сэкономить пропускную способность сервера и уменьшить время загрузки – сократить длину (размер кода) файлов JavaScript и CSS. JavaScript, в частности, бывает перегружен избыточными и ненужными длинными именами переменных. Зачем ссылаться на myFavoriteVariable 500 раз, когда вы можете просто назвать его Х и сохранять 17 байт при использовании ссылки? Зачем отображать 100 отступов табуляции и переносов, когда они не будут работать? Мы не защищаем отвратительный код, и выглядеть хороший код должен всегда понятно и наглядно. Любя все хорошее, правильное и красивое, используйте yourFavoriteVariableName и отступы между блоками кода. При программировании важна читаемость. При обработке браузером читаемость бесполезна. Но как вы можете разборчиво программировать и предоставлять маленький и сжатый файл клиенту? Ответ заключается в использовании минификатора!
Подобно работе с миниатюрами изображений вы можете автоматизировать также и работу с минимизацией. Например, существует компилятор от Google – Closure Compiler. Эта служба позволяет отфильтровать ваш прокомментированный, красивый, с переносами и табуляциями код. После чего его можно скопировать в отдельный файл и использовать на веб-странице в дальнейшем. Разумеется, объем такого файлика будет гораздо меньше оригинала. При этом оптимизацию можно проводить в трех вариантах: переносы и пробелы, простая и расширенная.
Вариант с отступами понятен и прост.
Простой (Simple), скорее всего, и есть именно то, что нужно в большинстве случаев. Компилятор не переименовывает общедоступные переменные, которые могут вызываться вне сценария. Например, у вас может быть файл JavaScript, содержащий функцию expandCollapse. Этот файл предназначен для внешних ссылок, так что указанная функция может быть вызвана в другом месте вашего приложения (например, при нажатии ссылки). Простой метод не будет переименовывать функцию, поэтому он и не влияет на ссылки извне на эту функцию.
С другой стороны, метод Advanced обрабатывает скрипт так, как если бы он был полностью программой. Он сжимает и изменяет название всех переменных, поэтому внешние ссылки на скрипт, скорее всего, будут испорчены при переименовании переменных или удалении неиспользуемого кода.
Для того чтобы вы представляли возможности компилятора, приведем некоторые образцы сжатия скриптов (GitHub).
Без компрессии 301 байт
Пробелы и переносы 212 байт
Простой 186 байт
Он переименовал все закрытые переменные, но оставил имя функции без изменений, чтобы на неё могли ссылаться другие программы.
Расширенный 139 байт
Была полностью удалена функция i_heart_you и переменная my_custom_code , поскольку в них и не было по сути необходимости, так как вызваны они были один раз. Хотя странно, почему он не объединил оба document.write.
Впрочем, совершенству нет предела, а вот несовершенство последнего метода, как и любые компиляторы в целом по сжатию кода, наводят вот на такую интересную и простую мысль.
После минимизации кода убедитесь, что он все еще работает. Но и этого будет недостаточно. Не стоит слепо верить тому, что компилятор проделал хорошую работу, и техника все сделала сама за человека. Если алгоритмы сжатия Simple и Advanced разрушают функциональность вашего сложного проекта, необходимо, по крайней мере, иметь возможность доверять первому методу с удалением пробелов, чтобы сохранить целостность и работоспособность.
Минимизировать CSS
Хотя сжатие JavaScript позволяет уменьшить размеры файлов и кода в разы, не будем забывать и о CSS! До сих пор сложно найти «самую лучшую» утилиту, которая бы сжимала код CSS и удовлетворяла все запросы разработчиков, поэтому каждый выбирает то, что ему больше нравится.
Но…
Проблема со сжатием CSS заключается в том, что здесь нет лучшего метода. Приходится угадывать и проверять. Но уменьшить размер файла CSS можно при группировке по элементу:
По нескольким общим атрибутам:
Важно понимать, что невозможно заранее узнать, какой из алгоритмов минимизации наиболее эффективен в данном конкретном случае до тех пор, пока разработчик его не опробует, поскольку файл CSS будет при каждом методе сжатия иметь разный размер.
Из-за бесчисленных комбинаций настроек сжатия, возможно, придется даже попробовать разные варианты и в вашем любимом приложении по сжатию CSS, чтобы подобрать наиболее подходящий вариант. При этом в отличие от сжатия JavaScript, при сжатии CSS невозможно получить такие же выгоды и большие уменьшения в размере файлов. Да и времени вся работа займет в разы больше.
Завершение
Разумеется, существуют и иные методы ускорения загрузки станиц сайта: сжатие gzip, работа с PHP, настройка кеширования и маленьких иконок, даже методы работы с JS и CSS могут быть иными. И даже вышеописанные методы могут опровергаться или видоизменяться. Мы рассказали только об одном из вариантов.
Но даже обращение внимания на минимизацию кода JavaScript и CSS, на отказ от масштабирования изображений на уровне HTML, уже делает вас более ценным и ресурсосберегающим разработчиком. Кроме того, в век скоростного интернета кажется, что на сайте можно разместить все, что угодно и пользователи все это увидят и им понравится, и у них всё будет работать. Но вот незадача: все такие сайты – разные. Некоторые быстро грузятся, а некоторые – не очень.
Да, есть вопрос в том, нужна ли действительно оптимизация кода. Представьте, что – нет. Попробуйте разок сделать сайт без оптимизации маломальской. Здесь речь даже не о размере изображений, а о коде в целом. Не забудьте еще прописать множество разных тегов, виджетов и прочего. И кстати, вопрос о том, зачем верстальщику самому писать код, а не использовать готовую CMS, тоже отсюда, как и все вопросы о том, как оптимизировать код, созданный CMS, для ускорения работы сайта. Банальный пример под занавес: на WP можно наставить «кучу» плагинов, вроде и небольших, и не ресурсоемких, но как только запустится сайт на сервере – грузиться он будет не вообразить сколько времени. И получается, что оптимизация – необходима.