Cómo Acelerar Su Sitio WordPress (La Mejor Guía para 2024)

Hemos publicado muchos tutoriales de optimización de la velocidad de WordPress a lo largo de los años con formas de optimizar y acelerar WordPress. Pero en algunas ocasiones puede ser un poco confuso intentar encontrar todo lo que necesita en un solo lugar. Así que el día de hoy, le compartiremos todo lo que sabemos para turbocargar WordPress con más de 15 años de experiencia y lecciones aprendidas. Aunque sea alguien que está empezando con WordPress o un desarrollador veterano, le prometemos que encontrará algo útil en este guía.

Más del 43.5% de la red funciona con WordPress. No cabe duda de que esto es sorprendente, pero también significa que hay miles de diferentes temas, plugins, y tecnologías que tienen que coexistir en un mismo lugar. Para el usuario cotidiano de WordPress, esto puede convertirse rápidamente en una pesadilla cuando su sitio comienza a producir cuellos de botella y no saben por qué o incluso dónde comenzar a solucionar problemas.

En nuestra guía previa sobre la velocidad de la página, hablamos mucho sobre los fundamentos del desempeño y cómo esto puede tener un fuerte impacto en el éxito de su negocio. Pero el día de hoy, nos adentraremos en los pasos aplicables que usted puede tomar ahora para mejorar sus propios sitios de WordPress. También le compartiremos algunos recursos que han sido muy valiosos para nosotros.

Tipos de Sitios de WordPress: Estático o Dinámico

Antes de empezar con las optimizaciones de velocidad de WordPress, es importante primero entender que no todos los sitios de WordPress son iguales.  Es por eso, que muchos usuarios tienen problemas, ya que no podremos resolver cada problema de la misma forma. Siempre damos a los sitios de WordPress una clasificación: estática o dinámica. Así que primero exploremos las diferencias entre estos dos tipos.

Sitios Principalmente Estáticos

Los estáticos, típicamente incluyen sitios como los blogs, sitios de pequeñas empresas, sitios de noticias de bajo volumen, personales, sitios de fotografía, etc. Por estático, queremos decir que los datos en estos sitios de WordPress, no están cambiando a menudo (quizás un par de veces al día). Incluso la mayor parte de nuestro sitio de Kinsta, podría ser considerado un sitio estático.

Esto es muy importante ya que muchas de las peticiones, pueden ser servidas desde la cache en el servidor a velocidades increíbles. Pero no se preocupe; hablaremos mucho más sobre el tema de la cache en otra sección del articulo. Esto quiere decir que tendremos menos consultas de la base de datos y no se requerirán tantos recursos para alcanzar un buen desempeño en Google.

Sitios Altamente Dinámicos

Por otro lado, también tenemos sitios altamente dinámicos. Estos son sitios como los de eCommerce (WooCommerce o Easy Digital Downloads), de comunidad, de membresía, foros (bbPress o BuddyPress) y sistemas de administración de aprendizaje (learning management systems LMS). Con dinámico, queremos decir, que los datos en estos sitios de WordPress están cambiando frecuentemente (transacciones de servidor están sucediendo cada tantos minutos o incluso segundos). Esto quiere decir, que no todas las peticiones al servidor pueden ser servidas directamente desde la cache y requieren recursos de servidor adicionales, como también peticiones de la base de datos.

Estos sitios típicamente tienen un gran número de visitantes y sesiones concurrentes. En un sitio informativo o corporativo de WordPress, el cual normalmente es estático, un visitante podría permanecer por cinco o 10 minutos, hasta que encuentre lo que necesitaba (y esto es un número muy alto, usualmente los números de rebote son mucho mayores). En sitios dinámicos, usted verá lo opuesto. Los visitantes típicamente vienen al sitio para encontrarse con algo o alguien. Si están haciendo un curso en línea, no es inusual que se queden por varias horas.

Ya podrá ver a dónde estamos yendo con esto. El número de visitantes concurrentes conectados a su host de WordPress se irán acumulando rápido. Para hacer esto aún peor, usted tendrá un gran número de visitantes concurrentes, además de un problema de “contenido que no puede ser almacenado en la cache”.

Elija un Hosting de WordPress de Alto Desempeño

Un host de WordPress, es una compañía que almacena todos los datos de su sitio web. Usted se inscribe a un plan y todas sus imágenes, contenido, videos, etc., serán almacenados en un servidor que se encuentra en el centro de datos del host. El host de WordPress les da un acceso fácil a estos datos, para poder administrarlos, y enviarlos a sus visitantes. Simple, ¿no? Bueno, no exactamente.

Hay tres tipos distintos de hosts de WordPress, con los que se encontrará alrededor de la red. Veamos las ventajas y desventajas de cada uno. Es importante elegir el correcto desde el principio, de otra manera, esto le causará dolores de cabeza y tiempo perdido a la larga.

1. Hosting Compartido de WordPress

El primer y el más popular tipo de hosting de WordPress es al que llamamos “hosting compartido.” Estos incluyen los hosts más grandes en la industria, compañías como EIG, Bluehost y HostGator, también proveedores como Siteground, GoDaddy, Media Temple, OVH, GreenGeeks y InMotion Hosting. Normalmente estos hosting utilizan cPanel y el cliente promedio paga usualmente entre $3 y $25 al mes.

Cualquier persona que utilice este tipo de hosting descubrirá tarde o temprano, lentitud, es cuestión de tiempo. ¿Por qué? Porque los hosts compartidos tienden a abarrotar sus servidores, lo cual lleva a causar un impacto en el desempeño de su sitio. Las suspensiones o los errores 500 frecuentes son cosas comunes que uno experimentará, ya que tienen limitaciones de espacio en casi todo, y consolidan recursos para sobrevivir. O aún peor, que su sitio quede temporalmente inactivo. A pesar de que aún no sabe esto, su sitio WordPress comparte espacio con 200 personas o más en su servidor. Cualquier problema que surja con otros sitios podrá afectar también al suyo.

Sin importar cómo haga sus cálculos, después de los gastos, $3 al mes no le genera suficientes ganancias a la compañía de hosting. Especialmente cuando se agrega el soporte a esto. Reciben un ticket de soporte y ya están en números rojos. La forma en que ganan la gran mayoría de su dinero, es vender más y con cargos escondidos. Estas sobreventas, incluyen cosas como migraciones, registros de dominio, certificados SSL, etc. Otra táctica común es proveer grandes descuentos por inscripción. Pero una vez que llega la renovación del contrato, usted obtendrá el recibo de verdad.

La mayoría de estos hosts ofrecen algo llamado “Recursos ilimitados”. Probablemente ya haya visto esto. Bueno, en el mundo, no existe tal cosa como “recursos ilimitados.” Lo que hacen los hosts, detrás del escenario, es limitar a los clientes que estén utilizando demasiados recursos. Esto, en su lugar, termina causando que muchos clientes molestos se vayan, dando más lugar a clientes que no usan tantos recursos. Al final, se obtiene un ciclo vicioso, uno en donde la compañía de hosting saca planes baratos, esperando a que la gran mayoría de sus clientes no usen demasiados recursos y terminen comprando los complementos.

El servicio y soporte al cliente con programas de hosting compartido, son de baja calidad, debido al alto volumen de sitios vs representantes de soporte. Los hosts compartidos tienen que expandirse de tal forma, que sólo dejen lo suficiente para obtener las ganancias necesarias, y esto usualmente termina siendo una experiencia negativa para el cliente.

Asegúrese de checar el articulo escrito por nuestro CFO, sobre las verdades impactantes sobre cómo trabajan realmente los hosting WordPress baratos.

2. Hosting de WordPress con un VPS (Servidor Virtual Privado) Hecho por Usted (DIY)

El segundo tipo de hosting de WordPress es el DIY VPS, o “Hágalo usted mismo en un Servidor Virtual Privado.” Este grupo, típicamente está hecho de startups y usuarios con un poco más de experiencia en desarrollo y administración de servidores de WordPress. Estos son el grupo de DIY. Estas personas, típicamente, intentan ahorrar dinero, pero también les preocupa el desempeño y se dan cuenta de lo importante que esto es para el éxito de su negocio. Las configuraciones comunes pueden incluir proveedores VPS como Digital Ocean, Linode, o Vultr; junto con una herramienta como ServerPilot, para administrar todo de forma más sencilla.

Un VPS pequeño de DigitalOcean, comienza desde los $5 por mes y el plan más popular de ServerPilot comienza desde los $10 al mes. Así que, dependiendo de la configuración, podría estar viendo un gasto de entre $5 y $15 al mes, quizás un poco más. El enfoque al DIY, puede ayudar a reducir los costos, pero también significa que tendrá que hacerse responsable si algo se rompe, y tendrá que optimizar su servidor para obtener un buen desempeño.

Este enfoque de DIY puede ser fantástico, pero también le puede causar problemas si no tiene cuidado. No tome esta ruta si no es muy bueno con la tecnología o porque le gusta experimentar. Su tiempo es dinero, y debería usarlo para crecer su negocio.

3 Hosting Administrado para WordPress

El tercer tipo de hosting es lo que ofrecemos en Kinsta y es el hosting administrado para WordPress. Este tipo de hosts pueden lidiar con todo relacionado con el servidor y back-end, y al mismo tiempo brindamos soporte cuando lo necesite. Hecho a la medida para funcionar con WordPress y normalmente esto incluye opciones como, entornos de staging y backups automáticos. Sus equipos de soporte tendrán mayor conocimiento, cuando se trata de tener que lidiar con el CMS ya que están enfocados en una plataforma cada día.

¡Si quiere ahorrar tiempo, el hosting administrado de WordPress es la mejor opción! 👍

Los planes por un hosting administrado normalmente van desde los $25 hasta los $150 al mes, dependiendo del tamaño de su sitio y necesidades. Las grandes compañías como jQuery, Intuit, Plesk, Dyn, Nginx, e incluso la Casa Blanca utilizan WordPress para hospedar sus sitios web. Algunos hosts administrados de WordPress que ya debe conocer, o quizás ya esté utilizando como: WP Engine, Flywheel, Pressable, Media Temple, Pressidium y Pagely.

Kinsta Toma un Enfoque Diferente

Kinsta por otro lado, lleva el hosting de WordPress al siguiente nivel. Nuestra plataforma de hosting no entra en ninguna categoría de las categorías de hosting tradicionales. Nuestra infraestructura está construida sobre Google Cloud Platform y es diferente a la infraestructura compartida, VPS o dedicadas tradicionales lo que la convierte en una de las soluciones de alojamiento de WordPress más rápidas disponibles.

Cada Sitio de WordPress, en nuestra plataforma, funciona en un contenedor de software aislado que contiene todos los recursos de software requeridos para correr el sitio (Linux, Nginx, PHP, MySQL). Esto quiere decir que el software que corre cada sitio es completamente privado y no es compartido ni entre sus propios sitios.

Cada contenedor del sitio funciona en máquinas virtuales en uno de los múltiples centros de datos de GC, y utiliza la red de nivel superior de la Google Cloud Platform para una transferencia de datos optimizada de baja latencia. Cada maquina tiene hasta 96 CPUs y cientos de GB de RAM. Los recursos de hardware (RAM/CPU) son ubicados automáticamente a cada contenedor de sitio por nuestros maquinas virtuales, cada vez que sea necesario.

A diferencia de otros hosts que utilizan las máquinas virtuales de propósito general de Google Cloud Platform, nosotros ponemos a disposición de todos nuestros clientes de las regiones compatibles máquinas virtuales C2 optimizadas para computación. Las máquinas C2 de Google Cloud cuentan con la última generación de procesadores escalables Intel Xeon capaces de mantener velocidades turbo de 3,8 GHz en todos los núcleos. Las máquinas C2 son populares para casos de uso intensivo de la CPU como el modelado científico y el aprendizaje de máquinas, pero también son excelentes para el alojamiento de WordPress de alto rendimiento. Durante nuestras pruebas, descubrimos que la migración de un sitio de WordPress de una máquina virtual de propósito general a una máquina virtual C2 resultó en un aumento de 2 veces en el rendimiento!

Thank you @kinsta for handling today's traffic spike without issue. It's comforting to know your site can handle surges. #webperf #webhosting #wordpress pic.twitter.com/fplO87LIu0

— Adam Lundeen (@adam_lundeen_) January 29, 2019

Cada año Review Signal publica sus Puntos de Referencia de hosting de WordPress, y nos enorgullece decir que, por cinco años consecutivos, ¡Kinsta ha demostrado ser la mejor compañía en todo los niveles! Y no sólo para uno o dos de nuestros planes, sino para todos planes, desde el Básico, hasta el de nivel Empresarial.🤘

Tampoco tenemos representantes de soporte de nivel 1 o nivel 2. Nuestro equipo de soporte completo está compuesto de desarrolladores de WordPress e ingenieros de hosting de Linux, muchos de los cuales han administrado sus propios servidores, han creado temas y plugins, y han contribuido hasta al core. Esto asegura que usted reciba soporte experto de alguien que utiliza activamente y desarrolla con WordPress.

Usted podrá conversar con los mismos miembros del equipo de soporte que respaldan clientes Fortune 500 y grandes empresas. Somos muy quisquillosos sobre la calidad de nuestro equipo de soporte, así que sólo contratamos a menos del 1% de la gente que aplica para el puesto. ¡No encontrará un mejor soporte en ningún lado!

Para aprender más sobre por qué elegir Kinsta para su hosting administrado de WordPress, lea ¿por qué nosotros? – como Kinsta es diferente. Pero sin importar a quien elija para ser su proveedor de hosting, siempre debe buscar estas opciones de servidor, para asegurar que su sitio corra lo más rápido posible.

PHP 7 en Adelante para el Mejor Desempeño

PHP es un lenguaje código abierto, de scripting y programación de servidor que es usado principalmente para desarrollo web. La mayor parte del core del software de WordPress está desarrollado en PHP, junto con sus plugins y temas, que hace PHP un lenguaje muy importante para la comunidad de WordPress. Usted debe asegurarse de que su host de WordPress ofrezca por lo menos PHP 7 o versiones superiores.

Hay diferentes versiones de PHP que su host le proporcionará en su servidor, el nuevo PHP 7.3 ofrece enormes mejoras de rendimiento.

De hecho, en nuestros recientes puntos de referencia de PHP, si compara PHP 7.3 con PHP 5.6, el primero puede manejar 3 veces más solicitudes (transacciones) por segundo. PHP 7.3 también es en promedio un 9% más rápido que PHP 7.2. Esto también puede afectar la capacidad de respuesta de su escritorio de WordPress.

Velocidades más rápidas y seguridad mejorada, es la razón por la que Kinsta siempre ofrece las versiones más recientes de PHP. Puede cambiar las versiones de PHP con un solo clic.

Y tenga cuidado con cualquier host de WordPress que ofrezca HHVM como una alternativa a PHP. HHVM ya no es una solución viable para el hosting de WordPress.

Elija un Host que Utilice Nginx

Detrás del escenario, cada host de WordPress utiliza un servidor web, para que sus sitios de WordPress funcionen. Las opciones más comunes son Nginx y Apache.

Le recomendamos elegir un host que utilice Nginx por tener raíces en la optimización del desempeño a escala. Nginx normalmente supera a otros servidores populares en pruebas de desempeño, especialmente en situaciones de contenido estático o cuando uno tiene alto número de peticiones concurrentes, por eso, Kinsta utiliza Nginx.

Algunas compañías de alto perfil utilizan Nginx, incluyendo Autodesk, Atlassian, Intuit, T-Mobile, GitLab, DuckDuckGo, Microsoft, IBM, Google, Adobe, Salesforce, VMWare, Xerox, LinkedIn, Cisco, Facebook, Target, Citrix Systems, Twitter, Apple, Intel, y muchos más. (fuente)

De acuerdo a W3Techs, Apache es usado por un 44.0% de los sitios web, haciéndolo la opción más usada. Pero si ve cuál es el servidor web más popular entre los sitios de alto tráfico (top 10,000), verá que Nginx es usado por un 41.9% de estos mientras que Apache sólo potencia el 18.1%. Es usado por algunos de los sitios en existencia que más recursos consumen, incluyendo Netflix, NASA e incluso el mismo WordPress.com.

Lea más en nuestro servidor web showdown: Nginx vs Apache.

La Red Usada por Su Host Importa

Al elegir un host de WordPress podría pensar que no tendría que pedir o investigar qué red están utilizando, pero eso es lo que tiene que hacer. La red debe tener un alto impacto en el desempeño de su sitio e incluso la rapidez del dashboard de su WordPress. Muchos hosts dejarán esto fuera de su marketing, ya que preferirán elegir la red más barata para recortar gastos.

Aquí tenemos algunas preguntas que debería hacer:

• ¿Qué redes utiliza para transmitir datos? ¿La mayoría es a través de redes ISP públicas o infraestructuras privadas como Google o Microsoft? Estos grandes proveedores tienen redes que están construidas y optimizadas para baja latencia y velocidad. ¡Incluso tienen sus propios cables de internet en las profundidades del océano!
• ¿Acaso las redes que están utilizando son redundantes? ¿Qué sucede si un cable es accidentalmente cortado? Esto sucede más comúnmente de lo que piensa.

En el 2017 Google anunció su red estándar, que es una red más lenta, pero más barata. En Kinsta utilizamos la red premium para todos nuestros planes de hosting. A pesar de que esto nos cuesta más a nosotros, esto asegura que usted tendrá velocidades más rápidas.

De acuerdo con Google, la red premium logra un desempeño de red mejorada, al reducir la duración del viaje en el internet público; los paquetes entran (y se van) a la red de Google lo más cerca posible al usuario y luego viajan en la “columna” de Google antes de entrar a la máquina virtual. El nivel estándar, ofrece tráfico saliendo desde el GCP al proveedor de internet sobre las redes de transporte publico (ISP) en lugar de la red de Google.

En pocas palabras, para que sea más fácil de entender:

• Los paquetes premium pasan más tiempo en la red de Google, con menos rebotes, y así funcionan mucho mejor (pero cuestan más).
• Los paquetes estándar pasan menos tiempo en la red de Google, y más tiempo en redes publicas y por eso, tienen un peor desempeño (pero cuestan mucho menos).

¿Qué impacto tiene esto? Bueno, para los datos que viajan a través de los continentes, la red de nivel premium es aproximadamente un 41% más rápida, en promedio, que la red de nivel estándar. Para los datos viajando a una región cercana (mismo continente), la red premium es un 8% más rápida. Mientras que las redes sólo toman una fracción de su tiempo de carga total, ¡cada segundo se acumula!

La redundancia también es clave, y es por eso que Google utiliza por lo menos tres caminos independientes (N+2 de redundancia) entre dos ubicaciones en la red de Google, asegurando que el tráfico siga fluyendo entre dos ubicaciones, incluso en caso de una disrupción.

Como podrá ver ahora, mucho de esto pasa detrás del escenario, cuando se trata de las redes. Asegúrese de que su host de WordPress esté utilizando una red prestigiosa y no esté eligiendo las de menor categoría para ahorrar dinero.

HTTP/2 es Necesario

HTTP/2 es un protocolo web lanzado en 2015, el cual fue diseñado para acelerar la entrega de los sitios web. Debido al soporte del navegador, este requiere HTTPS (SSL). Si su host de WordPress no soporta HTTP/2, usted debe de buscar un nuevo proveedor. Con todo el internet mudándose a HTTPS, esto ya no es solo una buena opción; es una necesidad.

La mejora en el desempeño con HTTP/2 es debido a una variedad de razones, como un mejor soporte a la multiplexación, paralelismo, compresión HPACK con decodificación Huffman, la extensión ALPN, y empuje del servidor. Solía haber un poco de demora por la TLS cuando se trataba de correr sobre HTTPS, pero esto ya no pasa tan seguido gracias a HTTP/2 y TLS 1.3. Kinsta soporta HTTP/2 y TLS 1.3 en todos nuestros servidores y CDN.

Otro gran logro con HTTP/2 es que con la mayoría de sitios de WordPress, usted no tendrá que preocuparse sobre concatenación (combinar archivos) o fragmentación de dominios. Estas ya son optimizaciones obsoletas.

