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

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

Вот один из методов, которые я использовал: Страница 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, но нет основополагающих причин, почему бы и нет.

Ответ 5

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

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

Ответ 6

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

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

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

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

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

Ответ 7

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

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

Ответ 8

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

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

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

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

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

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