WPO básico

Hoy, uno de nuestros estudiantes en prácticas, Luis Blanco, que llega del ciclo superior de Administración de Sistemas Informáticos en Red del IES Guadalpín, se ha propuesto enseñarnos cómo podemos mejorar el rendimiento de nuestra página web sin plugins y sin opciones complejas. Para ello hemos elegido uno de los proyectos en los que somos socios: farmacia bio.

Mejorando el rendimiento WPO de farmacia.bio

Farmacia Bio es una página la cual ofrece un servicio online sobre la venta y el envío de preparados medicinales, suplementos, aromaterapia, etc. Con un gran número de productos y secciones, esta web es bastante pesada y grande (los archivos hablan por si solos). Pero siempre que se abre una web desde un navegador el tiempo de carga es bastante importante.

Teniendo nuestra web ya preparada, todo completado, ordenado, listo para salir a las primeras búsquedas de Google, bum! “DEMASIADO LENTO” habrán gritado mucha gente al intentar abrir la pagina web desde un navegador web o móvil. Y no es problema de nuestro Internet, sino de la web que tarda años en cargar.

Puede ser la mejor del mundo, pero una página web que tarda demasiado en cargar no tiene éxito, nos aburrimos de esperar tanto para que cargue, y posiblemente eso ya sea nuestro mayor enemigo.

4 de cada 10 internautas abandonan una Web si tarda más de 3 segundos en cargar. [Via]

De ahí nuestro objetivo:

• Mejorar y minimizar el tiempo de carga de nuestra pagina web.
• Optimizar imágenes.
• Comprobar caché.
• Mejorar nuestros ficheros internos (CSS, java…).
• Intentar hacer todo eso sin usar plugins.

Por supuesto para esto, usare un servidor diferente que este vacío y haré una “página espejo” u clon de la propia para en caso de error o de testeo, no afecte para nada a la original. Aún así testearemos las mejoras una a una para ver como afectan.

¿Qué se va a hacer?

Empezaremos primero con un breve resumen de lo que significa nuestra pagina web tal y como esta. Sin ningún tipo de optimización. Haré capturas de cada testeo importante y lo iré explicando poco a poco

Y bueno, ¿Todo esto que significa?

Iremos por partes. He usado tres páginas web para que me den un informe detallado de como de optimizada es la web, estas paginas web son (por orden):

• https://gtmetrix.com/
• https://tools.pingdom.com/
• https://developers.google.com/speed/pagespeed/insights/

El único detalle es que cada página web tiene su propio servidor, el cual estará situado en un país que posiblemente este bastante lejos, por lo que los resultados pueden variar de una página a otra. Por ejemplo, gtmetrix usa un servidor en Canadá, mientras que pingdom nos deja usar un servidor mas cercano como el que esta en Estocolmo, y en insights de Google no sabemos cual de sus servidores esta usando

Ahora nos centraremos en arreglar esos errores que estas páginas nos han dado, tales como los mencionados en los objetivos a mejorar de la pagina, empezaremos por la caché del nuestra página web.

Mejorando caché

Lo primero sería explicar que es la caché y como funciona en una página web.

La caché es un bufer de memoria, el cual funciona casi igual que la memoria principal, la diferencia que hay es que es mas rápida, y se utiliza por el microprocesador para reducir el tiempo de búsqueda de datos. Esto asociado a la página web hace que los datos que nosotros queramos sean almacenados o no en esa caché y por cuanto tiempo, así la primera vez que una persona entre en la página web descargará todos los archivos, pero al entrar una segunda vez solo tendrá que descargar una mínima parte por que todo o casi todo estará ya en la caché.

Para conseguir eso, tenemos que modificar nuestro ‘.htaccess’ de nuestra página web y añadir el código.

Recomendamos tener una copia extra de los archivos ‘.htaccess’ y ‘functions.php’ de la theme de tu wordpress en caso de que haya algun error. De ser así, tendreis vuestras espaldas cubiertas

El código lo he dividido tanto en módulos como en archivos directos de la cabecera (por si acaso). Esto lo que hace es que da una prioridad y guarda las imágenes (jpg, jpeg…) por un año. Los css, html, pdf, javascripts por un mes y así con los archivos que queramos y el tiempo estimado.

Por motivos legales, no es recomendable usar mas de un año.

Ley de Protección de Datos (LOPD)

El segundo código es igual, pero solo asociado a la cabecera de la pagina web, así todos los elementos de la cabecera se guardaran por el tiempo máximo establecido en segundos. Ya que primero queremos que se cargue la cabecera de la pagina web, y después el resto de la página.

