Автоматизируем клиентскую оптимизацию

Ну, это public domain, так что, надеюсь, кому-нибудь это поможет сэкономить 749 (ну у них и цены %) баксов на сервер.

Ну, тут на самом деле ничего сложного — сложнее всего было продумать алгоритм :)

Ваш вариант тоже представляет собой вполне себе работоспособное решение, единственное что, некросплатформенное (для нас это критично), да и для работы с java-проектом сам бог велел использовать ant :)

1) Из-за того, что этот скрипт — ознакомительный, т.е. ставит перед собой цель «показать, представить пример того, как можно автоматизировать указанный процесс», он довольно громоздкий. На практике его можно очень и очень сильно упростить и сделать гибче.

2) А зачем вообще заморачиваться на автоматизацию выкладки проекта, если он маленький и над ним работает один человек? Вот у нас, к примеру, работает по 5-8 человек над проектом, и новые рабочие билды собираются teamcity с обязательной прогонкой через все тесты перед выкладыванием. И в наших условиях собирать это все руками — смерти подобно. Гораздо проще создать свод правил о том, как именовать файлы, куда их класть и все в таком духе, и потом создать скрипты для развертывания приложения для development, test и production окружения.

ага, а что Packer вытворяет? :)

То, что представлено на конечном сайте может быть сколь угодно уродским. Красивым и лаконичным структура проекта должна быть на девелопмент-версии. Попробуйте разобраться в JS на gmail.com

Видимо, вы невнимательно читали.
На дев-машине все остается по-прежнему.
А на продакшен все выкладывается примерно в том виде, что вы указали.
А что, вы хотите дебажить js-код прямо на продакшене? Так это неправильно, отлов багов должен происходить на машине тестера/разработчика. То, что лежит на сервере, должно быть оптимизировано для быстрой загрузки, для чего сжатие и делается.

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

Гигабайты ОЗУ — это здорово, но вот гигабайтные каналы далеко не у всех, и это я даже не вспоминаю всякие наладонники и GPRS.

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

JS Memory leaks == Drip? тогда фиг знает. Но могу посмотреть

Боюсь, что быстрого автоматического способа не знаю. Ниже sunnybear указал тот способ, что я хотел предложить.

кстати, попробуйте вставить перед каждым удалением элемента что-нибудь вроде метода purge от Дугласа Крокфорда:

function purge(d) {
    var a = d.attributes, i, l, n;
    if (a) {
        l = a.length;
        for (i = 0; i < l; i += 1) {
            n = a[i].name;
            if (typeof d[n] === 'function') {
                d[n] = null;
            }
        }
    }
    a = d.childNodes;
    if (a) {
        l = a.length;
        for (i = 0; i < l; i += 1) {
            purge(d.childNodes[i]);
        }
    }
}

Ну его можно по разному настраивать.
Ну и кроме того, всегда полезно послушать критику jslint относительно своего кода :)
Лично я тоже не следую абсолютно всем рекомендациям в strict-режиме, очень уж это накладно.

Ну, в моем случае выбор пал на ант потому, что мы программируем на java, и наши проекты собираются maven + ant. Выгоднее и для оптимизации использовать уже используемую технологию.

Ну а насчет использования xml+regex — то, что я не люблю эти технологии не означает, что я не могу ими пользоваться. Хотя вы не поверите — писал и плакал, писал и плакал :)

упс :)
комментарии я навешивал уже после того, как написал скрипт, халтурил, пользовался Ctrl-V -> Ctrl-C, и вот результат :)

Штука неплохая, но обладает рядом не очень удобных (для меня, по крайней мере) особенностей:

1) Он каждый раз при отдаче файлов заново проводит всю обработку. Не верите? Вот цитата из фака, пункт первый:
With Minify you will ideally serve fewer requests, but Minify can be slower than your HTTPd serving flat files

2) Он работает под апач. У нас, к примеру, апач на последних проектах вообще не используется (раньше использовался как frontend-сервер в связки nginx+jboss+apache, сейчас перешли на nginx+jboss).

3) Он работает на php5. Проблема в том, что многие компании (и мы в том числе) вообще не используем php. И ставить его ради таких случаев — не слишком разумно.

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

1) То, что исходники потеряются — бред. Для хранения исходников предназначен репозиторий системы управлениями версий (те же subversion и git). И место для исходников — рабочее место программиста и тот же репозиторий. Ну, еще бэкап репозитория. Все. Сервер, на котором исходники могут посмотреть все желающие — бред. Сервер не для этого предназначен. А на девелоперской машине все исходники остаются в прежнем виде.