Elija un Servidor Cerca de sus Visitantes

Una de las primeras cosas que debería hacer al hospedar su sitio de WordPress es determinar de dónde viene la mayoría de sus visitantes o clientes. ¿Por qué es importante esto? Porque la ubicación del host de su sitio web juega una parte importante en determinar la latencia total de su red y el TTFB. También impacta las velocidades de SFTP y el tiempo de respuesta del dashboard de admin de su WordPress.

Latencia de la Red: Se refiere al tiempo y/o retraso que está involucrado en la transmisión de datos sobre una red. En otras palabras, cuánto tiempo le toma a un paquete de datos ir de un punto a otro. Hoy día, esto es típicamente medido en milisegundos; sin embargo, podrían ser segundos dependiendo de la red. Cuanto más cercano a cero esté, mejor será.

Consulte este artículo sobre latencia de red.

TTFB: Esto es el acrónimo para time to first byte (tiempo para el primer byte). Para dejarlo más simple, esto muestra cuánto tiempo tiene que esperar el navegador antes de recibir el primer byte de dato desde un servidor. Entre más tiempo pase para obtener el dato, más tiempo tomará mostrarlo en la página. De nuevo, cuanto más cercano esté a cero será mucho mejor.

Lea este artículo detallado sobre TTFB.

No le aburriremos con todos los detalles técnicos en esta publicación, todo lo que necesita saber es que necesita que la latencia de su red y el TTFB sean lo más bajos posible. Una de las maneras más fáciles de lograr esto es elegir el servidor más cercano a sus visitantes. Puede determinar la mejor ubicación siguiendo los consejos a continuación.

Consejo 1 – Revise la Geolocalización de sus Visitantes en Google Analytics

Una de las primeras cosas que tiene que hacer es ver la geolocalización de sus visitantes en Google Analytics. Puede encontrar esto bajo “Audiencia -> Geo -> Ubicación.”

En el ejemplo de abajo, puede ver que más del 90% del tráfico viene de los Estados Unidos. Así que, en la mayoría de los casos, usted querrá ubicar su sitio de WordPress en un servidor en los Estados Unidos. También puede filtrarlos datos por ciudad. Esto es especialmente importante si usted es una compañía local. Pero normalmente recomendamos una ubicación central como Iowa, USA.

Consejo 2 – Consulte los Datos de Ecommerce

Si usted tiene una tienda de eCommerce, asegúrese de checar y observar de dónde vienen sus clientes. Así es como uno genera ingresos, así que estos son sus visitantes más importantes. Esto debería coincidir con el tráfico de arriba; sin embargo, esto no siempre es el caso. Si tiene los datos configurados de su eCommerce o metas en Google Analytics, usted puede fácilmente agregar esa información sobre los datos de geolocalización, para tomar una decisión más informada. O consulte la información de ubicación almacenada en las bases de datos de su plataforma de eCommerce.

Consejo 3 – Haga una Prueba de Latencia

Hay muchas herramientas útiles para medir la latencia de su ubicación actual para distintos proveedores de la nube. Esto puede ayudarle a rápidamente evaluar qué región sería la mejor opción para su sitio.

• GCP Ping (mide latencia a regiones de Google Cloud Platform, incluyendo los servidores de Kinsta)
• CloudPing.info (mide la latencia de las regiones de Amazon Web Services)
• Azure Latency Test (mide la latencia de las regiones de Azure)

En este ejemplo de abajo, podemos ver que Oregon, E.U.A. (us-west1) es la más rápida en donde nos ubicamos. Sin embargo, si está sirviendo a clientes en todas partes de Estados Unidos, podría ser mejor elegir Iowa, E.U.A. (us-central1) para asegurar una baja latencia para ambos, visitantes de la costa oeste y este.

En Kinsta, ofrecemos 37 centros de datos distintos alrededor del mundo. ¡Podrá elegir fácilmente un sitio que tendrá baja latencia y TTFB! Esto también ayudará a reducir los saltos de la red.

Formas Adicionales para Reducir la Latencia y el TTFB

Además de elegir un servidor con una ubicación más cercana, hay otras formas para reducir la latencia.

• Implementar una cache en su sitio de WordPress. ¡En nuestras pruebas la cache redujo nuestro TTFB por un sorprendente 90%!
• Utilice una red de entrega de contenido (CDN) para servir activos almacenados en la cache de POPs alrededor del mundo. Esto ayudará a negar la latencia de la red para visitantes quienes no se encuentran cerca del servidor de su host.
• Tome ventaja del protocolo HTTP/2 para minimizar el número de viajes redondos, gracias al proceso de paralelización. HTTP/2 está habilitado en todos los servidores de Kinsta.
• Reduzca el número de peticiones HTTP. Ya que cada una puede tener su propia latencia agregada, basada en la ubicación de su servidor.
• El DNS juega una parte importante en el TTFB, así que debería utilizar un proveedor de DNS premium con tiempos de búsqueda veloces.
• Utilice precarga y previsualización para llevar a cabo tareas detrás de escenas mientras la página carga.

No se preocupe, nosotros cubriremos todas las recomendaciones mencionadas anteriormente a continuación.

Velocidades SFTP y el Panel de Control de WordPress.

Sus visitantes y clientes siempre deberían ser su prioridad. Pero otro aspecto del desempeño del cual muchos no hablan es cómo algunas de estas decisiones afectan su trabajo diario. La ubicación del centro de datos que elija tiene un impacto en qué tan rápidas son sus descargas de su SFTP y las velocidades de subida (transfiriendo datos con un cliente FTP), al igual que la capacidad de respuesta de su dashboard de de WordPress.

Mientras se asegura y elige una ubicación que sea la mejor para sus visitantes, también tenga en mente que esto puede afectar al mantenimiento de su sitio. Las tareas, tal como subir archivos a la biblioteca de archivos multimedia de WordPress, serán más rápidas cuando su sitio tenga como host un centro de datos cercano a usted.

Consistentemente escuchamos de nuestros clientes en Kinsta que les sorprende qué tan rápido responde su dashboard de admin con nosotros. Hay una multitud de factores que influencian esto, pero tener 37 centros de datos distintos es una razón muy grande. Elija una ubicación que funcione para usted y sus visitantes. Después de todo, usted será el que pasará miles de horas trabajando en su sitio web.

Un DNS Premium es Mucho Mejor que un DNS Gratuito

DNS, acrónimo para Domain Name System, es uno de los componentes más comunes y al mismo tiempo más incomprendidos del entorno de la red. Para ponerlo con palabras más claras, el DNS ayuda a dirigir el tráfico en el internet, al conectar nombres de dominio con servidores actuales de la red. Esencialmente, toma una petición humana – el nombre de un dominio como kinsta.com – y lo traduce a una dirección IP de servidor amigable para computadoras – como 216.58-217.206.

Puede encontrar DNS gratuitos y Premium. Todos los clientes de Kinsta obtienen acceso a un DNS premium a través de Amazon Route 53. En general, nosotros creemos que tener un DNS premium es una necesidad en el mundo moderno.

Una gran razón por la que uno debe elegir un DNS premium es la velocidad y confiablidad. Buscar DNS récords y dirigir tráfico toma tiempo, incluso si es cuestión de milisegundos.

Típicamente, un DNS gratuito que obtendrá de un registro de nombre de dominio es realmente lento, mientras que un DNS premium ofrece un mejor desempeño. Por ejemplo, en nuestras pruebas, descubrimos que el DNS de NameCheap es un 33% más lento que Amazon Route 53, este siendo un DNS premium. Además de esto, un DNS premium puede ofrecer una mejor seguridad y disponibilidad, especialmente cuando se encuentra bajo un ataque DDoS.

Puede utilizar una herramienta como SolveDNS speed test para revisar los tiempos de búsqueda de su DNS. DNSPerf también brinda un excelente desempeño de datos en todos los mejores proveedores de DNS.

Para un buen equilibrio entre un proveedor de DNS gratuito por su registro de dominio y un DNS premium, Cloudflare DNS es un servicio gratuito que aún ofrece muchos de los beneficios de un DNS premium. Y son muy rápidos, con un promedio debajo de 20ms de tiempo de respuesta alrededor del mundo (como se puede observar abajo).

La integración de Cloudflare se incluye en todos los planes de Kinsta. Si usted está sirviendo principalmente a visitantes en los Estados Unidos, DNS Made Easy es otro proveedor de DNS premium que podría checar. Tienen la reputación de brindar uno de los mejores tiempos de respuesta de cualquier DNS en la última década.

En los últimos 30 días, DNSPerf muestra el siguiente tiempo de actividad de estos proveedores:

• DNS Made Easy: 99.99% el cual equivale a 4m 23.0s de inactividad al mes.
• Amazon Route 53: 99.88% lo cual equivale a 52m 35.7s de inactividad al mes.
• Cloudflare: 99.85% el cual equivale a 1h 5m 44.6s de inactividad al mes.

¿Es importante el tiempo de inactividad para los proveedores de DNS? La respuesta es, sí y no. El DNS típicamente se encuentra almacenado en la cache con ISPs, utilizando el tiempo de vida (TTL) en el DNS récord. Por lo tanto, si un proveedor de DNS se encuentra inactivo por 10 minutos, probablemente no lo notará. El tiempo de inactividad importa si hay tiempos de inactividad constantes de parte del proveedor, o si los récords de su ISP y DNS muestran bajos valores de TTL.

El Tema de Su WordPress Es Importante

Todos aman un nuevo tema de WordPress, pero tenga cuidado antes de elegir uno, con todo y sus bonitas opciones. Primero, usted debería revisar nuestro articulo sobre las diferencias cuando se trata de temas gratuitos contra los de pago. Tratándose del desempeño, cada elemento que usted ve en un tema, tiene algo de impacto en la velocidad total de su sitio web. Y desafortunadamente, con miles de temas a elegir, habrá buenas y malas elecciones.

¿Cómo se supone que sepamos cuál elegir? Recomendamos elegir una de estas dos opciones:

• Un tema rápido y liviano de WordPress que este hecho sólo con las opciones que usted necesita, y nada más.
• Un tema más completo de WordPress, pero uno donde pueda desactivar opciones que no utilice.

Cosas como Google Fonts, Font Awesome icons, sliders, galerías, video y parallax scripts, etc. Estas son algunas de tantas cosas que debería poder apagar si no las está utilizando. No querrá tener que arreglarlas manualmente en otro momento. Y no le mostraremos 50 formas diferentes para hacer las cosas más sencillas. En su lugar, usted debería empezar o cambiarse a un tema de WordPress más liviano desde el principio o uno que le de estas opciones.

Abajo, le mostraremos un par de temas de WordPress que recomendamos. Confíe en nosotros, nos lo agradecerá en un futuro. 😉

Cada tema mencionado a continuación, es completamente compatible con WooCommerce y Easy Digital Downloads, WPML, BuddyPress, y bbPress. Hicimos algunas pruebas de velocidad con cada tema, utilizando la siguiente configuración.

• Que tenga como host a Kinsta, funcionando con WordPress 4.9.8
• PHP 7.3 y SSL (HTTPS)
• Kinsta CDN
• Imagify fue utilizando para comprimir automáticamente las imágenes.

GeneratePress

GeneratePress es un tema de WordPress rápido, liviano (menos de 1MB en zip), móvil, hecho con velocidad, SEO y usabilidad en mente. Hecho por Tom Usborne, un desarrollador de Canadá quien activamente lo actualiza y bien soportado. Incluso algunos de los miembros del equipo de Kinsta utilizan GeneratePress para sus proyectos.

Hay versión gratuita y premium. Si ve su repositorio de WordPress, la versión gratuita actualmente tiene más de 200,000 instalaciones activas, y más de 2 millones de descargas, y una impresionante calificación de 5 de 5 (con más de 850 personas calificando con 5 estrellas).

Una de las grandes cosas sobre GeneratePress es que todas las opciones utilizan un WordPress Customizer, queriendo decir que podrá ver todo cambio que haga de forma instantánea antes de presionar el botón de publicar. Esto también quiere decir que no tendrá que aprender un nuevo panel de control de temas.

¿Qué tan rápido es? Hicimos una instalación nueva de GeneratePress, corrimos cinco pruebas en Pingdom y tomamos el promedio. El tiempo total de carga fue de 305 ms con un total de tamaño de página de tan solo 16.8 KB. Siempre es bueno tener una prueba base para ver lo que puede hacer un tema en términos de desempeño puro.

Luego hicimos otro conjunto de pruebas, con uno de los temas preconstruidos de la biblioteca del sitio de GeneratePress. Este contiene imágenes, fondos, nuevas secciones, etc. Una ventaja que tiene GeneratePress es que tiene muchos temas preconstruidos que no requieren un plugin de construcción de páginas. Puede ver que aún así, se mantiene por debajo de 400 ms.

Por supuesto, en un entorno de la vida real, podría tener otras cosas activas, como Google Analytics, Facebook remarketing pixel, Hotjar, etc. Pero usted debería aspirar a conseguir una marca debajo de 1 segundo. Consulte nuestra detallada reseña de GeneratePress en woorkup.

Le estaremos mostrando formas para optimizar y acelerar su WordPress.

OceanWP

El tema de OceanWP es liviano y altamente extensible. Le permite crear casi cualquier tipo de sitio web, como lo es un blog, portafolio, sitio de un negocio o una tienda de WooCommerce, con un bello y profesional diseño. Hecho por Nicolas Lococq, es activamente actualizado y soportado.

Como con GeneratePress, hay versiones gratuitas y premium. Si ve su repositorio de WordPress, la versión gratuita actualmente tiene más de 400,000 instalaciones activas, y otra impresionante calificación de 5 de 5 (con más de 2,600 personas calificando con 5 estrellas).

¿Qué tan rápido es? Hicimos una instalación nueva de OceanWP, le hicimos cinco pruebas de velocidad en Pingdom, y tomamos el promedio. El tiempo total de carga fue de 389 ms con un total de tamaño de página de tan solo 230.8 KB. Los scripts en OceanWP son un poco más grandes, pero nada fuera de lo común.

Luego hicimos otra serie de pruebas con uno de los temas demo del sitio de la biblioteca de OceanWP. Este contiene imágenes, fondos, nuevas secciones y el plugin constructor de páginas requerido, Elementor. Usted podrá ver que sigue estando por debajo de 600 ms.

Puede ver una reseña más detallada de OceanWP en nuestro blog.

Astra

Astra es un rápido, completamente configurable y bello, perfecto para blogs, portafolios personales, sitios de negocios, y tiendas de WooCommerce. Es muy liviano (pesando menos de 50 KB en el front-end) y ofrece una velocidad inigualable. Hecho por el equipo de Brainstorm Force, es activamente actualizado y soportado. Podrá reconocerlos como los creadores del popular plugin All In One Schema Rich Snippets que ha estado en línea por varios años.

Como con GeneratePress y OceanWP, hay versiones gratuitas y premium. Si ve su repositorio de WordPress, la versión gratuita actualmente tiene más de 400,000 instalaciones activas, más de 1.6 millones de descargas, y otra impresionante calificación de 5 de 5 (con más de 2500 personas calificando con 5 estrellas).

¿Qué tan rápido es? Hicimos una instalación nueva de Astra, le hicimos cinco pruebas de velocidad en Pingdom, y tomamos el promedio. El tiempo total de carga fue de 243 ms con un total de tamaño de página de tan solo 26.6 KB.

Luego, hicimos otro conjunto de pruebas con uno de los temas demo del Kit Básico de Astra en la biblioteca de su sitio. Este contiene imágenes, fondos, nuevas secciones, se requiere el plugin constructor de páginas Elementos. Puede ver que aún así estará por debajo de los 700 ms. Nota: las imágenes en este demo están completamente comprimidas, pero ellos eligieron unas de alta resolución desde el principio.

Es importante ser un poco escéptico al tomar las diferencias entre pruebas de velocidad con estos tres temas. El problema es que es casi imposible hacer pruebas precisas y de comparación de ambas. Lo importante que queríamos mostrarle, es que todos estos temas de WordPress son extraordinariamente rápidos, ¡en sus versiones completas y en sus demos! 🚀

Advertencias Sobre los Constructores de Páginas

Como ya se habrá dado cuenta, OceanWP y Astra requieren constructores de páginas para utilizar los temas de la biblioteca de su sitio. Aquí hay algunas cosas que debe tener en mente al utilizar un plugin constructor de páginas:

• Algunos constructores de páginas podrían incrementar el tiempo de carga en su sitio. Esto es porque tienen que cargar adicionalmente el CSS y JS para hacer que las cosas funcionen si código. ¡Así es como sucede la magia! Siempre recomendamos hacer pruebas de velocidad en su sitio de WordPress antes y después de instalar un constructor de páginas.
• Usted se está comprometiendo y encadenándose a ese constructor de páginas por diseño. Asegúrese de elegir uno que sea actualizado regularmente y tenga todo lo que necesita a largo plazo.

Habiendo dicho esto, aún así, seguimos siendo fanáticos de los constructores de páginas como Elementor y Beaver Builder. En su mayoría, estos son desarrollados con el rendimiento en mente y tan sólo agregan un poco de carga extra. Para muchos, la funcionalidad y usabilidad valen la pena, ¡ya que estos plugins le permiten crear cualquier cosa con la que haya soñado! También podrían ser más rápidos en algunos casos, ya que podrían reemplazar hasta más de 5 plugins distintos que tendría que haber usado en su lugar.

Sin embargo, si no necesita un plugin constructor de páginas, adelante, no tiene porque instalarlo. También será interesante ver como el nuevo editor Gutenberg jugará un rol en el diseño de sitio en los próximos años.

Todo Sobre los Plugins de WordPress

Ahora hablemos sobre los plugins de WordPress. Es posible que le hayan dicho que no debe de instalar demasiados plugins o que podrían causar que su sitio de WordPress esté más lento. Mientras que en algunas ocasiones esto es cierto, no es el factor más critico. El número de plugins no es importante, sino la calidad de estos. Listo, ya lo dijimos. 😜

Al igual que con los temas, importa si el plugin fue desarrollado y fue construido con el desempeño en mente. Tenemos muchos clientes de Kinsta que utilizan 30 a 40 plugins en sus sitios y cargan en un segundo.

Mientras que es divertido agregar código a su sitio, no siempre es práctico por las siguientes razones.

1. Tiene que mantener el código usted mismo y mantenerlo actualizado mientras los estándares cambian. La gente está ocupada, ¿Por qué no depender de desarrolladores fantásticos que conocen mejor que nadie estos estándares?
2. La mayoría del tiempo, un plugin bien programado no introducirá mucha carga más que el mismo código.
3. Tiene que recordar que la mayoría de la comunidad de WordPress no es tan conocedora de tecnología como lo sería un grupo de desarrolladores. Los plugins son soluciones que ayudan a resolver problemas.

Por supuesto también podemos encontrar plugins que no son tan buenos, y lo mejor sería alejarse de estos. Confíe en nosotros; hemos visto lo peor de lo peor en Kinsta. Muchos, no todos, de los plugins que hemos prohibido usar en Kinsta fue porque notamos problemas de desempeño al ser usados. Más adelante, también hablaremos sobre como identificar plugins malos en su sitio.

Francesco tiene una publicación interesante en la que se sumerge en la prueba de velocidad de los plugins de WordPress para ver cómo desempeñan en el back-end de un sitio de WordPress, que en la mayoría de los casos no se almacena en caché. Nos adentraremos en cómo encontrar plugins erróneos en su sitio más adelante.

Sin embargo, no podemos ignorar que una de las cosas que la gente ama de WordPress es su biblioteca masiva de plugins. Pero con más de 56,000 plugins gratuitos listados tan sólo en WordPress.org, y miles más en otros lados, puede ser difícil encontrar el plugin que necesita. ¡Es como encontrar una aguja en un pajar! Vea está lista que hemos compilado con solo los mejores plugins de WordPress en el mercado.

Sólo compartimos las cosas que utilizamos a diario. Y si, utilizamos plugins de WordPress en nuestro sitio como todos los demás. Incluso, muchos de los miembros del equipo en Kinsta han desarrollado y puesto a la venta sus propios plugins.

