CSS Diseño Web HTML Javascript
Cientos de miles de millones de horas más tarde, trasnoches al por mayor, litros y litros del buen café-café, dosis interminables de snacks y un sinfín de decisiones tomadas (¿Qué color? ¿Verde? ¿Rojo?) te han llevado al momento que tanto esperabas: El sitio está terminado y listo para el lanzamiento. A descansar ahora ¿no?, nada más lejos de la realidad.
Para todos aquellos que les gusta el diseño Web, trabajan en ello, o bien ambas, no hay mejor momento que cuando un sitio es terminado y se lanza. Sin embargo, junto con eso, se sabe que el trabajo no está ni cerca de terminar, ya que desde ese instante en adelante comienza el proceso interminable de la optimización y mejoramiento de lo que se ha hecho, lo cual, siendo bastante honestos, puede terminar siendo aún más exhaustivo e interminable que el proceso de diseño y desarrollo.
Pues bien, hoy en CLH, en nuestro continuo afán de hacer la vida un poco más sencilla, les traemos un sencillo top ten con algunos tips y trucos para que puedan optimizar sus sitios Web, para al menos partir con un poco de orientación en este largo y complejo camino.
El detalle, como siempre, después del salto.
Nota: La optimización de un sitio Web es un proceso continuo y bastante extenso, que de seguro toma bastante más que los 10 pasos presentados a continuación. Sin embargo, les presentamos algunos de los que consideramos, en nuestra opinión, más esenciales para poder partir, y esperamos en un futuro traer algunos más.
En este tutorial, al ser de un tipo distinto que los normales, no necesitamos ningún tipo de implementos de forma requerida, quizás es recomendable algún editor Web para alguna de las tareas, pero ahí lo podrán apreciar en cada punto.
Lo que veremos hoy es un conjunto de buenas prácticas, consejos útiles y tips de mejora de rendimiento que nunca están demás.
Sin más que decir, vamos con nuestro top ten:
Este es un punto al que muchos, incluyéndome, en algunas ocasiones le hemos dado poca importancia, pero sin duda que la tiene. El declarar el DocType o tipo de documento es clave para permitir que los navegadores interpreten de forma correcta el código que tenemos en cada página, ya sea HTML o XHTML. Si bien al no declarar, existe la posibilidad de que en nuestro navegador se vea de forma correcta, esto no asegura que el código se interprete bien para cada usuario y será complejo al momento de validar.
La gran mayoría de los editores Web (como Adobe Dreamweaver), agregan el DocType de forma automática, por lo que no hay que preocuparse. Sin embargo, nosotros lo podemos añadir de forma manual, siempre al inicio del documento, es decir, antes de la etiqueta <html>. Los 4 más recomendados de utilizar (siempre que no estemos trabajando con HTML 5), son:
<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN” “http://www.w3c.org/TR/html4/strict.dtd”>
<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3c.org/TR/html4/loose.dtd”>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3c.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<!DOCTYPE html PUBLIC”-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3c.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
La diferencia de utilizar una de las 4 formas anteriores depende primero de si estamos utilizando HTML o XHTML para codificar (las 2 primeras para HTML y las 2 últimas para XHTML) y de si estamos utilizando la versión Strict o la Transitional del lenguaje. La diferencia de lo último depende si queremos permitir el uso de etiquetas que estén descontinuadas de versiones anteriores del lenguaje (Strict no permite, Transitional si). Más allá de eso, cualquiera de las 4 es correcta.
Esto corresponde a una buena práctica, y si bien es un comportamiento adoptado y adaptado por la gran mayoría de diseñadores Web, siempre hay por ahí algún caso que cae en el error, por lo que es bueno recordarlo.
Con la popularización de CSS, y la descontinuación de etiquetas de estilo (como font face) en HTML, se buscaba hacer una separación completa y absoluta entre el estilo de los documentos Web y su estructura, por lo que al aplicar un estilo dentro de una etiqueta en particular caemos en lo que tanto se ha intentado evitar. Para muestra, un botón (aunque no es un botón realmente, sino que más un ejemplo):
Esto es incorrecto:
<p style:=”color: black; font-family:Arial;”>Texto de ejemplo</p>
Esto es correcto:
En una hoja de estilo externa, declarar:
p{
color:black;
font-family:Arial;
}O bien, en la misma hoja de estilo externa, declarar:
.estilo1{
color:black;
font-family:Arial;
}Y luego, en nuestro HTML:
<p class=”estilo1″>Texto de ejemplo</p>
De esta forma, separamos completamente la estructura del estilo, realizandolo de forma correcta y ahorrándonos bastante tiempo al momento de hacer modificaciones.
Este es un error en el que personalmente he caído bastante, con las librerías en Javascript, pero vamos por parte:
Lo recomendable para las hojas de estilo externas en CSS es siempre cargarlas al inicio del documento, entre las etiquetas <head> y </head>. Esto nos asegura tanto una carga más rápida de la página propiamente tal, como asegurar que siempre los estilos se carguen junto al documento y no luego de que se ha cargado el contenido, ya que si el usuario detiene la carga de la página, o su conexión se cae, se desplegará el contenido sin ningún estilo aplicado, entregando una experiencia visual bastante mala.
Lo correcto es:
<head>
<title>Mi sitio Web</title>
<link rel=”stylesheet” type=”text/css” href=”estilos.css” media=”screen”>
</head>
Por otro lado, las librerías en Javascript es todo lo contrario. Lo recomendable en este caso es incluirlas al final del documento, para que las cargas las realice cuando el contenido ya se depliegue en pantalla. ¿Por qué?, porque normalmente un documento Web no se seguirá cargando mientras una parte de el no se termine de cargar (enredado ¿no?). Considerando que las librerías en Javascript pueden llegar a tener un tamaño mayor al mismo documento, es muy probable que la carga se tome algunos instantes para poder seguir, por lo que a no ser que sea estrictamente necesario (por ej. si una librería determina como se despliega el sitio en si), lo más conveniente es cargarlas al final, y de esta forma presentarle el contenido al usuario lo más rápido posible para que este pueda empezar a navegar, sin necesitar que se cargue todo el documento.
Un ejemplo sería así:
</div>
<script type=”text/javascript” src=”libreria.js”>
</body>
</html>
La librería se cargara de cualquier forma, pero se le dará una mayor prioridad al contenido y estilo de la página.
Esta es una frase que debiésemos grabarnos a fuego. Todos los navegadores despliegan documentos Web de forma diferente. Es uno de los grandes problemas que nos cuesta comprender, especialmente cuando estamos empezando. Debido a que todos los navegadores son distintos, han sido codificados por empresas diferentes, usan motores que no son iguales a otros (excepto navegadores de la misma familia, como Firefox y Flock), el contenido, o más bien el estilo de este, es interpretado de distintas formas por cada uno de ellos.
Como tal, junto con asegurarnos de siempre probar nuestros diseños en todos los navegadores posibles (nunca podremos asegurar compatibilidad completa con todos, pero si debemos cubrir los más comunes), es esencial definir hojas de estilo para cada uno de ellos e indicarle al documento que junto con detectar el navegador, cargue el estilo correspondiente. El mayor problema es comunmente Internet Explorer, ya que hay muchos estilos que no reconoce, especialmente entre sus distintas versiones (6, 7 y 8 ), por lo que podemos hacer lo siguiente. Dentro de nuestra inclusión de hojas de estilo, añadimos una pequeña excepción para que si el navegador es IE, cargue la hoja de estilo correspondiente:
<!– [if lte IE 7]>
<link rel=”stylesheet” media=”screen” type=”text/css” href=”estiloie7.css”>
<!– [endif]–>
El código anterior indica que si el navegador es IE 7 o alguna versión inferior, entonces cargue la hoja de estilo correspondiente. Esto lo definimos con el parámetro lte, el cual significa less than or equal (menor a o igual a). En caso de solo querer cubrir versiones anteriores a IE 7, cambiamos el parámetro por lt.
Hoy en día, con toda la información disponible en Internet, es posible para los diseñadores y desarrolladores Web contar con un gran número de librerías de acceso libre y gratuito para utilizar en sus sitios. Sin embargo, muchas de estas librerías requieren ser cargadas desde sitios Web de terceros, lo que inevitablemente aumentará el tiempo final de carga de nuestro sitio y por ende empeorará la experiencia del usuario.
Es por esto, que en lo posible, lo recomendable es tener todas, o el mayor número posible, de librerías y hojas de estilo en el mismo servidor donde está el sitio, para que la carga se haga de forma local y mucho más rápida.
Un detalle comunmente pasado por alto son los atributos de descripciones a las imágenes que incluímos en nuestros sitios Web. Si bien al no añadirlas nada sucede y el contenido se despliega de forma correcta, si es necesario incluirlas para efectos de mejorar la accesibilidad de cada página y para el momento de la validación del código. Es importante recordar que los sistemas de navegación para no videntes reconocen este atributo de las imágenes para explicar el tipo de contenido que está ahí, así que a no olvidarlo:
Esto no es correcto:
<img src=”imagen.jpg”>
Esto es correcto:
<img src=”imagen.jpg” alt=”Una imagen cualquiera”>
Adicionalmente, hay algunos navegadores que en vez del atributo alt, reconocen title, por lo que nunca está demás agregar ambos.
HTML o XHTML, es 100% acerca de tener una estructura ordenada y definida en cada documento. Y como tal, siempre debemos asegurarnos de que cada etiqueta que abramos, sea cerrada. No importa si los navegadores obvien en algunas ocasiones este tema, es nuestro deber asegurarnos que todo esta abierto y cerrado como y cuando corresponde. De esta forma, nuestro sitio validará de mejor forma y nos haremos un gran favor al momento de realizar edición de código o bien si estamos realizando un trabajo colaborativo, para que otras personas sepan siempre donde empieza y donde termina cada parte del documento.
Esto no es correcto:
<p> Un párrafo de texto
<p> Otro párrafo de texto
<p> Y otro másEsto es correcto:
<p> Un párrafo de texto </p>
<p> Otro párrafo de texto </p>
<p> Y otro más </p>
Con XHTML además, tenemos la posibilidad de cerrar la etiqueta en la misma de apertura y es considerado una práctica correcta:
<br /> -> Una etiqueta abierta y cerrada.
Este corresponde más a un tip gráfico que Web, pero considerando que normalmente incluímos un gran número de imágenes en nuestros sitios Web, no está demás remarcar.
El formato más común para tratar imágenes es JPG, es de los más utilizados, pero no por eso el mejor. La verdad es que cada vez que manipulamos una imagen en formato JPG, ya sea al abrirla, editarla, cambiarla de tamaño, añadirle algo encima, o lo que sea y la volvemos a guardar, esta va perdiendo calidad, y así sucesivamente cada vez que trabajemos sobre ella, por lo que si estamos realizando constantes modificaciones, después de un tiempo la imagen será de una calidad notablemente inferior a la original.
Por esto es recomendable el uso de PNG, que es un formato que se encarga de mantener la calidad a través de los distintos cambios, algo a tener muy en cuenta, especialmente si trabajamos con imágenes de gran resolución o si son nuestra fuente primaria de trabajo (por ej. si tenemos un sitio con un portafolio de trabajos gráficos).
Adicionalmente a esto, al utilizar PNG, una técnica bastante buena para utilizar en imágenes que vayamos a desplegar en la Web, es guardarlas con entrelazado. ¿Qué significa esto?, bastante simple. El entrelazado añade características a la imagen para que esta se cargue de forma distinta a que si se guardara convencionalmente.
Por ejemplo, si tenemos una imagen sin entrelazado y la insertamos en un documento Web, la carga de esta se realizará de forma vertical, de arriba hacia abajo. Con esto, si la conexión es lenta, o la imagen muy grande, se irá viendo como se carga, trozo por trozo, de arriba hacia abajo.
Por otra parte, con el entrelazado, la modalidad de carga cambia, y en vez de realizarse de forma vertical como el caso anterior, esta se va realizando por capas, desde el fondo hasta el frente de la imagen, cargando en una primera etapa la imagen completa, viéndose como si estuviese pixeleada y eventualmente cargando capa tras capa encima de esta, de cierta forma despixeleándose. Con esto, el contenido de la imagen puede ser apreciado antes que termine de cargarse, y por lo general se muestran de forma mucho más rápida que de forma convencional.
Cuando empecé a meterme de lleno en el diseño Web, hace unos 10 años, la mayoría de los sitios eran diseñados utilizando 2 técnicas: Frames o marcos y con tablas.
Ámbos métodos eran bastante útiles, ya que permitían hacer una organización del contenido de forma sencilla y bastante rápida y ordenada. Por una parte los frames nos permitían separar el sitio en secciones y trabajar cada una de ellas mediante archivos independientes y por otra, las tablas, nos permitían definir una estructura segmentada y ordenada mediante filas, columnas y celdas, detallando contenido en ellas tal como si fuese un rompecabezas.
Sin embargo, con el tiempo y evolución que ha tenido HTML, hace bastante que no es visto con buenos ojos definir el diseño de un sitio mediante alguna de estas 2 técnicas, y es recomendable hacer el uso de bloques (o div’s) para hacer el diseño propiamente tal, utilizando posicionamientos en CSS y dejar las tablas solamente para presentar información tabulada.
Sin duda que el dominar de forma correcta el uso de bloques puede ser tremendamente complejo al compararlo con lo que hacíamos mediante tablas, pero a medida que se va teniendo un mejor entendimiento de como funcionan es posible alcanzar un mejor grado de ubicación de cada componente, así como un orden ideal.
Es por esto que si sus sitios están actualmente diseñados bajo una estructura de tablas, es recomendable empezar a actualizar los conocimientos y hacer los traspasos necesarios, todo con el fin de tener un sitio mejor adaptado a lo que hoy es considerado correcto.
Dejamos al final un punto que tiene tanta o más importancia que los anteriormente mencionados, que es el tema de la validación.
Cuando hablamos de validar un sitio, nos referimos a inspeccionarlo con el fin de determinar que toda la codificación haya sido hecha de forma correcta, y de esa forma asegurarnos que cada navegador verá exactamente lo que queremos mostrar. De esta forma podemos asegurarnos que los usuarios tendrán una buena experiencia visualizando el sitio y también ayudaremos a que los buscadores indexen de mejor forma en sus resultados.
Para validar tenemos varias opciones, como por ejemplo:
Adicionalmente existen otros sitios que validan nuestro código, pero con lo anterior podrán hacerlo sin problemas.
Y con este último punto damos cierre a esta práctica guía para optimizar tu sitio Web en tan solo 10 pasos. Al ir terminando nos hemos dado cuenta de algunos importantes que se nos quedaron fuera y que es importante recalcar, por lo que probablemente en un futuro cercano haremos una continuación sobre este tema, que sin duda a muchos les servirá.
Por ahora lo dejamos hasta aquí, recordando como siempre que este tutorial ha sido:
Cualquier comentario o duda que puedan tener, los invitamos a dejarnos unas líneas en el área habilitada a continuación.
Esperamos que este tutorial haya sido de utilidad para Uds.
Muchas gracias por leer y será hasta una próxima oportunidad
8:25:41 am
Muy buenos los tips. Gracias 🙂
1:33:22 pm
Gracias 5 estreyas oye Xabadu o alguien del equipo CLH podrian hacer un tuto de como hacer para que en tu web tenga un enlace de “donaciones” a paypal ?
1:35:43 pm
Hay perdon nose porque se puso todo eso yo solo copie tu nombre omg
1:43:53 pm
@helljanemba: No te preocupes, editamos el comentario.
Veremos el tema de Paypal para hacer un tutorial al respecto.
Saludos!
6:39:00 pm
Hola xabadu
Como lo hago – Cómo aprender a programaer y no morir en el intento
La verdad excelente tutorial.. aprendi mucho con lo que vos haces…
Quisiera saber si esto sigue en pie ya que quedo en la Parte Nº10 y hace rato que no scas la Nº11???
Desde ya gracias en espera de una respuesta rapida y satisfactoria
10:34:21 pm
a marcadores!
en algun momento me va a servir 😉
6:23:06 pm
Muchas gracias !!, excelente información de verdad, hacen falta más post’s como este en la red, porque es de muchisima utilidad y puedo dar fé de que estos consejos son realmente eficaces.
Un saludo y feliz año 2010 a todos !!
Os hago un trackback desde un blog para webmasters novatos apuntando a esta información 😉
6:10:14 pm
[…] algún tiempo publicamos un artículo con tips sobre como optimizar nuestros sitios Web. En esa ocasión recalcamos el hecho de que hubo algunos puntos que se nos escaparon o que […]
11:38:06 pm
Te felicito por el tuto.. esta muy bueno 🙂
Fuerza chile!
4:15:57 pm
Puedes encontrar más información sobre técnicas de optimización Web (WPO) que mejorarán la experiencia de tus usuarios y te permitirán ahorrar en recursos, todo ello en el blog de Funomy en http://www.funomy.com/blog
Esperamos que os resulten interesantes.
Saludos.