Скорость загрузки сайта является важным показателем как для поисковой системы, так и для пользователя. Доля мобильного интернета растет вместе с количеством мобильных устройств, и люди предъявляют к сайтам все больше требований – в том числе касающихся быстрой загрузки контента. А запуск нового алгоритма ранжирования 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 не является приоритетной рекомендацией по ускорению загрузки вашего сайта и по значимости стоит ниже настроек сжатия, уменьшения веса изображений и т.д. Но использование техник, описанных в этой статье, поможет существенно сократить время загрузки сайта, повысить удобство пользования вашим ресурсом и улучшить его показатели в поисковой выдаче.

Будем использовать тот же формат. Вызовем пакет 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.

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

Решение

Минимизация скрипта - это удаление из кода всех несущественных символов с целью уменьшения объема файла скрипта и ускорения его загрузки. В минимизированном коде удаляются все комментарии и незначащие пробелы, переносы строк, символы табуляции. В случае с Javascript, это уменьшает время загрузки страницы, т.к. размер файла уменьшается. Две самых популярных утилиты для минимизации javascript - JSMin и YUI Compressor.

Обфускация является альтернативным способом сокращения исходного кода. Также, как минимизация, она удаляет пробельные символы и вырезает комментарии, но в дополнение она измененяет сам код. К примеру, во время обфускации имена функций и переменных заменяются на более короткие, что делает код более компактным, но менее читабельным. Обычно этот прием используется для усложнения реверс-инжиниринга программы. Но обфускация помогает также уменьшить код настолько, насколько это не получится сделать одной минимизацией. С выбором средства для обфускации javascript не все так ясно, но я думаю, что самая распространенная утилита для этого - Dojo Compressor (ShrinkSafe).

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

Варианты решений JSMin

Использование Java и командной строки
2 скрипта написаны на Java: YUI Compressor и Dojo ShrinkSafe . Оба решения являются достойными. Dojo ShrinkSafe выделяет то, что используется Rhino (мозилловский JavaScript-движок, написанный на Java) для построения дерева, которое оптимизируется перед работой с файлами.

Использование с собственном скрипте
Если нужно использовать упаковку с своем коде, то можно использовать JSMin и Packer , которые реализованы на нескольких языках программирования.

• скопилированный MS-DOS.exe файл
• исходный код на C (можете сами компилировать)
• исходный код на C#
• исходный код на Java
• исходный код на JavaScript
• исходный код на Perl
• исходный код на PHP
• исходный код на Python
• исходный код на OCAML
• исходный код на Ruby

Продолжение статьи на Drupal CookBook.ru

Предлагаем Вашему вниманию перевод статьи Стива Содерса с 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 быстрее.

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

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

JavaScript - это один из наиболее известных объектно-ориентированных языков программирования. А это значит, что .js -файл в первую очередь представляет из себя продукт программирования. Это важно знать, чтобы понимать суть сжатия кода JavaScript. Допустим, что перед нами некий код, который написан на JavaScript и выполняет определенные действия. Для примера приведем банальную программу вывода слов «Hello World» в браузере:

document.write(«Hello World»);

Какими способами можно сократить.js-файл?

Изменить алгоритм . Каждая программа работает по некоторому алгоритму. В некоторых случаях можно найти алгоритм, который будет работать быстрее и при этом меньше весить. Но обычная программа не сможет изменить алгоритм другой программы. Для этого нужен искусственный интеллект. Либо естественный, в виде программиста.

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

Изменить переменные. Одним из ключевых элементов программирования являются переменные - названия определенных элементов. С помощью переменных программист обращается к данным, которые скрыты за ним. И чтобы понимать какая переменная что хранит, программисты частенько дают переменным достаточно длинные имена, в которых содержится подсказка по поводу того, что за данные тут лежат. Во время программирования это очень удобно, а во время оптимизации сайта они не сильно необходимы. Например, переменную с именем тут_хранится_количество_записей_сайта можно без проблем для функциональности сайта заменить на переменную а . Вы сократите объем .js -файла сразу на 20± 10 байтов. И данное число можно смело умножать на количество вхождений данной переменной. К тому же переменных может быть очень много.

Закодировать код . Это последний и, наверное, самый действенный способ сжать .js -файл. Инструмент, который я хочу Вам презентовать, производит кодировку с использованием технологии Base62 . Данная технология использует 62 символа ASCII - символы A-Z, a-z и 0–9 - для кодирования информации. Этот инструмент мы и рассмотрим более подробно.

Инструмент для сжатия JavaScript

Javascriptcompressor.com

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

Интерфейс сайта весьма прост. В первое окно Вы должны ввести JavaScript код, а во втором окне Вы получите его сжатую версию. Так же, на странице имеются два checkbox`а:

Base62 Encode

Shrink variables

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

Что еще нужно знать про сжатие JavaScript

Ресурсов, которые предлагают те же услуги, предостаточно. Я остановился на данном инструменте потому, что другие ресурсы производили сжатие с ошибками. Не следует отрицать возможность наличия ошибок в сжатом js-коде. Поэтому, перед сжатием javascipt кода, создайте резервную копию .js -файла. Сразу после сжатия кода, лучше протестировать работоспособность сайта. Ещё лучше будет, если Вы проведете испытания на тестовом сайте.

Так же хочу сказать, что кодирование маленьких по объему .js -файлов почти что бессмысленно. Очень часто после кодирования таких файлов, их объем только увеличивается. Удачи Вам в ваших попытках сократить и сжать JavaScript.