2012-08-07 22 views
14

¿Por qué la gente no hacen.phparchivos por susCSSyJavaScriptarchivos?¿Por qué no se utilizan los archivos PHP para (personalizado) CSS y JS?

Adición <?php header("Content-type: text/javascript; charset: UTF-8"); ?> al archivo hace que sea legible por los navegadores, y se puede hacer lo mismo con los archivos CSS estableciendo la propiedad Content-type a text/css.

Le permite usar todas las variables de PHP y métodos en los otros idiomas. Le permite, por ejemplo, cambiar los colores principales del tema dependiendo de las preferencias del usuario en css, o precargar los datos que su javascript puede usar en la carga de documentos.

¿Hay malos lados en el uso de esta técnica?

+6

La principal mala parte es que significa que el navegador no puede almacenar los archivos en la memoria caché, lo que representa un serio problema de rendimiento. – Pointy

+7

¿Qué te hace pensar que no? No es tan común, pero tampoco es desconocido. –

+1

@Pointy No puede agregar encabezados de caché? –

Respuesta

18

La gente lo hace más a menudo de lo que crees. Simplemente no puede verlo, porque generalmente esta técnica se usa en combinación con la reescritura de URL, lo que significa que el navegador no puede diferenciar entre un archivo .css servido de forma estática y una hoja de estilos dinámica generada por un script PHP.

Sin embargo, hay algunas razones de peso no de hacerlo:

  • En una configuración por defecto, Apache trata de salida del script PHP como 'sujeto a cambios en cualquier momento dado', y establece los encabezados apropiados para evitar el almacenamiento en caché (de lo contrario, el contenido dinámico no funcionaría realmente). Esto, sin embargo, significa que el navegador no guardará en caché su CSS y javascript, lo cual es malo: se volverán a cargar a través de la red para en cada página de carga. Si tiene unas pocas cargas de cientos de páginas por segundo, esto es absolutamente importante, e incluso si no lo hace, la capacidad de respuesta de la página sufrirá considerablemente.
  • CSS y Javascript, una vez desplegados, rara vez cambian, y las razones para hacerlo dinámico son realmente raros.
  • Ejecutar un script PHP (incluso si es solo para iniciar el intérprete) es más costoso que simplemente servir un archivo estático, por lo que debe evitarlo a menos que sea absolutamente necesario.
  • Es bastante difícil asegurarse de que el Javascript que usted entregue sea correcto y seguro; Escapar valores dinámicos para Javascript no es tan trivial como se podría pensar, y si esos valores son proporcionados por el usuario, está pidiendo problemas.

Y hay algunas alternativas que son más fáciles de instalar:

  • escribir unas cuantas hojas de estilo y seleccionar el más adecuado de forma dinámica.
  • Establezca reglas de hojas de estilo basadas en los nombres de clase, y establezca esas dinámicamente en su HTML.
  • Para javascript, defina las partes dinámicas dentro del documento principal antes de incluir el script estático. El escenario más típico es establecer algunas variables globales dentro del documento y hacer referencia a ellas en el script estático.
  • Compila scripts dinámicos en archivos estáticos como parte del proceso de compilación/implementación. De esta forma, obtienes la comodidad de PHP dentro de tu CSS, pero aún así puedes enviar archivos estáticos.

Si desea utilizar PHP para generar dinámicamente CSS después de todo:

  • anulan los encabezados de almacenamiento en caché para permitir que los navegadores y servidores proxy para almacenar en caché ellos. Incluso puede establecer la caducidad de la caché en 'nunca' y agregar un parámetro de cadena de consulta falsa (por ejemplo, <link rel="stylesheet" type="text/css" href="http://example.com/stylesheet.css?dummy=121748283923">) y cambiarla cada vez que cambie la secuencia de comandos: los navegadores interpretarán esto como una URL diferente y omitirán la versión en caché.
  • Configure la reescritura de URL para que la URL del script tenga una extensión .css: algunos navegadores (IE) son conocidos por obtener el tipo MIME incorrecto en algunas circunstancias cuando la extensión no coincide, a pesar de los encabezados Content-Type correctos.
+0

En mis pruebas, he encontrado que agregar una cadena de consulta evitará que IE almacene el archivo en caché, ya que asume que es dinámico. Una referencia sólida para probar o refutarme sería bienvenida. – IMSoP

+0

De hecho, ni siquiera es solo IE, mira mi comentario en otro lugar de la página. – IMSoP

0

PHP se utiliza a menudo como procesador para generar contenido dinámico. Lleva tiempo procesar una página y luego enviarla. En aras de la eficacia (tanto para el servidor como para el tiempo dedicado a la programación), los archivos JS o CSS dinámicos son solo creados si no hay una forma posible para que el archivo estático logre su objetivo deseado.

