Optimizar la velocidad de descarga de una Web WordPress depende fundamentalmente de dos factores: tiempo de respuesta del servidor de hosting y cómo esté configurado WordPress. Con respecto al primero, debemos contratar el mejor hosting WordPress. Pero después depende de cómo lo configuremos. Este artículo muestra la optimización real de la velocidad de una Web, mejorando 20 puntos en PageSpeed Insights.
Tiempo medio de lectura: 25 min (7.900 palabras).
Si no tienes tiempo ahora, puedes saltar directamente a las conclusiones del artículo.
Tabla de contenidos
Bueno, sí… y no 🙂
Sí, porque en este artículo encontrarás muchos conceptos y recomendaciones que podrás encontrar en prácticamente cualquier otro sobre este tema… Pero esto no es sorprendente: bajo este punto de vista, también se podría decir que todos los libros de mecánica son iguales porque todos mencionan válvulas, carburador, cigüeñal, … 😉
Entonces, ¿qué puedes encontrar aquí que despierte tu curiosidad y te motive a seguir leyendo ávidamente?
Y aquí es donde vendría el “No, porque…”:
Este último punto quizás sea el más importante cuando se trata de optimizar una web WordPress: no existen soluciones universales. Dependiendo del theme y los plugins instalados, o de la instalación específica de WordPress y su configuración, es posible que determinadas optimizaciones entren en conflicto con algunos elementos del entorno. Por este motivo, hay que ser extremadamente cauteloso en cada acción, para revertirla en caso que los resultados no sean los esperados y entonces aplicar alternativas, si las hubiera, con la misma finalidad.
Existen muchas herramientas que evalúan el rendimiento de un sitio web. Entre las más conocidas, además de la que proporciona Google, están Pingdom, GTMetrix, o WebPageTest, las cuales también ofrecen una extensa información y recomendaciones para optimizar el sitio web, bastante más completa, a mi modo de ver, que la que ofrece Google (a veces indescifrable).
Ante tal variedad, ¿cuál deberíamos utilizar para evaluar la mejora de nuestra web con las optimizaciones?
Desde el punto de vista del SEO, el principal objetivo de optimizar un sitio web es reducir su tiempo de descarga para que Google nos posicione mejor, lo lógico sería utilizar la misma métrica que Google utiliza. Esto es, Google PageSpeed Insights.
Sin embargo, esto no significa que debamos ignorar el resto de herramientas, pero inicialmente deberíamos enfocar nuestro propósito en eliminar o reducir los problemas que detecte PageSpeed Insight, y entonces utilizar la información que proporcionan estas otras herramientas para refinar o identificar mejor la causa de alguno de esos problemas.
Antes de empezar con las optimizaciones, voy a describir brevemente el escenario inicial del sitio web sobre el que las apliqué y las motivaciones que me llevaron a hacerlo.
El sitio web, claro, es éste que estáis leyendo 🙂
Está instalado en un WordPress, con 21 plugins, pero de los que sólo están activos 12, los que la web necesita para su funcionamiento (desde formularios a botones de compartir). El resto de plugins son utilidades para mantenimiento o gestión del WordPress, que sólo activo cuando voy a utilizarlas (por ejemplo, para hacer copias de seguridad o renombrar los nombres de las imágenes).
Hace más de dos meses hice una primera optimización de la web, fundamentalmente imágenes y plugins, consiguiendo unos valores PageSpeed de 75-77 para móviles y 86-88 para ordenadores. En ese momento me parecieron buenos valores y no hice nada más, apuntando en mi lista de “cosas-por-hacer” el resolver las incidencias menores que detectaban PageSpeed y el resto de herramientas.
Sin embargo, cuando hace unas dos semanas volví a ejecutar PageSpeed, obtuve valores inferiores: 69-70 para móviles y 80-81 para escritorio. No era algo coyuntural o pasajero, la bajada se mantenía en diferentes momentos del día y en diferentes días. ¿Qué había pasado en el mes y medio intermedio para haber perdido más de cinco puntos en PageSpeed?
Dado que no había cambiado nada en mi entorno WordPress, salvo revisar y añadir contenido tanto en páginas como en posts, lo primero que pensé es que debería ser algo relativo al servidor. Además, el informe de PageSpeed indicada que el tiempo de respuesta del servidor rondaba los 1,5 segundos. Esto era una barbaridad; anteriormente, este valor oscilaba entre 0,7 y 0,8 segundos. Así que, en principio, todo parecía indicar que había algún problema en el servidor:
Con estos datos, me puse en contacto con mi proveedor de hosting WordPress para notificarle la incidencia. Mi proveedor, del que también soy afiliado, es WebEmpresa, toda una referencia en alojamiento WordPress, y que siempre han atendido mis peticiones rápida y eficazmente, incluso en temas de baja trascendencia, por lo que tenía plena confianza en que también lo harían en esta ocasión. Solo desde esta confianza podría haberme suscrito a su programa de afiliación.
Como la web estaba plenamente operativa y tampoco era un desastre el haber bajado unos 5 puntos en el PageSpeed (los valores no eran tan malos y unas pocas horas no afectarían al SEO), hice la petición de baja prioridad. Soy de la opinión que, de esta forma, facilito que se organicen mejor y ofrezcan un mejor servicio final, de lo que todos salimos beneficiados en última instancia.
Aún así, me contestaron en media hora (¡bravo por ellos!), indicándome que no habían detectado ninguna incidencia en el servidor y me invitaron a hacer algunas comprobaciones para corroborarlo.
En esencia, crear un fichero PHP (es decir, fuera de WordPress pero usando el lenguaje PHP) y medir el tiempo de respuesta de su descarga. ¡El resultado fue alucinante!:
Un pleno al 100%, incluido el tiempo de respuesta del servidor, lo que significaba que era inferior a dos décimas de segundo. ¡Imposible más rápido!
Para quien tenga curiosidad, éste era el contenido del fichero PHP utilizado para esta prueba:
<?PHP echo "hola mundo"; ?>
Pero, claro, no es lo mismo descargar directamente un fichero PHP tan sencillo que una página desde WordPress. Así que hice otra prueba más: crear una nueva página WordPress, sin shortcodes ni códigos, sólo texto, y medir su tiempo de respuesta… ¡menos de cuatro décimas de segundo!
Esta última prueba también arrojaba conclusiones muy relevantes. Primero, que el servidor de alojamiento apenas necesitaba una o dos décimas de segundo adicionales para atender la petición de una página WordPress, un valor sorprendentemente bajo. Y, segundo, que el procesamiento y generación de la página por WordPress estaba produciendo una pérdida de 26 puntos. Definitivamente, mi WordPress necesitaba optimización.
Los tiempos de respuesta recabados en estas pruebas también demuestran la importancia de tener el mejor Hosting para WordPress posible. Imaginaos cuál habría sido mi desazón si en estas pruebas hubiera obtenido tiempos cercanos al segundo: por mucho que optimizara WordPress, apenas podría ganar unas pocas décimas de segundos. En cambio, estos magníficos tiempos indicaban que tenía más de un segundo de margen de mejora para optimizar y acelerar mi WordPress: ¡maravilloso!
Como puedes ver, el tener un buen proveedor de Hosting es crucial. Si estás buscando un proveedor de Hosting o estás descontento con el que tienes, ya sea por soporte inadecuado o servidores lentos, te recomiendo que eches un vistazo al Hosting WordPress de WebEmpresa. Sus planes y precios son muy equilibrados y ventajosos, y seguro que alguno se adapta a tus necesidades.
Si finalmente te decides a hacerlo, puedes contratarles a través del siguiente enlace. Además, con el código de descuento “cupon20” puedes obtener un descuento del 20% sobre la tarifa habitual… así, porque tú lo vales 😉
Por tanto, gracias a las indicaciones de WebEmpresa y estas pruebas, quedó meridianamente claro que algo estaba pasando con los plugins, la configuración de WordPress o la base de datos, añadiendo más de un segundo de retardo al tiempo de respuesta del servidor. Había que descubrir el qué.
Y aquí comenzó mi aventura…
Oh, vosotros, los que entráis, abandonad toda esperanza…
Desde este momento, nos estamos adentrando en un páramo tenebroso, donde detrás de cada esquina y recoveco acecha la amenaza que destroce nuestro trabajo de horas, sino días…
Bromas aparte, optimizar WordPress supone modificar muchos elementos de éste, desde plugins hasta hojas de estilo, pasando por la base de datos o porciones de código. Cualquiera de estas modificaciones puede afectar el correcto funcionamiento de nuestro sitio Web y dejarlo inoperativo. Incluso podríamos inhabilitar inadvertidamente el escritorio (dashboard) de nuestro gestor de contenidos favorito, sin posibilidad de interactuar con él.
Por este motivo, la primera tarea es asegurarnos que, en caso de error o desliz, seamos capaces de recuperar nuestra Web en minutos, sino segundos. Y las copias de seguridad son nuestra tabla de salvación ante las puertas de este Infierno…
Como tantas cosas en la vida y en los menús de nuestro restaurante favorito, disponemos de varias opciones para realizar los backups; en este caso, tres posibles platos distintos…
Hay muchos plugins de excelente calidad para hacer copias de seguridad sin tener que salir del panel de control de WordPress. Yo utilizo el XCloner, más que nada porque fue el primero que utilicé y no he tenido necesidad de cambiarlo.
Pero si nunca has usado ninguno (lo que equivale a haber estado conduciendo sin cinturón de seguridad), en este completo artículo de Ignacio Santiago tienes una selección de 10 plugins de backups, junto a una pequeña descripción de sus características, para que puedas elegir aquella que mejor se adapte a tus gustos o necesidades.
Un apunte muy importante: cuando hagas la copia de seguridad, debes hacerla tanto de toda la base de datos como del sistema de ficheros completo. Normalmente, los plugins lo hacen así por defecto, pero asegúrate de que así sea. No queremos que se nos quede nada atrás, ¿verdad?
La principal ventaja de utilizar plugins es que están integrados en WordPress y no necesitas cambiar de entorno para hacer los backups. Además, los plugins incluyen funcionalidades adicionales que pueden serte útiles, como programación automática de los backups, para que no tengas que hacerlas tú mismo a mano periódicamente, o subir el fichero de backup a una cuenta de Dropbox, entre otros muchos.
Sin embargo, el proceso de restauración de un backup no es tan sencillo como darle a un botón, sino que cada plugin proporciona instrucciones detalladas de cómo hacerlo, que debes seguir escrupulosamente.
En algunos casos, como el propio XCloner, es un proceso bastante manual (copiar ficheros, descomprimir ficheros, volver a copiar ficheros, importar fichero, etc., etc.), pero tiene la ventaja de que si sabes qué fichero/s ha/n fallado, sólo tienes que copiar o importar esos.
Para que os hagáis una idea, aquí tenéis un vídeo con una detallada explicación de cómo restaurar una copia de seguridad hecha con XCloner.
La segunda opción es utilizar las herramientas que proporciona el panel de administración de tu sitio web, que puede ser cPanel o Plesk, entre otros. Si no conoces estos entornos o no sabes qué son, mejor que utilices un plugin por ahora, pero ten presente que, en caso de problemas, es muy probable que sólo puedas resolverlo (o restaurar el backup) a través de este panel de administración, así que apúntate como tarea el empezar a conocerlo.
Como mi proveedor de Hosting, WebEmpresa, utiliza cPanel, detallaré cómo hacerlo en este entorno, pero el proceso sería muy similar para el resto de paneles de administración.
De igual forma que en el caso de los plugins, la copia de seguridad debe contener dos cosas: la base de datos y el sistema de ficheros.
El backup de la base de datos se realiza a través de phpMyAdmin, disponible en el área de Base de Datos de cPanel:
Dentro de phpMyAdmin, debéis seleccionar la base de datos de vuestro WordPress (lo más probable es que sólo tengáis una) y pulsar “Export”, dejando las opciones por defecto, que son más que suficientes:
Como resultado de la exportación, phpMyAdmin crea un fichero con extensión “.sql”, que contiene todas las instrucciones SQL necesarias para recrear la base de datos.
Para importar la base de datos, utilizaríais la opción “Import” del menú de phpMyAdmin.
Cuidado: el “import”, como su propio nombre indica, importa los datos del fichero de backup dentro de la base de datos que hayamos seleccionado en el panel izquierdo. Asegúrate, primero que hayas seleccionado la base de datos correcta y, segundo, que hayas borrado todas las tablas de esa base de datos, para que los datos corruptos que han destrozado tu WordPress no interfieran con la restauración:
Ok, ya tenemos el backup de la base de datos, pero también necesitamos una copia de todos los ficheros del sitio web. Es decir, páginas HTML, hojas de estilos, ficheros PHP, imágenes, etc.
Estos ficheros están todos dentro de la carpeta “public_html” del servidor. Para copiarlos, podemos utilizar el Administrador de Archivos del cPanel (o Plesk, o el que tengas):
Una vez dentro del Administrador de Archivos:
También podéis copiar la carpeta “public_html” mediante un cliente FTP (el que más me gusta es FileZilla, muy intuitivo y fácil de utilizar) a vuestro ordenador aunque, si lo queréis comprimido, tendréis que hacerlo vosotros mismos una vez lo hayáis descargado.
La restauración del sistema de ficheros es tan fácil como copiar ficheros en Windows, ya sea con el Administrador de Archivos de cPanel o con un cliente FTP, pero de nuevo con una consideración importante: previamente debes borrar todo el contenido de la carpeta “public_html”, para eliminar todo rastro de lo que haya corrompido tu web.
Aunque el proceso es muy sencillo, puede ser un tanto laborioso. En esta página tienes una guía de cómo restaurar una copia de seguridad a través de cPanel, tanto de base de datos como del sistema de ficheros. Este artículo utiliza la copia de seguridad creada por el plugin BackWPup, pero el proceso de restauración es prácticamente idéntico.
cPanel proporciona una herramienta que nos permite hacer copias de seguridad y restaurar la base de datos y el sistema de ficheros con un solo toque de botón. La ventaja: muy rápido y sencillo, no necesitamos saber prácticamente nada de la estructura interna del sitio web. El inconveniente: por defecto, no se pueden programar copias de seguridad periódicas.
La herramienta nos permite hacer varios tipos de copias de seguridad:
Recordad: la copia de seguridad es vuestro tesoro. Mimadlo, cuidadlo, preservadlo… Como el cinturón de seguridad, a veces es engorroso y molesto, pero el día que os haga falta (Dios no lo quiera), lo agradeceréis.
Hasta aquí la sección de copias de seguridad. He sido un poco extenso en este apartado porque la integridad y continuidad de nuestra web depende totalmente de que estén correctamente realizadas. No continúes con las optimizaciones de WordPress hasta que no estés completamente seguro de cómo se realiza una copia de seguridad completa y cómo se restaura.
Salvo que tengas conocimientos técnicos suficientes, mi recomendación es que te decidas por un plugin de WordPress, asegurándote que entiendas bien su proceso de restauración, puesto que la creación de la copia suele ser siempre muy sencilla.
Ahora empieza la optimización propiamente dicha de WordPress para acelerar su respuesta y que tu sitio web se descargue rápidamente en los navegadores de tus usuarios. Agárrate fuerte porque vienen curvas, algunas de ellas muy cerradas…
¿Por qué el primer paso de la optimización implica a los plugins? Fundamentalmente, porque cambios en los plugins pueden afectar al tratamiento de las imágenes (y su posterior optimización) y a la base de datos. Es lógico, por tanto, acometerlo primero.
Mi propósito: crear un entorno base lo más estable posible, apenas sujeta a cambios, conformada por WordPress y plugins. De esta forma, me aseguro que el resto de elementos importantes estén optimizados al máximo para dicho entorno. Si variásemos el entorno con frecuencia, estas optimizaciones podrían ir perdiendo fuerza.
El proceso de optimización de los plugins consta de cuatro pasos.
En este punto, entra nuestra valoración profesional y nuestro criterio subjetivo: ¿cada plugin que estamos utilizando aporta realmente algo a nuestro sitio web, o simplemente lo tenemos porque… “nos gusta”? Si la única respuesta a esta pregunta es esto último… ¡bórralo!
Pocas indicaciones puedo darte aquí, salvo que seas sincero contigo mismo: tener un plugin que solo te gusta a ti, ¿qué utilidad tendría para tus usuarios? Piensa en ellos, no en ti mismo.
En mi caso, ahora no tenía ningún plugin innecesario, debido a que ya los eliminé en la primera optimización que realicé dos meses atrás. No recuerdo sus nombres, pero fundamentalmente eran Widgets para colocarlos en la portada. Al final, tuve que reconocer que, en mi caso, no aportaban nada e incluso podrían ser confusos (había uno que permitía utilizar “shortcodes” en la portada, pero ya ni recuerdo para qué lo utilicé).
Ahora bien, hay otro tipo de plugins innecesarios que normalmente no tenemos en cuenta: los que podríamos sustituir fácilmente por unas cuantas líneas de código y hojas de estilo. Un plugin super-mega-extra-potente pero del que solo utilizamos una minúscula porción de sus posibilidades es un desperdicio.
Este es un aspecto que creo que a menudo se olvida: ¿podemos hacerlo nosotros mismos? De hecho, incluso podemos descubrir plugins innecesarios porque nuestro Theme, o incluso otro plugin, ya proporciona una funcionalidad similar (sí, me ha pasado 😉 ).
De nuevo, tenemos que revistar nuestra lista de plugins y, para cada uno de ellos:
En caso de que no tengáis los conocimientos técnicos para acometer el tercer punto, aún así sería importante que realizarais el análisis de los dos primeros puntos. Si descubres que tienes un plugin con infinitas posibilidades, pero del que solo utilizas una o dos de sus opciones, plantéate consultarlo con un desarrollador o diseñador. Otra opción, como veremos en el punto siguiente, sería cambiarlo por otro plugin, más ligero, que sólo tuviera esas opciones.
Como resultado de mi análisis, descubrí que dos de los plugings que estaba utilizando los podía sustituir fácilmente por código propio:
Por tanto, de 12 plugins que tenía inicialmente, me quedé con 10, más algunos cambios menores en html, css y fichero .htaccess para seguir con la misma funcionalidad que tenía antes. ¿No está mal, verdad?
Los plugins consumen memoria y tiempo de proceso, que se añade al propio tiempo de proceso de WordPress para generar nuestro sitio web. Nos interesa, por tanto, que nuestros plugins sean los más rápidos posible.
Para determinar el impacto de cada plugin en el tiempo total de proceso, disponemos del magnífico plugin P3 Performance Profiler, con el que podremos identificar de un vistazo qué plugins consumen más recursos.
Veamos mi caso:
En este caso, vemos que dos plugins, Contact Form 7 y Yet Another Stars Rating, destacan como los plugins más voraces. También aparece el Yoast WordPress SEO, pero el propio P3 nos advierte que es un falso positivo que no debe preocuparnos.
En la optimización que hice hace dos meses, ya había sustituido dos plugins que, en ese momento, consumían mucho: Sharealholic, que sustituí por Simple Share Buttons Adder, y kk Star Rating, que sustituí por Yet Another Stars Rating (YASR). Por tanto, me centraré en el plugin Contact Form 7.
Investigando y probando, descubrí otro plugin, tan versátil como Contact Form 7, que consumía bastante menos: el Cforms2. Este plugin, además tiene una particularidad muy útil: se puede configurar para que solo se cargue en determinadas páginas. Es decir, que el plugin permanece inactivo hasta que el usuario entre en alguna página con un formulario de Cforms2. Toda una ventaja, indudablemente.
Después de instalar Cforms2, configurarlo y crear los formularios, así quedó la distribución de recursos entre los plugins:
Una reducción bastante significativa, ¿verdad? Mirando los números, el impacto de los plugins en el tiempo de carga de la página ha bajado del 45,8% al 42,8%. No es mucho, pero a veces las optimizaciones es esto: la suma de muchos pequeños peldaños.
Un último apunte. Cuando busco alternativas a un plugin ineficiente, suelo fijarme en las puntuaciones y comentarios del resto de usuarios de esos plugins. Por lo general, tiendo a utilizar los plugins que estén entre los más usados (por eso del soporte) y siempre me fijo en los comentarios negativos: no importa lo bueno que sea un plugin, si a mí no me funciona, no me sirve para nada. Leyendo los comentarios negativos intento descubrir si yo podría tener los mismos problemas que tuvieron esos usuarios.
Ya lo adelantaba en el punto anterior, al cambiar Contact Form 7 por Cforms2: no sólo éste último consume menos recursos, sino que tiene una opción de configuración que permite indicar en qué páginas queremos que se cargue. Al no cargarse en todas las páginas, el tiempo de respuesta general del sitio web mejora.
Por tanto, cada vez que necesitemos un plugin, es conveniente analizar varias alternativas y comprobar si alguno de ellos permite esta configuración. Este factor, junto con el consumo de recursos que obtengamos con P3, nos hará decidir por uno u otro plugin.
Cuando el plugin no permita esta configuración, en algunos casos es posible conseguirlo mediante código PHP en el fichero functions.php. Sin embargo, esta solución es totalmente dependiente del plugin y no siempre será posible (al menos, hasta donde mi conocimiento alcanza). Cada plugin debe ser analizado por separado para determinar qué se puede hacer.
En mi caso, dos son los plugins a los que he añadido código específico para que no carguen en todas las páginas, que indico a continuación:
function remove_ssba_scripts() {
if ( !is_singular('post') ) {
remove_action('wp_enqueue_scripts', 'ssba_page_scripts');
}
}
add_action('wp_enqueue_scripts', 'remove_ssba_scripts', 1); function remove_ssba_header() {
if ( !is_singular('post') ) {
remove_action('wp_head', 'get_ssba_style');
}
}
add_action('wp_head', 'remove_ssba_header', 1); function remove_yasr_header() {
if ( is_front_page() || is_home() || is_archive() ) {
remove_action('wp_enqueue_scripts', 'yasr_add_scripts');
}
}
add_action('wp_enqueue_scripts', 'remove_yasr_header', 1); Sólo incluyo estos códigos como referencia y su funcionamiento se sale del alcance del presente artículo, pero si alguien está interesado en saber más al respecto, que me lo haga saber a través de los comentarios y estaré encantado de ayudarle. Ni que decir tiene que, antes de toquetear el código PHP de vuestro Theme… ¡hagáis la copia de seguridad!
En principio, un plugin desactivado no interfiere en la ejecución y rendimiento del WordPress, aunque los expertos de seguridad aconsejan desinstalarlos también porque puede suponer una brecha de acceso fraudulento.
En mi caso, como ya mencioné anteriormente, tengo 21 plugins, pero solo 12 activos, que son los que utiliza el sitio web. El resto, son utilidades y herramientas para mantenimiento y gestión tanto de WordPress como del sitio Web, que sólo activo cuando los voy a utilizar (me habéis pillado, XCloner es uno de ellos 😉 ).
Se podría argumentar que algunos de estos plugins, aun activados, no consumen recursos, porque WordPress no los utiliza para generar páginas, pero aún así, aunque no consuman tiempo de proceso, solo por estar activos ya están consumiendo algo de memoria. Y, bueno, tampoco es tan traumático tener que activarlos cuando los necesitemos y desactivarlos cuando hemos terminado.
Siguiente posta en nuestro camino: las imágenes.
¿Por qué ahora y no antes o después?
Antes no, porque algunos plugins pueden tener unos requisitos específicos de imágenes que podrían ser víctimas propicias para ser optimizadas. Por ejemplo, como sucede con el plugin Recent Posts Widget Extended, que permite indicar el tamaño de las imágenes que se mostrarán en portada de los posts más recientes.
Después no, porque aunque las imágenes se guardan en el sistema de ficheros, la información de éstas (los “meta”) se guardan en la base de datos. Cambios en las imágenes y en sus meta afectarían a la base de datos, que tendríamos que optimizar de nuevo.
No me voy a parar mucho en este punto porque es harto conocido y poco podría aportar al respecto. Para estar seguro que todos estamos en la misma página, consiste en optimizar las imágenes para que el fichero sea lo más pequeño posible sin afectar significativamente su calidad.
Se puede hacer tanto desde WordPress (con un plugin como EWWW Image Optimizer) como fuera de él, antes de subir la imagen a WordPress (yo suelo utilizar Kraken).
Lo que a veces se olvida cuando se trata de optimizar imágenes es que el tamaño importa, y mucho. No es lo mismo una imagen de 1024×512 que otra de 512×256. Aunque ambas guardan las mismas proporciones, la primera es cuatro veces más grande que la segunda; lógicamente, ocupará bastante más, aunque cuando estén comprimidas.
Esto es relevante porque cada Theme tiene unos tamaños recomendados para las imágenes y si, por ejemplo, para una imagen en un lugar determinado recomienda un tamaño 300×200, pero subimos una imagen de 1000×600, entonces estamos cargando una imagen mucho más grande (y más pesada) de lo necesario.
Bien es cierto que un buen Theme creará las imágenes del tamaño adecuado a partir de la que nosotros subamos al WordPress, pero estas nuevas imágenes que se crean en WordPress no estarán optimizadas (salvo que utilicemos un plugin de optimización), como podemos ver para esta imagen de mi blog:
La imagen original, analytics-crear-segmento.png, tiene unas dimensiones de 600×321, que es tal como se mostrará en pantalla (en la resolución recomendada por el Theme). WordPress y el Theme crean el resto de imágenes para diferentes resoluciones de pantalla. Como podéis ver, la imagen original, optimizada, ocupa menos que la mayoría de los thumbnails y copias.
Este problema se puede solventar (como veremos dentro de un momento), pero deberíamos intentar que la imagen original que subamos ya esté optimizada para las dimensiones del lugar donde se ubique, ya sea las recomendadas por el Theme o las que tendrá en nuestros posts y páginas.
Por ejemplo, todas las imágenes de mis posts y páginas que aparecen a la derecha o izquierda de los párrafos tienen un ancho de 300 píxeles si son horizontales, o de 250 si son verticales, así que mis imágenes originales siempre tienen esas dimensiones. A las imágenes en medio de página, en cambio, no les limito las dimensiones, excepto que deben tener como máximo 600 píxeles, tanto vertical como horizontalmente (con idea de que la imagen no se coma al texto).
Un factor a tener en cuenta es que estas dimensiones pueden variar en función de la resolución de la pantalla del navegador. No es lo mismo una pantalla de 1600×1200 que una de 800×600. En general, nuestro Theme ya debería crear thumbnails y copias de varios tamaños para distintas resoluciones, así que nosotros sólo deberíamos preocuparnos de que estos thumbnails estén optimizados (ya veremos cómo).
En conclusión, que nuestra imagen original ya esté optimizada para las dimensiones de su ubicación final en la resolución de pantalla recomendada por el Theme.
En mi sitio web no tuve que optimizar ninguna de las imágenes para los dos puntos anteriores. Ya las había optimizado anteriormente y había incluido en mi procedimiento de creación de imágenes la condición de usar sus dimensiones correctas. Sin embargo, algunas modificaciones que hice en el pasado habían empezado a pasar factura después de varios meses.
Como he mencionado en el punto anterior, los Theme suelen recomendar unas dimensiones determinadas para las distintas ubicaciones de las imágenes. Pero hace unos meses cambié algunos aspectos de mi Theme, fundamentalmente de proporción de la página con el barra lateral y las ubicaciones de las imágenes de portada.
Como consecuencia, las dimensiones recomendadas por el Theme dejaban de ser válidas, pero WordPress permite crear nuevas “dimensiones recomendadas”, mediante la instrucción PHP add_image_size(). Y eso hice: añadir las nuevas dimensiones y que WordPress se encargara de crear esas imágenes…
El problema: dejé las instrucciones que incluía el Theme para las antiguas dimensiones.
La consecuencia: por cada imagen que subía, tenía más de una docena de imágenes, algunas de ellas de tamaños bastante similares.
No sólo era un desperdicio de espacio en disco, sino que también afectaba tanto a la gestión de imágenes del Theme y WordPress, como al tamaño de la base de datos. En el primer caso, porque desde código PHP y HTML se gestionaban todas esas dimensiones disponibles, una docena nada menos. En el segundo caso, porque la base de datos debía guardar información de cada imagen por separado.
Un cacao monumental, en pocas palabras.
La solución pasaba por estos dos pasos:
El segundo punto se podría hacer a mano, pero puede ser una locura. En este caso, el plugin Force Regenerate Thumbnails es tu amigo y acude al rescate. Este plugin reconoce cuáles son las dimensiones que no están en uso y borra las imágenes correspondientes y sus entradas en la base de datos. Una maravilla, vamos (y no te olvides de la copia de seguridad antes de usar este plugin. Manipula la base de datos de WordPress y más vale prevenir).
Posiblemente creas que este problema no te pasa a ti, porque no has modificado el Theme, pero resulta que WordPress también crea sus propias imágenes para distintas dimensiones:
Por defecto, WordPress crea imágenes con dimensiones 150×150, 300×300 y 1024×1024, para los tamaños miniatura, medio y grande, respectivamente. Es posible deshabilitar cualquiera de ellas poniendo su anchura y altura a 0, como he hecho con la del tamaño grande (ni tengo ni necesito imágenes así de grandes). De todas formas, WordPress sólo crea imágenes para las dimensiones más pequeñas que la imagen original, no las más grandes.
Como resultado de esta purga, cada imagen de mi librería de medios ya solo tiene de cuatro a seis copias de distintas dimensiones, algo mucho más manejable desde código, y el espacio en disco se redujo en casi 50 Mb: una copia de seguridad que antes ocupaba más de 140 Mb, y ahora se ha quedado en menos de… ¡100 Mb!
Corolario: no subestimes el poder de las imágenes 😀
Este punto es fácil (¡bien!).
Como ya mencioné en el punto anterior, tanto WordPress como el Theme crean imágenes adicionales por cada imagen que subamos a la librería de medios. Por mucho que nuestra imagen original esté optimizada (lo cual recomiendo), estas nuevas imágenes no lo están.
Podríamos optimizarlas a mano, de una en una, pero es una tarea hercúlea que destrozará nuestras planificaciones. Pero, ¿porqué hacerlo a mano cuando tenemos plugins que lo hacen por nosotros?: WP-SmushIt y EWWW Image Optimizer.
Ambos tienen prácticamente las mismas funcionalidades: optimizar la imagen que subamos, y optimizar las imágenes nuevas que crean WordPress y el Theme. Además, también permiten optimizar las imágenes que ya estaban en la librería de medios.
La diferencia: WP-SmushIt utiliza su propio servidor para hacer las optimizaciones, con lo que consume ancho de banda; mientras que EWWW Image Optimizer lo hace en nuestro servidor, con lo que consume tiempo de proceso.
Yo prefiero que todo quede en casa y tengo el EWWW Image Optimizer, pero utiliza librerías externas para optimizar las imágenes y puede presentar dificultades para quienes no hayan librado tales batallas anteriormente.
Pero cuando cargamos una página, no todas las imágenes se muestran al mismo tiempo, sino solamente las que están “above the fold”, por encima del pliegue. Esto es, el área visible de la pantalla que muestra la parte superior de la página. Esta expresión volverá a aparecer más adelante, en la segunda parte del artículo, cuando hablemos de las descargas.
Aprovechando esta característica, la carga perezosa difiere la carga de las imágenes hasta que se muestran en la pantalla; es decir, hasta que el usuario desplaza la página hacia abajo hasta llegar a la imagen.
En principio, parece muy útil para cuando tenemos páginas largas con bastantes imágenes. Con esto, lo que quiero decir es que la carga perezosa no tiene porque ser beneficiosa para nuestro sitio web, sino que depende de cómo esté estructurada y de su contenido visual. Si las páginas tienen pocas imágenes y la mayoría están “above the fold”, no debería haber ninguna mejoría perceptible.
WordPress no dispone de esta funcionalidad de carga perezosa, pero tenemos plugins que sí lo soportan. Busqué entre ellos y finalmente me decidí por A3 Lazy Load y BJ Lazy Load; tienen bastante difusión, buenas puntuaciones y los comentarios negativos no me invitaban a ser demasiado cauteloso.
Sin embargo, después de probar ambos, decidí no utilizar ninguno. Hice varias pruebas con ambos, tanto en mi portada como en los artículos con más carga de imágenes (las recopilaciones), pero no observé ninguna mejoría significativa en los índices de velocidad, que se movían dentro del mismo rango anterior.
Me sorprendió un poco este resultado, porque esos artículos tienen bastantes imágenes (13 de tamaño grande), pero lo que realmente me hizo desistir de ellos es que ambos tenían un efecto perturbador en mi portada: al avanzar varias veces rápidamente con la tecla de página siguiente, la página se mostraba con huecos en blanco hasta que la imagen se terminaba de cargar. Al principio, incluso pensé que me había cargado la web.
De todas formas, para quienes tengáis muchas imágenes, creo que sí podrían ser útiles y, si tuviera que elegir uno de los dos, me quedaría con el BJ Lazy Load. Su interface de configuración es más sencillo que el de A3.
Además, el A3 crea nuevos estilos para la carga de las imágenes que bloquean el renderizado de la página, por lo que en algunos casos incluso puede afectar negativamente al PageSpeed:
Hoy en día, cualquier sitio web que se precie debe ser responsivo, no solo en su diseño, sino también en las imágenes. Es decir, según la resolución del dispositivo de acceso al sitio web (o, mejor dicho, de las dimensiones de la ventana del navegador), el navegador descarga las imágenes optimizadas para esas dimensiones o las más cercanas a ellas.
En el caso de los dispositivos móviles, esto es especialmente importante, porque sus pantallas son más pequeñas y descargarse imágenes de grandes dimensiones para después reducirlas al tamaño de la pantalla supone desperdiciar ancho de banda y tiempo durante su descarga, comparado con la misma imagen pero optimizada con dimensiones más reducidas.
Como WordPress es responsivo desde su versión 4.4, los Themes modernos suelen ser también responsivos y ya lo implementan de serie (¿recuerdas la instrucción PHP add_image_size() que vimos en un apartado anterior?) y generan el código HTML necesario para que el navegador sepa qué imagen descargar en función del tamaño de la ventana de visualización.
Ahora bien, si tu Theme no es responsivo y no puedes plantearte migrarlo a uno responsivo, o utilizas un versión anterior a WordPress 4.4 y por algún motivo tampoco puedes actualizarlo, ¿qué opciones te quedan? De nuevo, a través de plugins.
No son muchos los plugins disponibles para esta función y algunos de ellos incluso están descontinuados (llevan al menos dos años sin ninguna actualización). No es sorprendente, dado que los Theme no responsivos tienden a desaparecer y que WordPress ya soporta esta característica.
Seleccioné tres plugins, con bastantes descargas y buenas valoraciones, para verlos en más detalle. Ya adelanto que al final opté por no utilizar ninguno, porque no aportaban nada para mi caso concreto, pero comparto con vosotros mis impresiones por si os pudieran ser útiles para vuestros proyectos:
Para quienes seáis más técnicos, comentaros que el plugin RICG añade los atributos SCRSET y SIZE a las imágenes; el plugin Adaptive además detecta la resolución del navegador para generar la imagen específica en esa resolución; y el plugin Responsive añade esos mismos atributos y también puede utilizar el elemento PICTURE.
Un aspecto importante, tanto en el uso de estos plugins como de un Theme responsivo, es que sólo afectan a las imágenes que subamos a la librería de medios. Si copiamos directamente una imagen en el sistema de ficheros y la enlazamos desde nuestras páginas o artículos, no se generarán imágenes responsivas y esa imagen se utilizará para cualquier tamaño de pantalla del dispositivo de acceso (excepto en el caso de Adaptive Images, que las genera durante la primera petición desde el navegador).
Hemos llegado al final de la primera parte de esta guía de optimización de WordPress para acelerar la descarga de las páginas de tu sitio Web. Más de 8.000 palabras… y aún queda la segunda parte por venir.
Partimos de un sitio Web basado en WordPress, con unos índices de PageSpeed 69/83 (móvil/ordenador), un tiempo de respuesta del servidor rondando los 1,5 segundos, y con un margen de mejora de aproximadamente 1,3 segundos con respecto al tiempo de respuesta óptimo, según resulta de las pruebas de rendimiento realizadas.
Para mejorar el tiempo de respuesta del servidor, en esta primera parte hemos cubierto las siguientes áreas de optimización en WordPress:
Sin embargo, todas estas optimizaciones (y las que están por venir) son inútiles si nuestro servidor de Hosting no responde rápida y eficientemente las peticiones de los navegadores.
En concreto, este sitio Web está alojado por WebEmpresa, un proveedor de Hosting WordPress reconocido por su calidad y eficiencia, tanto en el soporte técnico como en las prestaciones de sus servidores. Llevo con ellos casi seis meses, siempre me han atendido con eficacia y no puedo estar más satisfecho con ellos. Además, fueron ellos los que me dieron las primeras pautas para hacer las pruebas de rendimiento del servidor y determinar que tenía más de un segundo de margen de mejora.
No puedo menos que recomendártelo si estás buscando proveedor o estás descontento con el actual. Puedes ver que sus planes y precios de Hosting WordPress cubren un amplio abanico de necesidades, y si finalmente te decides a contratarlos a través de mi enlace de afiliación, no olvides utilizar el cupón de descuento “cupon20” para acogerte a un descuento del 20% sobre la tarifa normal.
Quedan más temas por tratar, que los veremos en la segunda parte de este artículo. Para ir haciendo boca, estos son:
Mi propósito es publicarlo el próximo martes, 29 de marzo… ¡Hasta pronto!
Continuará…
Espero que esta primera parte te haya resultado interesante y útil. He intentado cubrir exhaustivamente cada uno de los puntos tratados, puesto que quería sacar lo máximo de mi propio sitio web. ¿Crees que me he dejado fuera algún aspecto relevante? ¿Qué otras técnicas de optimización, relativas a los plugins y las imágenes, utilizas en tu WordPress?
Imágenes: freepik, freeimages, de los propietarios de los plugins, elaboración propia.
Expectación inminente por el final del concurso VDR Quedan pocos días para que concluya el…
Identidad e imagen: dos visiones de una marca La marca conglomera productos y servicios de…
Cómo trabajar en casa, ¿estamos mentalizados para hacerlo? Sea empleado, autónomo o teletrabajador, tener la…
De nada sirve crear buenos contenidos si no los difundimos y promocionamos adecuadamente en Redes…
¿Consigues tus objetivos de negocio con el Email Marketing? Gracias al Email Marketing enviamos a…
Enamorar al usuario sin invadirlo Necesitamos conseguir nuevos clientes. Sin duda. Pero también gestionar nuestro…
Ver comentarios
Como uso correctamente el Pluggins para medir el uso de recursos de Pluggins P3 PERFOMANCE, Me sale que tengo 16 Pluggins, pero al completarse el scanner me sale que hay solo uno ese mismo pluggins P3 y ocupa el 100% porque me da este error?
Hola, Josue:
El plugin P3 dejó de actualzarse hace tiempo. Quizás sea debido a eso, a que ya deja de ser operativo con las últimas versiones de WordPress.
Gracias y un saludo
Buenas, me parecen geniales tus artículos. Que más puedo decir!!, he perdido la noción del tiempo leyéndolos, solo sé que hoy fue que descubrí la web y como mínimo me he leído 4 ó 5 artículos, sigue así que me parece un gran aporte.
Muchas gracias, saludos desde Cuba.
¡¡Muchas gracias a ti, Chelle!! :)
Recibir y leer esta palabras son las que me dan fuerzas a seguir aportando contenidos :)
¡¡Saludos!!
Hola Antonio, gracias por el artículo, es muy interesante, una pena que el plugin del que hablas, el P3 ya no se actualiza y no funcione como antes. ¿Conoces algun plugin que a día de hoy pueda reemplazar a este? Un saludo!
Hola, Nico:
Gracias por tu comentario :)
En efecto, P3 ya no se actualiza y es una pena, porque reunía características tanto para el usuario técnico como el usuario sin conocimientos técnicos.
No podría recomendarte solo un plugin, pues no conozco tu nivel técnico, así que te pongo dos, para que elijas el que mejor te resulte:
- WordPress Inspector, bastante básico pero lo suficiente para detectar plugins problemáticos.
- Query Monitor, bastante técnico, con información muy detallada sobres los plugins y WordPress.
Espero que te sean útiles.
¡Un saludo!
Excelente . Gracias por compartir tus conocimientos
Excelente post, hay cosas que ya voy a poner en marcha :) Vale leerlo unas cuantas veces porque tiene información valiosa y completa. Gracias.
Gracias a ti, Rosa, por tu comentario. Me alegro que te haya gustado.
Un saludo.
Buenos días Antonio.
Soy muy novato en el uso de Wordpress y por eso he recurrido a la ayuda on-line para resolver mis dudas. Ha sido una grata sorpresa encontrar un sitio web tan profesional y aclarador como es el tuyo, al cual presiento que acudiré muchas veces. Además la sorpresa es doble al ver que quien la crea es un tocayo MUY tocayo mío.
Prometo molestarte con preguntas lo mínimo posible, pero no me puedo resistir a hacerte una que no consigo contestar ni siquiera con Google.
¿Es posible aprovechar el espacio que desperdicia de la pantalla a lo ancho Wordpress?.
Comprendo que hace años "ajustarse" al monitor cuadrado del usuario podía ser complicado, pero hoy son raros los monitores NO panorámicos y veo que se desperdicia 2/4 partes en bandas grises y 1/4 en la columna de publicidad.
Entiendo el espacio reservado para la publicidad, pero ¿la mitad de la pantalla en banda gris?. Incluso si es para "compatibilizar " el uso en Tables lo veo un inconveniente absurdo.
Hola, tocayo ;)
Me alegro que este post, y el blog en general, te pueda resultar tan útil :)
Sobre tu pregunta, me imagino que te refieres al ancho de las páginas en el web hechas con Wordpress, no al panel de administración. En efecto, la mayoría de las webs en Wordpress no abarcan todo el ancho de la pantalla, pero se hace por razones prácticas, al menos tal como yo lo entiendo: Imagina cómo quedaría la página de un blog si abarcara todo el ancho de un monitor panorámico de 30 pulgadas: las líneas de texto serían tan largas que sería muy difícil de leer.
En cualquier caso, esto no depende de Wordpress, sino de tema que tengas instalado. La mayoría de temas están optimizados para una resolución máxima de pantalla, normalmente 1280 píxeles, que es una de las resoluciones más frecuentes. Por debajo de esa resolución, el tema se ajusta mediante CSS, para que la página se vea bien en pantallas más pequeñas o dispositivos móviles (por ejemplo, utilizando media-screen y max-width). Por ejemplo, en mi tema el ancho máximo lo pone esta clase:
.inner-wrap {
margin: 0 auto;
max-width: 1218px;
}
Así que, una de dos, o usas un tema que no tenga ancho máximo (y, la verdad, no sí las habrá, porque una página tan ancha queda poco estético) o modificas la hoja de estilos del tema que utliices (aunque no creo que baste con modificar solo una clase, pero sería cuestión de mirarlo en detalle).
Espero haberte servidor de ayuda.
¡Hasta la próxima!
Bueno, supongo que como dices, en una web de un fotógrafo que muestra un portafolio Lazy Load quizás sí que se note de algún modo para una mejora, aunque yo desde luego cuando lo he testeado no he notado ninguna mejoría.
Un CDN como apuntas debe ser lo último, lo básico coincido contigo que debe ser todo lo que apuntas para optimizar. Ahora bien, si además podemos servir nuestra web desde CDN gratuito como Cloudflare ¿por qué no hacer uso si además se nota la mejora?
No sé, la ventaja de los CDN se hacen más evidentes cuando hay bastante tráfico y las visitas cubren un amplia área geográfica. Y yo creo que todavía no reúno ambas condiciones como para aprovechar la potencia de los CDN... pero ya me haces dudar y has despertado mi curiosidad :)
Voy a hacer algunas pruebas con varios CDN, a ver cómo resulta. Si no tiene ningún efecto perceptible ahora, también me servirá como comparación si mi audiencia aumenta ;)
Gracias, RaMGoN, por tu aportación (e inspiración), y buen fin de semana.
Antonio, genial el post.
Me lo tengo que releer de nuevo, y por supuesto guardo a modo de guía.
Hay varios plugins que citas en los que he tenido similares conclusiones y sorpresas, como con los de carga lenta para las imágenes, que yo tampoco he notado mejoría en su día y me lo acabé cargando. Es mejor, según lo veo yo, servirlas desde un CDN.
Saludos.
Gracias por comentar, RaMGoN. Me alegra mucho que te haya gustado tanto el post y que te vaya a resultar útil :)
Gracias también por compartir tu experiencia con los plugins de carga lenta. A pesar de que hice bastantes pruebas y en las páginas con más carga de imágenes, estaba un poco en la duda de si no los habría usado correctamente (aunque tampoco es que sean de una configuración complejísima) o algún efecto secundarios de mi Theme, asi que saber que tú observaste lo mismo me deja más tranquilo. Es cuestión ahora de tener una página de decenas de imágenes y probarlos ahí para ver si realmente aportan algo.
Sobre el CDN, estos resultados de PageSpeed los obtuve sin CDN. Lo iba a mencionar en la segunda parte del artículo, como parte del apartado "Sobre las descargas", pero tienes razón, el CDN se usa más que nada para las imágenes y habría venido bien poner aquí una referencia. De todas formas, en la secuencia que propongo para la optimización, creo que el CDN debería estar entre lo último a realizar, sobre un WordPress robusto y optimizado, para así conocer todo su potencial.
¡Un saludo!