Un Gran Problema con los Plugins de WordPress

Un gran problema con los plugins de WordPress es el proceso de desinstalación. Sin importar que esté instalando un plugin o tema de WordPress, este almacena los datos en la base de datos. El problema es que cuando uno intenta borrar un plugin, usando uno de los métodos estándar, este, típicamente deja atrás tablas y filas en su base de datos. Con el tiempo, esto puede ir apilándose y hacer que su sitio empiece a estar más lento. En nuestro ejemplo, desinstalamos el plugin de seguridad Wordfence, y dejó atrás 24 tablas en nuestra base de datos (como puede ver abajo). Esto es mucho peor si dejan atrás datos en su tabla de wp_options.

Además de la base de datos, muchos de los plugins dejan atrás carpetas y archivos adicionales. En nuestra experiencia, esto es comúnmente visto en los plugins de seguridad y de cache que han creado directorios adicionales para iniciar sesión. Por ejemplo, después de haber borrado el plugin de Wordfence, nos dejó atrás una carpeta llamada “wflogs” en nuestro directorio de contenido. Y la intención no es hablar mal de Wordfence, la gran mayoría de plugins y temas en el mercado funcionan de esta manera.

¿Por Qué Hacen esto los Desarrolladores?

Así que se estará preguntando, ¿por qué no los desarrolladores agregan opciones de auto depuración cuando uno desinstala y borra un plugin? Bueno, sí lo hacen. Pero, hay algunas razones por las que no son tan obvias al principio.

1. Desean retener las opciones para el usuario. Si borra un plugin y decide usarlo de nuevo en otro momento, todas sus configuraciones y datos seguirán ahí. Mientras que esto es super conveniente, no es la forma más eficiente de hacerlo.
2. No les interesa su rendimiento. Algunos desarrolladores podrían decir que dejar en su lugar las tablas no causa un impacto en el desempeño. Pero imagínese un sitio, después de diez años, habiendo usado cientos de plugins, que han generado miles de filas o tablas. Las peticiones de la base de datos tienen un impacto importante en el desempeño de su sitio de WordPress, y los plugins pueden hacer muchas de estas peticiones si el desarrollador no tuvo cuidado. Generalmente, un plugin bien escrito sólo debería hacer una consulta a las tablas o filas a las cuales estaba atada, sin embargo, esto no siempre es el caso, lo hemos visto de primera mano en Kinsta, largos queries de base de datos haciendo que un sitio, vaya super lento, debido a datos auto cargados de forma innecesaria en la tabla wp_options, los cuales han sido dejados atrás.
3. Han cometido un error. El manual de plugins de WordPress dice que “algunos desarrolladores, no tan experimentados, en algunas ocasiones cometerán el error de utilizar un gancho de desactivación para este propósito.”

¿Las buenas noticias? Hay formas de limpiar y deshacerse de un plugin de forma apropiada. Consulte los siguientes tutoriales.

• Cómo Desinstalar un Plugin de WordPress (de forma apropiada)
• Cómo Limpiar las Tablas Dejadas Atrás

Configuración Optima de WordPress

Ahora, es momento de pasar a la configuración optima de WordPress. Hay un par de cambios que puede hacer para acelerar su sitio de WordPress. Muchos de estos cambios son sutiles, ¡pero todo esto puede ser de ayuda!

Cambie la URL de Inicio de Sesión de WordPress

Por defecto la URL de inicio de sesión de su sitio de WordPress es domain.com/wp-admin/. Uno de los problemas con esto, es que todos los bots, hackers, y scripts también saben esto. Al cambiar la URL, usted ya no será un objetivo (o por lo menos ya no tanto), mejor protéjase ante entradas forzosas, y reduzca el ancho de banda usado por bots que llegan a su URL constantemente.

Cambiar la URL de inicio de sesión de WordPress puede ayudar a prevenir errores comunes, como el “429 Demasiadas Peticiones.” Esto no es una solución para todo, es un simple truco que puede ayudarle a proteger y reducir la carga en ese sitio.

Para cambiar la URL de su inicio de sesión de WordPress, recomendamos utilizar uno de los siguientes plugins:

• WPS Hide Login (gratuito)
• Perfmatters (premium, pero incluye otras opciones de optimización de desempeño. Desarrollado por un miembro del equipo de Kinsta)

Deshabilite o Configure las Actualizaciones de los Plugins y Temas

Los dashboards de admin lentos de WordPress pueden ser impactados por la red, ubicación de los centros de datos, e incluso versiones de PHP. Pero otro factor del que no hablan muchos es el chequeador de actualizaciones de WordPress que funciona en el fondo. Esta es una instancia donde el tener muchos plugins y temas de WordPress podría afectarle. WeFoster tiene un excelente articulo sobre esto, donde la frase clave es “Síndrome de Chequeo de Actualizaciones de Plugins de Terceras Partes” o por sus siglas en inglés TPPUCS (Third Party Plugin Update Check Syndrome).