Todo estos datos, pueden ser guardado desde un segundo, un día, una semana, mes o año, dependiendo de la importancia que le de el usuario a sus archivos, tras búsqueda de información he llegado a la conclusión que la forma más óptima es la que he mostrado arriba en la imagen.

Comprobamos la optimización hecha de la caché con las paginas web nombradas anteriormente.

Como se puede comprobar, ha habido un cambio notable, y uno de los problemas que aparecía en esta página web ya no esta. Comprobemos ahora con las otras páginas si ha habido también un cambio mínimo.

Vemos que aquí también ha habido un pequeño cambio, y ha incrementado la calidad de la página referente al tiempo de carga, y que la F que salia antes ya no está

También vemos que en insights de Google también hay un pequeño cambio y las notas suben, pero aún queda algunos problemas por resolver.

Con esto pasamos al segundo problema, que es el ‘Defer parsing of Javascript’. Pero, ¿qué es esto?

‘Defer parsing of Javascript

El Defer parsing of Javascript es un problema común que pasa en las páginas web, el cual ralentiza y se nota bastante. En una página web como es lógico primero carga la cabecera, después el cuerpo y así hasta abajo del todo, ahora bien, si hay un javascript que llama a algún objeto pesado o que este tarde mucho en cargar, hasta que no termine no sigue hacia delante, mantiene el orden. Arreglando esto lo que dice es: “Los javascritps, hasta que no se cargue todo lo básico, no os carguéis y dejad que lo que menos peso tenga, vaya primero” así manteniendo el orden, pero dejando eso al final, habrá objetos que cargue mucho antes el cual no podían antes por que había un java bloqueándolo.

Y ¿cómo se arregla esto? Como hicimos en el anterior, habría que meter un código en el archivo ‘functions.php’ en nuestra carpeta de ‘wp-content’

Una vez incluido el código en nuestro archivo comprobamos si ha funcionado haciendo otra búsqueda de nuestra página web.

Como podemos comprobar el tiempo de carga de la página sigue bajando poco a poco, y que nuestro problema de ‘Defer parsing of Javascript’ esta casi al 100% solucionado

Como se puede comprobar aquí ya no hay mejoras, puesto que dice que ya esta casi optimizada al máximo.

Aquí tampoco se aprecia tanto el cambio aún así son detalles que se tienen que tocar, y por mínimo que sea, cualquier optimización es siempre asequible para la mejora de una página web.

A partir de aquí cada pagina da su propio informe sobre la página web, y cosas que en un sitio están perfectas, en otra no lo esta. Cosas que se pueden mejorar, están optimizadas al 100% en otras.

Así que ahora procederemos a optimizar cosas especificas de los consejos y recomendaciones que nos dan los informes de nuestra página.

Minimización de CSS y Javascript

Empezaremos por la minimización de CSS y Javascript, buscaremos una manera de comprimir la página para que pese menos, buscaremos una manera de optimizar las imágenes aunque no es un caso excepcional o de máxima prioridad.

Compresión GZip

Ahora empezaremos a optimizar partes individuales. Empezando por la compresión del wordpress, para ello habría que habilitar la compresión Gzip en el ‘.htaccess’, para los que no sepan lo que es Gzip, es una compresión de la pagina web (no se debe confundir con Zip, aunque su función es casi igual): Lo que hace es comprime casi toda la página, HTML, CSS y Javascript mayoritariamente menos las imagenes (de ahí que las imágenes tengan que ser optimizadas por su cuenta) y añadir el siguiente código.

En el caso de que no sea compatible la compresión Gzip, dejaremos todo en modo comentario ‘#’ para que no afecte, y así cuando sea posible la compresión solo habrá que quitar el modo comentario. Aunque hoy en día casi todas las páginas son compatibles y es muy recomendable usarlo.

Minimizar (a.k.a. Minificar) javascript

Lo siguiente que haremos sera minificar la carga de Javascript, para ello usaremos este código, haciendo que primero cargue las cosas que están por encima de la mitad de la pantalla (normalmente, lo que suele abarcar una pantalla normal), y después hace que cargue el resto, así primero cargue lo primario y después que cargue lo de abajo ya que para verlo hay que hacer scroll hacia abajo.

Esto solo hace que funcione con Javascript y habría que buscar algo para que también funcionase con algún CSS, ya que queremos lo mismo que con el Javascript, para ello habría que tocar cada archivo de estilo que hay en nuestra página web y mirar que se puede optimizar.

