Optimiza y acelera tu WordPress hasta las estrellas

La velocidad de descarga de una Web en 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 una Web, mejorando más de 20 puntos en Google 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

  1. Backups: no te dejes la copia de seguridad en casa…
    1. 1.1 Plugins de backups
    2. 1.2 A través del panel de Administración de tu Hosting
    3. 1.3 A través de la herramienta de Backups de cPanel
  2. Acerca de los plugins de WordPress
    1. 2.1 Quitar plugins innecesarios
    2. 2.2 Utilizar plugins más eficientes
    3. 2.3 Cargar los plugins sólo donde se utilicen
    4. 2.4 Activar sólo los plugins que estemos utilizando
  3. Acerca de las imágenes
    1. 3.1 Reducir el peso de las imágenes
    2. 3.2 Utilizar dimensiones adecuadas en las imágenes
    3. 3.3 Eliminar copias superfluas de las imágenes
    4. 3.4 Optimizar las imágenes creadas por WordPress y el Theme
    5. 3.5 Lazy Load Images: cuando lo perezoso es bueno
    6. 3.6 Imágenes responsivas para acelerar tu Web Móvil

Raiola NetWorks: alojamiento WordPress
¡El mejor hosting Wordpress con un 20% de descuento!

¡Buff! ¿Otro post más para optimizar y acelerar WordPress…?

¿Es éste otro artículo más sobre optimizar y acelerar WordPress?
Espero que no te aburras… aún 😉

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…”:

  1. Tal como aparece en la imagen de cabecera, muestra el proceso real de optimización de una web en un buen Hosting WordPress que ha mejorado su rendimiento una media de 15-20 puntos el índice de Google PageSpeed Insights: de 69 a 90 en móviles, y de 83 a 96 en ordenador. Es decir, de un rendimiento aceptablemente bueno a un rendimiento muy bueno, sin necesidad de rediseñar la web, cambiar el Theme o reescribir la mitad del código.
  2. No solo describe las distintas posibles optimizaciones que se pueden aplicar, sino que incluye una secuencia para hacerlo que, básicamente, será el mismo orden en que están expuestos. Para cada caso se explica por qué es mejor que deba hacerse en ese paso. No es que otro orden no fuera aceptable o diera malos resultados pero si, por ejemplo, primero optimizamos la base de datos y después los plugins o las imágenes, estos últimos cambios afectarían a la base de datos casi con seguridad, con lo que tendríamos que optimizarla de nuevo.
  3. No doy soluciones totalmente cerradas para cada tipo de optimización. Siempre que sea posible, además de explicar lo que hice, incluiré otras opciones que también valoré y que pueden ser tan eficaces como aquella. En muchos casos, el elegir entre una u otra es mera cuestión de preferencia personal; sin embargo, puede ocurrir que una opción funcione a la perfección en una web, pero que para otra web no dé tan buenos resultados.

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.

 

¿Porqué Google PageSpeed Insights?

Rendimiento del sitio Web con Google PageSpeed Insights
PageSpeed Insights, la referencia para optimizar

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.

 

La importancia de un Hosting WordPress rápido y eficaz

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?

Valores PageSpeed iniciales del sitio WordPress

 

Cómo analizar el rendimiento de un Hosting en WordPress

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:

Tiempo de respuesta del servidor de Hosting antes de optimizar

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!:

Tiempo de respuesta del servidor para un fichero PHP

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!

Tiempo de respuesta del servidor para una página WordPress

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 un  buen Hosting en WordPress. 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 😉

WebEmpresa: alojamiento 100% WordPress

 

WebEmpresa no es el único proveedor de hosting con el que haya tenido experiencias positivas. Con la gestión de sitios webs de clientes, de los que evidentemente no puedo dar más detalles, también he tenido mucho contacto con Raiola Networks. Tanto en el servicio como en el soporte técnico, no puedo más que destacar su rapidez, eficacia y calidad. Y también dispones de un 20% de descuento, solamente pulsando en los enlaces:

Raiola NetWorks: alojamiento WordPress

 

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…

 

1. Backups: no te dejes la copia de seguridad en casa

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…

Los riesgos durante la optimización de WordPress
¿Las puertas para optimizar WordPress?

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…

1.1 Plugins de Backups

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.

1.2 A través del panel de Administración de tu Hosting

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:

phpMyAdmin en la sección Base de Datos del 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:

Exportar una Base de Datos desde phpMyAdmin

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:

Borrar las tablas de la Base de Datos en phpMyAdmin

 

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):

Adminsitrador de Archivos en cPanel

 

Una vez dentro del Administrador de Archivos:

  1. Seleccionamos la carpeta raíz de nuestro entorno en el panel izquierdo.
  2. Seleccionamos la carpeta “public_html”.
  3. Pulsamos el botón “Comprimir” de la barra de menú superior.
  4. Selecionamos el tipo de compresión (yo siempre utilizo ZIP), pulsamos el botón “Compress files” y guardamos el fichero en nuestro ordenador. Aunque no necesario, es aconsejable cambiar el nombre del fichero y añadirle alguna información adicional al nuevo nombre para facilitar su identificación; por ejemplo, el nombre del blog y la fecha y hora de la copia: backup_afernandezalonso-20160318_0930.zip

