Tag: html

PHPSpeedy: mejora el tiempo de carga de tu sitio

Posted on by

PHP Speedy Hay muchas formas de mejorar el tiempo de carga de una página; algunas de ellas son:

  • realizar menos peticiones al servidor
  • agregar una cabecera de expiración muy lejana en el futuro
  • comprimir los componentes de la página
  • “minificar” tu javascript, css, html

PHP Speedy es un script para PHP que realiza estas cuatro tareas automáticamente. Está disponible como clase (para utilizar en cualquier sitio/página que soporte PHP) o como plugin para WordPress —he estado probando este último en mi tumblelog y el resultado ha sido bastante satisfactorio.

Si quieres utilizar el plugin para WordPress, debes asegurarte que tu theme incluya el hook <?php wp_head(); ?> antes de </head>. Además, revisa que todo lo que tenga que ver con JavaScript siga funcionando: el plugin combinará y “minificará” tus scripts y los enlazará en el punto donde se encuentre <?php wp_head(); ?>. Si tienes código que necesita de librerías que se hayan invocado anteriormente, puedes solucionarlo simplemente moviendo tu código más abajo de <?php wp_head(); ?>.

Miopía standardista y la paradoja de los tipos de contenido

Posted on by

Sobre el sinsentido de atender irrestrictamente a los estándares web, la insuficiencia de validar y la paradojal utilización de los tipos de contenido.

Hace muuucho tiempo, este artículo iba a ser una discusión sobre los futuros estándares para HTML: XHTML 2 y HTML 5. Luego, pasó a ser una discusión sobre lo jodido que resulta el parser XML, el que en teoría, debería ser el que debe ser usado al elegir un DOCTYPE XHTML. Ahora, intento resumir algo de ello y apuntar a un tema que hace tiempo me está llamando a escribir algo: los mal-llamados y auto-denominados standardistas. Aquí vale la pena hacer inmediatamente una pausa para aclarar a qué me refiero con esto: históricamente, el movimiento pro-estándares surge en un momento en el que la guerra de los navegadores había llegado a un punto en el que, como medida de lograr ventajas competitivas, cada empresa implementaba mejoras propietarias, incompatibles con los demás productos del mercado. No sólo MSIE propiciaba esto, Netscape también hacía lo suyo.

El movimiento por los estándares tenía, en principio, una gran tarea: asegurar una experiencia común para usuarios de distintos navegadores, y es en ese contexto donde respetar un estándar web encuentra su sentido. La separación del contenido y la presentación, la disminución de los tiempos de carga, la ventaja de escribir menos (y mejor) código han sido quizás los mejores argumentos en esta pelea, que al cabo de largos años ya podríamos dar por ganada —qué mejor evidencia que el interés de los desarrolladores de Internet Explorer en aumentar su conformidad con los estándares… aun con una implementación todavía muy, muy mejorable.

Entonces, como vimos y aceptamos guiar nuestro trabajo por un estándar es bueno, muchos desarrolladores comenzaron a interesarse en desarrollar con estándares… pero nada más. Su nueva insignia de orgullo y admiración no sería “Optimizado para…”, sino HTML válido; validar se convirtió en un fin, y creo que a estas alturas decir que el solo hecho de pasar la prueba del validador de la W3 es cuando menos insuficiente, y en muchos casos, engañoso.

Fue entonces que muchos comenzaron a creerse el cuento de ser standardista, no como aquellos que tuvieron la visión suficiente para pensar en un estándar como una forma de mejorar la experiencia de los usuarios, sino fijándose casi exclusivamente en el validador, y sintiéndose autorizados de apuntar con el dedo a aquellos que no pasaban esta prueba.

Junto con ello, y dado que la separación de contenido y presentación es una de sus máximas, muchos despreciaron a HTML 4 por incluir elementos y atributos representacionales, ¡una verdadera herejía! XHTML 1.0 Transitional tampoco es mucho mejor, puesto que es básicamente lo mismo que HTML 4, por lo que las únicas alternativas dignas parecen ser XHTML 1.0 Strict o XHTML 1.1… y aquí es donde llegamos a la paradoja.

A cada documento, su tipo

Si ser standardista significa un respeto irrestricto a los estándares de la W3, ¿cómo es que tantos de ellos se han olvidado de servir su contenido como corresponde? Al parecer, simplemente se saltaron ese capítulo o bien, derechamente, lo ignoran. La cuestión es que todos aquellos que lucen orgullosos sus enlaces de XHTML 1.0 Strict, pero sirven su contenido como text/html caen en una estupenda contradicción, y es que servir XHTML como text/html no es solamente erróneo según los mismos estándares por los que juran lealtad, sino que incluso puede ser considerado “dañino”.

Vamos lentamente: cuando conectamos a un servidor y éste nos envía un archivo, junto con él recibimos una indicación que señala qué tipo de documento estamos descargando. Así, cuando descargamos una imagen GIF, se envía la cabecera Content-Type: image/gif, o Content-Type: image/jpeg cuando es un JPG. De acuerdo a esa información (el content type), el cliente decide qué hacer con el archivo; en estos dos ejemplos, y asumiendo que estamos utilizando un navegador gráfico, éste nos mostrará la imagen requerida —como nota aparte: utilizaré content type y media type como sinónimos.

Con las “páginas” (me refiero al X/HTML) pasa lo mismo: el cliente solicita el archivo, recibe la información del content type y la muestra. Sin embargo, entre estos dos pasos ocurre algo muy importante: se selecciona el “parser”.