Esencialmente el problema es que el chequeador de actualizaciones de WordPress, es el que hace una petición GET externa detrás de las escenas (https://third-party-plugin/update-check.php). En algunas ocasiones esto puede ser periódico o muy frecuente. Si está pasando todo el tiempo, esto podría dejar completamente inservible su dashboard de admin.

Esto es un problema con la forma en que el chequeador de actualizaciones de WordPress fue construido. Si está sufriendo de un tiempo de carga lenta en el dashboard de WordPress, podría querer intentar esto. El remedio es deshabilitar las actualizaciones automáticas. Advertencia: Haga esto sólo si pretende hacer las actualizaciones manualmente. Muchas actualizaciones incluyen arreglos de seguridad y de bugs.

Para desactivar las actualizaciones, le recomendamos utilizar uno de los siguientes plugins:

• Disable All WordPress Updates: Completamente gratuito sin opciones. Hace lo que hace muy bien.
• Easy Updates Manager: Brinda más control sobre la selección de actualizaciones. La versión básica es gratuita.

Fácilmente podría poner un recordatorio en su calendario, para deshabilitar el plugin una vez por semana, checar todas las actualizaciones y reactivarlo.

Desactivando Pingbacks

Un pingback es un comentario automatizado que es creado cuando otro blog tiene un enlace al suyo. También puede haber pingbacks propios que son creados cuando uno enlaza a un articulo propio en su blog.

Le recomendamos simplemente desactivar estos, ya que generan peticiones innecesarias y spam adicional en su sitio. Recuerde, entre menos llamadas su sitio de WordPress haga, será mejor, especialmente en sitios de alto tráfico. Sin mencionar el hecho de que un pingback en su sitio web es algo molesto. Siga estos pasos para desactivar los pingbacks.

Paso 1 – Desactive los Pingbacks de Otros Blogs

En su dashboard de WordPress, de clic en “Opciones -> Discusión.” Debajo de la sección de Discusión, desactive la opción de “Permitir notificación por enlaces de otro blog (pingbacks y trackbacks) en nuevos artículos.”

Paso 2 – Desactivando los Pingbacks Propios

Cuando se trata de desactivar los pingbacks propios, tiene un par de opciones. Puede utilizar el plugin gratuito No Self Pings. O utilizar un plugin premium como Perfmatters.

De forma alternativa, también podría desactivar los pingbacks propios agregando el siguiente código al archivo functions.php de su tema de WordPress. Pero cuidado, editar la cuenta de un tema de WordPress podría deshabilitar su sitio si no se hace de la forma correcta. Un consejo, usted puede agregar fragmentos de PHP como este con el plugin gratuito Code Snippets. Esto quiere decir que jamás tendrá que tocar su tema.

function wpsites_disable_self_pingbacks( &$links ) {
 foreach ( $links as $l => $link )
 if ( 0 === strpos( $link, get_option( 'home' ) ) )
 unset($links[$l]);
}
add_action( 'pre_ping', 'wpsites_disable_self_pingbacks' );

Limitar Publicaciones en el Contenido de su Blog

Si su blog de contenido está establecido como su página principal o utiliza otra página de su sitio, usted no necesita 50 thumbnails cargando al mismo tiempo. Para aquellos que tengan un blog con alto tráfico, su página de inicio es la página más importante de su sitio, y usted querrá que cargue rápido. Entre menos peticiones y archivos multimedia tenga, será mejor en términos de desempeño.

También, esta es la razón por la cual se inventó la paginación (como se puede ver a continuación). La paginación es lo que usted ve al final del contenido de un blog que permite que pueda navegar a la siguiente página. Típicamente se usan números, o podrían utilizar “siguiente/anterior” publicación. Su tema de WordPress probablemente tenga un sistema de paginación incluido.

WordPress por defecto establece un limite de instalaciones frescas de WordPress a 10, pero hemos visto que esto cambie tantas veces, que hasta ya perdimos la cuenta. Así que asegúrese de checar dos veces para ver qué valor está usando. Nosotros le recomendamos algo entre los 8 y 12. Si tiene curiosidad, estamos utilizando 12 en la página de inicio de nuestro blog de Kinsta.

Podrá encontrar esta opción en el dashboard de admin. de WordPress bajo “Opciones -> Lectura.” Luego, puede cambiar el valor por “Máximo número de páginas mostrado.”

¿Por Qué el Caché Es Tan Importante?

¡El caché es sin duda alguna una de las formas más importantes y sencillas para acelerar WordPress! Pero antes de enseñarle como usar el caché, es esencial primero entender cómo funciona y los distintos tipos de caché disponibles.

¿Qué Es el Caché?

En pocas palabras, cada página web que uno visita en su sitio de WordPress requiere una petición al servidor, ser procesado por ese servidor (incluyendo los queries de la base de datos), y luego un resultado final enviado desde el servidor hasta el navegador del usuario. El resultado es su sitio web, completo, con todos los archivos y elementos que hacen que luzca como es.

Por ejemplo, podría tener un encabezado, imágenes, un menú, un blog. Ya que el servidor tiene que procesar todas esas peticiones, toma un poco de tiempo para que se entregue al usuario la página web completa – especialmente con sitios web desordenados o más grandes.

¡Aquí es cuando entra el plugin de WordPress caching! El caché instruye al servidor a almacenar algunos archivos al disco o al RAM, dependiendo de la configuración. Así que, puede recordar y duplicar el mismo contenido que ha estado sirviendo en el pasado. Básicamente, reduce la cantidad de trabajo requerido para generar una vista de la página. Como resultado, sus páginas web cargarán mucho más rápido, directamente desde el caché.

Algunos beneficios del caché incluyen:

• Su servidor utiliza menos recursos – Esto está atado a la velocidad, ya que menos recursos hacen que un sitio sea más rápido. Sin embargo, también pone menos estrés en su servidor. Esto es muy importante cuando se trata de sitios altamente dinámicos, como los sitios de membresía, y determinar lo que uno puede servir y no servir del caché.
• Usted notará un TTFB menor – El caché es una de las formas más sencillas para reducir su TTFB. De hecho, ¡en nuestras pruebas el caché típicamente reduce el TTFB hasta en un 90%!

Tipos de Caché

Cuando se trata de tipos de caché, hay dos enfoques distintos que son comúnmente usados:

1. Caché a Nivel Servidor
2. Caché con un Plugin

1. Caché a Nivel Servidor

El caché a nivel servidor es uno de los enfoques más sencillos para el usuario final. Esto quiere decir que el proveedor de hosting de WordPress se encarga de esto por usted. En Kinsta, nosotros utilizamos los siguientes cuatro tipos de caché, los cuales son automáticamente usados en el software o a nivel servidor:

• Caché Bytecode
• Caché de Objeto
• Caché de Página
• Caché CDN

Esto quiere decir que no tendrá que preocuparse de tener que lidiar con plugins de caché complicados y confusos. Puede dejar de usar Google, buscando “el mejor plugin de caché para el 2024” y enfocarse más en tareas productivas. 👏

An instant 37% reduction in the loading time after moving @WPColt to @kinsta! (NO CACHING PLUGINS) 🚀🚀🚀

— WPColt (@WPColt) January 3, 2018

El caché de la página está configurado para funcionar desde el principio con el WordPress estándar. ¡No tendrá que hacer nada! Simplemente abra su sitio de WordPress y el caché de la página empezará a funcionar.

También tenemos reglas de caché para sitios de ecommerce, como WooCommerce y Easy Digital Downloads. Por defecto, ciertas páginas que no deberían ser puestas en el caché, como el carrito de compras, mi cuenta y la página de pago, están excluidas del caché. Los usuarios automáticamente se saltarán el caché cuando la cookie woocommerce_items_in_cart o la de edd_items_in_cart sean detectadas para asegurar un proceso de sincronización de pago correcto.

Fácilmente puede borrar el caché de su sitio de WordPress en cualquier momento desde la barra de herramientas de admin.

También está integrada en nuestro dashboard de MyKinsta. Sólo de clic en Herramientas y de clic en “Limpiar Caché.”

2. Caching with a Plugin

Si su proveedor de hosting no ofrece un caché, usted puede utilizar un plugin de caché para WordPress externo. Basándonos en nuestra experiencia. Recomendamos uno de los siguientes:

1. WP Rocket (premium)
2. Cache Enabler (gratuito)
3. W3 Total Cache (gratuito)

También puede checar algunas opciones adicionales en nuestro detallado artículo sobre los plugins de caché de WordPress.

¡También ofrecemos soporte completo para WP Rocket en Kinsta! Usualmente no permitimos plugins de caché en nuestro entorno porque normalmente entran en conflicto con nuestra solución de caché interna. Sin embargo, a partir de la versión 3.0 de WP Rocket, su función de caché de página será automáticamente desactivada al utilizar servidores de Kinsta.

Esto les permite a los clientes de Kinsta utilizar nuestro caché a nivel servidor súper rápido, pero aún obtener la ventaja de las fantásticas opciones de optimización que WP Rocket tiene para ofrecer.

Sin Caché vs con Caché

¿De qué tanto sirve el caché? La prueba está en el pudín.

Hicimos algunas pruebas de velocidad con el caché a nivel servidor de Kinsta, para que pueda ver las diferencia que hace, en términos de velocidad general y TTFB.

Sin Caché

Primero hicimos cinco pruebas en Pingdom sin el caché habilitado y tomamos el promedio.

TTFB sin Caché

También es importante tomar en cuenta la diferencia en el TTFB sin y con caché. El TTFB en Pingdom está representado por una barra de “espera” amarilla. Como puede ver el TTFB sin caché es de 192 ms. Podrá ver que no está sirviendo desde el caché ya que el encabezado x-kinsta-cache está mostrando un MISS (Faltante).

Con Caché Habilitado

Luego habilitamos el caché a nivel del servidor e hicimos cinco pruebas en Pingdom y tomamos el promedio.

¡Como puede ver el caché a nivel servidor disminuyó el tiempo de carga de nuestra página por un 33.77%! y esto es sin el trabajo extra requerido. Este sitio que pusimos a prueba estaba bien optimizado, así que algunos grandes sitios sin optimizar verán diferencias mayores.

TTFB con el Caché Habilitado

Ahora si vemos el TTFB con el caché habilitado, podemos ver que se encuentra por debajo de 35 ms. Podrá ver que no está sirviendo desde el caché ya que el encabezado x-kinsta-cache está mostrando un HIT.

El caché de CDN es igual de importante que el caché de su host de WordPress. Hablaremos más detalladamente sobre las CDNs más adelante.

Problemas con el Caché y los Sitios de Membresía

Los sitios de membresía contienen mucho contenido que no puede ser alojado en el caché, igual tiene páginas que se encuentran continuamente cambiando. Las cosas como la página de inicio de sesión para los miembros de la comunidad (la cual estaría recibiendo hits contantes dependiendo del tamaño del sitio), las páginas de pago para artículos o cursos digitales, y los foros de discusión son culpables comunes y puntos de dolor, ya que usualmente estas no pueden estar en el caché.

Sin embargo, esto no termina aquí. En sitios de WordPress estándar, el dashboard de WordPress tampoco está almacenado en el caché para los usuarios “que ya iniciaron sesión”. Esto está bien cuando tiene algunos autores y admins, pero cuando de pronto, tiene miles de miembros utilizando el dashboard, esto inmediatamente causa problemas de desempeño ya que ni uno puede servirse del caché en el servidor. Esto quiere decir que usted necesitará la potencial y arquitectura detrás de las escenas para respaldarlo. Los proveedores de hosting compartido usualmente colapsan bajo estas circunstancias.

Caché de Objeto para Sitios Altamente Dinámicos

Cuando se trata de sitios de membresías de WordPress, las configuraciones comunes de caché usualmente no son suficientes ya que no toman ventaja total de estas. Aquí es donde entra en juego el caché de objeto.

El caché de objeto almacena los resultados de los queries de la base de datos para que la próxima vez que un pedazo particular de dato es requerido, este pueda ser entregado desde el caché, sin la necesidad de hacer consulta a la base de datos (una petición). Esto acelera los tiempos de ejecución de PHP y reduce la carga en su base de datos. ¡Esto es extremadamente importante en sitios de membresía! Con WordPress, usted puede implementar caché de objeto en un par de formas distintas:

1. Una solución de caché como W3 Total Cache
2. Redis (recomendada)
3. Memcached

Nosotros ofrecemos Redis como un add-on en Kinsta, para que pueda tomar total ventaja de caché de objeto persistente para sus sitios de membresía.

Caché de Análisis

¿Recuerda el encabezado x-kinsta-cache que hemos mencionado anteriormente? Dependiendo del proveedor de host o solución de caché, el encabezado podría ser llamado de forma un poco distinta. Cada vez que se hace una petición, desde su sitio de WordPress, ese encabezado tiene un valor, como HIT, BYPASS, MISS y EXPIRED. Esto le permite ver como se está desempeñando su caché.

Incrementar el rango de hit del caché de su sitio de WordPress es importante porque usted necesita que la gran mayoría de su sitio esté servida desde el caché si es que es posible. En Kinsta usted puede analizar los datos en nuestro MyKinsta analytics tool y el Kinsta cache logs para determinar si hay caché que esté BYPASSing (Traspasando) peticiones GET que podrían estar alojadas en el caché o peticiones POST que podrían ser eliminadas.

El stack de componentes del caché (como se muestra abajo) le permite ver el estado de cada petición, sea un HIT, BYPASS, MISS o EXPIRED. Usted puede filtrar los datos de las últimas 24 horas, 7 días o 30 días.

La gráfica de componentes de caché le da un pequeño vistazo al rango de su caché. Entre más peticiones usted sirva desde el caché, será mucho mejor. Como puede ver en el ejemplo de abajo, este sitio de WordPress se encuentra en un rango de caché de 96.2% HIT. ¡Eso es bueno!

La sección de los traspasos más altos del caché le permite ver qué peticiones no están siendo servidas desde el caché. Típicamente estas podrían incluir CRON jobs, peticiones admin-ajax, páginas de pago de ecommerce, query strings, y parámetros UTM, etc.

La Optimización de Imágenes Es Necesaria

La optimización de imágenes es otra cosa directa que usted puede hacer, que tiene un alto impacto en el tiempo de carga total de su página. Esto no es opcional; ¡todo sitio debería estar haciendo esto!

Las grandes imágenes disminuyen la velocidad de sus sitios web, lo cual no crea una experiencia de usuario óptima. La optimización de imágenes es el proceso de reducir el tamaño de su archivo, utilizando un plugin o un script, lo cual terminará acelerando el tiempo de carga de la página. Compresión lossy y lossless son dos métodos comúnmente utilizados.

De acuerdo a HTTP Archive, desde agosto de 2019, las imágenes ocupan un promedio del 34% del peso total de la página web. Así que, después de los videos, los cuales son mucho más difíciles de optimizar, ¡las imágenes son por mucho el primer lugar donde debería comenzar! Es más importante que JavaScript, CSS y Fonts. E irónicamente, un buen flujo de trabajo de optimización de imágenes es una de las cosas más sencillas de implementar, aún así, la mayoría de los dueños de sitios web pasan esto por alto.

Las imágenes ocupaban en promedio un 54% del peso total de las páginas en el período de diciembre de 2017. Así que, aparentemente, la red como un total, ¡se está haciendo mejor en optimizar las imágenes! Pero un 34% sigue siendo un número que no puede ser ignorado. Si no tiene contenido en vídeo en su sitio web, las imágenes aún seguirán siendo el punto crítico #1 para el peso de la página.

Encontrando el Equilibrio (Tamaño y Calidad del Archivo)

La meta principal del formato de sus imágenes es encontrar el equilibrio correcto entre el tamaño del archivo más bajo y una calidad aceptable. Hay más de una forma de llevar a cabo la mayoría de estas optimizaciones. Una de las formas más básicas es comprimirlas antes de empezar a subirlas a WordPress. Usualmente, esto se puede hacer mediante una herramienta como Adobe Photoshop o Affinity Photo. O utilizando la nueva app online de Squoosh de Google. Sin embargo, estas tareas también pueden ser desempeñadas de forma automática, utilizando plugins, de los que hablaremos más adelante.

Las dos cosas primarias a considerar son el formato del archivo y el tipo de compresión que utiliza. Al elegir la combinación correcta del formato del archivo y tipo de compresión, usted puede reducir el tamaño de la imagen hasta 5 veces más. Usted tendrá que experimentar con cada imagen o formato de archivo para ver cuál funciona mejor.

Antes de empezar a modificar sus imágenes, asegúrese de que haya elegido el mejor tipo de archivo. Hay varios tipos de archivos que puede utilizar:

• PNG – produce imágenes de más alta calidad, pero también tiene un mayor tamaño de archivo. Fue creada como un formato de imagen sin pérdida, a pesar de que también puede ser con pérdida.
• JPEG – utiliza optimización con o sin pérdida. Usted puede ajustar la calidad para un buen balance de calidad y tamaño de archivo.

Idealmente, usted debería utilizar JPEG (o JPG) para imágenes con muchos colores y PNG para imágenes más simples.

También debería considerar el uso de imágenes WEBP en su sitio web.

¿Y los GIFs? Los GIFs animados siempre serán divertidos, pero estos matarán el desempeño de su sitio. Muchos GIFs están por arriba de 1 MB de tamaño. Recomendamos mantener estos para las redes sociales y Slack. Si hay alguno sin el cual no pueda vivir en su blog, entonces revise como puede comprimir GIFs animados.

Calidad de Compresión vs Tamaño

Aquí tenemos un ejemplo de lo que puede pasar cuando uno comprime demasiado una imagen. El primero está utilizando un rango de compresión bajo, el cual resulta en calidad más alta (pero un tamaño de archivo más grande). El segundo está utilizando un rango de compresión más alto, el cual resulta en una imagen de menor calidad (pero de menor tamaño). Nota: la imagen original sin modificar pesa 2.06 MB.

Como puede observar la primera imagen rebasa los 590 KB. ¡Esto es muy grande para una sola foto! Lo mejor es mantener el peso total de su sitio por debajo de 1 o 2 MB. 590 KB sería un cuarto de ese total. La segunda imagen luce terrible, pero pesa tan solo 68 KB. Lo que necesita lograr, es encontrar un bonito equilibrio, entre el rango de compresión (calidad) y el tamaño del archivo.

Así que tomamos la imagen de nuevo a un rango de compresión media, como podrá observar abajo, la calidad luce bien ahora, y el tamaño del archivo es de 151 KB, el cual es aceptable para una foto de alta resolución. Tratamos de mantener la mayoría de nuestras imágenes debajo de la marca de 100 KB para tener mejor desempeño.

Optimización Lossy vs Lossless (con o sin Pérdida)

También es importante entender que hay dos tipos de compresión que puede utilizar, lossy y lossless

La compresión lossy elimina información de los datos en su imagen. Como resultado, usted podría ver una degradación (reducción en la calidad o a lo que muchos llaman una imagen pixelada). Así que tiene que tener cuidado cuando reduce su imagen. No sólo por la calidad, sino porque no podrá revertir el proceso. Por supuesto, uno de los grandes beneficios de la compresión lossy y la razón por la que es uno de los métodos de compresión más populares es que uno puede reducir el tamaño del archivo por una cantidad considerable.

La compresión sin pérdida, a diferencia del lossy, no reduce la calidad de la imagen. ¿Cómo es esto posible? Usualmente se consigue al eliminar metadatos innecesarios (datos automáticamente generados producidos por el dispositivo que captura la imagen). Sin embargo, la desventaja más grande a este método es que no podrá ver una reducción de tamaño de archivo significativa. En otras palabras, usará mucho espacio de disco a la larga.

Querrá experimentar con lo que funcione mejor para usted. Pero para la mayoría de los usuarios, recomendamos utilizar compresión lossy debido a que podrá comprimir fácilmente una imagen hasta un 70% (incluso hasta 90%) sin perder mucha calidad. Multiplique esto por 15 imágenes en una página, y esto jugará un rol importante en reducir el tiempo de carga de su sitio.

Plugins de Compresión de Imágenes

Las buenas noticias es que hay algunos plugins de compresión de imágenes sorprendentes para WordPress que puede utilizar para automatizar el proceso entero. Aquí tenemos algunos plugins que le recomendamos:

• Imagify (lossy y lossless – optimiza imágenes externamente)
• WP Smush (lossy y lossless – optimiza imágenes externamente)
• Optimole (lossy y lossless- optimiza imágenes externamente)
• ShortPixel (lossy y lossless – optimiza imágenes externamente)

La cosa más importante al elegir un plugin de optimización de imagen es utilizar una que comprima y optimice las imágenes externamente en sus servidores. Esto, causa una reducción en la carga de su sitio. Todas las mencionadas arriba hacen esto.

Si tiene curiosidad, nosotros utilizamos el plugin de Imagify en el sitio de Kinsta. Este automáticamente comprime imágenes cuando las subimos a la biblioteca multimedia en WordPress. Así que jamás tenemos que preocuparnos. Con el tiempo usted sabrá qué nivel de compresión de imagen desea. Ofrece modo Normal, Agresivo y Ultra.

Nosotros usamos el modo Agresivo en Kinsta y normalmente vemos un ahorro del 60-70% dependiendo de la imagen. Nota: utilizamos muchos más PNGs que JPEGs debido a que la mayoría de nuestras imágenes son iconos e ilustraciones, no utilizamos fotos.

¿Qué tan rápido podría quedar su sitio de WordPress al usar un compresor de imágenes? Depende del tamaño de sus imágenes originales y cómo quedan después de la compresión. Sin embargo, ¡hicimos unas pruebas de velocidad y descubrimos que una solución de calidad de compresión de imagen puede reducir el tiempo de carga de una página hasta un 80%!

Lazy Loading

Si tiene muchas imágenes, podría considerar hacerles carga diferida (lazy loading). Esta es una técnica de optimización que carga contenido visible, pero retrasa la carga y la visualización del contenido que aparece debajo del fold.

Revise nuestra guía sobre cómo implementar lazy loading en WordPress. Este puede ser muy importante para publicaciones de blog con muchos iconos de gravatar de los comentarios. Google acaba de publicar sus recomendaciones para lazy loading.

Consejos Adicionales de Optimización de Imagen

Aquí hay algunos consejos de optimizaciones de imagen finales para tener en mente.

• Los días de subir imágenes escaladas al ancho de la columna o DIV han terminado. Las imágenes responsivas funcionan desde el principio en WordPress (desde la versión 4.4) y automáticamente mostrarán tamaños de imagen mucho más pequeñas para usuarios móviles.
• SVGs pueden ser otra forma alternativa sorprendente a usar imágenes. Todas las ilustraciones hechas a mano que ve en el sitio de Kinsta son SVGs (vectores). Los SVGs son típicamente mucho más pequeños en tamaño de archivo, aunque no siempre. Revise nuestro tutorial sobre cómo utilizar los SVGs en su sitio de WordPress
• Use fuentes de iconos en lugar de poner texto dentro de las imágenes  – se ven mejor y ocupan menos espacio. Y si está usando un generador de fuentes puede optimizarlas aún más. Aprenda cómo disminuimos el tamaño de la fuente del icono de nuestro archivo por un 97,59% usando un generador de fuentes.

Optimizando Su Base de Datos

Ahora le dejaremos algunos consejos sobre cómo optimizar la base de datos de su WordPress. Al igual que un coche, su base de datos necesita mantenimiento, ya que con el tiempo puede hincharse.

Los sitios de membresía son especialmente complejos, ya que usualmente generan más consulta complejas, las cuales agregan latencia adicional al sacar la información de la base de datos de MySQL. Mucho de esto es debido a las piezas móviles adicionales y grandes cantidades de datos que tienen. Esto podría ser causado por sitios que dependen mucho de los queries de búsqueda para la navegación o para utilizar WP_Query.

Sin mencionar, también tendrá grandes cantidades de usuarios concurrentes continuamente haciendo consultas a su base de datos.

Utilice el Motor de Almacenamiento de InnoDB MySQL

Muchos de los viejos sitios aún utilizan el motor de almacenamiento de MyISAM en su base de datos. En años recientes, InnoDB, ha mostrado un mejor desempeño y una mayor confiabilidad.

Aquí le dejamos un par de ventajas de InnoDB vs MyISAM:

• InnoDB tiene un seguro a nivel fila. MyISAM sólo tiene un seguro a nivel tabla. Esto le permite a sus queries procesar más rápido.
• InnoDB tiene a lo que llamamos integridad referencial la cual involucra soportar llaves foráneas (RDBMS) y limitaciones de relación, MyISAM no hace esto (DMBS).
• InnoDB soporta transacciones, lo cual quiere decir que puede comprometerse y regresar a como estaba antes. MyISAM no puede hacer esto.
• InnoDB es más confiable, ya que utiliza registros transaccionales para auto recuperación. MyISAM no.

Así que podría estar preguntando, ¿está utilizando InnoDB o MyISAM? Si está usando un sitio relativamente nuevo de WordPress, es posible que ya esté utilizando el motor de almacenado InnoDB MySQL. Pero con sitios más antiguos de WordPress podría querer revisar esto. Algunos sitios podrían tener una mezcla de tablas MyISAM y de InnoDB, y podría ver mejoras al convertirlas todas.

Siga estos simples pasos de abajo para revisar lo anterior.

Paso 1

Inicie sesión a phpMyAdmin y de clic en la base de datos de MySQL.

Paso 2

Haga un escaneo rápido u ordene por “Tipo” en la columna, y podrá ver qué tipos de Motor de Almacenamiento están utilizando sus tablas. En el ejemplo de abajo, puede ver que dos de los tipos de las tablas siguen utilizando MyISAM.

Borrando y Límite de Página y Revisiones de Publicaciones

Cuando uno guarda una página o publicación en WordPress, esta crea a lo que llamamos una revisión. Esto ocurre en los borradores y en publicaciones ya publicadas que son actualizadas. Las revisiones de WordPress pueden ser útiles en caso de que necesite revertir a una versión previa de su contenido.

Sin embargo, las revisiones también pueden dañar el desempeño de su sitio de WordPress. En sitios más grandes, esto puede irse acumulando muy rápido a miles de filas en su base de datos que no son necesarias. Y entre más filas tenga, más grande será el tamaño de la base de datos, la cual ocupa espacio en disco. Mientras que los índices fueron creados por este propósito, aún vemos cómo este problema afecta a los sitios de WordPress. Hay un par de cosas que puede hacer.

1. Borrando Viejas Revisiones

Si usted tiene un viejo sitio de WordPress con muchas páginas y publicaciones, podría ser momento de hacer una rápida depuración y borrar esas viejas revisiones. Puede hacer esto con MySQL, pero con todos los malos fragmentos de código flotando alrededor de la red, le recomendamos hacer un backup de su sitio y utilizar un plugin gratuito como WP-Sweep.

Otro de nuestros plugins favoritos, WP Rocket, también tiene una opción de optimización para bases de datos para poder depurar las revisiones.

Si usted sabe utilizar WP-CLI, hay un par de comandos que puede utilizar para esto.

Ingrese a su servidor a través de SSH y use el siguiente comando para obtener y ver el número de revisiones actuales en la base de datos.

wp revisions list

Si usted obtiene un error, podría necesitar primero instalar el paquete wp-revisions-cli con el siguiente comando:

wp package install trepmal/wp-revisions-cli

Luego puede utilizar el siguiente comando para limpiar las revisiones:

wp revisions clean

2. Limitar Revisiones

Otra buena estrategia y una que utilizamos en Kinsta es limitar el número de revisiones que pueden ser almacenadas por publicación o página. Incluso establecer un límite de quizás diez, evitará que las revisiones se salgan de control, especialmente si hace muchas actualizaciones.

Para limitar revisiones, usted puede agregar el siguiente código a su archivo wp-config.php. El código de abajo necesita ser insertado arriba de ‘ABSPATH’, de otra forma, no funcionará. Puede cambiar el número al número de revisiones que usted quiera mantener almacenados en la base de datos.

define('WP_POST_REVISIONS', 10);

O puede utilizar un plugin como Perfmatters para limitar revisiones.

3. Desactivando Revisiones

Y, por último, pero no por eso menos importante, también puede deshabilitar completamente las revisiones en su sitio. Si elije hacer esto, le recomendamos seguir la primera opción de arriba para borrar revisiones y luego deshabilitarlas. De esta forma su base de datos estará completamente libre de toda la vieja revisión y no se agregarán nuevas de ahora en adelante.

Para deshabilitar revisiones, puede agregar el siguiente código a su archivo wp-config.php. El código de abajo necesita ser insertado arriba de ‘ABSPATH’ de otra forma, no funcionará.
define('WP_POST_REVISIONS', false);

O puede utilizar un plugin como Perfmatters para deshabilitar revisiones.

Limpie su Tabla de wp_options y Datos Autocargados

La tabla de wp_options normalmente no es tomada en cuenta cuando se trata en general de WordPress y el desempeño de la base de datos. Especialmente en sitios viejos y grandes, este puede ser fácilmente el culpable por tiempos de consultas lentas en su sitio debido a datos autocargados que son dejados atrás por plugins y temas. Confíe en nosotros; vemos esto todos los días.

La tabla wp_options contiene todo tipo de datos para su sitio de WordPress como:

• URL del sitio, URL de página de inicio, email del admin, categoría por defecto, publicaciones por página, formato de tiempo, etc.
• Configuración para plugins, temas y widgets
• Datos temporalmente almacenados en el caché

Esta tabla contiene los siguientes campos (columnas):

• option_id
• option_name
• option_value
• autoload (este es el que nos importa cuando se trata de desempeño)

Una de las cosas más importantes a entender sobre la tabla wp_options es el campo de autocargado. Este contiene un valor de sí o de no (flag). Esto esencialmente controla si ha sido cargado o no por la función wp_load_alloptions(). Los datos autocargados son  datos que son cargados en cada página de su sitio de WordPress. Ya le mostramos cómo deshabilitar que ciertos scripts sean cargados en todo el sitio, la misma idea aplica aquí. El atributo de autocargado está en “sí” por defecto para los desarrolladores, pero teóricamente, no todos los plugins deberían cargar sus datos en cada página.

Un problema que los sitios de WordPress podrían encontrarse, es cuando hay una gran cantidad de datos autocargados en la tabla wp_options. Este típicamente es un resultado de lo siguiente:

• Los datos están siendo autocargados por un plugin cuando debería estar establecido como “no.” Un buen ejemplo de esto sería un plugin de formulario de contacto. ¿Necesita cargar datos en cada página o sólo la página de contacto?
• Los plugins o temas han sido eliminados del sitio de WordPress, pero sus opciones siguen estando en la tabla de wp_options. Esto podría significar que los datos autocargados innecesarios siguen siendo consultados en cada petición.
• Los desarrolladores de plugins y temas están cargando datos en la tabla de wp_options en lugar de utilizar sus propias tablas. Hay argumentos para ambos lados tratándose de esto, ya que algunos desarrolladores prefieren plugins que no creen tablas adicionales. Sin embargo, la tabla de wp_options no fue diseñada para retener miles de filas.

¿Cuál es el límite de los datos autocargados? Esto puede variar, pero idealmente, usted tiene que tener esto entre 300 KB a 1 MB. Una vez que empiece a acercarse al rango de 3-5 MB o más, hay probablemente cosas que pueden ser optimizadas o removidas de ser autocargadas. Y cualquier cosa arriba de 10 MB debería ser resuelta de inmediato. Esto no siempre quiere decir que causará un problema, pero es un buen lugar donde empezar.

Considerando que esto es un gran problema, tenemos un tutorial por separado que le aconsejemos leer, sobre cómo resolver los problemas de los datos autocargados y también cómo limpiarlos.

Limpiando Transitorios

Al menos que esté utilizando un caché de objeto, WordPress almacena registros transitorios en la tabla de wp_options. Típicamente estos reciben un tiempo de expiración y deberían desaparecer con el tiempo. Sin embargo, esto no siempre es el caso. Hemos visto algunas bases de datos donde hay miles de viejos registros transitorios. De hecho, en un sitio, hemos tenido que lidiar con algunos registros transitorios corruptos en donde más de 69,000 filas fueron generadas en la tabla wp_options. ¡WoW!

Es importante tomar en cuenta que los transitorios no son autocargados por defecto. Usted podría utilizar un query como el de abajo para ver sí hay datos transitorios autocargados.

SELECT * 
FROM `wp_options` 
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%transient%'

Una mejor y más segura opción sería utilizar un plugin gratuito como Transient Cleaner o Delete Expired Transients que pueden ayudarle a limpiar solo los transitorios expirados de su tabla wp_options. Sin embargo, aparentemente ahora hay una función en WordPress que fue agregada en 4.9, que limpia transitorios expirados. Así que esperemos, que esto suceda automáticamente en su sitio.

WP Rocket también tiene la habilidad de limpiar transitorios en sus opciones de optimización de base de datos.

Limpiando Sesiones de WordPress

Otro problema común que hemos visto es que, en algunas ocasiones, los cron jobs dejan de estar sincronizados o no se activan de forma apropiada, y por eso, las sesiones no son depuradas. Podría terminar obteniendo un montón de filas _wp_session_ en su base de datos. En el ejemplo de abajo el sitio terminó con  más de 3 millones de filas  en su tabla de wp_options. Y la tabla ha crecido a más de 600 MB en tamaño.

Podría utilizar un query como el de arriba para ver si se está encontrando con este problema:

SELECT *
FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'

En la mayoría de los casos usted puede borrar estos sin problema alguno (como se debería con un cron job) utilizando el siguiente comando:

DELETE FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'

Después de limpiar todas las filas restantes de _wp_session_ rows la tabla tenía menos de 1,000 filas y se redujo a 11 MB de tamaño.

También reparó los picos que el sitio estaba obteniendo en MySQL.

Agregue un Índice para Autocargar

Si el limpiar su tabla de wp_options no fue suficiente, podría intentar agregar un “índice” en el campo de autocarga. Esto esencialmente ayuda a que pueda buscar, de forma más eficiente. El sorprendente equipo de 10up llevó a cabo algunos escenarios de prueba en la tabla wp_options con un típico número de registros autocargados para mostrar como el agregar un índice de autocarga a los queries de wp_options puede mejorar el desempeño.

También recomendamos leer estos dos recursos adicionales de WP Bullet:

• Cómo agregar índice MySQL a la tabla wp_options
• Limpiando la tabla wp_options utilizando WP-CLI

Utilice Redis como un Caché de Objeto Persistente para WordPress

Redis es un almacén de estructura de datos en memoria de código abierto. En el contexto de WordPress, Redis puede ser usado para almacenar los valores generados por el caché de objeto nativo de WordPress persistentemente para que los objetos en el caché puedan ser reusados entre las cargas de página.

Utilizar un caché de objeto persistente como Redis, permite que se puedan reusar los objetos en el caché en lugar de requerir que la base de datos de MySQL sea consultada por segunda vez por el mismo objeto. El resultado es que Redis puede reutilizar la carga en la base de datos de MySQL en un sitio web, simultáneamente reduciendo el tiempo de respuesta del sitio e incrementando la habilidad de escalar del sitio y el poder lidiar con tráfico adicional.

Sitios altamente dinámicos (WooCommerce, sitios de membresías, foros de discusión, blogs con sistema de comentarios extremadamente activo) que no pueden hacer bien uso del caché de la página son candidatos potenciales para una opción de caché de objeto persistente como Redis.

Si usted es cliente de Kinsta, ofrecemos un add-on de Redis. Revise cómo agregar Redis a su plan de hosting.

Utilice Elasticsearch para Acelerar la Búsqueda de WordPress

Elasticsearch es un motor de búsqueda de texto completo de software libre. Es usado para indexar datos y buscar los datos increíblemente rápido.

En el contexto de WordPress, Elasticsearch puede ser utilizado para acelerar la consulta de una base de datos de WordPress. Esto se hace al construir un índice del contenido de la base de datos de su sitio y luego utilizar Elasticsearch para buscar este índice mucho más rápido que lo que es capaz una consulta de MySQL de hacer lo mismo.

Si tiene el tiempo y la habilidad. Elasticsearch puede ser integrado con un sitio de WordPress por un desarrollador altamente conocedor de WordPress y Elasticsearch. Si su sitio hace un uso relativamente estándar de WP_Query, Elasticsearch también puede ser integrado al instalar ElasticPress, un plugin gratuito de WordPress de 10up, disponible de WordPress.org, el cual automáticamente se integra con el objeto WP_Query para generar resultados de query con Elasticsearch en lugar de hacerlo con MySQL.

Cualquier sitio que utilice bastante WP_Query puede beneficiarse de Elasticsearch. Aquí tenemos unos ejemplos de sitios que pueden beneficiarse de Elasticsearch:

• Sitios en donde la búsqueda es la principal forma de navegación.
• Sitios de WooCommerce con un gran número de órdenes donde los admins del sitio necesitan poder buscar la lista de órdenes regularmente.
• Cualquier sitio con un gran número de publicaciones donde los queries de MySQL están produciendo bajos resultados.

Deshabilitar Opciones No-Criticas que Utilizan Mucho la Base de Datos

Esto puede ser un poco obvio, pero puede hacer un mundo de diferencia si usted deshabilita las opciones de plugins que no son críticas y que requieren usar bastante la base de datos.

• Los widgets y plugins de publicaciones populares o relacionadas son terribles. Estos típicamente tienen queries pesados a nivel del sitio.
• Plugins de optimización de imágenes que comprimen imágenes utilizando su servidor. Siempre debería utilizar un plugin de optimización de imagen que optimice las imágenes de forma externa.

Si usted visita el blog de Kinsta y llega al final de la publicación, notará que tenemos a lo que llamamos artículos relacionados “seleccionados.” Estos son seleccionados manualmente por nosotros y asignados a la publicación. Esto reduce el query a casi nada y no dañará el desempeño del sitio entero. ¿Toma más trabajo? Sí, pero puede ser aún mejor si usted elige qué quiere que vean sus lectores.

Así que, ¿cómo logramos esto? Utilizamos el sorprendente plugin de Advanced Custom Fields y luego asignamos estos campos a nuestro tipo de publicación de blog. Esto nos permite buscar y asignar cualquier contenido relacionado que queramos a cada una de nuestras publicaciones del blog (como podrá observar a continuación).

También recomendamos alejarse de plugins que agreguen un contador de vistas/publicaciones a su sitio, al menos que realmente lo necesite. Por ejemplo, evite cosas como “792 publicaciones” a un lado del avatar del usuario en las publicaciones de foro o “5,243 vistas” al listar publicaciones de foro. Cuando uno tiene una larga discusión, estos contadores serán una carga pesada para su base de datos. En general, minimice el uso de contadores y sólo utilícelos si es necesario.

Esto también es cierto para muchos contadores sociales. Por ejemplo, en este sitio, en la parte de abajo, podrá ver el tiempo de respuesta del popular plugin Social Warfare, este tiene 30 veces más que el siguiente plugin justo debajo de este. El caché está habilitado, pero obviamente, este plugin tiene un límite considerable de desempeño. Después de deshabilitar el plugin en el sitio, los tiempos de carga disminuyen instantáneamente y el tiempo de respuesta del dashboard de admin de WordPress mejorarán.

Utilizando un Content Delivery Network (CDN)

CDN es acrónimo para content delivery network. Estos son una red de servidores (también conocidos como POPs) ubicados alrededor del mundo. Están diseñados para hospedar y entregar copias de su sitio de contenido estático de WordPress (y en algunas ocasiones dinámico), como imágenes, CSS, JavaScript, y video streams.

Antes que nada, usted no querrá confundir una CDN con un host de WordPress. Estos son dos servicios completamente distintos. Una CDN no es un remplazo de su proveedor de hosting, sino que es una forma adicional de incrementar la velocidad de su sitio. Mientras que nuestro hosting aquí es Kinsta es súper rápido, una CDN puede hacer el sitio aún más rápido.

¿Cómo Funciona una CDN?

¿Cómo realmente funciona un CDN? Bueno, por ejemplo, cuando usted hospeda su sitio web con Kinsta, usted tiene que elegir una ubicación de centro de datos, como los de EUA, Europa, Asia-Pacífico, o América del Sur.

Digamos que elige US Central. Esto quiere decir que su sitio web estará físicamente ubicado en un “servidor host” en Council Bluffs, Iowa. Cuando la gente en Europa visite su sitio web, tomará más tiempo para que se cargue, comparado con alguien que vive en Dallas, TX.

¿Por qué? Porque los datos tienen que viajar distancias más lejanas. Esto es a lo que llamamos latencia. La latencia se refiere al tiempo y/o retraso que sucede durante la transmisión de datos a través de una red. Entre más lejano, mayor será la latencia.

Tipos de CDN

Hay dos distintos tipos de content delivery networks:

1. Traditional Pull CDN
2. Reverse Proxy CDN

Los Traditional pull CDNs hacen caché a una copia de todo su contenido y archivos multimedia, pero una petición del cliente aún se hace directamente a su proveedor de hosting. KeyCDN y CDN77 son ejemplos de CDNs tradicionales.

Un reverse proxy CDN es un poco diferente. Mientras que sigue actuando como una CDN, este intercepta todas las peticiones entrantes y actúa como un servidor intermediario entre el cliente y su host. Cloudflare y Sucuri son ejemplos de reverse proxy CDNs. Esta es una razón por la que uno tiene que apuntar su DNS directo a estos proveedores en lugar de a su host.

El beneficio de esto es porque actúan como un servidor intermediario, pueden brindar apps de firewalls potentes, los cuales pueden ayudar a bloquear y evitar que el tráfico dañino llegue a su sitio de WordPress y/o proveedor de hosting. Una cosa negativa de esto es que vienen con una pequeña carga adicional en términos de desempeño, comparado a un traditional pull CDN. Pero con un desempeño adicional y opciones de seguridad, esto podría ser considerado despreciable.

Abajo tenemos un ejemplo de lo que pasó después de habilitar Sucuri en el sitio de un cliente. Como puede ver, tuvo un impacto dramático en la cantidad de tráfico negativo que entrante. Al final, este tipo de servicios pueden ayudarle a ahorrar costos de hosting.

Pruebas de Velocidad de CDN

Anteriormente hablamos sobre los grandes beneficios del caché de WordPress. Bueno, el caché de CDN también es muy poderoso. Esto es porque típicamente las CDNs tienen más ubicaciones de servidores que los proveedores de hosting. Esto quiere decir que estos pueden cachear a todos sus activos (imágenes, JS, CSS) en un lugar más cercano a sus visitantes y servirles en tiempo record.

Hagamos unas rápidas pruebas para ver qué tan rápido puede llegar a ser su sitio con una CDN.

Sin CDN

Nuestro sitio de prueba tiene como host a Kinsta y está físicamente ubicado en el centro de datos de Iowa, EUA. Primero hicimos cinco pruebas de velocidad en Pingdom (sin la CDN habilitada), y tomamos el promedio. Importante: Estamos utilizando la ubicación de Europa-Reino Unido-Londres en Pingdom para demostrar el verdadero poder de una CDN. El tiempo de carga total fue de 1.03 s.

Con CDN

Luego habilitamos nuestra CDN e hicimos cinco pruebas adicionales de velocidad en Pingdom. Nuestro tiempo de carga total es ahora de 585 ms desde la ubicación de prueba de Pingdom en Europa – Reino Unido – Londres. Así que al usar una CDN, pudimos reducir el tiempo de carga de nuestras páginas por un 43.2%. Esto es bastante.

La razón de esta drástica diferencia es porque la CDN tiene un centro de datos en Londres. Esto quiere decir que todos los activos son almacenados en el caché en esa ubicación y listas para ser servidas con mínima latencia.

TTFB sin CDN

Recuerde que esa barra amarilla en Pingdom es para el tiempo de espera, el cual es el tiempo al primer byte (TTFB). En nuestras pruebas de velocidad corriendo sin CDN, el TTFB promedio en activos fue de 98 ms.

TTFB con CDN

Una vez que habilitemos a CDN, el TTFB promedio en los activos redujo a un promedio de 15 ms. Al utilizar una CDN nuestro TTFB promedio redujo por un 84.69%. Esto es principalmente porque los activos están siendo servidos directamente desde el caché de la CDN.

¿Cómo Habilitar una CDN?

Habilitar un CDN en su sitio de WordPress no tiene que ser difícil, y de hecho es bastante sencillo! Sólo siga estos pasos.

Paso 1

Seleccione un proveedor de CDN y suscríbase al servicio. Estos típicamente cobran por mes o por uso de datos. La mayoría de los proveedores tendrán una calculadora para estimar sus costos.

• Si está buscando lanzar KeyCDN por su cuenta, le recomendamos leer este articulo en CDN for dummies. Cada proveedor de CDN debería tener documentación para ayudarle a empezar.
• Tenemos tutoriales detallados sobre cómo instalar Cloudflare y cómo instalar Sucuri.

Paso 2

Si está utilizando una traditional pull CDN, puede utilizar un plugin gratuito como CDN Enabler, WP Rocket, o Perfmatters para integrarlo con su sitio de WordPress. Estos plugins automáticamente enlazarán sus activos a la CDN. Usted no tendrá que hacer nada para lograr que esté su contenido en la CDN; ¡todo esto es manos libres! El Reverse Proxy CDN típicamente no requiere de ni un plugin, aunque en algunas ocasiones las tienen para habilitar opciones adicionales.

¿Cómo Habilitar la Kinsta CDN?

¿Le han gustado las pruebas de velocidad de CDN anteriores? Estuvimos utilizando KeyCDN en esas pruebas. Las buenas noticias es que nuestra Kinsta CDN utiliza KeyCDN. Es un content delivery network HTTP/2, con 200+ ubicaciones, para turbocargar sus activos y archivos multimedia alrededor del mundo. Actualmente, las regiones a las que sirven incluyen América, América del Sur, Europa, África y Australia.

Si usted es un cliente de Kinsta, incluimos ancho de banda de CDN gratuito en todos nuestros planes de hosting. Puede habilitar la Kinsta CDN en dos simples pasos.

Paso 1

Primero, ingrese a su dashboard de MyKinsta. De clic en su sitio y luego en la pestaña de CDN de Kinsta.

Paso 2

Luego de clic en “Habilitando el Kinsta CDN.” Después de unos minutos, l CDN automáticamente será lanzado, y sus recursos serán servidos desde el caché alrededor del mundo. Eso es todo. 😄

Optimizaciones de CDN adicionales

Aquí tenemos algunas optimizaciones de CDN adicionales que podría querer revisar o considerar.

• Si tiene muchos comentarios, los gravatars pueden generar muchas peticiones. Estos se cargan desde secure.gravatar.com. Consulte este tutorial sobre como cargar gravatar desde su CDN. Nosotros hacemos eso en nuestro sitio de Kinsta 👍
• Puede hospeda sus propias fuentes personalizadosa desde su CDN o incluso de Google Fonts en su CDN. Consulte este detallado tutorial sobre las fuentes locales.
• Asegúrese de cargar su favicon desde su CDN. A pesar de ser pequeño, ¡cada petición cuenta!

Descargue Archivos Multimedia y Email Cuando lo Necesite

Todo lo que genera una petición tiene un impacto en el desempeño de su sitio de una forma y otra. Para sitios que alojan cientos de miles de archivos o grandes archivos multimedia, podría ser muy buena idea descargar todo esto por completo. La descarga es diferente a servirlo a través de una CDN. Con una CDN los datos originales aún siguen estando en su host, la CDN simplemente tiene múltiples copias de este.

Cuando el caché expira en los activos de su CDN este pide la consulta de nuevo a su host para las últimas copias de los archivos. Las CDNs están hechas para cachear archivos por largos períodos de tiempo. Pero debido al hecho de que tienen demasiados POPs, podría haber muchas consultas a medida que el caché expira en diferentes regiones.

Cuando uno descarga archivos multimedia o archivos normales, quiere decir que actualmente, están moviendo la ubicación física original de su proveedor de hosting. Así que mientras parece que sus archivos están siendo servidores de su sitio, en realidad se encuentran ubicados en otro lugar completamente distinto. Además de reducir las consultas adicionales de vuelta al host, la razón número uno, obviamente, es también ahorrar espacio en el disco.

Descargando Archivos Multimedia a Amazon S3

Una de las soluciones de descarga más populares es Amazon S3. Amazon S3 es una solución de almacenamiento, y parte de los muchos productos del Amazon Web Services. Normalmente esta es usada por sitios grandes que necesitan backups adicionales o están sirviendo archivos grandes (descargas, software, videos, juegos, archivos de audio, PDFs, etc.) Amazon tiene un excelente récord de ser muy confiable, y por su infraestructura masiva, puede ofrecer bastante almacenamiento a precios muy bajos. Algunos de los clientes de S3 incluyen Netflix, Airbnb, SmugMug, Nasdaq, etc.

Porque normalmente lidian con almacenamiento en masa, puede tener por garantizado que sus precios serán menores que su host de WordPress. Descargar archivos multimedia a AWS puede ser una gran forma de ahorrar dinero y es gratuito por el primer año (hasta 5 GB de almacenamiento). También, porque las peticiones para sus archivos multimedia están servidas directamente desde Amazon, Esto pone una menor carga a su sitio de WordPress, queriendo decir, tiempos de carga más rápidos.

Consulte nuestro detallado tutorial sobre como descargar archivos multimedia a Amazon S3. También puede utilizar una CDN con los archivos descargados para sacar provecho de dos mundos.

Descargar Archivos Multimedia a Google Cloud Storage

Otra solución de descarga popular es el Google Cloud Storage. Ya que en Kinsta utilizamos el Google Cloud Platform, somos grandes fanáticos de su tecnología e infraestructura. Debido a la infraestructura masiva de Google y por el hecho de que normalmente lidian con almacenamiento en masa, ellos también pueden ofrecer precios de almacenamiento muy bajos. Algunos de sus clientes incluyen a Spotify, Vimeo, Coca-Cola, Philips, Evernote, y Motorola.

Consulte nuestro detallado tutorial sobre cómo descargar archivos multimedia de WordPress a Google Cloud Storage.

Descargar Emails Transaccionales y de Marketing

Aunque lo crea o no, los emails si tienen un impacto en su servidor y recursos de servidor. Con algunos hosts, especialmente hosts compartidos, abusar de esto podría causar que lo suspendan. Esto se convierte en un problema para aquellos que envían correos en masa. Esta es la razón por la que los proveedores de emails transaccionales existen y la razón por la que muchos proveedores de hosting bloquean el envío de emails en puertos estándares desde el principio. Nosotros nunca recomendamos el servicio de email de su proveedor de hosting.

Si está enviando newsletters o bulk emails, siempre recomendamos las siguientes alternativas para obtener los mejores resultados:

• Utilice software de email marketing profesional que no sea parte de WordPress.
• Utilice un proveedor de servicio de email transaccional (HTTP API o SMTP) junto con WordPress

Otras ventajas de utilizar servicios externos incluyen:

• Mejor envío de emails. ¡Deje que los proveedores de email hagan lo que mejor saben hacer!
• Menos probabilidad de ser puesto en la lista negra.
• Podría no ser siempre posible establecer registros DMARC con sus proveedores de hosting.

Herramientas de Email Marketing

Algunos ejemplos de marketing de email, incluye newsletters, anuncios de productos o servicios, ventas, invitaciones a eventos, recordatorios, etc. Aquí tenemos algunas de las herramientas de email marketing que recomendamos:

• MailChimp – Nosotros utilizamos MailChimp en Kinsta.
• MailerLite
• Drip

Servicios de Email Transaccionales

Algunos ejemplos de emails transaccionales incluyen recibos de compra de WooCommerce o EDD, notificaciones de creación de cuenta, notificaciones de envío, mensajes de error de apps, restablecimiento de contraseñas, etc. Si usted es cliente de Kinsta, nosotros dependemos de un proveedor externo de SMTP para asegurar un alto nivel de capacidad de entrega. Pero dependiendo de su volumen, siempre recomendamos moverlo fuera del sitio. Aquí tenemos algunos servicios de email transaccional que recomendamos:

• SendGrid – Nosotros usamos SendGrid en Kinsta.
• Mailgun – Vea cómo configurar Mailgun en WordPress.
• SparkPost

¿Cómo Encontrar Cuellos de Botella y Plugins Lentos?

Ahora hablaremos de algunos consejos sobre cómo encontrar embotellamientos en su sitio de WordPress y qué puede hacer sobre esto.

Utilice New Relic para Identificar Plugins Lentos y Queries de Base de Datos

Hay varias herramientas excelentes en el mercado que le pueden ayudar a encontrar e identificar queries y plugins lentos en la base de datos, aquellos que estén consumiendo mucho tiempo. Nosotros somos grandes fanáticos de New Relic y lo usamos a diario. New Relic es una herramienta monitora de PHP que puede utilizar para obtener estadísticas detalladas sobre su sitio.

Si usted es cliente de Kinsta, incluso puede agregar su propia llave de licencia de New Relic en el dashboard de su MyKinsta.

Sin embargo, utilice New Relic con cuidado, ya que este impacta al desempeño del sitio. Este agrega JavaScript a su sitio. Nosotros recomendamos habilitarlo cuando necesite resolver problemas de desempeño, y luego desactivarlo de nuevo.

Encontrando Plugins Lentos

Cuando un plugin de WordPress está causando lentitud generalizada, los síntomas variarán dependiendo de la actividad en la que el plugin se esté desempeñando. Sin embargo, en muchos casos, usted descubrirá que un plugin lento afectará cada página de un sitio de WordPress. En el caso del sitio cuyos datos podrá ver en la imagen de abajo, una lentitud generalizada fue observada en cada página de front-end en el sitio. Esto es lo que demostró New Relic tratándose del desempeño de los plugins en el sitio.

Inmediatamente podrá ver que el plugin de adinjector está consumiendo más de 15 veces la cantidad de tiempo que el siguiente plugin más lento.

Cuando uno ve datos como estos, puede ser atractivo pensar inmediatamente que el plugin está mal escrito o que es inefectivo. Mientras que esto puede ser cierto, no siempre es el caso. Una mala configuración del plugin, lentitud de la base de datos, o recursos externos que tarden en responder podrían causar que un plugin consuma más tiempo de lo esperado.

Así que, cuando ve un plugin que está respondiendo lentamente, es buena idea revisar otras pantallas en New Relic para encontrar información adicional. Las transacciones, las bases de datos y recursos externos deberían ser revisados antes de decidir si desactivar el plugin es la mejor opción, o incluso la única opción.

Una Lentitud Generalizada Causada por una Base de Datos Sobrecargada

Una base de datos mal optimizada puede causar una lentitud generalizada en un sitio de WordPress. Anteriormente, hablamos sobre todas las cosas que podría hacer para arreglar esto. En New Relic, esta lentitud relacionada a la base de datos probablemente aparecerá en dos lugares:

• Primero, usted verá una gran cantidad de actividad MySQL en la vista general.
• Segundo, usted verá una o más tablas consumiendo mucho tiempo en la pestaña de la base de datos.

Empezando con la pantalla de vista general, un sitio con una base de datos sobrecargada podría lucir de la siguiente forma:

Para entender un poco mejor qué tabla de la base de datos o query es el que está causando el problema, vaya a la pestaña de base de datos.

La pestaña de la base de datos apuntará a la tabla y el tipo de query que está consumiendo la mayor parte del tiempo. Si usted selecciona una de estas entradas en la lista, podrá ver más detalles, incluyendo algunos ejemplos de queries.

En este caso, los datos apuntan hacia los datos autocargados en la tabla de wp_options. Recuerde, ya hemos repasado esto. Y sin duda alguna, un rápido análisis de la tabla wp_options confirma que casi 250 MB de datos son autocargados de esta tabla, haciendo a este sitio un candidato obvio para recibir mantenimiento y optimización de base de datos.

Asegúrese de consultar nuestro detallado tutorial sobre cómo utilizar New Relic para resolver los problemas de desempeño en su sito de WordPress.

Utilice el Plugin Gratuito Query Monitor

También puede utilizar un plugin de WordPress gratuito como Query Monitor. Utilícelo para identificar y reparar consultas a de base de datos lentas, llamadas AJAX, peticiones de REST API y mucho más. Además de esto, el plugin reporta detalles sobre el sitio, cosas como las dependencias de script y dependientes, los ganchos de WordPress que fueron lanzados durante la generación de páginas, detalles del entorno de hosting, etiquetas condicionales de consultas encontradas por la página actual, y mucho más.

El plugin fue desarrollado por John Blackbourn, un comisionado de WordPress que actualmente es desarrollador en Human Made y previamente trabajaba con WordPress VIP – en otras palabras, alguien que conoce muy bien WordPress. Query Monitor fue agregado al directorio de plugin de WordPress en 2013 y actualmente cuenta con más de 10,000 instalaciones activas – una suma impresionante para un plugin de desarrollo. La calificación de cinco estrellas de cinco ayuda a explicar la razón de su popularidad entre los desarrolladores.

Revise nuestro tutorial completo sobre cómo utilizar Query Monitor.

Utilizando Sitios de Prueba Sin Tocar la Producción

No sabemos que haríamos sin los entornos de prueba. Estos pueden ser de valor incalculable cuando se trata de resolver problemas de desempeño. Afortunadamente, Kinsta tiene entornos de staging con tan sólo dar un clic. Si su host de WordPress no le ofrece entornos de staging. Podría utilizar un plugin como WP Staging, aunque no es algo sencillo.

Después de tener un sitio de prueba funcionando, lo primero que puede hacer es deshabilitar todos los plugins. Ya que esto es una copia de su sitio en vivo, no tendrá que preocuparse de romper algo. Sin duda alguna, es una de las formas más sencillas para identificar problemas. Simplemente vaya a Plugins, seleccione todos y elija “Desactivar” de las opciones de masa.

Después de hacer esto, puede monitorear los tiempos de respuesta en New Relic o Query Monitor y ver qué pasa. En este ejemplo de abajo los tiempos de respuesta inmediatamente bajaron a niveles normales en el sitio, así que sabíamos que era uno de los plugins el que estaba causando un problema. Luego puede reactivarlos uno por uno, repitiendo el mismo proceso hasta encontrar al culpable.

Aquí hay un ejemplo de qué pasó cuando habilitamos el plugin que estaba causando problemas. Los tiempos de carga (tiempos de transacción en la red) inmediatamente subieron.

¿Qué hacer después de encontrar el plugin que está causando problemas? Este es nuestro consejo:

1. Actualice sus plugins y temas, a las últimas versiones, si es que aún no lo ha hecho. 
2. Comuníquese con el desarrollador del plugin o tema y pida asistencia.
3. Encuentre un plugin alternativo que pueda ofrecer la misma funcionalidad.
4. Quizás su versión de PHP esté causando un problema. Cambie el motor de su PHP a una versión anterior y vea si el plugin o tema aún funciona.

También puede contratar a un desarrollador de WordPress para que arregle este problema. Si está relacionado con el desempeño, tenemos que mencionar a Mike Andreason en WP Bullet. Es un desarrollador de tiempo completo en Codeable, que se especializa en optimización de desempeño, él ha ayudado a muchos clientes de Kinsta con instalaciones complejas y llevar sus sitios al siguiente nivel.

Revise sus Registros de Error (Error Logs)

Revisar los registros de error nunca es divertido, pero puede revelar mucho sobre los problemas de desempeño de los plugins de WordPress. Si usted es cliente de Kinsta, puede ver fácilmente sus registros de errores, de caché y de acceso desde el dashboard de MyKinsta.

También puede habilitar el registro de errores al agregar un poco de código a sus archivos de wp-config.php. Primero, querrá conectarse a su sitio a través de SFTP. Luego, descargue su wp-config.php para que pueda editarlo. Nota: ¡Siempre tenga listo un backup de este archivo primero!

Encuentre la línea que dice /* That's all, stop editing! Happy blogging. */ y justo antes de esta, agregue lo siguiente (como se muestra abajo):

define( 'WP_DEBUG', true );

Si el código anterior ya existía en su archivo de wp-config.php pero estaba seleccionado como “falso,” simplemente cámbielo a “verdadero.” Esto habilitará el modo de debug. Nota: también verá las advertencias o error en su WordPress admin si es que existen.

Luego puede habilitar el registro de debugs para enviar todos los errores a un archivo al agregar el siguiente código justo después de la línea WP_DEBUG (como se ve abajo):

define( 'WP_DEBUG_LOG', true );

Guarde los cambios y suba de nuevo esto a su servidor. Los errores luego serán registrados al archivo debug.log dentro de su carpeta /wp-content/. Si por alguna razón no ve este archivo, siempre podrá crear uno.

Utilice MyKinsta Analytics

Si usted es cliente de Kinsta, puede tomar ventaja de las percepciones de desempeño que hemos construido en nuestra herramienta de MyKinsta Analytics.

Bajo la sección de monitoreo de desempeño, usted podrá ver el tiempo de respuesta promedio de PHP + MySQL, rendimiento de PHP, uso de AJAX, tiempo de subida promedio, y el tiempo máximo de subida.

Tiempo Promedio de PHP + Tiempo de Respuesta de MySQL

Al visitar su sitio de WordPress, PHP y MySQL son usados para compilar y hacer consultas a los datos que ve en la página. Esta gráfica le muestra el tiempo de respuesta promedio del motor PHP y el motor MySQL para cada petición dinámica en el caché. Conocer estos tiempos de respuesta podrán ayudarle a resolver los problemas de velocidad.

El Rendimiento de PHP

El rendimiento indica el número de transacciones por segundo que una aplicación puede manejar, y en este reporte, se refiere al rendimiento de PHP desde su sitio de WordPress. En otras palabras, muestra cuántas veces ha sido solicitado un activo de PHP.

Uso de AJAX

AJAX es un script de parte del cliente que se comunica hacia y desde el servidor/base de datos sin la necesidad de una devolución de datos o un refrescar completo de la página. Cuando se trata de WordPress, muchos de ustedes probablemente hayan visto esto en sus pruebas de velocidad. Los dos problemas principales con AJAX incluyen plugins causando que tenga picos y problemas de CPU en el back-end.

Asegúrese de leer nuestra publicación detallada sobre la diagnosis de uso excesivo de Admin-AJAX en su sitio de WordPress.

El reporte de uso de AJAX en MyKinsta analytics puede ser una gran forma para ayudarle a resolver este tipo de problemas ya que podrá ver si está seguro de ver ciertos picos de AJAX durante ciertos periodos. La gráfica muestra el conteo de peticiones admin-ajax. Luego puede utilizar algunos de los consejos en la publicación que mencionamos arriba para dejar claro de dónde vienen.

El Mejor Tiempo de Respuesta Promedio de PHP + MySQL

Esta lista muestra el mejor tiempo de respuesta promedio de PHP y MySQL. Estos números pueden ser picos de una sola vez, así que se sugiere comparar esta lista con “El Mejor Tiempo de Subida Máximo.”

El mejor Tiempo de Subida Máximo

El tiempo de subida es el tiempo total tomado para Nginx (y servidores de subida) para procesar una petición y enviar una respuesta. El tiempo es medido en segundos, con milisegundos de resolución. Lea más sobre las métricas de Nginx.

Su Sitio Podría Estar Hackeado

Si está teniendo problemas rastreando un problema de desempeño, podría ser que su sitio esté siendo hackeado, siendo infectado con malware, o es objetivo de un ataque DDoS. Esto puede impactar la velocidad de su sitio e incluso el tiempo de respuesta de su dashboard de admin de WordPress. En estos casos recomendamos lo siguiente:

1. Implemente un servidor proxy y WAF como Cloudflare o Sucuri
2. Bloquee las direcciones de IP malas utilizando los servicios de arriba o si es cliente de Kinsta, también puede bloquear direcciones de IP desde el dashboard de MyKinsta.
3. También puede implementar geo-bloqueo. Algunos países son muy malos cuando se trata de la calidad del tráfico que generan. Si usted está bajo ataque, podría necesitar bloquear un país entero, sea temporalmente o permanentemente.

Resolviendo Problemas con Códigos de Error (Códigos de Estado HTTP)

Los códigos de estado de HTTP son como breves notas del servidor de la red que es clavada sobre la parte superior de la página web. No es parte de la página. En su lugar, es un mensaje desde el servidor haciéndole saber como sucedieron las cosas cuando la petición para ver la página fue recibida por el servidor. ¡Estos pueden ser invaluables cuando se trata de resolver problemas!

Mientras que hay más de 40 códigos de estado distintos, abajo están los que vemos que los usuarios de WordPress comúnmente tienen problemas.

429: “Demasiadas Peticiones.” Generadas por el servidor cuando el usuario ha enviado demasiadas peticiones en una cierta cantidad de tiempo (limitando el rango). Esto puede ocurrir en algunas ocasiones si bots o scripts están intentando acceder a su sitio. En este caso, podría querer intentar cambiar la URL de Inicio de sesión de su WordPress.

500: “Hubo un error en el servidor y la petición no pudo ser completada.” Un código genérico que simplemente significa “error de servidor interno.” Algo salió mal en el servidor, y el recurso pedido no fue entregado. Este código normalmente es generado por plugins de otras compañías, PHP defectuoso, o incluso cuando se rompe la conexión a la base de datos. Consulte estos tutoriales sobre como arreglar el error al establecer una conexión con la base de datos y otras formas de cómo resolver un error 500 de servidor interno.

502: “Puerto de Enlace no Válido.” Este error de código típicamente significa que un servidor ha recibido una respuesta invalida de otro. Algunas veces un query o una petición tomará mucho tiempo, así que es cancelada o eliminada por el servidor y la conexión a la base de datos se rompe. Revise nuestro detallado tutorial sobre cómo arreglar el error 502 de Puerto de Enlace incorrecto”.

503: “El servidor no se encuentra disponible para hacerse cargo de esta petición por el momento.” La petición no puede ser completada ahora. Este código puede ser regresado por un servidor sobrecargado que no puede lidiar con peticiones adicionales.

504: “el servidor, actuando como una puerta de enlace, agotó el tiempo de espera para que el otro servidor responda” El código es regresado cuando hay más de dos servidores involucrados en el proceso de una petición, y el primer servidor se queda sin tiempo de espera al esperar que responda el segundo servidor. Lea más sobre cómo arreglar errores 504.

También puede adentrarse a estos códigos de respuesta de HTTP en nuestra herramienta de MyKinsta Analytics. Nuestro reporte de desglose de los códigos de respuesta le permitirá ver una vista general de la distribución de los códigos de estado de HTTP servidos para los recursos pedidos.

El reporte de estadísticas de respuesta le permite ver el número total de redirecciones sucediendo en este momento, número de éxitos, y rango de error. Cada sitio de WordPress típicamente tiene un rango pequeño de error; esto es completamente normal.

Luego hay reportes por cada tipo de código de error, como los errores 500, los errores 40 y las redirecciones.

Recomendaciones sobre la Optimización del Back-End

Ahora nos adentraremos a las formas en las que puede acelerar WordPress al optimizar el back-end. El backend típicamente involucra a cualquier cosa que sea manejada completamente por el servidor, como PHP, HTTP, encabezados de caché, compresiones GZIP, etc.

Cree una Página 404 Ligera

Hemos visto de primera mano que los sitios altamente dinámicos típicamente generan muchos errores 404. ¡Su sitio web podría generar más de los que se imagina! Nuestra herramienta de analytics de MyKinsta puede ayudarle a determinar el número exacto (como se puede ver abajo).

La razón por la que estos errores son malos, es que muchas páginas 404 utilizan muchos recursos. Para sitios altamente dinámicos de WordPress, usted querrá evitar una página llena de 404. Cree una plantilla simple de 404 que evite hacer consulta a la base de datos lo más que se pueda. Y por su puesto, tómese el tiempo de arreglar los errores 404 ya que no sólo ocupan recursos, es simplemente una mala experiencia de usuario.

Además de utilizar una página 404 ligera, también recomendamos implementar una regla especial de caché de página para las páginas 404. En Kinsta, automáticamente almacenamos en caché 404 páginas durante 15 minutos. Si nuestro servidor web detecta que se ha creado una nueva página con la misma URL que una página 404 en caché, purgaremos automáticamente la caché. Si tu sitio de WordPress no tiene páginas 404 en caché, recomendamos trabajar con tu host para agregar esta capacidad a tu servidor web.

Incremente los PHP Workers

Los PHP workers podrían ser un término que jamás había escuchado, pero estos son de gran ayuda para muchos hosts, incluyendo a Kinsta, para poder controlar y limitar las peticiones (en lugar de limitarlo por CPU o RAM, lo que normalmente hacen los proveedores de hosting compartidos).

Los PHP workers determinan cuantas peticiones simultáneas puede aguantar su sitio al mismo tiempo. En pocas palabras, cada petición que no esté en el caché para su sitio web es controlado por un PHP worker. Por ejemplo, si tiene 4 peticiones que llegan a su sitio al mismo tiempo y su sitio tiene 2 PHP workers, dos de estas peticiones serán procesadas, mientras que las otras dos tendrán que esperar en la fila hasta que las primeras dos hayan terminado de procesar.

¿Recuerda cuando hablamos sobre uno de los mayores problemas de los sitios de membresías de WordPress con todas esas peticiones sin almacenar en el caché? Es por eso que los PHP workers son tan importantes, ya que ellos hacen el trabajo por cada petición. Por lo tanto, estos sitos típicamente requerirán PHP workers adicionales para asegurar que cada petición sea procesada sin retrasos y que sean completadas con éxito.

¿Qué pasa si continuamente pone hasta el tope a sus PHP workers? Básicamente, la fila empezará a empujar viejas peticiones las cuales podrían resultar en errores 500 en su sitio. Cada plan de hosting de Kinsta incluye un número predefinido de PHP workers. Si tiene problemas estimando lo que necesita su sitio, siempre podrá conversar con nuestro equipo de ventas o de soporte.

Utilice Compresión GZIP

GZIP es un formato de archivo y una aplicación de software utilizada para la compresión y descompresión de archivos. La compresión GZIP está habilitada a nivel del servidor, y permite una mayor reducción en el tamaño de su HTML, stylesheets, y archivos de JavaScript.

Cuando un navegador visita un sitio, este revisa si el servidor web tiene el GZIP habilitado al ver si existe el encabezado HTTP content-encoding: gzip. Si se detecta el encabezado, este sirve los archivos los archivos comprimidos y pequeños. Si no es así, este sirve los archivos sin comprimir. Si no tiene habilitado el GZIP, probablemente verá advertencias y error en las herramientas de prueba de velocidad como Google PageSpeed Insights y GTmetrix.

Habilitando la compresión GZIP puede ayudar a reducir el tamaño de su página web, el cual puede reducir significativamente la cantidad de tiempo para descargar el recurso, reducir el uso de datos para el cliente y mejorar el tiempo para la primera visualización de sus páginas. Esto es lo estándar a través de la mayoría de los proveedores de hosting, pero ya nada nos sorprende a estas alturas.

Habilitando Protección contra Hotlink

Este concepto de hotlinking es bastante simple. Usted encuentra una imagen en algún lado del internet y utiliza la URL de la imagen directamente en su sitio. Esta imagen será mostrada en su sitio web, pero será servida desde la ubicación original. Esto es muy conveniente para el que hace el hotlink, pero en realidad esto es robo, ya que está utilizando los recursos del sitio al que hizo hotlink. Es como si estuviéramos usando nuestro coche y conducir con la gasolina del el coche que va a nuestro lado.

Hotlinking puede ser una gran fuga de recursos para el servidor objetivo. Imagínese si usted está en un host compartido de WordPress y Huffington Post de repente pone un enlace a sus imágenes. Usted podría pasar de cientos de consultas por hora en su sitio a varios cientos de miles. Esto podría resultar en una suspensión de su cuenta de hosting. Esta es solo una razón para usar hosts de alto desempeño (los cuales puedan lidiar con dificultades como esta), pero también permitir protección de hotlink, para que esto no suceda.

Aprenda más mediante nuestro tutorial sobre cómo prevenir hotlinking.

Minimice las Redirecciones y Agréguelas a Nivel del Servidor

Uno siempre debe tener cuidado cuando tiene demasiadas redirecciones. Simples redirecciones como una simple redirección 301 HTTP a HTTPS, o www a no www (y vice versa) están bien. Y en muchas ocasiones estas son necesarias en ciertas áreas de su sitio web. Sin embargo, cada una tiene un costo en el desempeño de su sitio. Y si usted empieza redirigiendo una sobre otra, es importante darse cuenta como impactarán a su sitio. Esto aplica a páginas y direcciones de publicaciones, redirecciones de imagen y todo.

Una redirección generara una respuesta 301 o 302 en el estado de respuesta del encabezado.

¿Qué tanto impactan estas redirecciones a su sitio? Hagamos una pequeña prueba. Primero, hagamos una prueba de velocidad en nuestra página de contacto: https://perfmatters.io/contact/. Como puede ver abajo, obtuvimos un tiempo total de carga de 417 ms.

Luego, modificamos un poco la URL y hacemos otra prueba de velocidad para ver el impacto de múltiples redirecciones. http://www.perfmatters.io/contact. Como puede ver, la misma página ahora toma 695 ms para cargar. Eso es un incremento de 66%. ¡Wow!

El utilizar plugins gratuitos de WordPress para implementar redirecciones en algunas ocasiones puede causar problemas de desempeño ya que la mayoría utilizan la función wp_redirect, la cual requiere ejecución de códigos y recursos adicionales. Algunos de estos agregan datos autocargados a su tabla de wp_options, la cual incrementa la carga de la basa de datos. Agregarlo a nivel del servidor es donde se deberían hacer. Nosotros le permitimos hacer eso en MyKinsta, con nuestra herramienta de reglas de redirección.

También puede ver un desglose completo de cuantas redirecciones están pasando en sus sitios en nuestra herramienta de MyKinsta analytics. Vea el número total de 301, 302 y 304.

Conozca más leyendo nuestra publicación sobre las redirecciones de WordPress.

No Permita que los Cron Jobs Salgan de Control

Los CRON jobs (WP-CRON) son usados para agendar tareas repetitivas para su sitio de WordPress. Sin embargo, con el tiempo, estos se pueden salir de control y causar problemas de desempeño. Puede utilizar el plugin gratuito de WP Crontrol para tener el control de todos los Cron jobs pasando en su sitio.

También hemos visto problemas de desempeño con el controlador de Cron de WordPress: WP-Cron. Si un sitio no tiene suficientes PHP workers, en algunas ocasiones una petición entrará, WordPress creará el cron, pero el cron tiene que esperar para que el worker, y seguirá esperando, Un enfoque mejor es deshabilitar WP-Cron y usar el cron del sistema en su lugar. Esto incluso se recomienda en la guía oficial del Plugin.

Para deshabilitar el WP-CRON, agregue lo siguiente a su archivo wp-config.php, justo antes de la línea que dice “That’s all, stop editing! Happy blogging.” Nota: Esto lo deshabilita de que se active durante la carga de la página, no cuando lo llama directamente a través de wp-cron.php.

define('DISABLE_WP_CRON', true);

Usted necesitará agendar wp-cron.php de su servidor. Si es cliente de Kinsta, los sistemas crons ya estarán habilitados y se activarán cada 15 minutos por defecto. También puede incrementar la frecuencia al ponerse en contacto con el equipo de soporte. Si está familiarizado con SSH, usted podrá administrar los crons del servidor desde la línea de comando.

Agregue Control de Caché y Encabezados que Expiran (Determine la Duración del Caché)

Cada script en su sitio de WordPress necesita tener un encabezado de caché HTTP adjunto a este (o por lo menos debería). Esto determina cuando expira el caché en el archivo. Para arreglar esto, asegúrese de que el host de WordPress tenga la configuración de encabezados cache-control y expires apropiada. Si no es así, probablemente verá advertencias sobre necesitar agregar encabezados de expiración o hacer leverage browser caching en las herramientas de prueba de velocidad.

Mientras que el encabezado de cache-control activa el caché desde el lado del cliente y establece la edad máxima de un recurso, el encabezado expires es usado para especificar un punto especifico en el tiempo en que el recurso ya no es válido. Mientras que ambos encabezados pueden ser usados al mismo tiempo, no tiene que agregar necesariamente ambos. El Cache-control es el más reciente y usualmente el método más recomendado.

Kinsta automáticamente agrega encabezados de caché HTTP en todas las peticiones del servidor, y si está utilizando una CDN, probablemente agregaran estos encabezados por usted.

Si a su servidor le faltan estos encabezados, puede agregarlos manualmente.

Agregando Encabezado de Cache-Control en Nginx

Puede agregar encabezados de cache-control en Nginx al agregar lo siguiente a la ubicación o bloque de la configuración de su servidor.

location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico)$ {
 expires 30d;
 add_header Cache-Control "public, no-transform";
}