2) Моя реализация работает быстрее. Вот почему: этот скрипт один раз за билд (т.е. развертывание приложение на сервере) склеил все, сжал и заботливо положил в папочку к nginx. А тот его сжал с помощью gzip и положил рядышком два варианта — сжатый и сжатый. И когда клиент просит контент, он смотрит, поддерживает ли клиент gzip, и если да, отдает ему пожатый, если нет — отдает ему непожатый (gzip'ом). И потом это все добро еще и кеширующий прокси закешировал. Кроме того, бьюсь об заклад, что ant-скрипт отработает в разы быстрее аналогичного php-скрипта (в данном случае под словом аналогичный я понимаю «имеющий один и тот же алгоритм»).

А в вашей реализации на каждый запрос клиента будет отрабатывать php-скрипт (+compressor), а это нагрузка. Маленькая, но все же. А что, если посетителей будет очень много? Возможно, отдача flat-файлов как раз и даст ту необходимую экономию ресурсов, которая позволит серверу не захлебнуться под валом запросов.

Впрочем, простите, я слишком резко ответил.

Ваш вариант тоже вполне себе жизнеспособное и обладающее рядом плюсов (как минимум, нет столько xml-a :) решение.

Видимо, мне очень дорого свое детище, аж на людей начал кидаться :)

Да, мне js-builder тоже понравился. Он как-раз делает все, что нужно.
К сожалению, он обладает одним, но очень существенным недостатком. Он только под win-платформу.
А у нас в команде половина разработчиков сидит под *nix, сервер (где это развертывание должно происходить) под *nix, я вообще белая ворона — у меня мак.

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

Такие css файлы просто напросто нельзя сливать. И получается только два варианта:
1) не переопределять классы по ходу проекта.
2) не сливать эти файлы.

Ага, уверен. Мы все-все сливаем в один файл.
У нас на последнем проекте вес исходников js-кода порядка 1 мегабайта (правда, та же jQuery не сжатая, и плагины к нему тоже не сжатые, да и код у нас хорошо задокументирован).
После склеивания и сжатия получается один файл размером в 98 KB. По моему, нормально. Грузится очень быстро, и функционал для всех страничек готов.
А если бить js на core-файл и кучку специализированных для каждой странички файликов, то будет все медленнее в итоге грузиться, уже не из-за трафика и размеров файлов, а из-за того, что запросы-то все равно проходят, и специализированный файл будет грузиться как минимум (ping + request_process_time + ping + download_time). Я подробнее уже вот тут отвечал.

Итого — выгоднее клеить все. Правда, есть еще одно правило:
1) Если объем сжатого js-кода больше 100 KB, то правильнее бить его на части, чтобы браузер мог грузить его в два потока. Или больше частей.
2) Если объем сжатого js-кода больше 500 KB, то надо его переписывать, т.к. такое количество js-кода просто убъет интерпретатор javascript (т.е. вкладка начнет тормозить сразу после загрузки кода, а через минуту работы подвесит весь браузер) во всех браузерах, кроме chrome.

Спасибо за интересный комментарий.

1) Чем именно хранение порядка склейки файлов в скрипте (и который, к слову, можно вынести как в файл пропертис, так и вообще включить в шаблон, как описано в пункте TODO) отличается от хранения порядка склейки в файле project.js/css? Я думаю, только тем, что вам нравится один вариант, и не нравится другой. Что так в одном файле все лежит, и надо не забывать обновлять список, что эдак.

2) JavaScript. Очень и очень редко нужно указывать пофайловый порядок для склейки, чаще всего нужно указать только, какой файл (обычно — javascript framework) должен идти первым, и какой файл (какой-нибудь файл, в котором все инициализируется) должен идти последним. Порядок включения остальных файлов совершенно не важен и не сделает новых ошибок. Короче говоря, я считаю, что тот синтакс, что описан в TODO, гораздо лучше, чем ваш или мой способ.

3) CSS. В принципе, для css верно все, что сказано выше, хочется только уточнить один момент, насчет объединения файлов стилей в один. Пожалуйста, покажите пример сжатого какой-нибудь утилитой объединенного css-файла, в котором есть как обычные data:URL'ы, так и специализированные для использования в ie mtm'ы. Я уверен, что вы не предоставите, потому что после сжатия YUI Compressor'ом (или другой утилитой) картинки не будут отображаться в ie. Именно в этом причина того, что для ie заводится отдельный файл, который не обрабатывается сжималкой (и не включается из-за своего веса в общий css), а не в том, что условные комментарии представляют какую-нибудь сложность для освоения.

4) Отдельные файлы для отдельных страниц — если использовать тот синтакс, что описан в TODO, то составит отдельный файл для отдельной страницы — раз плюнуть.