Подтвердить что ты не робот

Упаковка, кеширование, JS и CSS в PHP, которые различают среду разработки и производства

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

Цели, которые я пытаюсь сделать, это:

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

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

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

Я бы предпочел решение, состоящее из PHP script (в конечном итоге несколько файлов .php,.htaccess и сжатие исполняемых файлов), который сжимает .JS с помощью Google Closure Compiler и сжимает/компилирует файлы 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 - это оптимизированная, упакованная и скомпилированная версия script. Это решение должно иметь возможность обнаруживать, когда исходный файл изменяется и перекомпилирует сценарии для производства. Он должен быть конфигурирован в отношении местоположений script и типа кэширования (диск в порядке). В идеале у pack_js, вероятно, есть возможность сделать возможную ленивую загрузку js в процессе производства.

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

4b9b3361

Ответ 1

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

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

Другие решения и статьи Комбиниров JS/CSS

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

  • http://code.google.com/p/php-closure/ PHP скрипт, который позволяет комбинировать .js файлы. ancd combile считает API-интерфейс Google Closure REST. Проверять метки времени и кэшировать комбинированную версию локально.
  • http://dean.edwards.name/download JS-упаковщик-компрессор/обфускатор. Я не знаю, как долго проходит декомпрессия. Но он смог сжать jQuery 1.4.2, скомпилированный/уменьшенный с Closure до 50639 байт от 71946 (почти 30% сокращение!) С Base62 Encode on! Было бы интересно сравнить версии 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 Инструмент для упаковки JS/CSS Ruby Juicer

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

В параметрах времени развертывания:

Ответ 2

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

Ответ 3

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

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

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

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