Para los CSS, no tocaremos ni el CSS del core ni los CSS implementado en los plugins, así que sólo tocare lo mayormente posible a mi disposición que serán los que están en la pagina principal y los productos.

Con esto podemos mejorar bastante el rendimiento de nuestra web, pero estas dos cosas tanto minificar la carga de los CSS y de los Javascript es algo puntual que te lo dice Google insights, pero es una regla muy estricta que te da, por lo que no es obligatorio al 100%.

He probado a usar un plugin para arreglar el bloqueo de CSS y Java, pero lo único que hizo fue ralentizar la pagina por 1.5 segundos. Así que eso queda totalmente descartado. (De ahí que no se el jefe me haya pedido que no usemos plugins de “optimización” en los wordpress)

Al no servir los plugins me dispongo a hacerlo de forma manual mediante las herramientas de desarrollo que nos da Firefox, y haremos las modificaciones en directo.

Para ello simplemente vamos a minificar todos los archivos de CSS que hay en la ‘frontpage’.

Minimizar (a.k.a, minificar) CSS

Esto seria nuestros CSS dentro de la página y así es como se ven. Para poder comprimirlos y que ocupen menos usaremos una herramienta de internet el cual nos facilitará la compresión.

Como se puede observar, lo que hacemos es copiar el propio estilo en la página y este nos lo comprime. La compresión consta de quitar los espacios innecesarios, los espacios después y los retorno de carro. También se puede observar lo que ocupaba antes el archivo y lo que va a ocupar ahora, también nos facilita un porcentaje para saber cuanto hemos ‘ahorrado’ con el proceso que vamos a hacer. Esto se haría a cada .css de la página principal para que ocupe tanto espacio y no ralentice nuestra página web.

http://csscompressor.com/

Por último se coloca de nuevo en la ventana correspondiente, y vemos que ahora todo esta en una linea en vez de estar “de forma bonita” pero así nos quitamos peso encima. Nos podemos fijar que ninguna regla se ha modificado y esta todo en orden.

Por último quedaría optimizar las imágenes, en este caso se pueden usar algún programa para minificar el peso y el tamaño de las imágenes, o usar Photoshop. Algunas de las propiedades que se pueden usar sería:

• Color indexado
• Minimizar el tamaño, comprobando que el tamaño es el adecuado
• 72ppp (Píxeles por pulgadas)

Después de hacer estos cambios al servidor volvemos a comprobar los cambios, a ver si hemos podido conseguir alguna mejora referente al resultado que nos ha dado el servidor, habiendo minimizado las cargas pesadas de la ‘frontpage’ o de la página principal.

Los resultados serían los siguientes:

No he incluido a Google insights por el hecho de que no da la velocidad de carga del servidor. Pero aun así se pueden notar un poco los cambios hechos.

En resumen, los resultados serian:

Cambio de Servidor

Gtmetrix: 5.8 – 4.7 – 3.7 – 7.3 – 4.5

PingDom: 2.2 – 1.4 – 1.5 – 3 – 1.9

Esto es debido a que el primer byte del server tarda en responder de ahí los tiempos de espera hayan subido notablemente tal y como se puede apreciar en la imagen siguiente.

También, ante un cambio de servidor (que según los técnicos de cybernéticos) estaba obsoleto, el día 20 de Abril hicimos un cambio (upgrade) a este, haciendo que sea más actual y que no tenga tantos fallos, el propuesto de la actualización del servidor es casi obligatorio debido al continuo cambio y a las actualizaciones necesarias para su correcto uso.

Estos cambios suponen un cambio de Sistema Operativo, acctualizando de ‘Debian 6’ a ‘Debian 8 – 64 bits’, el hecho de actualizar este Sistema Operativo es debido a que ‘Debian 6’ esta desfasado, muchas propiedades estan obsoletas, y debido a que es antiguo, apenas tiene soporte y no es nada seguro.

Algunas de las mejoras al actualizar a este servidor son:

• ModSecurity: Protección a nivel de PHP. Lo que viene a ser protección web.
• Suhosin: Sistema de protección avanzado para PHP
• Monitor de Fuerza Bruta: Previene ataques a la zona de administracion de Wordress, mail, FTP…
• BlockCracking y EasySpamFighter: Para luchar contra el Spam
• Mejora de PHP avanzando de 5.5 a 5.6

A continuación hare un resúmen de los cambios mas importantes que no han sido mencionados