Agregando Encabezado Expires en Nginx

Puede agregar encabezados expires en Nginx al agregar lo siguiente al bloque de su servidor. En este ejemplo, usted podrá ver cómo especificar diferentes tiempos de expiración basados en los tipos de archivos.

Agregando Encabezado Cache-Control en Apache

Usted puede agregar encabezados cache-control en Apache al agregar lo siguiente a su archivo de .htaccess. Los fragmentos de código pueden ser agregados en la parte superior o inferior del archivo (antes de #BEGIN WordPress o después de #END WordPress).

<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|svg|js|css|swf)$">
Header set Cache-Control "max-age=84600, public"

Agregando Encabezados Expires en Apache

Usted puede agregar encabezados expires en Apache al agregar el siguiente archivo de .htaccess.

## EXPIRES HEADER CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType image/svg "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 2 days"
</IfModule>
## EXPIRES HEADER CACHING ##

También es importante tomar en cuenta que usted sólo puede agregar encabezados de caché de HTTP en recursos en su servidor. Si usted está recibiendo advertencias sobre eso, quizás usted necesite hacer leverage browser caching en una petición externa, no hay nada que pueda hacer, ya que usted no tiene una petición sobre su servidor. Los culpables más comunes incluyen el script de Google Analytics y marketing pixels, como Facebook y Twitter.