A ver, a ver… ¿que qué cresta es un parser? Básicamente, es el encargado de interpretar un documento; en este caso, documentos escritos en lenguajes de marcado como XHTML y HTML. Si las cosas fueran como deberían (pretendamos que lo son), cualquier navegador debería ser capaz de parsear un documento HTML como HTML y un documento XHTML como XHTML de acuerdo a la declaración de su media type: text/html o application/xhtml+xml, respectivamente; si las cosas fueran como deberían, tendría que existir una estricta correspondencia entre el tipo de documento, el media type y el parser. Honrando a Murphy (el de [la ley->Ley de Murphy@wiki], no [el de las películas->Eddie Murphy@wiki]), las cosas no son como deberían.

La correspondencia entre el tipo de documento y el media type pocas veces es efectiva, de hecho, la mayoría de las veces nos encontramos con que los documentos XHTML son servidos como text/html lo cual es permitido (como en May) pero no recomendado en XHTML 1 y derechamente desincentivado (como en Should Not) para XHTML 1.1 en adelante —lo pueden ver mejor explicado en en este documento de la W3 y la definición de “Should Not” en este memo.

¿Y cuál es el problema con servir XHTML como text/html? —se estarán preguntando. La respuesta no muy simple, pero por suerte a algunas personas ya se les ocurrió una forma un poco más digerible de presentarla; intentaré una traducción (por pésima que resulte), aunque de todos modos recomiendo la lectura del artículo completo:

Por qué utilizar text/html para XHTML está mal

Lo que generalmente pasa a los autores que deciden enviar XHTML como text/html es lo siguiente:

  1. El autor escribe XHTML que hace suposiciones que sólo son válidas para navegadores HTML 4 o tag soup, y no para navegadores XHTML, y lo sirve como text/html [las suposiciones se listan más abajo en este artículo]
  2. El autor encuentra que todo funciona bien
  3. El tiempo pasa
  4. El autor decide servir el mismo contenido como application/xhtml+xml porque, después de todo, es XHTML
  5. El autor encuentra que el sitio se estropea horriblemente [las razones se listan más abajo en el artículo]
  6. El autor culpa a XHTML

Sending XHTML as text/html Considered Harmful

Atención ortodoxos, servir XHTML como text/html es simplemente no seguir el estándar —cito: El media type text/html es primariamente para HTML, no para XHTML. En general, este media type NO es conveniente para XHTML (W3.org: XHTML Media Types, énfasis del original).

Quizás estén pensando “bueno, entonces la solución es simple: servir XHTML como application/xhtml+xml“… pero eso no es tan simple: entonces debería ser interpretado como XML, y esto conlleva a las complicaciones (el “horrible estropeamiento”) inherentes al parser XML. La cuestión es la siguiente:

XML tiene un manejo de errores definido muy precisamente (a diferencia de HTML): cuando el parser encuentra algo inesperado, simplemente se detiene y muestra un error. Esto significa dos cosas: hace que el editar documentos XML sea más cercano a “programar de verdad” (si cometes un pequeño error [el programa] no se compila), y como no se necesita código para el manejo de errores, los parsers se hacen a la vez más rápidos y más fáciles de escribir. Como pueden imaginar, los programadores se sintieron en casa.

Why XHTML is a bad idea

Algo así:

XML Parsing Error

XHTML.com: Serving XHTML as XML

Como decía antes, si las cosas fueran como deberían, y XHTML fuera servido como application/xhtml+xml e interpretado como XML, un gran porcentaje de las páginas actuales se verían como la imagen anterior: bastaría que la codificación no correspondiera (por ejemplo, indicar ISO-8859 en vez de UTF-8), que existieran etiquetas anidadas incorrectamente, nombres de elementos en mayúsculas o un ampersand (&) no codificado para que no se viera más que una pantalla amarilla indicando amablemente el error… ¡incluso un trackback de un blog con una codificación distinta bastaría para producir un error!

The advantages of XHTML

When sent as application/xhtml+xml, XHTML has several advantages:

  1. XHTML content will be able to be mixed-and-matched with content from other well-known namespaces (in particular, MathML). This is the main advantage for content authors.
  2. Browsers will immediately catch well-formedness errors (though other errors still won’t be caught).
  3. Tools interacting with XHTML documents are guaranteed a well-formed document.

However, none of these apply when an XHTML document is sent as text/html, and since authors feel their pages should be readable on the most popular Web browser, which does not support application/xhtml+xml, there is basically no point in using XHTML at the moment.

Sending XHTML as text/html Considered Harmful

¿Qué queda entonces? Aun respetando los estándares, una solución sería utilizar XHTML 1.0 Transitional, que puede ser servido como text/html, y en consencia interpretado como HTML… ¡pero ni siquiera el HTML servido como text/html es interpretado como HTML!

Mientras que HTML 4.01 es formalmente un formato de documento basado en [SGML->@en.wiki], los únicos clientes que realmente tratan al HTML de esta forma son los validadores. Los navegadores, por otra parte, tratan al HTML como si fuera sopa de etiquetas [tag soup]— tratan hacer sentido de, y mostrar, incluso el documento más horriblemente estropeado según su mejor habilidad.

Digital Web Magazine – HTML5, XHTML2, and the Future of the Web

En resumen:

  • Servir XHTML como text/html es incorrecto según la W3
  • Servir XHTML como text/html impide cualquier beneficio de la utilización de XHTML
  • Servir XHTML como application/xhtml+xml produce que se interprete como XML, por lo que si tu código no es perfecto, tus visitantes no verán nada
  • Si aún quieres servir XHTML como text/html, podrías hacerlo con el DOCTYPE XHTML 1.0 Transitional…
  • …pero será interpretado como HTML…
  • …pero HTML es interpretado como tag soup

¿Y yo? Uso XHTML como text/html… y no me quita el sueño.

Lecturas