Como mejorar la velocidad de carga de mi página web

Tal vez ya estés cansado del tema del aumento de la velocidad de carga del sitio, es por eso que he escrito sobre la optimización de la velocidad, así como añadir algunos puntos importantes, que permiten reducir la carga en el servidor del hosting utilizando la compresión Gzip estática y no dinámica.

Cómo acelerar la carga de una página web

Todo el proceso de optimización de la velocidad, en mi opinión, debería comenzar con la instalación de Page Speed. Este complemento para Firefox o Chrome le permitirá conocer en profundidad la velocidad de carga de su sitio web y le dará valiosos consejos para mejorarla.

La primera vez que ejecuté Page Speed en la página de inicio de mi blog, vi una triste imagen. Sólo 72 puntos de 100 posibles y un montón de observaciones marcadas en rojo. Sin embargo, he seguido casi todas las recomendaciones que me dio y la página principal ha obtenido una puntuación más alta de 94 puntos.

Compresión estática Gzip para reducir la carga del servidor

En primer lugar, Gzip en un servidor utilizando el método tradicional de activación de Gzip (descrito en este artículo Cómo activar la compresión Gzip con .htaccess) se ejecutará en tiempo real, es decir, de esta manera hemos implementado el archivado dinámico. ¿Qué significa?

La cuestión es que para cada nuevo usuario que abra las páginas de su sitio, se producirá un repetido archivo sobre la marcha de los archivos Html, Css y Js. Como comprenderá, en primer lugar, esto llevará algún tiempo, y, en segundo lugar, la compresión sobre la marcha consumirá recursos adicionales de la CPU del servidor.

Mi situación con la carga del blog es bastante deplorable - me balanceo al borde de una falta. Por lo tanto, cualquier oportunidad de reducirla, sin que suponga una disminución de la velocidad de carga del sitio, será muy útil.

Esta paja, a la que decidí agarrarme, fue la compresión estática Gzip de Html, Css y Js, que se lleva a cabo de antemano, y los usuarios reciben archivos listos, sin ralentizar la velocidad y crear una carga innecesaria en el hosting del procesador.

Esto es especialmente cierto para los scripts y estilos externos (Css y Js), porque casi nunca se modifican, pero se archivan repetida e inútilmente sobre la marcha, cada vez que se abre una página de su recurso. Sería mucho más lógico cargarlos en Gzi, y dejar que el servidor web haga el trabajo.

Dada la diferente percepción que tienen algunos navegadores de las extensiones de archivo .gz (archivos Gzip) se suele utilizar una forma bastante inteligente de renombrar los archivos en los estilos habituales con la extensión .CSS y scripts.

Y se añadirán líneas al .htaccess explicando al servidor web cómo servir estos archivos a los distintos navegadores. En general, un esquema tan complicado funciona y por lo tanto voy a describir en detalle todos los pasos para preparar los archivos Gzip y dar el código para el .htaccess.

Por lo tanto, los siguientes pasos deben ser realizados por usted para todos los estilos y scripts externos, que se cargan con las páginas de su sitio. Para evitar la pérdida de datos en caso de error, asegúrese de copiar todos los datos en su ordenador (lea más en este artículo sobre la copia de seguridad de la base de datos y los archivos).

Por lo tanto, tendrá que descargar en su ordenador todos los archivos Css y Js externos, que intervienen en la carga de las páginas (después de haberlos fusionado, no será difícil) y crear una copia de archivo de cada uno de ellos con extensión .gz. Puedes hacerlo con el programa gratuito 7zip. A continuación, déjame mostrarte un ejemplo, ya que no tiene sentido teorizar aquí.

Tomemos como ejemplo el archivo style.css básico de mi blog. Después de empaquetarlo en Gzip con 7zip, tengo un archivo style.css.gz.

Pero como algunos navegadores no quieren incluir un archivo de estilo con una extensión .gz, le quitamos la terminación .gz y acabamos con style.css de nuevo, pero que en realidad es un archivo (¿aún no te has confundido?).

Pero no bastará con sustituir el archivo original style.css en el servidor (aún no comprimido en Gzip) por el archivo que acabamos de crear, pero que sigue llamándose style.css.

Algunos navegadores todavía no soportan la compresión (normalmente las versiones más antiguas que todavía utilizan los usuarios), así que junto a style.css, que en realidad es un archivo (recuerda que le hemos quitado la extensión .gz), tendremos que poner el archivo de estilo original sin comprimir.

Pero lo nombraremos de forma diferente a style.css. Para ello, puede cambiar su nombre, por ejemplo, de la siguiente manera: style.nogzip.css. Ahora tendré dos archivos de estilo en el servidor en la carpeta del tema de WordPress:

style.css - archivo con la extensión .gz cortada

style.nogzip.css - un archivo de estilos sin comprimir, que deberá entregarse a los navegadores que no admitan la compresión

Tendrá que hacer esto para todos los estilos y scripts externos (Css y Js) que se cargan con las páginas de su recurso. Sólo tenía cuatro: la hoja de estilos principal, en la que también tengo añadidas algunas propiedades del plugin de WordPress, así como un archivo de script de la carpeta del tema de diseño y dos scripts externos del plugin SyntaxHighlighter.

Ahora para hacer que la compresión estática para los estilos y scripts externos funcione, necesitas abrir para editar el .htaccess de la carpeta raíz de tu recurso y reemplazar el código responsable de Gzip con el siguiente código modificado:

<IfModule mod_rewrite.c>

 RewriteEngine On

 RewriteCond %{HTTP:Accept-encoding} !gzip [OR]

 RewriteCond %{HTTP_USER_AGENT} Konqueror

 RewriteRule ^(.*)\.(css|js)$ $1.nogzip.$2 [QSA,L]