Si está intentando arreglar esto con el script de Google Analytics, usted puede hospedarlo localmente o en su CDN (aunque esto no es oficialmente soportado) con un plugin como Perfmatters o WP Rocket.

Agregue Encabezados de Último Modificado (Last-Modified) y ETag (Validando Caché)

Luego, tenemos dos sets de encabezados, last-modified y etag.

Mientras que los encabezados de cache-control y expires  ayudan a que el navegador determine  si el archivo ha cambiado desde la última vez que fue requerido. (o más bien, estos validan el caché). Los encabezados de last-modified y etag validan y establecen la longitud del caché y deben incluirse en cada respuesta del servidor de origen. Si estos no son establecidos apropiadamente usted podría ver una advertencia diciendo «Especifique un validador de caché.»

Si los encabezados no son encontrados, este generará una nueva petición para el recurso todo el tiempo, lo cual incrementa la carga en su servidor. Al utilizar encabezados de caché, asegurará que las peticiones subsecuentes no tengan que ser cargadas desde el servidor, así ahorrando ancho de banda y mejorando el desempeño para el usuario.

Kinsta automáticamente agrega los encabezados anteriores en todas las peticiones del servidor, y si está utilizando una CDN, probablemente también terminen agregando estos encabezados por usted. Al igual que con el cache-control y expires, y usted no podrá establecer manualmente estos encabezados HTTP en recursos externos.