Comprimir una carpeta en el Administrador de Archivos de cPanel

 

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.

1.3 A través de la herramienta de Backups de cPanel

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.

Herramienta de copias de seguridad de cPanel

 

La herramienta nos permite hacer varios tipos de copias de seguridad:

  • Copia completa. De todo el sitio web, incluidos carpetas de sistema. Esta opción normalmente la reservaremos cuando queramos trasladar nuestra web a otro servidor. En general, no utilizaremos esta opción, ya que la restauración debe hacerse manualmente.
  • Copias parciales. De la base de datos (debemos seleccionarla) o del directorio principal (sistema de ficheros de nuestro sitio web). En este caso, para restaurar uno u otro basta con cargar el fichero de backup correspondiente a través de esta herramienta.

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.

 

Hsta 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.

2. Acerca de los plugins de WordPress

Cómo optimizar los plugins de WordPressOk, llegados a este punto, entiendo que sabes hacer y restaurar copias de seguridad. Si no lo sabes o no la has hecho, significa que eres un amante del riesgo y que te gusta demasiado la ruleta rusa…

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.

2.1 Quitar plugins innecesarios

Analizar qué plugins no aportan nada al sitio webSí, eso ya lo sabemos, cuantos más plugins tengamos, más recursos consumirán. Pero ¿qué son “plugins innecesarios”?

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:

  1. Determinar qué puede hacer,
  2. Para qué lo estamos utilizando y,
  3. Preguntarnos si nosotros mismos podemos implementar esa funcionalidad con poco esfuerzo.

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:

  • Social Media Widget, que permite crear fácilmente barras de botones para entrar en decenas de redes sociales, con muchos efectos de animación. Es un plugin muy útil, sí, pero el único uso que yo le hacía era para mostrar varios botones en la barra lateral y en el pie de página. Sin ninguna funcionalidad adicional. Candidato perfecto para sustituirlo por código HTML y unos pocos estilos.
  • Quick Page/Post Redirect. Plugin muy versátil, para configurar todas las redirecciones que podamos necesitar sin tener que crear patrones complejos de redirección. ¿El problema? Yo sólo lo estaba utilizando para redirecciones 301 (permanentes) de pocas páginas, que se podían configurar muy fácilmente en el fichero .htaccess.

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?

2.2 Utilizar plugins más eficientes

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:

Rendimiento de los plugins con P3 Performance (antes)

 

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:

Rendimiento de los plugins en P3 Perfomance (después)

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.

2.3 Cargar los plugins sólo donde se utilicen

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:

  • Simple Share Button Adder, que solo debe cargarse en posts:
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);
  • Yet Another Star Rating, que solo debe cargarse en posts y pages:
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!

2.4 Activar sólo los plugins que estemos utilizando

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.

 

3. Acerca de las imágenes

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.

3.1 Reducir el peso de las imágenes

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).

3.2 Utilizar dimensiones adecuadas en las imágenes

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:

WordPress y Theme generan varias copias de las imágenes

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.

3.3 Eliminar copias superfluas de las imágenes

Identificar y eliminar imágenes que no utilizamos en WordPress
Desházte de las imágenes que no uses

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:

  1. Eliminar (o comentar) las instrucciones add_image_size() del Theme que creaban las dimensiones de imágenes que ya no se utilizaban.
  2. Borrar todas las imágenes de dichas dimensiones.

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:

Copias y miniaturas de imágenes generadas por WordPress

 

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 😀

3.4 Optimizar las imágenes creadas por WordPress y el Theme

Reduce el tamaño de las imágenes sin perder calidad
Aprieta, aprieta, para que ocupe menos

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.

3.5 Lazy Load Images: cuando lo perezoso es bueno

Carga perezosa de las imágenes de una página WordPressUno de los elementos que más afectan al tiempo de carga de una página web son las imágenes. Por muy optimizadas que estén, son el recurso que más espacio ocupa y rara vez hay solo una o dos imágenes en una página (con permiso de Medium).

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:

Plugin A3 Lazy Load crear ficheros CSS para cargar las imágenes

3.6 Imágenes responsivas para acelerar tu web móvil

Plugins para tener imágenes responsivas en WordPressHoy 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:

  • RICG Responsive Images. Este plugin no tiene panel de control; es decir, basta instalarlo y activarlo, sin más configuración. Pero requiere que el Theme utilizado esté adaptado para él, utilizando las funciones PHP que el plugin proporciona para el soporte Responsive. Además de generar imágenes responsivas, también puede optimizarlas (comprimirlas), por lo que no haría falta disponer de un plugin optimizador de imágenes. Este plugin sería útil para quienes tengan un WordPress anterior a la versión 4.4 y con un Theme que lo soporte (o ellos mismos incluyan el código PHP necesario).
  • Adaptative Images for WordPress. Además de generar imágenes responsivas con un tamaño predefinido (de forma similar al propio WordPress o al Theme), este plugin tiene una cualidad bastante interesante: “adapta” las imágenes al tamaño de la ventana de visualización del navegador. Es decir, genera una nueva imagen con las dimensiones exactas con que se muestra en la pantalla del navegador y la cachea para accesos posteriores. Especialmente útil, por tanto, si vuestra web tiene bastantes imágenes y un elevado número de visitas desde dispositivos móviles, que no es mi caso, pero me lo guardo para el futuro 😉
  • Responsify WP. También genera imágenes responsivas con un tamaño predefinido. Además, proporciona un conjunto de funciones PHP para generar imágenes responsivas desde las plantillas del Theme. En realidad, este plugin amplía el soporte responsivo de WordPress, por lo que sería útil en caso que este soporte no fuese suficiente para vuestra web y necesitéis más dimensiones de imágenes; por ejemplo, galerías de imágenes de dimensiones muy dispares.

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).

 