Recomiendo solo hacer esto si absolutamente requiere la ayuda de un procesador dinámico basado en una base de datos.

5

La ejecución del motor de PHP no tiene un costo cero, ni en tiempo ni en CPU. Y dado que los archivos CSS y JavaScript rara vez cambian, no tiene sentido hacer que funcionen con el motor para hacer absolutamente nada; es mejor dejar que el navegador los guarde en caché cuando sea apropiado.

+3

Sin mencionar que los archivos estáticos se pueden alojar en CDNs – Esailija

+1

@tdammers: pero igual tiene que invocar PHP cada vez, incluso si solo para obtener el 304. –

+0

Creo que tdammers significaba que los archivos que no cambian pueden ser estáticos, CDN'd, etc., pero las partes que sí cambian (por ejemplo, estilos personalizables en un CMS) se pueden servir a través de PHP. Estoy de acuerdo en que organizar el almacenamiento en caché para que no haya una invocación de PHP es complicado, aunque no es completamente imposible. – IMSoP

1

En ocasiones puede que tenga que crear javascript o estilos dinámicamente.

el problema es que los servidores web están optimizados para servir contenido estático. Generar dinámicamente contenido con php puede ser un gran golpe perforante porque debe generarse en cada solicitud.

10

Algunos lo hacen, lo mejor es generar sus scripts JS/CSS en PHP y almacenarlos en caché en un archivo.

Si sirve todos sus archivos CSS/JS usando PHP, entonces tiene que invocar PHP más que incurre en más sobrecarga (CPU y memoria) que no es necesaria cuando se sirven archivos estáticos. Mejor dejar que el servidor web (Apache/nginx/lighttpd/iis, etc.) haga su trabajo y sirva esos archivos por usted sin la necesidad de PHP.

+1

Exactamente. Si rara vez cambian, existe la ventaja de poder generarlos y almacenarlos cuando lo hacen, pero se benefician poco al generarlos dinámicamente en cada solicitud (el almacenamiento en caché del navegador a un lado). –

+0

¿Algún punto de referencia para apoyar esto? –

+1

No tengo detalles, pero variarán en función de cómo se invoca PHP (módulo, CGI) y con qué módulos se compila PHP (cuantos más módulos, más memoria base se usa). En la mayoría de los casos, la sobrecarga adicional es probablemente pequeña, pero puede sumar mucho si tiene una gran cantidad de usuarios simultáneos. Básicamente terminas invocando PHP innecesariamente para generar el mismo contenido una y otra vez cuando podría ser atendido estáticamente. – drew010

0

Las malas caras: un montón, pero por nombrar sólo unos pocos:

  • Será muertos lenta: la construcción de estilo personalizadas para cada solicitud pone una enorme carga en el servidor, no es algo que desea.

  • Los diseñadores crean archivos CSS, los programadores no deberían (en algunos casos no se les debería permitir). No es su trabajo/su especialidad.

  • Mezclar JS y PHP es, en mi humilde opinión, uno de los mayores errores que se pueden cometer. Con jQuery siendo una lib muy popular, utilizando el signo $, podría ser una gran fuente de errores y errores de sintaxis. Además de eso: JS es un lenguaje completamente diferente a prácticamente cualquier otro lenguaje de programación. Muy pocas personas saben cómo aprovecharlo al máximo, y dejar que los desarrolladores de PHP escriban extensos guiones JS a menudo termina en lágrimas.
    JavaScript es un lenguaje funcional OO (prototypal). Las personas que no comprenden completamente estas diferencias cruciales escriben código incorrecto como resultado. Lo sé, porque he escrito toneladas de código JS terrible.

  • ¿Por qué querrías hacer esto, en realidad? PHP te permite cambiar todas las clases de elementos mientras generas la página, solo asegúrate de que las clases tengan las reglas de estilo correspondientes en tus archivos CSS y los colores cambien como quieras, sin tener que enviar varios archivos, jugando con los encabezados y todos los dolores de cabeza eso viene con esta práctica

Si quieres más razones por las que no deberías hacer esto, puedo pensar en al menos otras docenas.
Dicho esto: solo puedo pensar en 1 razón por la que pensaría en hacer esto: hace que los problemas causados ​​por los scripts en caché del lado del cliente no sean un problema. No es que deba ser un problema en primer lugar, pero bueno ...

+3

No acuerde que los "programadores no deben crear archivos CSS". Los diseñadores deberían crear diseños; Depende de los programadores/especialistas en CSS hornearlos en las hojas de estilo. – tdammers