Encabezado Last-Modified

El encabezado last-modified es generalmente enviado de forma automática desde el servidor. Este es un encabezado que generalmente no tendrá que agregar manualmente. Este es enviado para ver si el archivo en el caché de su navegador ha sido modificado desde la última vez que fue pedido. Usted puede ver la petición del encabezado en Pingdom o utilizar Chrome DevTools para ver el valor del último encabezado last-modified.

Encabezado ETag

El encabezado ETag también es muy similar al encabezado last-modified. También es usado para validar el caché de un archivo. Si usted está usando Apache 2.4 o mayor, el encabezado ETAG es agregado automáticamente, usando la directiva FileETag. En el caso de Nginx, el encabezado ETag ha sido habilitado por defecto desde el 2016.

Puede habilitar el encabezado ETag de forma manual en NGinx utilizando el siguiente código.

etag on

Agregando Encabezado Vary: Accept-Encoding

El encabezado vary: Accept-Encoding debería ser incluido en cada respuesta de servidor origen, ya que le dice al navegador si el cliente puede manejar o no las versiones comprimidas del contenido. Si esto no es establecido correctamente, podría ver una advertencia diciendo que usted necesita «Especificar un Encabezado Vary: Accept-Encoding.»

Por ejemplo, digamos que tiene un viejo navegador sin compressión GZIP y un navegador moderno con este. Si no utiliza el encabezado  vary: Accept-Encoding su servidor web o CDN podría almacenar en el caché la versión sin compressión y entregar eso a la versión moderna del navegador por accidente, lo cual causaría daños al desempeño de su sitio de WordPress. Al utilizar el encabezado puede asegurar que su servidor web y/o CDN entregue la versión apropiada.

Kinsta automáticamente agrega los encabezados anteriores en todas las peticiones de servidor, y si usted está utilizando una CDN, probablemente terminen agregando estos encabezados por usted. Como con los otros encabezados de caché de los que hemos hablado anteriormente, usted no puede establecer manualmente este encabezado en recursos externos.

Agregar Encabezado Vary: Accept-Encoding en Apache

Usted puede agregar el encabezado vary: Accept-Encoding en Apache al agregar lo siguiente a su archivo .htaccess</code.

<IfModule mod_headers.c>
  <FilesMatch ".(js|css|xml|gz|html)$">
    Header append Vary: Accept-Encoding
  </FilesMatch>
</IfModule>

Agregar Encabezado Vary: Accept-Encoding en Nginx

Usted puede agregar el encabezado vary: Accept-Encoding en Nginx al agregar el siguiente código a su archivo de configuración. Todos los archivos de configuración Nginx están ubicados en el directorio /etc/nginx/. El archivo principal de configuración es /etc/nginx/nginx.conf.

gzip_vary on

Cambiando el límite de Memoria de WordPress en wp-config.php

Como se declara en el Codex de WordPress, con la Versión 2.5 de WordPress, la opción WP_MEMORY_LIMIT le permite especificar el número máximo de memoria que puede ser consumido por PHP. Esta opción podría ser necesaria en el evento de que usted reciba un mensaje como “tamaño permitido de memoria de xxxxxx bytes se ha agotado.”

Por defecto, WordPress intentará incrementar la memoria asignada a PHP a 40 MB para un solo sitio y 64MB para un multisitio. Ellos definen los límites de memoria en el archivo ./wp-includes/default-constants.php, en las líneas 32-44 (fuente).

También puede tener PHP memory_limit en el servidor por su proveedor de hosting. Estas son dos cosas distintas. En Kinsta nosotros establecemos memory_limit por defecto a 256M. Si usted se está encontrando con el error de “se ha agotado el tamaño de la memoria” puede intentar incrementar el límite de memoria de PHP en WordPress.

Agregue lo siguiente a su archivo wp-config.php file, antes de la línea que dice “That’s all, stop editing! Happy blogging.”

define( 'WP_MEMORY_LIMIT', '256M' );

Jan Reilink también tiene un excelente articulo que describe el problema del límite de memoria de WordPress detalladamente. También da una variante del código que podría utilizar. En lugar de establecer la cantidad manualmente, usted puede establecerla al valor de memory_limit de PHP..

define( 'WP_MEMORY_LIMIT', ini_get( 'memory_limit' ) );

Consejos sobre la Optimización del Front-End y los Servicios Externos

Ahora hablaremos de algunas formas para acelerar WordPress al optimizar el front-end. El front-end típicamente involucra cualquier cosa que ha sido manejada completamente por el navegador por lado del cliente, como CSS, JavaScript, Imágenes, etc. Esto también incluye analizar los servicios externos que usted tiene cargando en su sitio y cómo estos impactan su tiempo de carga total.

Dos de los objetivos más importantes que debería tener cuando se trata de optimizaciones de front-end son:

• Reducir el tamaño general de la página web. El tamaño de su CSS, JavaScript, imágenes es muy importante. Un sitio web de 4 MB típicamente cargará mucho más lento que un sitio web de 1 MB. Sin embargo, Paul Calvano tiene un excelente articulo sobre el impacto del peso de la página, cuando se trata del tiempo de carga, y cómo esto es importante para asegurarse de que no sea la única cosa que usted está rastreando, ya que en algunas ocasiones esto podría ser confuso.
• Reduciendo peticiones HTTP y servicios externos. Con HTTP/2, múltiples peticiones y respuestas ahora pueden ser enviados al mismo tiempo, utilizando una sola conexión TCP. Aunque esto es sorprendente, tratándose del desempeño, reducir las peticiones HTTP puede ayudarle a acelerar su sitio de WordPress. Esto también incluye reducir el número total de peticiones externas y servicios. Cada una de estas agregan retrasos adicionales como búsquedas de DNS, conexiones TLS, y una latencia de red.

Haga Pruebas de Velocidad a Su Sitio de WordPress para Obtener una Referencia

Cuando se trata de optimizar el front-end de su sitio, siempre es bueno empezar con una referencia. Esto usualmente significa hacer una prueba de velocidad. Hay una multitud de formas en las que puede hacer esto, verifique nuestra lista de 15 sorprendentes herramientas de prueba de velocidad de sitios web.

Consulte nuestras detalladas guías sobre cómo utilizar Pingdom y cómo utilizar GTmetrix. Aquí hay un par de cosas a tener en mente cuando haga pruebas:

1. Elija Uno y Siga con Ese

Somos fanáticos de Pingdom, GTmetrix, WebPageTest, PageSpeed Insights y Chrome DevTools. Sin embargo, no importa tanto qué herramienta de prueba de velocidad elija, lo más importante es que sea consistente. Todas tienen formas distintas para medir y cuantificar la velocidad, así que elija una herramienta y siga usando esa para todas sus pruebas y optimizaciones. Incluso Google le dice que elija una.

2. No Se Obsesione Tratando de Obtener una Calificación Perfecta

Muchas de las herramientas como Google PageSpeed Insights tienen un tipo de calificación de velocidad y desempeño. Es importante recordar que la calificación no siempre importa tanto, ya que la velocidad de su sitio web y el desempeño percibido por usuario siempre será distinto. La calificación existe para ayudarle a medir qué tan bien le está yendo. Pero obsesionarse por conseguir esa perfecta calificación de 100/100 o una A, en algunos casos podría ser una pérdida de tiempo. Y los sitios más grandes con muchos scripts externos y anuncios jamás obtendrán una calificación perfecta, y esto está bien.

3. La Ubicación de Sus Pruebas Importan

La ubicación que elija cuando haga pruebas de velocidad importa bastante. Como hemos mencionado en secciones anteriores, la razón es que, todo esto es relativo a la ubicación del centro de datos que elija. TTFB, latencia de la red, todo entra en juego. Así que haga pruebas desde una ubicación que se encuentre cercana a su centro de datos y una lejana. Esto también le ayudará a ver qué tanto impacto tiene la CDN en su sitio de WordPress.

4. Haga Varias Pruebas por el Caché

Como ya hemos hablado anteriormente en la sección sobre el caché, si el caché ha sido depurado recientemente o ha expirado en su host de WordPress o CDN, este registrará un “MISS” en el encabezado de HTTP. Esto quiere decir que su sitio web o recursos no están siendo servidos desde el caché.

Para poder ver de forma apropiada la velocidad de su sitio entero, usted necesita ver que todo cargue del caché, su página inicial y que todos sus activos registren un “HIT.” Esto en algunas ocasiones requiere que haga unas pruebas de velocidad adicionales. Luego podrá sacar el promedio.

Ahora hablaremos de algunas optimizaciones de front-end que podrá hacer en su sitio de WordPress.

Elimine Render-Blocking JavaScript y CSS

Una advertencia sobre render-blocking JavaScript y CSS podría aparecer cuando usted tiene archivos previniendo que la página cargue lo más rápido posible. JS y CSS específicos a veces son condicionales, queriendo decir, estos no requieren mostrar el contenido above-the-fold. Usted puede prevenir que se conviertan en bloqueadores de visualización al utilizar atributos async y defer.

Consulta este vídeo para saber más sobre cómo eliminar los recursos render-blocking:

Para eliminar render-blocking JavaScript y CSS usted necesita hacer lo siguiente:

Limpie JS del Camino Crítico de Visualización

Mover JavaScript del camino crítico de visualización es típicamente hecho al agregar el atributo defer o async a los elementos HTML script que llaman a los recursos de JavaScript.

• El atributo async le dice al servidor que empiece a descargar el recurso inmediatamente, sin hacer más lenta la fragmentación del HTML. Una vez que esté disponible el recurso, la fragmentación HTML será pausada para que el recurso pueda ser cargado.
• El atributo defer le dice al navegador que deje de descargar el recurso por un momento hasta que la fragmentación HTML se haya completado. Una vez que el servidor haya terminado con HTML, luego descargará y visualizará a todos los scripts diferidos en el orden en que aparecieron en el documento.

Optimice la Entrega de Recursos CSS

Optimizando la entrega de CSS esencialmente quiere decir que usted necesita descubrir cómo hacer que se bloquee la visualización.

• Identifique los estilos que son requeridos para visualizar a contenido above-the-fold y entregar esos estilos en línea con HTML.
• Utilizar CSS condicionalmente en dispositivos, sólo cuando es necesario.
• Cargar CSS restante de forma asíncrona.

Hacer todo esto puede llegar a ser complejo y sin duda alguna requiere de algunos arreglos basado en los scripts que tenga cargando en su sitio. Aquí tenemos un par de plugins de WordPress que podrían ser de ayuda:

• Autoptimize
• Async JavaScript
• Hummingbird

Para ver una explicación más detallada y una guía, le recomendamos checar nuestro articulo sobre cómo eliminar JavaScript y CSS bloqueadores de visualización

Combine CSS y JavaScript Externos en WordPress

La advertencia de combinar CSS externos es típicamente visto al usar una CDN porque usted está alojando sus archivos CSS en un dominio externo, como cdn.domain.com. En el pasado, una forma rápida de arreglar esto era concatenar sus archivos CSS, o combinarlos para que carguen en una sola petición.

Sin embargo, si está utilizando HTTP con un proveedor que soporta HTTP/2, esta advertencia ya no es tan relevante como solía ser. Con HTTP/2 múltiples archivos CSS pueden ser cargados en paralelo sobre una sola conexión. Y más del 86% de navegadores soportan HTTP/2.

Pero esto no quiere decir que esta optimización esté completamente muerta. En algunas ocasiones, hemos visto que esto acelere los sitios de WordPress. Depende del tamaño de los archivos y cuántos de estos hay. Así que, esta es una optimización que recomendamos que le haga pruebas en su sitio.

Una de las formas más fáciles de combinar sus archivos de CSS y JavaScript externos es el plugin gratuito Autoptimize. Después de combinarlos, usted verá un archivo “autoptimize_xxxxx.css” o “autoptimize_xxxxxx.js” También soporta la carga desde su CDN. También puede hacer eso con su plugin de WP Rocket.

Consulte nuestro detallado articulo sobre cómo combinar CSS y JavaScript externos en WordPress.

Utilice Minificación en HTML, CSS y JavaScript

Podemos reducir la cantidad de datos que el navegador tiene que descargar al minificar recursos HTML, CSS y de JavaScript. La minificación es el proceso de remover caracteres innecesarios como los comentarios y whitespace del código fuente. Estos caracteres son extremadamente útiles en el desarrollo, pero son inútiles para el navegador para visualizar  la página.

HTML sin Minificar

Aquí le dejamos un ejemplo de código HTML sin minificar.

HTML Minificado

Aquí le dejamos un ejemplo de código HTML después d minificación

Puede utilizar este plugin gratuito de Autoptimize o WP Rocket para minificar fácilmente sus archivos.

Si eres cliente de Kinsta, tienes acceso a la función de minificación de código integrada directamente en el panel de control de MyKinsta. Esto permite a los clientes habilitar rápida y fácilmente la minificación automática de CSS y JavaScript con el clic de un botón y acelerará de forma efectiva tu sitio sin ningún esfuerzo manual.

Utilice Dominios Libres de Cookies

Generalmente, cuando uno sirve contenido como imágenes, JavaScript, CSS, no hay razón para que una cookie HTTP lo acompañe, ya que crea una carga adicional. Una vez que el servidor establece una cookie para un dominio en particular, todas las peticiones subsecuentes de HTTP para ese dominio deben incluir una cookie. Esta advertencia es típicamente vista en sitios con grandes números de peticiones.

Tenemos una publicación detallada sobre cómo lidiar con la advertencia de contenido estático de un dominio sin cookies. Muchas veces, uno puede ignorar esta advertencia, ya que nuevos protocolos, como HTTP/2, ahora lo hacen menos importante. El precio de una nueva conexión es usualmente más costoso que hacer streaming a todo sobre esa misma conexión.

Una forma sencilla de arreglar esta advertencia es utilizar un proveedor de CDN que pueda ignorar cookies, e igual pueda eliminar cookies, que podrían prevenir que el cliente reciba el encabezado de respuesta de la cookie establecida. KeyCDN es un proveedor de CDN que sí ofrece esta opción. Por defecto, podrá ver que las siguientes dos opciones estarán habilitadas. Esta es una alternativa sencilla sin tener que lidiar con el proceso de mover y configurar su sitio para entregar activos estáticos de subdominios separados.

Si usted está usando Cloudflare, no puede deshabilitar las cookies en los recursos servidos a través de su red. CloudFlare incluye su propia cookie en el encabezado. De nuevo, estas cookies son muy pequeñas y las implicaciones del desempeño son extremadamente mínimas. Pero si usted utiliza Cloudflare, no hay forma de evitar esta advertencia.

Una segunda forma de lidiar con esto es re-configurando su sitio de WordPress para entregar activos estáticos desde un nuevo dominio o subdominio.

Deshabilitar Embebidos en WordPress

Cuando lanzaron WordPress 4.4, unieron la opción de oEmbed al core. Esto les permite a los usuarios incrustar videos de YouTube, tweets y muchos otros recursos en sus sitios simplemente con pegar una URL, la cual WordPress automáticamente convierte en un embed y provee una vista previa en vivo en su editor visual. Con la actualización, WordPress se convierte en el proveedor de oEmbed.

Esta opción es útil para muchas personas, y es mejor mantenerla activa. Sin embargo, lo que quiere decir esto, es que también genera peticiones de HTTP adicionales en su sitio de WordPress para cargar el archivo wp-embed.min.js. Y este se carga en todo el sitio. Mientras que este archivo tan solo pesa 1.7 KB, las cosas como esta se van acumulando con el tiempo. Esta petición en algunas ocasiones es mucho más importante que el tamaño del contenido descargado.

Usted fácilmente podría lograr que este archivo no se cargue. Aquí tenemos tres opciones distintas.

• Optión 1 – Deshabilitar Embeds con un Plugin
• Optión 2 – Deshabilitar Embeds con Código
• Optión 3 – Mover el Inline de JavaScript