• Debian 6 –> Debian 8 64 bits
• PHP 5.4 –> PHP 5.6
• Apache 2.2 –> Apache 2.4
• MySQL 5.5.33 –> MariaDB 10
• Mejora de Seguridad

Ahora tenemos que ver como afecta a nuestra página web, por lo que analizaremos de nuevo nuestro wordpress y proyectaré los resultados.

Como se puede apreciar, estos cambios no han sido muy favorables para nuestra página web, ya que todas las puntuaciones han bajado y el tiempo de espera al servidor han aumentado notablemente hasta el punto de haber una diferencia de más de 3-4 segundos con respecto al servidor antiguo.

Aunque las actualizaciones son casi siempre favorables al servidor en cuanto a seguridad y rapidez, este no ha sido el caso para nuestra página web por lo que habra que mejroar y optimizar al máximo en lo que podamos para compensar este cambio tan drastico que ha habido en el servidor.

CAMBIOS EN LA PÁGINA ORIGINAL

Una vez hecho los cambios en nuestra página clon y visto los resultados pasaremos a hacer los cambios en el servidor original. Hay que tener en cuenta que el servidor es diferente, la cantidad de archivos también por que no he pasado todas las funciones por lo que los resultados van a variar. Aun así el resultado siempre es quitar tiempo de espera para cargar la página.

Empezaremos con los tiempos por las tres páginas mencionadas al principio del informe. Primero ira Gtmetrix, después ira Pingdom y por último Google Insights. No habrá mucha explicación ya que lo que significa cada cosa esta explicada con anterioridad.

Una vez mostrados los resultados de la página procederemos a hacer los cambios que hicimos a nuestra página espejo. Los cambios serán los mismos, especialmente haciendo hincapié a los cambios mas notables como los de caché, orden de carga y mitad superior de pantalla. Las explicaciones están en los cambios, por lo que ahora iré mas rápido a la hora de mostrar los resultados.

El primer cambio se realizará en el archivo ‘.htaccess’ el cual incluiremos las normas de caché y compresión Gzip ya explicadas con anterioridad.

Estos son los cambios de tiempo y puntuación sobre el primer cambio, normalmente este cambio suele ser el mas notable ya que es donde se reside la carga principal de la página web. Ahora lo que cambiaremos sera el archivo de la ‘theme’ de la página llamado ‘functions.php’ el cual esta en la ubicación de ‘wp-content/themes/farmaciabio/’ y ahí haremos los cambios realizados con anterioridad.

Para recordar, los cambios serán: defer of javascript, cargas aplazadas de javascript, la visualización de los CSS y la mejora de la parte superior de la página web.

A continuación mostraré los resultados finales, incluyendo los cambios al archivo ‘.htaccess’ y los cambios del archivo ‘functions.php’ de la theme de la página web.

Y estos serian los resultados finales, la diferencia entre el resultado final de la página espejo y esta es un poco notable aun así he intentado mejorar lo máximo posible dentro de lo que tenía permitido.

Debido al error de no poder manejar las importaciones por culpa de los codigos de Javascripts eliminare los codigos de optimización que hacen uso de tal, por lo que el último paso se cancela ya que lo más importante de la pagina es que pueda importar/exportar correctamente, mas si es algo relacionado con el stock. Por lo que la velocidad media se quedaría en el segundo paso. Es decir con la primera mejora.

CONCLUSIÓN

Hemos conseguido reducir el tiempo que tarda nuestra página en cargar y ¡sin usar ningún plugin!. Con esto nos ahorramos el tener que estar actualizando nuestros plugins cada dos por tres por temas de versión de wordpress o del propio plugin y el peligro que esto supone ya que muchas veces puede desconfigurar nuestra página web.

Junto a lo anexado anteriormente, hemos conseguido mejorar la velocidad de carga de nuestra página web, casi un aumento de 3 segundos, aun así el cambio de servidor puede ser mejorable, aun así he conseguido poder mejorar el cambio. Lo cual es una diferencia notable.

Puntos que se han mejorado:

• Servidor

Mejoras del servidor explicadas con detalle en su apartado

• Caché

Para almacenar archivos en la pagina web y que no tengan que ser descargados cada vez que se entra en la página web

• Compresión Gzip

Comprensión de la página web (HTML, CSS y Javascript)

• Orden de carga de los elementos de la página

Hacer que lo pesado se cargue al final y si algo se bloquea que no pare la carga de la página web

• Optimizar CSS y Javascript

Reducir la carga de los archivos de CSS y Javascript

• Imágenes

Optimizar tamaño y peso de las imágenes