</IfModule>

<IfModule mod_headers.c>

 Header append Vary User-Agent

 <FilesMatch .*\.(js|css)$>

 Header set Content-Encoding: gzip

 Header set Cache-control: private

 </FilesMatch>

 <FilesMatch .*\.nogzip\.(js|css)$>

 Header unset Content-Encoding

 </FilesMatch>

</IfModule>

Si al renombrar los archivos originales de estilo y script utilizó nombres distintos a style.nogzip.css, deberá sustituir la máscara $1.nogzip.$2 por la suya en la línea de código correspondiente. Básicamente, eso es todo.

Ahora el servidor no comprimirá Css y Js sobre la marcha cada vez, sino que enviará a los navegadores una copia de su archivo comprimido antes, o, en caso de un navegador que no entienda Gzip - la versión original de un archivo como style.nogzip.css.

En persona será un ligero aumento de la velocidad de carga del sitio y la reducción de la carga de su recurso en el hosting. Aquí es sólo un par de días más tarde tuve una vergüenza. Al parecer, la memoria caché de mi navegador se ha borrado y el área de administración de WordPress ha cambiado drásticamente: el diseño del estilo se ha caído.

Pero el problema se solucionó bastante rápido con las manipulaciones descritas anteriormente con el archivo de estilo utilizado en el panel de administración. En mi caso fue colors-classic.css de la carpeta:

/wp-admin/css

A continuación, quería aplicar la compresión estática Gzip a los archivos Html, que también son comprimidos por el servidor sobre la marcha, creando una carga adicional. Aquí es donde encontré una solución bastante sencilla, aplicada a WordPress. El caso es que llevo mucho tiempo utilizando el plugin de caché Hyper Cache.

En su configuración hay un área llamada "Compresión", que inicialmente pensé que era responsable de compactar las páginas en caché en el disco duro del hosting. Me pareció que el archivo de las páginas en caché consumiría un tiempo innecesario del procesador, y lo he desactivado con seguridad.

Pero después de buscar un poco sobre el tema de la compresión Gzip de las páginas Html, he cambiado de opinión sobre estos ajustes de compresión en el plugin Hyper Cache.

Parece que al marcar esta casilla "Activar la compresión", estamos activando la precompresión de las páginas del blog almacenadas en caché mediante el algoritmo Gzip.

No puedo asegurarlo, pero después de activar la compresión en la configuración de Hyper Cache he visto una disminución de la carga en el servidor durante mucho tiempo. En definitiva, parece que siempre ha sido un camino de rosas.

Por cierto, si su proyecto está basado en Joomla, tiene algunos componentes muy buenos (según los usuarios), lo que permite el máximo uso de mis formas descritas para mejorar la velocidad de carga del sitio, pero será mucho más fácil, porque mucho se hace de forma automática con el mínimo esfuerzo para su configuración.

Optimización de los gráficos y reducción del número de solicitudes

La optimización de los gráficos también puede tener un impacto muy significativo en la velocidad de carga. Como he escrito antes, puedes optimizar las imágenes en Page Speed. Pero esto sólo será útil en el caso de un número reducido de ellos.

Personalmente, he utilizado el servicio en línea PunyPNG para la optimización de lotes, que ya ha escrito en detalle. También puedes utilizar otro servicio de compresión de fotos online muy popular de Yahoo.com: Smush.it. Pero encontré que el grado de compresión de las fotos en PunyPNG es mayor, probablemente debido al uso de mejores scripts.

Copié una carpeta con las imágenes de mi blog a mi ordenador y las subí todas (en paquetes de 15, ya que PunyPNG tiene esa limitación) a este servicio online, y luego descargué un archivo compartido que contenía imágenes ya optimizadas de mi blog.

En general, después de pasar media hora, conseguí comprimir las imágenes PNG en un 7 por ciento de media, y las Gif y Jpg en un 5 por ciento.

Como resultado, el tamaño total de todas las imágenes utilizadas en mi blog disminuyó en varios megabytes, lo que sin duda aumentará la velocidad de carga del sitio y reducirá ligeramente la carga del servidor de hosting.

Por último, y una de las formas más efectivas de acelerar, puede ser reducir el número de peticiones http, que se formarán al cargar las páginas de su recurso. Se pueden reducir reduciendo el número de objetos que se descargan junto con la página web. Ya hemos hablado al principio de este artículo sobre la combinación de archivos CSS y Js externos sólo para este propósito.

Pero la parte de las solicitudes siempre va a la carga de gráficos. Pueden ser imágenes de fondo que se han mencionado en el archivo de estilo o imágenes especificadas directamente en el código Html de la página.

Para reducir su número, hay que analizar si es necesario cargar tal o cual imagen con la página. De este modo, me he librado de un par de docenas de peticiones http innecesarias. Las mismas imágenes de fondo de la plantilla, que todavía será necesario para el funcionamiento de su recurso, puede combinar los llamados sprites CSS. Como resultado, en lugar de docenas de solicitudes para hacer sólo una.

Ya he empezado a pensar en un paso tan radical como hacer mi blog casi estático, con los archivos Html habituales en la carpeta raíz, y todo el motor de WordPress se ejecutará en una carpeta separada. De este modo, la carga se minimizará.

Es posible realizarlo en WordPress con la ayuda de un plugin milagroso Really Static. Es cierto que su versión aún no ha madurado hasta la unidad, pero los comentarios sobre su trabajo fueron exclusivamente positivos.

El precio por reducir la carga será la pérdida de algunas funcionalidades, pero creo que con una adecuada configuración de actualización de la caché (en este caso serán páginas Html normales, como los sitios de principios de este milenio) será posible minimizar todas esas desventajas.