Почему PHP-файлы не используются для (пользовательских) CSS и JS?

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

Однако есть несколько серьезных причин не делать этого:

• В конфигурации по умолчанию Apache рассматривает вывод PHP-скрипта как «подлежащий изменению в любой момент времени» и устанавливает соответствующие заголовки для предотвращения кеширования (в противном случае динамический контент на самом деле не работает). Это, однако, означает, что браузер не будет кэшировать ваши CSS и javascript, что плохо – они будут перезагружены по сети для каждой загрузки одной страницы . Если у вас есть несколько сотен загрузок страниц в секунду, это абсолютно важно, и даже если вы этого не сделаете, чувствительность страницы значительно страдает.
• CSS и Javascript, когда-то развернутые, редко меняются, и причины сделать его динамичным действительно редки.
• Запуск PHP-скрипта (даже если это просто запуск интерпретатора) дороже, чем просто обслуживание статического файла, поэтому вам следует избегать его, если это абсолютно необходимо.
• Очень чертовски сложно убедиться, что Javascript, который вы вывешиваете, является правильным и безопасным; ускорение динамических значений для Javascript не так тривиально, как вы думаете, и если эти значения предоставляются пользователем, вы просите о проблемах.

И есть несколько альтернатив, которые легче настроить:

• Напишите несколько таблиц стилей и выберите правильный динамически.
• Создавайте правила стилей на основе имен классов и динамически устанавливайте их в своем HTML.
• Для javascript определите динамические части внутри родительского документа, прежде чем включать статический скрипт. Наиболее типичным сценарием является установка нескольких глобальных переменных внутри документа и ссылка на них в статическом скрипте.
• Компилируйте динамические скрипты в статические файлы как часть процесса сборки / развертывания. Таким образом, вы получаете удобство PHP внутри своего CSS, но вы по-прежнему получаете статические файлы.

Если вы хотите использовать PHP для генерации CSS динамически:

• Переопределите заголовки кеширования, чтобы браузеры и прокси могли кэшировать их. Вы даже можете установить срок хранения кеша «никогда» и добавить параметр строки фальшивого запроса (например, <link rel="stylesheet" type="text/css" href="http://example.com/stylesheet.css?dummy=121748283923"> ) и изменяйте его при каждом изменении сценария: браузеры интерпретируют это как другой URL-адрес и пропускают кешированную версию.
• Настройте переписывание URL-адресов, чтобы URL-адрес сценария имел расширение .css: некоторые браузеры (IE) печально известны тем, что при неправильном использовании типа MIME недопустимо, если расширение не совпадает, несмотря на правильные заголовки Content-Type .

Некоторые делают, лучше всего сгенерировать сценарии JS / CSS в PHP и кэшировать их в файл.

Если вы используете все ваши файлы CSS / JS с помощью PHP, тогда вам нужно вызывать PHP больше, что накладывает дополнительные накладные расходы (процессор и память), что не нужно при обслуживании статических файлов. Лучше просто позволить веб-серверу (Apache / nginx / lighttpd / iis и т. Д.) Выполнять свою работу и обслуживать эти файлы для вас без необходимости в PHP.

Запуск PHP-движка не имеет нулевой стоимости, как в момент времени, так и в CPU. И так как файлы CSS и JavaScript обычно редко меняются, их запуск через движок абсолютно ничего не имеет смысла; лучше позволить браузеру кэшировать их, когда это необходимо.

Вот один из методов, которые я использовал: Страница HTML содержит ссылку на /path/12345.stylesheet.css . Этот файл не существует. Таким образом .htaccess направляет запрос в /path/index.php . Этот файл (a) выполняет запрос базы данных, (b) создает CSS, (c) сохраняет файл в следующий раз, (d) служит CSS для браузера. Это означает, что в следующий раз есть запрос на /path/12345.stylesheet.css , на самом деле есть физический статический файл, который должен быть установлен Apache как обычно.

О, и всякий раз, когда редактируются правила стилей (a) статический файл удаляется, и (b) идентификатор ссылки изменяется, так что на странице HTML в будущем будет содержаться ссылка на /path/10995.stylesheet.css или без разницы. (Фактически, я использую временную метку UNIX.)

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

Иногда вам может потребоваться динамическое создание javascript или стилей.

проблема заключается в том, что веб-серверы оптимизированы для обслуживания статического контента. Динамическое создание контента с помощью php может быть огромным ударом perforamce, потому что он должен генерироваться при каждом запросе.

Это неплохая идея или все это необычно, но есть недостатки. Кэширование – важное соображение – вам нужно, чтобы браузеры кэшировали, когда контент один и тот же, но обновляется, когда он будет меняться (например, когда кто-то еще входит в систему). Любая строка запроса немедленно остановит кеширование браузеров, поэтому вам понадобятся правила перезаписи, а также заголовки HTTP.

Любая обработка, которая занимает заметное время или требует блокировки на что-либо (например, session_start), задерживает браузер, пока он ждет актива.

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

В javascript может быть полезно преобразовать некоторые данные PHP в (JSON) переменные, а затем перейти к статическому JS-коду. Существует также преимущество в производительности для объединения нескольких JS-файлов назад, браузер загружает их все за один раз.

Для CSS существуют определенные языки, такие как «Меньше», которые больше подходят для этой цели. Используя LessPHP (http://leafo.net/lessphp/), вы можете легко инициализировать шаблон Less с переменными и обратными вызовами из вашего PHP-скрипта.

PHP часто используется в качестве процессора для создания динамического содержимого. Для обработки страницы требуется время, а затем отправить ее. Ради эффективности (как для сервера, так и для времени, затраченного на программирование) динамические файлы JS или CSS создаются только в том случае, если статический файл не может успешно выполнить свою намеченную цель.

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

Плохие стороны: много, но назвать несколько:

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

• Дизайнеры создают файлы CSS, программисты не должны (в некоторых случаях не должны допускать). Это не их работа / их специальность.

• Смешивание JS и PHP – это ИМХО, одна из самых больших ошибок может сделать. Поскольку jQuery является очень популярным lib, используя знак $ , он может быть огромным источником ошибок и синтаксических ошибок. Кроме того: JS – совершенно другой язык, чем любой другой язык программирования. Очень немногие люди знают, как извлечь максимальную выгоду из этого, и позволить разработчикам PHP писать обширные сценарии JS, которые часто заканчиваются слезами.
  JavaScript – это функциональный OO ( прототипный ) язык. Люди, которые не полностью понимают эти критические различия, пишут плохой код в результате. Я знаю, потому что я написал множество ужасных JS-кодов.

• Зачем вам это делать? PHP позволяет вам изменять классы всех элементов при создании страницы, просто убедитесь, что классы имеют соответствующие правила стиля в ваших файлах css, и цвета будут меняться так, как вы хотите, без необходимости отправлять разные файлы, возиться с заголовками и всеми головными болями который приходит с этой практикой

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