+2

También no estoy de acuerdo con la parte 'Los programadores PHP no pueden escribir JS'. No todo el mundo es un pony de un solo truco; algunos de nosotros podemos trabajar cómodamente en media docena de idiomas y no tenemos problemas para cambiar entre ellos. Y JS no es * que * diferente, es básicamente la mitad de Scheme en el camuflaje de Java.Si quieres 'a diferencia de cualquier otro idioma', prueba Haskell. O Malbolge. – tdammers

+2

Puntos de contador: 1. El almacenamiento en caché niega las preocupaciones de velocidad una vez hecho y PHP no está "muerto lento" 2. El argumento es para un archivo CSS (con sugerencias/variables adicionales), no necesariamente BL 3. Se está argumentando que PHP es un uso de una "plantilla" aquí 4. ¿Por qué no? Eso es lo que el afiche pregunta :) –

1

No es una mala idea, o muy poco común, pero tiene sus desventajas. El almacenamiento en caché es una consideración importante: debe permitir que los navegadores guarden en caché cuando el contenido sea el mismo, pero actualice cuando varíe (por ejemplo, cuando alguien más inicie sesión). Cualquier cadena de consulta detendrá inmediatamente el almacenamiento en caché de algunos navegadores, por lo que necesitará algunas reglas de reescritura y encabezados HTTP.

Cualquier proceso que requiera un tiempo notable o que requiera un bloqueo en algo (por ejemplo, session_start) mantendrá el navegador en espera mientras espera el activo.

Finalmente, y bastante importante, mezclar idiomas puede dificultar la edición del código: el resaltado de sintaxis y los navegadores de estructura pueden no funcionar, y la superposición de sintaxis puede llevar a cosas desagradables, como escapes múltiples hacia atrás.

En javascript, puede ser útil convertir algunos datos PHP en variables (JSON), y luego proceder con el código JS estático. También hay un beneficio de rendimiento para concatenar múltiples archivos JS porque el navegador los descarga todos de una vez.

Para CSS, hay idiomas específicos como Less que se ajustan mejor a la finalidad. Usando LessPHP (http://leafo.net/lessphp/) puede inicializar fácilmente una plantilla Less con variables y callbacks desde su script PHP.

+0

Una cadena de consulta ** no ** detiene el navegador del almacenamiento en caché. Eso depende de las directivas de caché dadas por el recurso servido. – Brad

+0

Como mencioné en otra parte de esta página, esa es mi experiencia probando con IE; parece interpretar las páginas con una cadena de consulta como dinámica. IIRC, envía un If-Modified-Since, pero manejar eso para el contenido generado dinámicamente no es trivial. – IMSoP

+0

Puedo reproducir esto consistentemente con la última versión de Firefox (14.0.1). Vaya a http://rwec.co.uk/x/caching/cache-test-dummy.html y abra un depurador HTTP como Firebug o Fiddler, y haga clic en el enlace "self" varias veces. La URL con la cadena de consulta se marca repetidamente usando If-Modified-Since. Estos son todos los archivos estáticos, por lo que el servidor responde con un 304. Si se tratara de un script PHP, se estaría ejecutando en cada carga de página. – IMSoP

2

Aquí hay un método que he usado: La página HTML contiene una referencia a /path/12345.stylesheet.css. Ese archivo no existe. Entonces, .htaccess enruta la solicitud al /path/index.php. Ese archivo (a) hace una solicitud de base de datos, (b) crea el CSS, (c) guarda el archivo para la próxima vez, (d) sirve el CSS para el navegador. Eso significa que la próxima vez que hay una solicitud para /path/12345.stylesheet.css, hay un archivo físico estático que Apache debe servir normalmente.

Oh, y cada vez que se editan las reglas de estilos (a) se borra el archivo estático y (b) se cambia la ID de referencia, de modo que la página HTML contendrá en el futuro una referencia a /path/10995.stylesheet.css o lo que sea. (En realidad, uso una marca de tiempo UNIX.)

Utilizo un método similar para crear miniaturas de imágenes: crea el archivo en la primera solicitud y guarda un archivo estático en el mismo lugar para futuras solicitudes. Nunca tuve ocasión de hacer lo mismo con javascript, pero no hay una razón fundamental para no hacerlo.

Esto también significa que no tiene que preocuparse por el almacenamiento en caché encabezados en PHP: sólo el primero invocación de cada archivo CSS (o miniatura de la imagen) pasa a través de PHP, y si que se sirve con cabeceras anti-caché ese no es un gran problema

Cuestiones relacionadas