Сжатие css js. Список онлайн сервисов для сжатия и кодирования JS. Drupal модуль минификации
Всем-всем привет!
Продолжаем оптимизировать и сегодня на очереди у нас оптимизация JS (JavaScript) и CSS кода. Напомню, вчера мы работали с изображениями, если Вы все еще не оптимизировали их, то как раз для Вас (обязательно примените то, что написано там).
Урок получится коротким, поэтому скорее начнем. Погнали!
Что такое JS и CSS код?В настоящее время сайт, созданный исключительно на HTML и CSS, уже является отстающим, ведь на этих языках нельзя написать какие-то удобные, полезные штуки, которые облегчили бы взаимодействие с ним. Пользователям, в свою очередь, необходимо преподнести максимально удобный продукт (веб-ресурс). Осуществить данное требование помогут различные языки программирования, к которым относится и JavaScript.
JavaScript — язык программирования, позволяющий создавать различные скрипты (приложения), которые встраиваются в HTML-страницы. Скрипты выполняются в браузере пользователя.
Чтобы вывести даже тот самый пресловутый счетчик времени потребуется JS. Так что, думаю, и на Вашем сайте присутствует данный язык программирования.
CSS — язык описания внешнего вида любого элемента сайта. То есть то, как выглядит Ваш сайт, мой сайт, да любой другой, написано на этом языке.
Для чего нужно оптимизировать JS и CSS код?Задача данного мероприятия одна — снизить время загрузки страниц сайта. К сожалению, JS-скрипты и CSS код зачастую несут в себе очень много символов, пробелов, чем и замедляют загрузку веб-ресурса. Оптимизация подобных файлов направлена на то, чтобы отсечь лишние символы, лишние пробелы, тем самым снижая их размер и, как следствие, облегчая загрузку веб-страниц. По сути происходит обычное сжатие файла. Можно сделать и более глубокую оптимизацию, если, конечно, Вы разбираетесь в программировании и сайтостроении.
Оптимизация JS и CSS кодаВ Интернете, как и в случае с оптимизацией изображений, существует несколько онлайн-сервисов, которые выполняют то, что написано выше:
Ваша задача: скопировать код файла, вставить его в один из перечисленных сервисов, получить оптимизированный код и вставить его в исходный файл. Вот и все.
Предупреждаю: после оптимизации код станет не читабельным, поэтому дальнейшая работа с ним будет немного затруднена.
Оптимизируя свой , я попробовал оба сервиса: в первый залил проблемный файл JS, а во второй CSS () и буквально через 5 секунд код оптимизировался и уже можно было заливать, что я и сделал.
Сокращение или сжатие.js -файлов - один из процессов оптимизации сайта. Сжатие файлов JavaScript, которые используются на Вашем сайте, достаточно весомо может отразиться на скорости загрузки страницы. Естественно, только в лучшую сторону. Сокращение JavaScript не только ускорит скорость загрузки страницы, но так же ускорит синтаксический анализ и отображение страницы.
Что такое JavaScript и как происходит сжатие.js-файловJavaScript - это один из наиболее известных объектно-ориентированных языков программирования. А это значит, что .js -файл в первую очередь представляет из себя продукт программирования. Это важно знать, чтобы понимать суть сжатия кода JavaScript. Допустим, что перед нами некий код, который написан на JavaScript и выполняет определенные действия. Для примера приведем банальную программу вывода слов «Hello World» в браузере:
document.write(«Hello World»);
Какими способами можно сократить.js-файл?
Javascriptcompressor.com
можно произвести три из четырех приведенных способов для сжатия кода JavaScript. Данный онлайн инструмент не позволяет выполнить первый пункт - он не может проанализировать Ваш алгоритм и заменить его на аналогичный. С остальными же тремя он справляется на ура.
Интерфейс сайта весьма прост. В первое окно Вы должны ввести JavaScript код, а во втором окне Вы получите его сжатую версию. Так же, на странице имеются два checkbox`а:
Если Вы отметите первый из них, то сжатие Вашего кода будет происходить с использованием технологии Base62 . Ну, а второй checkbox будет по-возможности заменять длинные переменные на более короткие. В любом случае - отметите Вы хотя бы один checkbox, оба или вообще не отметите - произойдет сжатие кода JavaScript путем удаления комментариев, пропусков и пробелов. В дополнение к этому, Вы можете увидеть размер кода до сжатия и после сжатия.
Что еще нужно знать про сжатие JavaScriptРесурсов, которые предлагают те же услуги, предостаточно. Я остановился на данном инструменте потому, что другие ресурсы производили сжатие с ошибками. Не следует отрицать возможность наличия ошибок в сжатом js-коде. Поэтому, перед сжатием javascipt кода, создайте резервную копию .js -файла. Сразу после сжатия кода, лучше протестировать работоспособность сайта. Ещё лучше будет, если Вы проведете испытания на тестовом сайте.
Так же хочу сказать, что кодирование маленьких по объему .js -файлов почти что бессмысленно. Очень часто после кодирования таких файлов, их объем только увеличивается. Удачи Вам в ваших попытках сократить и сжать JavaScript.
Здравствуйте, уважаемые коллеги веб-мастера, читатели сайт.
Продолжая цикл обучающего материала по ускорению загрузки страниц сайта по рекомендациям сервиса PageSpeed Insights от Google, затронем животрепещущую тему о сокращении JavaScript.
"Сжатие кода JavaScript (сокращенно JS) позволяет сократить объем данных, чтобы ускорить загрузку, обработку и выполнение " – так говорит нам сам сервис. Ваш сайт тоже нуждается в таком улучшении? Если ответ утвердительный, тогда читайте дальше. Инструкция будет короткой и очень простой.
Ну что же, надо так надо. Выигрыш в скорости конечно небольшой, зато мы увеличим свой рейтинг в PageSpeed Insights (сокращенно PSI) и, как следствие - слегка улучшим свои позиции в ТОПе. Как говорится: "Маленькая бородавка – все сайту прибавка".
В прошлый раз в статье " " мы оптимизировали внутренние JavaScript, принадлежащие шаблону проекта или его плагинам. Рекомендация по сокращению теперь может возникнуть в основном для внешних системных скриптов, которые подгружаются со стороны чужого сервера.
Кликните по ссылке "Как исправить? " под рекомендацией PSI и чуть ниже всплывут URL всех JS, нуждающихся в сжатии. Внутренние несжатые JS будут иметь URL адрес вашего ресурса а внешние (как на первом скриншоте), соответственно, не вашего:-). Начнем с последних.
Сокращение внешних JavaScriptПо адресу JS вы уже сможете его идентифицировать, останется только вспомнить где он сидит. К примеру, наш объект для оптимизации - JS форма подписки почтового сервиса в боковой колонке сайта. Присмотритесь к коду формы и обязательно найдете там путь к исполняемому скрипту.
Не забудьте добавить директиву "Disallow: /js/
" в robots.txt.
Тут все гораздо проще. Скачанные в первом пункте предыдущей инструкции сжатые JS закачайте с заменой туда, где находятся их неоптимизированные близнецы. И забудьте про них до следующего обновления шаблона или наших подопытных плагинов.
Проверьте результат, наслаждайтесь выполненной работой.
P.S. Возможно, из-за врожденного косноязычия или лени я не все доступно объяснил. Поэтому, если у кого останутся вопросы, спрашивайте в комментариях.
Стоит все же осветить наиболее характерные проблемы этого самого сжатия и объединения.
Начнем с простого: как JS-сжатие способно испортить нам настроение. И как его поднять обратно:)
UPD стартовал конкурс ускорения сайтов . В призах: монитор, веб-камера, мышь. Все гипер-быстрое.
JavaScript-сжатие Вообще стоит сразу упомянуть, что сжатие JavaScript-файлов даст нам всего лишь 5-7% уменьшение размера относительно обычного gzip, который можно использовать везде (нет, реально, везде - начиная от конфигурации Apache через.htaccess и заканчивая статическим сжатием через mod_rewrite + mod_mime и конфигурацией nginx (или LightSpeed). Но вернемся к теме топика: мы хотим минимизировать JavaScript-файлы, как это лучше всего сделать?Два года назад был произведен обзор текущих инструментов , за это время ситуация не сильно изменилась (разве что появился Google Compiler). Но все по порядку.
- Начнем с простого. JSMin (или его клон, JSMin+). Работает очень универсально (по принципу конечных автоматов). Почти всегда минимизируемый файл даже исполняется. Дополнительный выигрыш (здесь и далее относительно простого gzip) - до 7% в случае продвинутой версии, т.е. совсем мало. Процессор кушает умеренно (продвинутая версия, JSMin+ сильнее, и память значительно), но не анализирует область видимости переменных, в связи с чем не умеет сокращать их длину. В принципе, может применяться почти для всех скриптов, но иногда возможны нюансы. Например, удаляются условные комментарии (это лечится) или неверно распознаются различные конструкции (например, + + преобразуется в ++ , это ломает логику), это тоже лечится, но сложнее.
- YUI Compressor . Наиболее известный (до недавнего времени еще и наиболее мощный) инструмент для сжатия скриптов. Базируется на движке Rhino (насколько известно, корни движка где-то рядом с фреймворком Dojo, т.е. очень-очень давно). Сжимает скрипты отлично, работает над областью видимости (может уменьшать длину переменных). Степень сжатия - до 8% сверх gzip, однако, процессор кушает будь здоров (в связи с использованием виртуальной машины Java), так что с использованием в режиме онлайн стоит быть осторожным. Также в связи с уменьшением длин переменных возможны различные проблемы (и их даже потенциально больше, чем для JSMin).
- Google Closure Compiler появился недавно, но уже завоевал доверие общественности. Базируется на том же движке Rhino (ага, нет ничего нового под луной), но использует более продвинутые алгоритмы уменьшения размера исходного кода (отличный обзор во всех деталях), до 12% относительно gzip. Но тут стоит быть втройне острожным: может быть вырезана весьма существенная часть логики, особенно при агрессивных преобразованиях. Однако для jQuery уже используется этот инструмент . По процессорным издержкам он, видимо, еще тяжелее YUI (данный факт не проверялся).
- и Packer . Данный инструмент уже уходит в прошлое в связи с развитием каналов связи и отставанием процессорных мощностей: ибо сжатие в нем (алгоритм, аналогичный gzip) производится за счет JavaScript-движка. Это обеспечивает очень значительное (до 55% без gzip) уменьшение размера кода, но дополнительные издержки вплоть до 500-1000 мс на распаковку архива. Естественно, это становится не актуальным, если процессорные мощности ограничены (привет, IE), а скорость соединения весьма высока (+ gzip уже почти везде применяется и поддерживается). Дополнительно, данный метод оптимизации наиболее склонен к различным багам после минимизации.
Но вернемся к баранам. Сейчас мы будем разговаривать про некоторую автоматизацию объединения «сторонних» скриптов. Если вы имеете к ним полный доступ (и разбираетесь в веб-разработке), то не составляет большого руда пофиксить проблемы (или исключить ряд проблемных скриптов из объединения). В противном случае (когда набор скриптов никак не хочет объединяться без ошибок) нижеследующий подход как раз для вас.
Итак, у нас есть 10-15 кусков кода (часть из них в виде встроенного кода, часть - в виде внешних библиотек, которые мы можем так же «слить» вместе). Нам нужно гарантировать их независимую работоспособность. В чем она заключается?
Если у нас есть JavaScript-ошибка в файле, то браузер прекращает выполнение этого файла на ошибке (некоторые наиболее древние еще и прекращают выполнение всех JavaScript-файлов на странице в этом случае, но мы не совсем про это разговариваем). Соответственно, если первая же библиотека, которую мы хотим объединить в общий файл, выдает ошибку, то во всех браузерах у нас клиентская логика после объединения развалится. Грустно.
Дополнительно стоит отметить, что встроенный (inline) код достаточно тяжело отлаживать. Его можно либо исключить из объединения (например, расположив вызов объединенного файла до или после кода), или же при его использовании вообще отменить объединение файлов.
Обратная совместимость Что мы можем с этим поделать? Наиболее простой путь: исключать проблемные файлы (при этом ошибки могут проявляться только на этапе объединения, отдельные же файлы могут отрабатывать на ура) из логики объединения. Для этого нужно будет отслеживать, в каком месте происходить ошибка, и собрать конфигурацию для объединения для каждого такого случая.Но можно поступить несколько проще. Для JavaScript мы можем воспользоваться конструкцией try-catch . Ага, мысль уловили? Еще нет? Мы можем все содержимое файлов, которые объединяем, заключать в try {} , а в catch(e) {} вызывать подключение внешнего файла примерно следующим образом:
При этом у нас у пользователя загрузится один-единственный файл, если никаких проблем не возникло. Если же ошибки были, то подключатся все внешние проблемные файлы в прежнем порядке. Это и обеспечит обратную совместимость.Проблемы производительности Очевидно, что данный подход не является «самым правильным». Наиболее логичным было бы определить JavaScript-ошибки, их устранить, и загружать для всех пользователей один файл. Но не всегда это возможно. Также стоит учесть, что try-catch конструкция тяжеловата для исполнения в браузерах (добавляет 10-25% ко времени инициализации), стоит быть с ней осторожным.
Но описанный подход может замечательно применяться для отладки конкретно объединения JavaScript-файлов: ведь он позволяет точно определять, какие файлы «сыпятся» (если файлов несколько десятков, это очень и очень полезно).
Небольшое резюме После дополнительной минимизации JavaScript-файлов обязательно проверяйте их функциональность. А отладку корректности объединения JavaScript-файлов можно легко автоматизировать, или даже настроить обратную совместимость в случае невозможности отладки конкретных скриптов.Современная вёрстка без таблиц, отказ от использования инлайновых стилей и сжатие html-страниц позволяют достаточно серьёзно уменьшить трафик сервера и повысить скорость загрузки сайта для пользователей, работающих на «узких» каналах. Выигрыш в трафике может составлять 60-80% (для HTML)!
Несмотря на это, всё равно остаётся ряд достаточно больших файлов, которые браузер посетителя должен будет загрузить: основной css с вёрсткой (от 10 до 30КБ), javascript-фреймворк (mootools - 70-80КБ, prototype.js - 120КБ и т.д.) Конечно, эти файлы кешируются браузером и грузятся только при первом посещении, но не мне вам объяснять, насколько важно, чтобы после перехода из выдачи поисковика пользователь увидел загруженный сайт как можно быстрее…
Сжимать эти файлы можно при каждом обращении, прогоняя через mod_gzip (mod_deflate). Но это неизбежно приведёт к дополнительной нагрузке на сервер, которая может оказаться критической для посещаемого сайта на недорогом виртуальном хостинге.
Другой способ, который и будет рассмотрен в данной статье, — хранить сжатые (.gz) файлы на сервере наряду с исходными и с помощью директив mod_rewrite выдавать.js.gz и.css.gz вместо.js и.css соответственно. Итак, приступим.
Сначала нужно определиться, какие файлы требуют сжатия. Для типичного шаблона Joomla!, например, это будут, как правило, /media/system/js/mootools.js и template_css.css активного шаблона.
Теперь нужно подготовить сжатые версии файлов. Это можно сделать в Windows с помощью бесплатного архиватора 7-ZIP , выбрав GZip в качестве формата при создании архива. Обратите внимание: каждый файл в отдельном архиве. В консоли UNIX-сервера это можно сделать с помощью команды gzip:
gzip mootools.js -c > mootools.js.gzПосле этого требуется разместить.js.gz и.css.gz в тех же директориях на сервере, где расположены их несжатые версии (если сжатие делалось в Windows с помощью 7-Zip).
Если.htaccess в корне сайта не существует, создаём его и добавляем следующие строки:
Вариант 1 ### Ассоциируем расширение.gz с gzip AddEncoding gzip .gz ### Задействуем mod_rewrite RewriteEngine On ### Отдаём foo.bar.gz вместо файла foo.bar, если foo.bar.gz присутствует в той же директории, ### что и foo.bar. Если браузер - Safari, отдаём foo.bar RewriteCond %{ HTTP:Accept-encoding} gzip RewriteCond %{ HTTP_USER_AGENT} !Safari RewriteCond %{ REQUEST_FILENAME} .gz -f RewriteRule ^(.*) $ $1 .gz [ QSA,L] Вариант 2Однако это способ иногда не работает. Сервер устанавливает HTTP-заголовок Content-Type в application/x-gzip и браузеры, определяющие тип данных по нему (например, Firefox), а не по содержимому (IE) «не видят» скрипты и css. Чтобы решить эту проблему, нужно принудительно устанавливать Content-Type в text/javascript или text/css. В этом случае надо добавить в.htaccess такой код («вариант 1» надо убрать или закомментировать!):
AddEncoding gzip .gz ### 1. Обработка js-файлов ForceType text/javascript Header set Content-Encoding: gzip RewriteEngine On RewriteCond %{ HTTP_USER_AGENT} !".*Safari.*" RewriteCond %{ HTTP:Accept-Encoding} gzip RewriteCond %{ REQUEST_FILENAME} .gz -f RewriteRule (.*) \.js$ $1 \.js.gz [ L] ForceType text/javascript ### 2. Обработка css-файлов ForceType text/css Header set Content-Encoding: gzip RewriteEngine On RewriteCond %{ HTTP_USER_AGENT} !".*Safari.*" RewriteCond %{ HTTP:Accept-Encoding} gzip RewriteCond %{ REQUEST_FILENAME} .gz -f RewriteRule (.*) \.css$ $1 \.css.gz [ L] ForceType text/cssВсё, никаких изменений больше не нужно !
Проверить корректность работы метода можно в Firefox с установленным плагином Live HTTP Headers :
История изменений:
- 19.04.2008 — первичная публикация;
- 14.11.2008 — добавление альтернативного варианта (FilesMatch);
- 21.03.2009 — исправлена опечатка в примере альтернативного варианта (FilesMatch).