Conclusiones

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:

  • Copia de seguridad (backups). De acuerdo, no es una optimización, pero nunca recalcaré lo suficiente la importancia de hacer copias de seguridad. Optimizar WordPress requiere acciones tanto en código como en Base de Datos que pueden corromper nuestro sitio web. Tengamos siempre todo preparado para recuperarnos cuanto antes de cualquier caída o error.
  • Acerca de los plugins de WordPress. Los plugins son el día a día de WordPress y debemos seleccionarlos y ulizarlos sabiamente. Un número excesivo de plugins o una elección inadecuada puede afectar el tiempo de descarga de todas las páginas del sitio Web. Asimismo, siempre que podamos sólo se deben cargar los plugins en las páginas donde se utilicen.
  • Acerca de las imágenes. Sí, optimizar, o comprimir, imágenes es fácil, pero no es la única consideración que debemos tener en cuenta. Las dimensiones también son relevantes; si tenemos una imagen de 2048×2048 que se va a mostrar en un cuadro de 300×300, por muy optimizada que esté seguirá siendo mucho más grande que una de 300×300. También debemos gestionar y optimizar adecuadamente las imágenes que WordPress y el Theme generan cuando se cargan en la librería de medios. Finalmente, dependiendo de las características de nuestro sitio Web, podemos utilizar técnicas como la carga perezosa (“lazy load”) o imágenes responsivas para conseguir mejores resultados.

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.

No te pierdas el próximo episodio…

Quedan más temas por tratar, que los veremos en la segunda parte de este artículo. Para ir haciendo boca, estos son:

  • Acerca de la Base de Datos. Todo lo que hagamos con WordPress queda almacenado en su base de datos; lo bueno… y lo malo. El problema: que llega un momento que la base de datos pierde eficiencia y responde más lentamente.
  • Acerca de las descargas. Navegar por un sitio web supone descargar desde el servidor páginas, hojas de estilo, ficheros javascript e imágenes. En WordPress, las páginas son generadas cada vez que se visitan, lo que puede suponer una sobrecarga del servidor, mientras que las hojas de estilo y ficheros javascript pueden alargar la descarga de la página. Veremos cómo reducir estos efectos.
  • Acerca de las fuentes y otros ficheros extraños. ¿Cómo resolver que nuestro Theme descargue las fuentes desde otro servidor, bloqueando la generación de la página hasta que se descarguen completamente?
  • Depuración final y otras posibles optimizaciones. Llegado a este punto, qué otras técnicas de optimización avanzada se pueden aplicar, fuera de las categorías discutidas hasta aquí.

Mi propósito es publicarlo el próximo martes, 29 de marzo… ¡Hasta pronto!

Continuará…

¿Qué pasará en el próximo episodio?

 


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.

 

¿El post te ha resultado útil? ¡Ayúdame a mejorar y puntúalo!

[ Hasta ahora habéis votado 12, con nota media 4.8 ]
 
Tweet about this on Twitter6Share on Facebook0Share on Google+3Pin on Pinterest0Share on LinkedIn1Buffer this pageEmail this to someone

Quizás también te interese...

Elegir y optimizar el mejor Hosting para WordPress – Guía paso a paso (I)
Etiquetas: guía    hosting    optimización    plugins    rendimiento
Sobre el autor,
Consultor SEO Freelance, Ingeniero Superior de Informática, Certificado en Google Adwords y Experto Universitario de Social Media Marketing, con más de 20 años de experiencia en el sector de Internet y las Nuevas Tecnologías.

Hay 7 comentarios acerca de:
    “Elegir y optimizar el mejor Hosting para WordPress – Guía paso a paso (I)

  • 23/03/2016 a las 18:14
    Enlace permanente

    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.

    Responder
    • 24/03/2016 a las 9:47
      Enlace permanente

      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!

      Responder
  • 24/03/2016 a las 17:14
    Enlace permanente

    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?

    Responder
    • 25/03/2016 a las 14:14
      Enlace permanente

      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.

      Responder
  • Pingback: Bitacoras.com

  • 28/11/2016 a las 13:08
    Enlace permanente

    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.

    Responder
    • 28/11/2016 a las 22:05
      Enlace permanente

      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!

      Responder

Deja un comentario

Tu dirección de correo electrónico no será publicada.