Упаковка, кэширование, JS и CSS в PHP, которые различают среду разработки и производства - PullRequest
20 голосов
/ 17 августа 2010

Я пытаюсь упростить разработку и иметь высокооптимизированный выход в производство.

Цели того, что я пытаюсь сделать:

  • Сделайте рабочие страницы быстрыми! Мне бы хотелось, чтобы Google Page Speed ​​ и YSlow возвращали лучшие баллы. Это означает:
    1. Объедините и сожмите JS-файлы и CSS и поместите группу в нужное место (внизу или вверху страницы) в HTML. Для .js Google Closure кажется лучшим выбором.
    2. .JS и .CSS тщательно кэшируются , но убедитесь, что они перезагружаются при обновлении компонента .JS или CSS. 301 Файл не изменен и т. Д.
    3. Тип кэша : Я думаю, что кэш на диске в порядке. Рассмотрите APC и Memcache или Redis, если они значительно улучшают скорость.
    4. Может указывать и использовать ленивая загрузка .JS при необходимости или, по крайней мере, не блокировать рендеринг страницы.
    5. (Необязательно) Сжатие HTML тоже.
  • Упростите разработку веб-сайта :
    1. Используйте короткую команду в файле .php, если вы хотите включить .js или .css и сжимать их только в производственной среде.
      • Используйте синтаксис, такой как pack_js (['first.js', 'second.js' 'third.js']) и pack_css (['first.less', 'second.less '' third.css '], true)
      • Легко настроить среду разработки или производственную среду. Может быть, просто вызов SetDebug (true или false) . Производство по умолчанию
      • Простота установки папок кеша и исходных папок
    2. Использование LESS , чтобы сделать разработку CSS меньше отстой. Автоматически компилируйте файлы LESS в CSS в производственной среде, но при разработке используйте LESS.js , чтобы при каждом изменении файла .less в процессе разработки он обновлялся на сервере.
    3. (необязательно). В разработке он включает JS и консоль LESS, аналогичную оболочке в https://www.squarefree.com/bookmarklets/webdevel.html

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

Есть ли что-то, что делает это? Или какие ресурсы лучше всего начать?

Я бы предпочел решение, состоящее из сценария PHP (в конечном итоге, нескольких файлов .php, .htaccess и сжатия исполняемых файлов), который сжимает .JS с помощью компилятора Google Closure и сжимает / компилирует файлы CSS / LESS, удаляя ненужные комментарии и пробелы. Специальный файл cookie может использоваться на рабочем сервере для вывода версии для разработки.

Хотелось бы иметь:

Функцию php можно использовать так: pack_js (['first.js', 'second.js', 'third.js']) , которые пишут что-то вроде:

На серверах разработки:

<script type="text/javascript" src="static/js/first.js"></script>
<script type="text/javascript" src="static/js/second.js"></script>
<script type="text/javascript" src="static/js/third.js"></script>

На производственных серверах (если специального cookie нет):

<script type="text/javascript" src="cache/12a42323bfe339ea9w.js"></script>

Другая функция: pack_css (['first.less', 'second.less', 'third.css'], true) , которые пишут что-то вроде:

На серверах разработки:

<link rel="stylesheet/less" href="/static/css/first.less" type="text/css" />
<link rel="stylesheet/less" href="/static/css/second.less" type="text/css" />
<link href="/static/css/third.css" type="text/css" />
<script src="http://lesscss.googlecode.com/files/less-1.0.21.min.js"></script>

<script type="text/javascript" charset="utf-8">
    less.env = "development";
    less.watch();
</script>

На производственных серверах (если нет специального cookie):

<link href="/cache/46537a8b8e876f7a8e7.css" type="text/css" />

второй параметр указывает, нужно ли выводить файл less.js на сервере разработки

Очевидно, что 12a42323bfe339ea9w.js и 46537a8b8e876f7a8e7.css являются оптимизированной, упакованной и скомпилированной версией скрипта. Это решение должно быть в состоянии обнаружить, когда исходный файл изменяется, и перекомпилировать сценарии для производства. Он должен быть настраиваемым с учетом местоположения скрипта и типа кэширования (с диском все в порядке). В идеале в pack_js, вероятно, должна быть возможность сделать ленивую загрузку js в производственном процессе.

Приветствуется каждое предложение.

Ответы [ 3 ]

6 голосов
/ 18 августа 2010

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

CSS-JS-Booster и Турбина пока выглядит как лучшая отправная точка: http://github.com/Schepp/CSS-JS-Booster и http://turbinecss.org/

Другие решения и статьи по JS / CSS Combiners

Ресурс для сжатия и кэширования JS:

  • http://code.google.com/p/php-closure/ PHP-скрипт, позволяющий объединять файлы .js и объединять их с помощью REST API Google Closure. Проверьте метки времени и локально кэшируйте комбинированную версию.
  • http://dean.edwards.name/download JS упаковщик компрессор / обфускатор. Я не уверен, сколько времени займет декомпрессия. Но он смог сократить JQuery 1.4.2, скомпилированный / минимизированный с Closure, до 50639 байт с 71946 (почти на 30%!) С включенным Base62 Encode! Было бы интересно сравнить gzipped версии. Что касается JS obfuscation Packer, оптимизатор немного усложняет вмешательство в ваш JS-код.
  • http://thinkvitamin.com/dev/serving-javascript-fast/ Отличная дискуссия о gzip и кешировании
  • http://cjohansen.no/en/ruby/juicer_a_css_and_javascript_packaging_tool Упаковочный инструмент Ruby Juicer JS / CSS

LESS компиляторы / учебные пособия / инструменты:

Параметры времени развертывания:

2 голосов
/ 17 августа 2010

Почему бы вам не использовать систему сборки проекта для развертывания приложения на производственном сервере, который делает именно это? Для PHP вам может понравиться Phing , поскольку это позволит вам писать дополнительные плагины на PHP, которые вы сможете запускать при развертывании. Другие варианты, которые вы могли бы рассмотреть, выбирая этот маршрут: Ant и Capistrano (и есть много других), но для этого требуется знание других языков (предоставлено, вы могли бы начать парсер из них php если уж очень хотел ...).

0 голосов
/ 17 августа 2010

Отличный вопрос!

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

  1. Включите сжатие / компиляцию в процесс доставки. (Возможно, вы уже делаете это, но из вышесказанного было не ясно).
  2. Сожмите / скомпилируйте его также на серверах разработки. Это может быть хлопотно для отладки / тестирования, но вы хотите иметь возможность убедиться, что рабочая версия и тестовая версия максимально похожи. Если вы можете позволить себе роскошь нескольких этапов разработки, вы можете сжать один из них.
  3. Сжатие / компиляция возможна только в том случае, если она проходит какое-то качественное сканирование (например, jslint )
  4. Не объединяйте модули - держите их отдельно. Выигрыш в производительности будет настолько незначительным, что будет почти бессмысленным.
  5. Не изменяйте HTML, просто изменяйте содержимое зависимых модулей.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...