Что такое JavaScript и как происходит сжатие.js-файлов.

24.04.2019

Одним из пунктов оптимизации сайта является минимизация кода, который передается браузеру посетителя в момент открытия сайта. Сюда относится как содержимое CSS-файлов и JS-файлов, так и HTML-код страниц. Данные меры позволяют заметно сократить размер итогового кода и немного ускорить загрузку сайта.

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

Минимизация HTML-кода

Загляните в исходный код этого блога, чтобы посмотреть, как это будет выглядеть в результате. Как видите, почти весь код страницы не отформатирован и «собран в кучу» (о том, почему «почти», будет сказано ниже).

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

Первую часть необходимо вставить в самое начало исходного кода вашего сайта (т.е. прямо перед ):

А вторую часть, напротив, необходимо вставить в самый конец исходного кода сайта, т.е. после тега :

При этом содержимое тега pre добавлено в исключение, т.е. не минимизируется, это необходимо для правильного отображения примеров кода.

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

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

Минимизация CSS-файлов и JS-файлов

Для этого я использую замечательный бесплатный инструмент Minify . Это PHP-приложение, которое кладется в отдельную папочку на сайте и через которое пропускаются все необходимые файлы.

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

Подключается он просто:

  • Копируем папку /min/ в корень своего сайта.
  • Открываем файл /min/config.php в текстовом редакторе и в строке $min_enableBuilder = false; меняем false на true .
  • Заходим по адресу http://ваш_сайт/min/builder/ и вводим логин и пароль admin . Откроется инструмент для получения ссылок на файлы, пропущенные через минимизатор.
  • Указываем относительные пути до нужных файлов, нажимаем «Update» и получаем ссылки на минимизированные версии.
  • После того, как получили все необходимые ссылки, лучше закрыть доступ к билдеру. Для этого в config.php обратно меняем true на false в строке $min_enableBuilder = true; .
  • Если у вас несколько файлов одного типа, то рекомендую воспользоваться группировкой (для этого редактируется файл /min/groupsConfig.php). В билдере, да и в самом этом файле показаны примеры, как объединить несколько CSS- или JS-файлов.

    Кстати, даже если у вас всего один файл, и вы хотите при минимизации сократить путь до него, тогда тоже можно использовать группировку.

    К примеру, на этом блоге я сделал так:

    • Исходный файл — http://сайт/wp-content/themes/сайт/style.css
    • Группировка в groupsConfig.php:

      return array("style..css"),);

    • Результат — http://сайт/min/g=style.css

    Есть еще одна особенность Minify , которая кому-то может понадобиться. На некоторых серверах для корректной работы минимизатора необходимо в файле.htaccess (который в папке /min/) убрать знак # в строке #RewriteBase /min . Я однажды столкнулся с этим при переносе сайта на другой хостинг, и данная правка мне помогла.

    На этом все, спасибо за внимание. Надеюсь, эта информация окажется для вас полезной.

    Будем использовать тот же формат. Вызовем пакет uglify, настроим его и укажем, какие файлы задействовать и создать.

    \n*/\n" }, build: { files: { "dist/js/magic.min.js": "src/js/magic.js" } } } });

    Здесь настраивается параметр с именем banner , он добавит хороший комментарий вверху нашего минимизированного файла. Обратите внимание, что мы используем pkg.name из файла package.json. Внутри build мы определяем файл, который желаем создать (dist/js/magic.min.js) из исходного файла (src/js/magic.js). Нам нужно больше кода в файле, чем просто какие-то две строки сделанных ранее, так что поработаем с гигантским файлом для минимизации. Возьмём jQuery. Скопируйте содержимое несжатого файла jQuery и вставьте его в src/js/magic.js. Видите, какой у них классный комментарий в начале файла? Мы сделаем такой же с помощью параметра banner. Теперь пора минимизировать наш файл. Перейдите в консоль и наберите:

    $ grunt uglify

    Мы уменьшили оригинальный файл размером 360 Кб до скромных 97.1 Кб!

    Минимизация нескольких файлов в один

    Можно сделать гораздо больше, чем просто минимизировать единственный файл - взять несколько файлов и уменьшать их все в один выходной файл. Это может ускорить наши сайты, поскольку мы обрабатываем только один JS-файл для посетителей. Настройка нескольких файлов довольно проста:

    // Gruntfile.js grunt.initConfig({ // получить конфигурацию из package.json // так мы можем использовать штуки вроде name и version (pkg.name) pkg: grunt.file.readJSON("package.json"), ... // настройка uglify для минимизации JS-файлов uglify: { options: { banner: "/*\n \n*/\n" }, build: { files: { "dist/js/magic.min.js": ["src/js/magic.js", "src/js/magic2.js"] } } } });

    В данном примере мы берём два указанных файла и минимизируем их в magic.min.js. Можно также применить краткую форму, которую мы узнали ранее и просто сказать минимизировать все JS-файлы в папке src . Для этого вы должны использовать src/**/*.js.

    Предлагаем Вашему вниманию перевод статьи Стива Содерса с Yahoo по улучшению производительности сайта путем правильного проектирования HTTP/HTML/CSS/JS.

    В статье рассмотрены 14 весьма(!) полезных правил

    В 2004 году я создал группу Exceptional Performance на Yahoo!. Тогда мы были небольшой командой, целью деятельности которой было улучшение производительности продуктов Yahoo!. Проработав бОльшую часть своей карьеры как инженер внутреннего интерфейса, я подошёл к этому, как к проекту по оптимизации кода: я очертил весь процесс работы сети, чтобы выявить те места, где можно достугнуть максимальных возможностей для повышения производительности. С тех пор наша цель --- обогащение опыта конечного пользователя; я измерил времена отклика в браузере при разных скоростях передачи данных. Данные этих исследований представлены на следующей диаграмме, отображающей HTTP-траффик сайта http://www.yahoo.com .

    На представленной схеме первая строка ("html") --- представляет исходный запрос для документа HTML. Как видно, только 5% времени отклика конечного пользователя тратится на считывание документа: такой результат справедлив практически для всех сайтов. Из первой десятки сайтов Соединённых штатов все, кроме одного, использовали менее 20% общего времени отклика при загрузке HTML-документа. Остальные 80% уходили на загрузку содержания страницы. Этот факт предоставляет возможности для ускорения работы сайтов за счёт улучшения пользовательского интерфейса.

    Есть три основные причины, почему стоит начинать именно с пользовательского интерфейса.

  • Существует много возможностей улучшения пользовательского интерфейса. Если уменьшить его наполовину, количество откликов уменьшится на 40% и более, в то время как сокращение серверной части даст выигрыш менее, чем в 10%.
  • Улучшения клиентской части обычно требуют меньше времени и ресурсов, чем серверной (переработка архитектуры и кода приложения, поиск и оптимизация критических участков, добавление и настройка аппаратного обеспечения, распределение баз данных и т.п.).
  • Настройка производительности клиента доказала свою работоспособность. Более 50 команд на Yahoo! уменьшили время отклика клиентской части за счёт наших методов зачастую на 25% и более.
  • Наше золотое правило производительности звучит следующим образом: оптимизируйте сначала производительность клиента, где тратится более 80% времени отклика конечного пользователя .

    Уменьшайте число HTTP-запросов

    80% времени отклика конечного пользователя тратится на отображение интерфейса. БОльшая часть времени связана с загрузкой всех компонентов страницы: рисунков, таблиц стилей, скриптов и т.д. Уменьшение числа компонентов, в свою очередь, ведёт к уменьшению числа HTTP-запросов, необходимых для отображения страницы. В этом и заключается ускорение.

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

    Есть известные проблемы с браузерами и прокси-серверами, которые могут вызвать несоответствие между тем, что браузер ожидает и что получает, при сжатии содержимого. К счастью, число таких крайних случаев сокращается из-за уменьшения количества старых браузеров. Модули Apache помогают тем, что добавляют соответствующие заголовки автоматически.

    Серверы выбирают, какие данные будут сжимать, на основании типов файлов, но обычно они слишком ограниченны в выборе объектов для сжатия. Большинство веб-сайтов сжимают HTML-документы. Кроме того, стоит также сжимать скрипты и таблицы стилей, но многие сайты упускают эту возможность. Фактически, нужно сжимать любую текстовую информацию, включая XML и JSON. Не нужно архивировать PDF-документы и изображения, потому что они уже сжаты: вы не только впустую потратите время процессора, но и можете увеличить размер по сравнению в первоначальным.

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

    Помещайте таблицы стилей вверху страницы

    Исследуя производительность Yahoo!, мы обнаружили, что перемещение таблиц стилей в заголовок (HEAD) приводит к ускорению загрузки страниц. Дело в том, что в этом случае страница формируется последовательно.

    Инженеры интерфейса, заботящиеся о производительности, желают именно этого; то есть хочется, чтобы браузер мог отобразить всё содержимое как можно быстрее. Это особенно важно для больших страниц, которые просматривают пользователи с медленным соединением. Важность предоставления пользователям визуальной обратной связи, например, индикатора загрузки, хорошо изучена и документирована . В нашем случае страница и является этим индикатором! Когда браузер загружает страницу последовательно: заголовок, панель навигации, логотип и т.п. --- все компоненты служат индикаторами для ожидающего посетителя.

    При расположении таблиц стилей внизу документа становится невозможной последовательная формирование во многих браузерах, включая Internet Explorer. Они откладывают формирование, чтобы избежать переотображение элементов страницы, если их стиль изменится. Пользователю приходится ждать и смотреть на пустой белый экран. Firefox не блокирует визуализацию, таком образом, когда стили загружены, некоторые элементы будут изменены, что приведёт к появлению моментов, когда страница будет не стилизована .

    Есть и другой способ оптимизации кода JavaScript. Как и прошлый, он также предполагает удаление комментариев и лишних пробельных символов, но ещё и модифицирует сам код. В частности, это проявляется в изменении имён переменных и функций так, чтобы они содержали минимальное число символов, т.е. код становится более компактным, но читать его гораздо сложнее. Здесь вопрос выбора подходящего средства остаётся открытым, но наиболее часто (насколько мне известно) используется Dojo Compressor (ShrinkSafe).

    Минимизация --- это безопасный и довольно простой процесс. Оптимизация кода, с другой стороны, является более сложной вещью и, следовательно, приводящей к большему числу ошибок; она также зависит от выявления имён API-функций, имена которых трогать не следует. Вдобавок становится затруднительной отладка оптимизированного кода. Я не видел проблем, связанных с минимизацией, но при применении оптимизации они встречались. В ходе исследования первой десятки американских веб-сайтов выяснилось, что минимизацию используют 21%, а оптимизацию --- 25%. Несмотря на преимущества второго способа, я всё-таки советую остановиться на минимизации, что уменьшит риски и сложность поддержки скриптов.

    В дополнение к минимизации внешних скриптов, ту же технику можно и нужно применять к встроенным. Даже если вы сжимаете их gzip-ом, как описано в , минимизация уменьшит размер на 5% и более. Это особенно актуально в условиях роста использования и размеров скриптов JavaScript.

    Избегайте переадресаций

    Переадресация выполняется с использованием кодов статуса 301 и 302. Вот пример HTTP-заголовков в отклике с кодом 301:

    HTTP/1.1 301 Moved Permanently Location: http://example.com/newuri Content-Type: text/html

    Браузер автоматически переходит по ссылке, указанной в поле Location . Вся необходимая для перенаправления информация содержится в заголовках. Тело ответа обычно пусто. Несмотря на названия, ни 301-й ни 302-й ответы не кэшируются на практике, если только это явно не указывается в дополнительных заголовках, например Expires или Cache-Control . Тэг meta refresh и JavaScript являются альтернативными способами перенаправить пользователя на другой URL, но если вы должны сделать переадресацию, то предпочтительнее будет использовать стандартные коды статуса 3xx HTTP, в первую очередь, для обеспечения корректной работы кнопки «Назад».

    Главное помнить, что переадресация замедляет работу пользователя. Вставляя перенаправление между пользователем и HTML-документом, вы замедляете всё на странице, так как ничто на ней не будет формироваться и никакие компоненты не станут загружаться, пока не поступит HTML-документ.

    Одна из наиболее бесполезных переадресаций часто возникает и веб-разработчики обычно о ней не беспокоятся. Так происходит, когда забывают вставить завершающий слэш (/) в URL, когда тот необходим. Например, если зайти на http://astrology.yahoo.com/astrology , результатом будет ответ с кодом 301 301, перенаправляющий на http://astrology.yahoo.com/astrology/ (заметьте добавленный слэш). Эта ошибка исправляется сервером Apache с помощью Alias или mod_rewrite или директивы DirectorySlash , если вы используете обработчики Apache.

    Еще одно традиционное использование перенаправления --- соединение старой и новой версий сайта. Некоторые используют соединения с различными частями сайта в зависимости от некоторых условий (типа браузера, типа аккаунта и т.п.). Объединение двух веб-сайтов в один с помощью перенаправлений достаточно просто и почти не требует написания дополнительного кода. Несмотря на то что разработчики таким образом упрощают себе задачу, подобный подход отрицательно влияет на продуктивность работы сайта и, соответственно, конечного пользователя. Среди альтернатив можно выделить использование Alias и mod_rewrite , если оба проекта находятся на одном сервере. Если изменится имя домена, то можно использовать CNAME (DNS-запись, создающая alias, указывая с одного домена на другой) вместе с Alias или mod_rewrite .

    Удаляйте дубликаты скриптов

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

    Ненужные HTTP-запросы встречаются в Internet Explorer, но не в Firefox. В Internet Explorer, если внешний скрипт включён дважды и не кэшируется, создаются два HTTP-запроса во время загрузки страницы. Даже если скрипт закэширован, всё равно возникают дополнительные HTTP-запросы, когда пользователь обновляет страницу.

    Помимо генерации лишних запросов время тратится на многократное выполнение скрипта. Это излишнее выполнение скриптов характерно и для Firefox, и для Internet Explorer, причём независимо от того, кэшируется ли он или нет.

    Один из способов избежать случайного включения одного скрипта дважды --- реализовать модуль управления скриптами в вашей системе шаблонов. Традиционный способ подключения скрипта --- использовать тэг SCRIPT в вашей станице:

    Script type="text/javascript" src="menu_1.0.17.js">

    Альтернативой в PHP будет создание функции insertScript:

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

    Настраивайте тэги содержимого

    Тэги содержимого (Entity tags, ETags) --- это механизм, который используют серверы и браузеры для определения, совпадает ли компонент в кэше браузера с тем, что находится на сервере. (Под содержимом имеются в виду изображения, скрипты, таблицы стилей и т.п.) Эти тэги используются для обеспечения механизма проверки содержимого, что более гибко по сравнению с датой последней модификации. Они представляют собой строку, которая однозначно определяет версию компонента. Единственное ограничение на формат --- заключённая в кавычки строка. Сервер определяет тэг компонента, используя заголовок ETag:

    HTTP/1.1 200 OK Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT ETag: "10c24bc-4ab-457e1c1f" Content-Length: 12195

    Далее, если браузеру требуется провериться компонент, он использует заголовок If-None-Match , чтобы отправить ETag обратно серверу. В случае совпадения тэга возвращается код 304, уменьшая ответ на 12195 байт для этого примера:

    GET /i/yahoo.gif HTTP/1.1 Host: us.yimg.com If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT If-None-Match: "10c24bc-4ab-457e1c1f" HTTP/1.1 304 Not Modified

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

    Формат ETag для Apache 1.3 и 2.x --- inode-size-timestamp . Хотя один и тот же файл может находиться в одном каталоге на нескольких серверах и иметь одини и те же размер, права, время создания, модификации и т.п., его inode могут различаться.

    У IIS 5.0 и 6.0 дела с ETags обстоят так же. Фотрматом для ETags в IIS служит Filetimestamp:ChangeNumber . ChangeNumber --- это счётчик, используемый для отслеживания изменений конфигурации IIS. Маловероятно, что ChangeNumber один и тот же на всех IIS-серверах, поддерживающих веб-сайт.

    В итоге, ETags, сгенерированные Apache и IIS для одного компонента, не будут совпадать на разных серверах. В таком случае пользователь не получит быстрый ответ с кодом 304, для чего и были созданы эти тэги; вместо него сервер вернёт обычный ответ с кодом 200 со всеми данными компонента. Если ваш сайт располагается на одном сервере, то такой проблемы не возникнет; в противном случае, при использовании Apache или IIS с конфигурацией тэгов содержимого ETags по умолчанию, пользователи получат медленные страницы, серверы будут больше загружены, трафик увеличен и прокси не будут кэшировать содержимое должным образом. Даже если заголовок Expires компонентов содержит значение далеко в будущем, условный запрос GET будет генериться как только пользователь нажмёт кнопку обновления страницы.

    Если вы не используете преимуществ гибкой модели валидации, которую обеспечивают тэги содержимого, лучше вообще их удалить. Заголовок Last-Modified осуществляет проверку на основании временнЫх отметок компонента. Удалив ETags, вы уменьшите размер заголовка ответа и последующих запросов. Статья Microsoft Support article описывает, как их удалить. В Apache это делается просто добавлением следующей строки к файлу конфигурации:

    FileETag none

    Делайте Ajax-элементы кэшируемыми

    Люди спрашивают, применимы ли эти правила улучшения эффективности к приложениям Web 2.0. Конечно! Это правило было первым, которое принесло плоды после начала работы приложений Web 2.0 на Yahoo!.

    Одним их основных преимуществ Ajax является обеспечение мгновенной обратной связи с пользователем, потому что он запрашивает информацию асинхронно у конечного веб-сервера. Однако, использование Ajax не гарантирует, что пользователю не придётся бить баклуши, ожидая этих асинхронных JavaScript и XML ответов. Во многих приложениях то, будет ли пользователь ждать или нет, зависит от того, как используется Ajax. Например, в email-клиенте с веб-интерфейсом пользователь ждёт результатов ответа Ajax, чтобы найти все сообщения, удовлетворяющие критериям поиска. Важно помнить, что «асинхронный» не значит «мгновенный».

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

    Однако, правило 3 является основным для разгона приложения. Посмотрим пример. Почтовый клиент на технологии Web 2.0 может использовать Ajax, чтобы загрузить адресную книгу пользователя для автопродолжения. Если пользователь не изменял её с прошлой загрузки, то адресную книгу можно взять из кэша, если прошлый ответ Ajax был кэшируемым с использованием заголовка Expires. Браузер должен знать, когда использовать ранее кэшированную адресную книгу, а когда загрузить с сервера новую. Это можно сделать, добавив временнУю отметку к URL книги, например, &t=1190241612 . Если она не изменялась с момента последней загрузки, то отметка будет той же самой и адресная книга будет взята из кэша браузера. Если же пользователь изменил адресную книгу, то отметка времени модификации не совпадёт с той, что соответствует кэшу и браузер запросит обновлённые данные.

    Даже если ответы Ajax создаются динамически и применяются только к одному пользователю, они всё ещё могут кэшироваться. Подобная техника делает приложения Web 2.0 быстрее.


    Скорость загрузки сайта является важным показателем как для поисковой системы, так и для пользователя. Доля мобильного интернета растет вместе с количеством мобильных устройств, и люди предъявляют к сайтам все больше требований – в том числе касающихся быстрой загрузки контента. А запуск нового алгоритма ранжирования Google для мобильного поиска – Speed Update – обязует уделять больше внимания скорости загрузки мобильных сайтов.

    Рассмотрим два способа ускорить сайт – ручной и с помощью программ-минимизаторов.

    Что такое минимизация кода

    В инструменте Google для проверки скорости загрузки PageSpeed в результате проверки страницы сайта можно встретить следующие рекомендации:

    «minify HTML» - сократить код HTML;
    «minify CSS» - сократить код CSS;
    «minify JavaScript» - сократить код JavaScript.

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

    Ручная минимизация кода

    Рассмотрим для примера простую HTML-страницу:

    /* container for main page */

    Container { font-size: 100% }

    Container { width: 70% }

    Metrics(); // use metrics


    1. Комментарии в коде пишутся для программистов, чтобы им было проще ориентироваться в проекте при разработке.

    – для HTML
    // use metrics – для JavaScript
    /* container for main page */ – для CSS.

    При просмотре кода страницы в браузере комментарии чаще всего выделены зеленым цветом:

    Они не влияют на отображение страницы в браузере, и для уменьшения количества символов и веса страницы их можно удалить.

    2. CSS-стили содержат два объявления для класса container, которые можно объединить в одно. При этом другие стили затронуты не будут, и тем самым мы сократим размер страницы:

    .container { font-size: 100% } .container { width: 70% } для браузера означает то же, что и .container { font-size: 100; width: 70%} . Такие конструкции можно часто встретить в больших CSS-файлах, если у программиста не было времени искать уже существующее CSS-правило для элемента, и он решил прописать новое внизу документа.

    3. Пробелы и табуляция нужны для удобства чтения документа разработчиком, их тоже можно удалить.

    В итоге минимизированный код этой страницы будет выглядеть так:

    .container{font-size:100%;width:70%}…Metrics();

    Код уменьшился с 335 символов до 131, но сохранил свою полную работоспособность. Вес страницы при этом уменьшился на 40%, что увеличило скорость ее загрузки в 3 раза.

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

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

    Сервисы для минимизации кода

    Существует множество сервисов и программ для минимизации кода. От использования online-сервисов советуем отказаться – ради безопасности и предотвращения утечки исходного кода вашего сайта третьим лицам. Сторонний сайт может без вашего ведома сохранить код в базе данных и использовать его в дальнейшем по своему усмотрению.

    Если все же намерены использовать онлайн-сервис, следует удостовериться, что он работает на JavaScript и выполняется только со стороны клиента. Для этого нужно отключить в браузере JavaScript и попробовать выполнить минимизацию.

    Например, в Google Chrome это делается в меню Настройки > Настройки контента > JavaScript:

    О том, как выключить JavaScript в других браузерах, легко найти информацию в сети.

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

    Поскольку 100% гарантий в вопросе безопасности не существует, мы советуем пользоваться надежными сервисами, требующими локальной установки. Например, проверенными программами для сокращения кода, которые советует Google:

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

    Как альтернативу можно использовать хорошо зарекомендовавший себя компрессор от Yahoo YUI Compressor . Также существует официальный аддон от Google для автоматизации минимизации кода – PageSpeed Module , который можно установить на сервера Apache и Nginx.

    Удаляя комментарии, особенно при использовании сторонних инструментов, стоит проследить, чтобы случайно не удалить код вида

    .

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

    Выводы

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

    Зачем нужна минимизация js и css файлов?

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

    Что же из себя представляет минимизация?

    Из кода удаляются комментарии, код пишется в одну строку (удаляются переносы строк и лишние пробелы).

    Существует множество онлайн и офлайн сервисов которые могут из Вашего js или css файла сделать минимизированный файл. Однако в данной статье рассмотрим расширение для Yii, которое будет минимизировать и соединять в один файл js скрипты (только JavaScript) и css в другой (только CSS). Это расширение создаст минимизированный файл для js и css (один файл для js, один файл для css) при первой загрузке страницы и разместит его в папке assets . После чего будет использовать эти файлы до тех пор пока Вы не внесете изменение в любой из подключаемых js или css (или не очистите папку assets). После внесения изменений процедура повторяется (проверка изменений осуществляется по времени модификации файла). Таким образом Вам не нужно после каждого изменения в исходниках делать минимизацию вручную, js и css остаются в читабельном виде, а на сайте уже работают их минимизированные копии.

    Внимание! Хочу заметить что это не единственное расширение для минимизации css и js. Все расширения Вы можете посмотреть на официальном сайте Yii, в разделе расширения.


    И так приступим к внедрению расширения минимизации наших js и css файлов.

    Расширение Вы можете скачать официального сайта Yii, раздел расширения:

    С GitHub репозитория разработчика:


    Распаковываем архив и копируем папку yii-EClientScript в папку /protected/vendors

    Теперь нам необходимо подключить расширение к проекту, открываем файл конфигураций /protected/config/main.php и в components добавляем подключение и настройку расширения:

    Похожие статьи