Deshabilitar Emojis en WordPress

Similar a los embeds, en WordPress 4.2, agregaron soporte para emojis en el core de los viejos navegadores. El gran problema con esto es que genera peticiones HTTP adicionales en su sitio de WordPress para cargar el archivo wp-emoji-release.min.js. Y esto se carga en todo el sitio. Mientras que este archivo tan sólo pesa unos 10.5 KB, es inútil si no utiliza emojis en su sitio.

Hay un par de formas distintas para deshabilitar los Emojis en WordPress. Puede hacerlo con un plugin gratuito o con código.

• Deshabilitar Emojis con un Plugin
• Deshabilitar Emojis con Código

Cómo Acelerar los Comentarios de WordPress o Deshabilitarlos

Una sección de comentarios atestada en un sitio puede causar muchos problemas de desempeño. Sólo piense en los recursos que se usan para hacer que funcionen los comentarios:

• Una base de datos es necesaria para mostrar comentarios existentes.
• Las entradas de la base de datos son creadas para cada comentario.
• Los comentarios y los metadatos de los comentarios son recibidos y procesados por el navegador de un visitante.
• Los recursos externos, como los Gravatars, son pedidos, descargados y cargados (requiriendo una búsqueda de DNS separada)
• En muchos casos, grandes recursos de JavaScript y jQuery tienen que ser descargados y procesadas para lograr que funcione el sistema de comentarios de la forma en que se supone que deba funcionar.

Aquí tenemos cuatro opciones distintas de lo que puede hacer para acelerar los comentarios en WordPress:

Opción 1 – Deshabilitar los Comentarios

Si su sitio no está teniendo muchos comentarios y no cree que aporte gran valor, podría ser mejor deshabilitar el sistema de comentarios. Recuerde, los comentarios pueden impactar su SEO ya que Google típicamente pondrá estos como contenido adicional de la página, así que sólo debe aprobar comentarios de alta calidad. Revise estas tres formas sencillas para deshabilitar los comentarios:

• Deshabilitar Comentarios dentro de las Opciones de WordPress
• Deshabilitar Comentarios con un Plugin
• Deshabilitar Comentarios con Código

Opción 2 – Optimizar los Comentarios Nativos de WordPress

Su segunda opción sería optimizar el sistema de comentarios nativo de WordPress. Una forma sería reducir el número de comentarios que son cargados en la carga inicial de la página.

1. Vaya a Opciones -> Discusión en el área de admin de WordPress
2. Busque la sección de otras opciones de comentarios
3. Seleccione la cajita a un lado de Separar comentarios en páginas y agregar valor por el número de comentarios que quiera mostrar en la carga inicial de la página.

Otra opción que tiene es hospedar los Gravatars en su CDN. Este es el enfoque que elegimos en Kinsta.

Por defecto, cuando los comentarios de WordPress son cargados, cada Gravatar único requiere una petición de HTTP. Así que si una página cargada con comentarios de 50 participantes distintos, se requerirán 50 peticiones de HTTP para descargar todos esos Gravatars. Como se podrá imaginar, esto puede impactar la velocidad de su página. Sin mencionar el hecho de que hemos visto que la búsqueda externa de DNS a gravatar.com también empieza a tardar mucho y en algunos casos desconectarse por completo.

Si usted ve los Gravatars en el blog de Kinsta, podrá ver que se están cargando de Kinsta.com (incluyendo nuestra CDN). Revise cómo cargar gravatars desde su CDN.

Opción 3 – Utilizar un Sistema de Comentarios Externo

Su tercera opción es utilizar un sistema de comentarios externo. Si su sitio está alojado en un servidor barato, compartido, carente de recursos, entonces utilizar un sistema de comentarios externo podría ayudar a acelerar páginas con muchos comentarios. Es la misma idea que la optimización de imágenes, delegar el trabajo. Sin embargo, si usted tiene como host a Kinsta u otro host de calidad, pasarse a un sistema externo no sería de gran ayuda, ya que, en lugar de acelerar el tiempo de carga de su sitio, podría incluso, hacerlo más lento.

Siempre asegúrese de hacer pruebas de velocidad al usar sistemas de comentarios externos. Vea todas estas peticiones separadas que Disqus genera (como se muestra a continuación). Mientras que muchas de estas peticiones están siendo cargadas de forma asíncrona, aún así notará algo de tiempo de carga adicional si está utilizando Disqus.

Opción 4 – Hacer Carga Diferida a los Comentarios

Su cuarta opción es hacer lazy load a los comentarios, para que no hagan más lenta la carga durante la visualización inicial de la página. Aquí tenemos un par de plugins que podría checar:

• Lazy Load for Comments: Este plugin le permite hacer carga diferida a los comentarios nativos de WordPress.
• Disqus Conditional Load: Si quiere utilizar el sistema de comentarios de Disqus, este es un plugin necesario para hacer lazy load a los comentarios.

Deshabilitar WordPress RSS Feeds

Si no está utilizando la porción de blogging de WordPress en su sitio, usted podría deshabilitar los RSS feeds de WordPress. Probablemente esto no cause un gran impacto en el desempeño, pero cualquier cosa puede ser útil. Es una cosa menos de la que preocuparse.

Consulte estas dos formas distintas para deshabilitar los RSS feeds en WordPress:

• Deshabilitar RSS Feed con un Plugin
• Deshabilitar RSS Feed con Código

Utilice Prefetch y Preconnect

Las sugerencias y directivas de recursos como prefetch y preconnect pueden ser una gran forma para acelerar WordPress detrás del escenario. KeyCDN tiene un excelente artículo y vista general sobre este tema.

Prefetch

El DNS prefetch le permitirá resolver los nombres de dominio (llevar a cabo búsquedas DNS en el fondo) antes de que un usuario haga clic en el enlace, lo que causará una mejora en el desempeño. Esto se hace al agregar una etiqueta rel=”dns-prefetch” en el encabezado de su sitio de WordPress.

<link rel="dns-prefetch" href="//domain.com">

Algunas cosas comunes para usar el prefetching de DNS es para la URL de su CDN, Google fonts, Google Analytics, etc.

 <link rel="dns-prefetch" href="//cdn.domain.com/">
 <link rel="dns-prefetch" href="//fonts.googleapis.com/">
 <link rel="dns-prefetch" href="//www.google-analytics.com">

El prefetch también es soportado por la mayoría de los navegadores modernos. Consulte nuestro tutorial sobre cómo agregar código a su encabezado de WordPress.

O puede simplemente implementar un DNS prefetch utilizando un plugin como Perfmatters. Simplemente de clic en la pestaña de “Extras” en el plugin de Perfmatters y agregue dominios. Formato: //domain.tld (uno por línea)

Preconnect

Preconnect le permite al navegador establecer conexiones anticipadas antes de que suceda una petición de HTTP, eliminando la latencia del viaje completo y ahorrando tiempo a los usuarios.

Preconnect es una herramienta importante en su caja de herramientas de optimización… este puede eliminar muchos viajes en círculos costosos de su vía de petición – y en algunos casos, reducir la latencia de petición por cientos e incluso miles de milisegundos. – lya Grigorik (fuente)

Se hace al agregar una etiqueta rel =”preconnect” en el encabezado de su sitio de WordPress.

<link rel="preconnect" href="//domain.com">

Algunos ejemplos de cosas en las que podría utilizar esto es en la URL de su CDN o Google Fonts.

 <link rel="preconnect" href="https://cdn.domain.com">
 <link rel="preconnect" href="https://fonts.gstatic.com">

Preconnect es soportado por la gran mayoría de navegadores modernos, con la excepción de Internet Explorer, Safari, IOS Safari, y Opera Mini. Consulte nuestro tutorial sobre cómo agregar código a su encabezado de WordPress.

O podría, simplemente implementar preconnect, utilizando un plugin como Perfmatters. Simplemente de clic en la pestaña de “Extras” en el plugin de Perfmatters y agregue dominios. Formato: scheme scheme://domain.tld (uno por línea).

Deshabilite Scripts por Página/Publicación

Otra poderosa forma de acelerar WordPress es revisar cada petición que está cargando en sus páginas y publicaciones. Probablemente termine encontrando scripts que están cargando en todo el sitio, cuando no deberían hacerlo.

Puede utilizar un plugin premium como Perfmatters, el cual tiene una opción de “Script manager”. Esto le permitirá deshabilitar scripts (CSS y JavaScript) por página/publicación, o incluso en todo el sitio con un sólo clic. De nuevo, este plugin es desarrollado por un miembro del equipo de Kinsta.

Algunos ejemplos de cosas que se pueden hacer con esto:

• El popular plugin Contact Form 7 se carga a sí mismo en cada página y publicación. Fácilmente puede deshabilitarlo en todos lados con un clic y habilitarlo solo para su página de contacto.
• Los plugins para compartir en las redes sociales solo deberían cargarse en sus publicaciones. Fácilmente puede deshabilitarlo en todos lados y sólo permitir que cargue en tipos de publicaciones o tipos de publicaciones personalizados.
• El plugin de Tabla de Contenidos (TOC) es cargado en cada página y publicación. Con el administrador de scripts, fácilmente puede controlar en dónde se cargará.

¿Por qué Algunos Plugins Están Codificados de esta Forma?

Podría estar preguntando ¿por qué todos los desarrolladores de plugin simplemente no cargan sus scripts sólo cuando el plugin es detectado en la página? Bueno, es un poco más complicado que eso. Por ejemplo, si usted tiene un plugin como Contact Form 7, este también tiene shortcodes que le permitirán colocarlo en cualquier lado. Esto incluye colocarlo en un widget. Con WordPress, es mucho más difícil hacer consulta a datos de estos, cuando uno quita de la fila los scripts, a diferencia a hacer consulta a datos de la publicación o metadata de la página.

Por lo tanto, en muchas ocasiones esto es debido a problemas de usabilidad. Entre menos oportunidad tenga para que se rompa un plugin, menor serán los tickets y soporte que tendrán. Sin embargo, con tantos plugins en el mercado, hay formas de lidiar con esto y codificar para obtener desempeño si es que así lo desean. Desafortunadamente, algunas veces, el gran número de descargas y usuarios hacen que el codificar por usabilidad sea una prioridad.

Conociendo el Administrador de Scripts

Le daremos un pequeño tour del Administrador de Script. Después de dar clic en su barra de herramientas, se le presentarán todos los scripts que están siendo cargados en esa URL actual, para archivos de JavaScript y CSS. Luego, usted tendrá las siguientes opciones:

1. Estado Prendido:(opción base)
2. Estado Apagado: Deshabilitar en todos lados (luego puede elegir qué tipos de publicaciones quiere tener esto habilitado, junto con la URL actual)
3. Estado Apagado: deshabilitar sólo en la URL actual (esto es muy útil para usar en su página de inicio)
4. Estado Apagado: Excepciones (URL actual, tipo de publicación, o archivo)

Todo está agrupado por el plugin o el nombre del tema. Esto hace que sea súper sencilla deshabilitar el plugin entero. Típicamente un plugin de WordPress tendrá un archivo de JavaScript y de CSS. Un tema de WordPress podría tener más de 10 archivos.

Después de seleccionar y/o modificar las opciones, asegúrese de dar clic en “Guardar” en el parte de abajo. Luego podrá ponerlo a prueba con una herramienta de prueba de velocidad, para asegurarse de que los scripts no estén siendo cargados en la página o publicación. ¡Asegúrese de limpiar primero el caché! Y si todo sale mal visualmente en su sitio, siempre podrá rehabilitarlo en las opciones para regresar a la normalidad.

En una prueba de velocidad por woorkup, pudieron disminuir el tiempo total de carga por un 20.2%. En su página de inicio, pudieron reducir el número de peticiones HTTP de 46 a 30. El tamaño de su página también se hizo más pequeño, de 506.3 KB a 451.6 KB.

Para ver otras formas para deshabilitar scripts, lea nuestra publicación sobre cómo deshabilitar y evitar que se carguen los plugins de WordPress.

Analizando Desempeño de Terceros

Básicamente, cualquier cosa que llame externamente desde su sitio, tiene consecuencias en los tiempos de carga. Lo peor de este problema es que algunos de estos son sólo lentos de forma intermitente, haciendo que sea muy difícil identificar el problema.

Un servicio externo podría ser considerado cualquier cosa que se comunica con su sitio de WordPress desde afuera de su servidor. Aquí tenemos algunos ejemplos comunes con los que nos hemos encontrado regularmente:

• Plataformas de redes sociales, como Twitter, Facebook e Instagram (widgets o pixels de conversión)
• Redes externas de publicidad como Google Adsense, Media.net, BuySellAds, Amazon Associates.
• Analítica de sitios web y scripts de rastreo como Google Analytics, Crazy Egg, Hotjar, AdRoll
• Herramientas de Prueba A/B como Optimizely, VWO, Unbounce
• Sistemas de comentarios de WordPress como Disqus, Jetpack, Facebook comments
• Herramientas de backups y de seguridad como VaultPress, Sucuri y CodeGuard
• Herramientas para compartir en redes sociales como SumoMe, HelloBar
• Redes CDN como KeyCDN, Amazon CloudFront, CDN77, y StackPath
• JavaScript con un host externo.

¿Cuántos de estos rastreadores impactan al desempeño? En nuestro propio estudio de caso, notamos que los scripts externos incrementaron los tiempos de carga por 86.08%.

Ghostery también midió los 500 mejores dominios de EUA en Alexa, y los resultados fueron inigualables, pero para nosotros, no fue realmente una sorpresa. Los sitios web eran 2x veces más lentos cuando no se habían bloqueado a estos rastreadores. Lo que quiere decir que los scripts de rastreo externos son uno de los principales contribuidores para reducir las velocidades de carga en la red.

Tiene que tener mucho cuidado en su sitio de WordPress. ¡Tener tan sólo una llamada de un API externa podría causar que su sitio entero se caiga! Sí, no debería ser así, pero en muchos casos, así es. Lo hemos visto más veces de las que podemos contar.

New Relic brinda una excelente y sencilla forma para monitorear servicios externos con el tiempo. En este ejemplo de abajo, podemos ver llamadas externas que se hacen a twitcount.com, graph.facebook.com y widgets.pinterest.com.

Es importante que cuando agregue una nueva opción o plugin a su sitio, primero investigue los recursos externos que se están cargando de este. ¡Entre menos mejor!

Siempre Optimice con los Dispositivos Móviles en Mente

Google empezó a sacar su índice de mobile-first el 26 de marzo del 2018. Previamente los sistemas de crawling, indexación y de posicionamiento de Google, usaban la versión de escritorio de los sitios web. La indexación centrada en móviles significa que el Googlebot ahora usará la versión móvil de su sitio de WordPress para indexar y posicionar. Esto ayuda a mejorar la experiencia para usuarios móviles.

Cuando se trata de optimizar su sitio para dispositivos móviles, la velocidad es uno de los factores más importantes a tener en cuenta. La velocidad juega un rol importante en todo, desde usabilidad a rangos de rebote y para determinar si los compradores potenciales regresarán o no a su sitio. De hecho, la velocidad es un factor importante para posicionarse en Google Search y en los Ads para las búsquedas en dispositivos móviles.

Las malas experiencias móviles llevarán a la mayoría de los usuarios a no regresar nunca. De acuerdo al último reporte de velocidad de página de Google, el tiempo promedio en que un sitio móvil tarda en cargar en 2018 es de 15 segundos. ¿Se puede imaginar esperar tanto tiempo para cargar una sola página? Sorprendente.

Los usuarios demandan (y merecen) algo mejor. De acuerdo al mismo reporte de velocidad de página, 53% de los visitantes de sitios móviles dejan de esperar si la página tarda más de 3 segundos en cargar.

Las experiencias lentas en dispositivos móviles no están matando las conversiones. Estas previenen que usted obtenga la oportunidad de convertir clientes potenciales desde un principio. A medida que incrementen los tiempos de carga por unos segundos, la probabilidad de que alguien rebote aumenta exponencialmente. Aquí hay algunas cosas a considerar cuando uno optimiza para dispositivos móviles.

Revise Su Tráfico Móvil

Siempre es importante tomarse el tiempo de ver cuánto tráfico móvil está recibiendo, ya que esto podría cambiar un poco sus prioridades. Puede ver cuántos dispositivos móviles están visitando su sitio en Google Analytics bajo “Audiencia -> Móvil -> Vista general.” Como puede ver en este sitio, más del 67% de este tráfico viene de móviles. ¡Eso es muchísimo!

Si usted es cliente de Kinsta, también puede checar el tráfico de los dispositivos móvil vs computadoras en MyKinsta Analytics. Como puede ver en este sitio, más del 88% del tráfico viene de las computadoras. Siempre es importante verificar y no sólo asumir. Simplemente porque todos dicen que las cosas se están pasando al mercado móvil, no quiere decir que pase lo mismo con su sitio. Vea los datos.

Asegúrese de que Su Sitio Sea Responsive

En 2019, ¡Más vale que su sitio sea responsive! Esto quiere decir que utiliza queries de medios para escalar las cosas de forma automática a dispositivos móviles. Si aún no ha hecho esto, entonces ya está detrás de su competencia. Todos los temas de WordPress que hemos mencionado en este artículo funcionan y se ven geniales en todos los dispositivos.

Utilice la herramienta Google Mobile-Friendly para hacer pruebas y asegurarse de que su sitio pase todos los requerimientos.

Revise Varias Veces para Asegurarse de que srcset Funcione

En el pasado, era muy importante cargar las imágenes para escalar y no permitir que CSS altere su tamaño. Sin embargo, esto ya no es importante ya que WordPress 4.4 ahora soporta imágenes responsivas (no escaladas por CSS). WordPress automáticamente crea varios tamaños distintos de cada imagen subida a la biblioteca de medios. Al incluir los tamaños disponibles de una imagen en un atributo srcset  los navegadores ahora pueden elegir descargar el tamaño más apropiado e ignorar los otros. Vea este ejemplo de como lucirá su código.

Debido a plugins externos de imágenes disponibles, hemos visto, en varias ocasiones, que esto no funcione de forma correcta. Por lo tanto, es importante revisar varias veces para verificar que sus imágenes estén recibiendo de forma apropiada el atributo srcset agregado con versiones distintas para diferentes tamaños de pantalla. La optimización de imagen es importante de ahora en adelante.

Google AMP Podría Ser la Solución Para Usted

Google AMP (Accelerated Mobile Pages Project) fue originalmente lanzado en octubre de 2015. El proyecto dependía de un AMP HTML, un nuevo framework abierto, construido en su totalidad de tecnologías existentes de la red, que permite a los sitios web, construir páginas livianas. En pocas palabras, ofrece una forma de servir una versión básica de la página web actual.

Tenemos una relación de amor/odio con Google AMP, y al parecer gran parte de la comunidad piensa lo mismo. Lo hemos probado y no obtuvimos buenos resultados. Sin embargo, esto no quiere decir que no funcione. Cada sitio web es distinto, y Google AMP está siendo constantemente mejorado.

Puede empezar rápidamente con Google AMP en su sitio de WordPress con uno de los siguientes plugins:

• AMP para WordPress
• AMP para WP

Revise nuestro tutorial sobre cómo configurar Google AMP. Y si lo necesita, cómo deshabilitar Google AMP. Esto es algo que no podrá quitar tan fácil cuando ya no lo necesite.

Resumen

Cómo ya se habrá dado cuenta, estamos obsesionados con todos los tipos de formas en las que usted puede acelerar su WordPress. Tener un sitio rápido es perfecto para incrementar su posicionamiento, mejora la selección de los motores de búsqueda, mejora las tasas de conversión, incrementa el tiempo que uno está en el sitio y reduce la tasa de rebote. ¡Sin mencionar el hecho de que todos aman visitar un sitio web veloz!

Esperamos que está guía fuera útil y de su agrado, y que haya memorizado algunas cosas y las aplique en su sitio de WordPress. Si es así, por favor, tómese un momento y comparta con otros.

¿Nos olvidamos de algo importante? Si es así, nos encantaría escucharlo. Comparta con nosotros sus consejos para acelerar WordPress en los comentarios de abajo.