Potencia Pro 337: Cómo diagnosticar una web WordPress lenta con método

Tercer capítulo de la decimoprimera temporada de potencia.pro, el podcast de WordPress y cozas. Es el número 337, aunque ni los propios anfitriones terminan de ponerse de acuerdo al principio sobre si es el tercero o el cuarto. Miguel Angel Terrón y Mariano Pérez vuelven con su mezcla habitual: WordPress, IA, actualidad tecnológica y chistes malos. Muy malos. El calentamiento no falla. Primero llega un chiste de multas por exceso de velocidad y coches tuneados. Después, el que sirve de puente al tema del día: ¿qué generan los tractores que no corren? Cuellos de botella en las carreteras. Pues de cuellos de botella va el episodio, pero de los que aparecen en WordPress. «Mi web va muy lenta»: cómo hacerlo de forma profesional La escena es conocida. Un cliente llega diciendo que su web va lenta. Nosotros la abrimos con los ojos muy abiertos y, muchas veces, no sabemos por dónde empezar o caemos en lo obvio: «¿será tal plugin?», dicho con voz de asco. La propuesta del episodio es sustituir esa intuición por un método ordenado en cuatro pasos. Al final, toda la información se convierte en una lista de prioridades. Paso 1: medir como mide un usuario real Lo que hace casi todo el mundo es entrar en PageSpeed Insights o en una herramienta parecida de Core Web Vitals, pegar la URL de la portada y mirar la nota. Este planteamiento tiene dos fallos. Las condiciones no son reales. El servicio analiza la web desde un buen servidor y con una buena conexión. Tus usuarios, en cambio, quizá navegan con un móvil y 4G. Conviene simular esas condiciones con herramientas que permiten configurar el dispositivo y la conexión: WebPageTest SpeedVitals (no es de Google) Scanfully Solo se mide la portada. La portada puede ir rapidísima y el resto de páginas no. Lo ideal es elegir tres páginas: la portada; una ficha de producto, si es una tienda; otra página con muchas visitas, como la de contacto. Nada de escoger las condiciones del servicio, que son solo texto. Tampoco vale la 404: esa siempre vuela. De esta medición salen las métricas clave: TTFB : lo rápido que responde el servidor. LCP : lo que tarda en mostrarse el elemento más grande, normalmente «la foto gorda». CLS : cuánto se mueve el diseño mientras carga la página. INP : lo rápido que responde la web cuando el usuario interactúa, por ejemplo al escribir en un formulario de contacto. A mitad de explicación hubo tiempo para quejarse de la carraspera que llega con septiembre. Clásico. Paso 2: servidor y base de datos Después de lo que ve el usuario, toca mirar lo que hay debajo. Versión de PHP Lo primero es comprobar la versión de PHP. Con PHP 8.2 o superior, adelante. Por debajo de eso, malamente: optimizar va a ser difícil y perderás el tiempo. Caché de objetos A quien no es de sistemas, «caché de objetos» le suena a los trastos que tiene en casa. En realidad es la caché de la base de datos. Cada artículo que se muestra en la página del blog es un objeto que sale de una consulta. Conviene recordar cómo funciona una web con WordPress: archivos PHP que piden datos a la base de datos para montar la página. La base de datos suele ser una de las partes más lentas, así que es un cuello de botella habitual. Si la web no tiene caché de objetos, hay que activarla. Si el servidor no lo permite, toca plantearse cambiar de hosting. Estado de la base de datos Hay que revisar varias cosas: Opciones de carga automática (autoload): si se está cargando demasiado. Versión del motor. Muchos hostings te dejan usar PHP 8.3 u 8.4, pero mantienen MariaDB o MySQL en versiones antiguas. Actualizar la base de datos da respeto, pero es un punto clave. Índices. Funcionan como el índice de un libro: van directos al dato. WordPress no los trae por defecto. En una web corporativa pequeña casi no se nota, pero en una tienda con 5.000 productos marcan la diferencia. Algunos plugins los generan, aunque no es lo ideal, porque las tareas de sistemas no deberían hacerse desde WordPress. Herramientas para este paso Query Monitor : el básico para detectar consultas de más o consultas demasiado grandes. WP-CLI con el comando `doctor`, para los avanzados que prefieren la terminal. Code Profiler : una herramienta reciente y muy completa para analizar el rendimiento. Scanfully : además de medir, revisa la salud del sitio con más profundidad que la herramienta que trae WordPress. AAA Option Optimizer , el plugin de Joost de Valk, fundador de Yoast. El nombre está pensado para salir el primero en la lista. Lo dejas funcionando una semana o diez días y te dice qué opciones se cargan sin usarse. Es especialmente útil en webs con muchos años de vida. También se pueden revisar las consultas SQL a mano en el servidor. Pero a mano, poco, que somos «agentes de la automatización». Paso 3: el frontend Aquí la herramienta principal es el inspector del navegador. Sus pestañas de red, cabeceras y respuestas muestran todo lo que hace el navegador para pintar la página. Estos son los puntos que conviene vigilar: Cuántos archivos JavaScript y CSS se cargan. Hay temas y constructores que meten decenas de archivos. Con Avada , por ejemplo, es fácil ver 30 hojas de estilo cargándose a lo loco. Conexiones a dominios externos. Imágenes alojadas en otro sitio, scripts de terceros o plugins de seguridad que conectan con servidores como los de Sucuri para escanear. Todo eso ralentiza. Tareas largas de JavaScript. A veces no hay muchos scripts, pero uno solo hace muchísimo trabajo. Tiempos de carga de cada elemento. Si sabes lo que buscas, o sabes preguntarle a una IA sobre lo que estás viendo, el inspector te da información a raudales. «Una jartada», en palabras del episodio. Paso 4: la caché, siempre al final La caché es el último paso por una razón: si la aplicas antes, puede tapar todos los problemas anteriores sin resolverlos. Lo correcto es dejar la web bien desde el principio y usar la caché para ganar ese último empujón. En todos sus tipos (de objetos, de navegador, de página), la idea es la misma: tener las cosas preparadas antes de tiempo para servirlas más rápido. En este paso también se revisa el CDN, y aquí hay un error frecuente. Para qué sirve un CDN. Un CDN es útil para el tráfico internacional. Si tu tienda vende en China, tiene sentido que las imágenes se sirvan desde un servidor cercano y no desde el Reino Unido. Cuándo sobra. Si todo tu tráfico viene de España y tu hosting ya está en España, añadir un CDN con nodo en España apenas mejora nada. Y ahora, a priorizar Contarle al cliente todo lo recopilado solo sirve para que te mire con cara rara. Lo profesional es priorizar. Normalmente habrá dos, tres o cuatro factores que frenan de verdad la web, y otros que apenas influyen. La clave está en centrarse en lo que más rendimiento aporta. Reflexión: webs hechas con IA en un VPS «propio» De ahí surge una reflexión que va más allá de WordPress. Entre moda y moda, como el aura farming, crece otra tendencia: gente que prefiere no pagar el mantenimiento a un desarrollador. Se hace la web con IA y la monta en un VPS «propio». ¿Propio de quién? Del propietario, claro. Muchos creen que una web así no puede ser atacada porque es estática. Pero todo lo explicado en el método es justo lo que resulta crítico para la seguridad: una base de datos sin actualizar; reglas WAF desfasadas; un CDN mal configurado. Con eso, la web queda expuesta a ataques de denegación de servicio o a scripts maliciosos. Hay además otro riesgo. Todas las IA aprenden de las mismas fuentes y tienden a hacer las cosas del mismo modo. Si aparece una vulnerabilidad en ese patrón, o en una versión concreta de PHP o de Java, afecta a todas las webs generadas igual. Lo que parecía libertad frente al mantenimiento puede acabar siendo una cárcel, sobre todo si no sabes qué está pasando en tu servidor. Un VPS en Hetzner por entre 5 y 14 euros al mes es una maravilla, pero hay que mantenerlo. Por eso el consejo es claro. Si creas un proyecto con Codex, Claude, OpenCode o cualquier otra herramienta, incluye una regla fundamental: revisar qué hay pendiente de actualizar en el servidor y actualizarlo. Y pídelo por favor, que cuando las máquinas tomen el control conviene haber sido educado. Noticia: ataques a la cadena de suministro en plugins En el terreno de la seguridad se está poniendo de moda en WordPress el ataque a la cadena de suministro. Funciona así: 1. Un plugin lleva años siendo fiable en WordPress.org. 2. El desarrollador, que apenas gana dinero con él, lo vende encantado. 3. El nuevo dueño mete código malicioso en la siguiente actualización. 4. Tú, que llevas diez años usando ese plugin, ni te enteras de que ha cambiado de manos. Para combatirlo ha aparecido wpbacon.io , un servicio que audita los plugins que cambian de propietario y revisa sus versiones posteriores. Sus cifras actuales: 124.548 plugins vigilados; unas 50.000 auditorías ya cerradas; código malicioso encontrado en 22 plugins. Puedes buscar los plugins que usas para ver si están auditados o pedir que auditen alguno. Recurso del día: 10Web Esta vez la recomendación es un servicio, no un plugin: 10Web . Le describes la web que quieres, por ejemplo una tienda de galletas con pepitas de chocolate. Te hace preguntas y genera una web bonita sobre WordPress, con un tema basado en bloques que luego puedes llevar a tu hosting. Si lo prefieres, puedes limitarte a tomar las ideas y construirlas tú. Tiene planes de pago, pero los tokens gratuitos del principio dan de sobra para crear una primera web sin pagar nada. Gratis total. Cierre con bizcocho (y con chiste) Para terminar, el recordatorio de apuntarse a la gaceta, donde llega un resumen de cada episodio. Resumen, no transcripción completa, que se enrollan mucho. Por si el chiste también acaba en la newsletter, Mariano Pérez remata con uno sobre una camiseta de Desigual que no desmerece al resto. Y con esto y un bizcocho, hasta la semana que viene. No mañana a las 8, aunque el cuerpo lo pida. 🤖 El contenido de este post ha sido generado automáticamente con inteligencia artificial a partir de la transcripción del audio. Puede contener errores o imprecisiones. 🎙️ Publicado con VozCaster , el bot de Telegram que convierte tu voz en un episodio de podcast publicado. Pruébalo gratis . ¿Te ha gustado el episodio? Si quieres que sigamos experimentando con bots, protocolos y empanadillas polacas, no olvides suscribirte y dejarnos tu valoración. ¡Nos escuchamos en el próximo capítulo! Métodos de contacto Enviadnos vuestras preguntas al grupo de Telegram . Apuntaos al canal de Youtube del podcast https://www.youtube.com/potenciapro Si nos queréis decir algo directamente lo podéis hacer a @potenciapro , @materron , @ mpc , o en el grupo de Telegram Y si eres muy muy muy fan del podcast Echa un vistazo a cómo nos puedes ayudar en https://potencia.pro/se-prosperoso/