(Parte 2 wordpress)
PHP en WordPress: Apache frente a NGINX
Resumen
Elegir entre Apache y NGINX para una instalación WordPress no es solo una cuestión de “cuál es más rápido”, sino de cómo se administra WordPress en la vida real: enlaces permanentes, cachés, plugins que intentan tocar la configuración del servidor, picos de tráfico desde redes sociales, tareas programadas y endurecimiento de seguridad. WordPress está muy “cómodo” con Apache porque puede apoyarse en .htaccess para reescrituras y reglas por directorio, algo que WordPress usa de forma directa para los pretty permalinks y que muchos plugins aprovechan… incluso a veces “rompiéndolo”. [1]
NGINX, en cambio, suele brillar cuando la estrategia es servir lo máximo posible sin ejecutar PHP: está diseñado con un modelo de procesos maestro‑trabajador y un enfoque orientado a eventos, lo que encaja muy bien con tráfico concurrente y entrega eficiente de estáticos; pero exige que la configuración se gestione a nivel de servidor y que las reescrituras (permalinks) vivan en el server block, no en archivos por directorio. Eso reduce “magia automática” dentro de WordPress, pero aumenta el control y, bien configurado, suele facilitar una arquitectura muy sólida (y muy rápida) con PHP‑FPM y caché a nivel de servidor. [2]
La conclusión práctica (y honesta) es que, para WordPress, la caché y la configuración de PHP pesan más que el logo del servidor web: sin caché, Apache y NGINX pueden rendir parecido; con caché (p. ej., FastCGI cache), el salto tiende a ser enorme. [3]
Artículo
Palabras clave
WordPress, servidor web, Apache, NGINX, PHP‑FPM, .htaccess, permalinks, reescrituras, FastCGI cache, caché de página, caché de objetos, Core Web Vitals, SEO técnico, seguridad WordPress, WP‑Cron, hosting compartido, reverse proxy. [4]
Introducción
Cuando se habla de WordPress, se suele simplificar el debate así: “NGINX es más rápido” o “Apache es más compatible”. En la práctica, WordPress funciona como un motor PHP que genera HTML (y también JSON vía APIs) y que se apoya en base de datos y en un conjunto de plugins que añaden capas: SEO, seguridad, optimización, integración social y automatizaciones. [5]
En ese escenario, Apache y NGINX juegan dos papeles:
- Servidor de archivos estáticos (imágenes, CSS, JS, fuentes).
- “Portero” de solicitudes dinámicas que acaban en PHP (páginas no cacheadas, área de administración, formularios, búsquedas, carrito si lo hubiera, etc.). [6]
El detalle decisivo para WordPress es que el CMS sí interactúa con la configuración cuando está en Apache: genera reglas de reescritura típicas en .htaccess para que los “enlaces bonitos” funcionen, y además muchos entornos/plug‑ins se apoyan en esa misma idea de “configuración por directorio”. [7]
Con NGINX, WordPress puede funcionar perfectamente (y lo hace incluso en sitios enormes), pero no existe el equivalente por directorio a .htaccess, y eso desplaza parte del trabajo al administrador del servidor: las reescrituras y reglas viven en configuración central, que hay que recargar para aplicar cambios. [8]
Metodología
La valoración se construye a partir de:
Documentación oficial y semioficial de WordPress sobre Apache (.htaccess) y NGINX, incluyendo su guía avanzada, y material formativo específico sobre permalinks y reescrituras. [9]
Documentación técnica primaria de Apache y NGINX (cómo gestionan configuración, arquitectura de procesos y el coste de .htaccess), y documentación de PHP‑FPM y de integración FastCGI. [10]
Datos de uso y cuota de mercado para contextualizar “qué se usa más” a fecha cercana a febrero de 2026. [11]
Fuentes de operación en WordPress (caché a nivel de NGINX, advertencias de configuración, WP‑Cron como carga real por plugins de autopublicación/automatización) y evidencia empírica publicada con metodología explícita como ejemplo de impacto de caché. [12]
SEO técnico usando documentación de Google sobre Page Experience y Core Web Vitals (porque la pregunta incluye SEO y el impacto “real” suele medirse ahí). [13]
Seguridad según el propio WordPress (mantenimiento, permisos) y guías de endurecimiento, más reglas típicas de servidor relacionadas con ficheros sensibles y superficies comunes. [14]
Resultados
Compatibilidad WordPress y el factor .htaccess
En WordPress, el caso de uso más universal donde aparece una diferencia tangible es Permalinks.
En Apache, WordPress suele manejar el “enrutado” de URLs “bonitas” a través de reglas en .htaccess; el propio material formativo y la documentación avanzada muestran cómo, al cambiar la estructura de enlaces permanentes, aparece un bloque de reglas de mod_rewrite que permite mapear URLs limpias hacia index.php. [15]
En NGINX, esa lógica se lleva normalmente a la configuración del server block con una directiva tipo try_files, precisamente porque NGINX no soporta un sistema “.htaccess por instalación” y la configuración no la puede autogenerar WordPress de forma equivalente. [16]
Aquí aparecen dos “realidades operativas”:
En Apache, WordPress afirma explícitamente que usa .htaccess para manipular cómo se sirven archivos desde el raíz y subdirectorios, especialmente para permalinks; y también reconoce un problema típico: un plugin mal comportado puede corromper .htaccess, motivo por el que ofrece incluso contenido de restauración. [17]
En NGINX, WordPress advierte que no es un sustituto intercambiable: no hay configuración por directorio, WordPress no puede modificar la configuración del servidor, no puede generar reglas de reescritura automáticamente, y si no se adapta la configuración, puede colarse index.php en los permalinks. [18]
Resultado claro: para WordPress “tipo blog/web con plugins habituales”, Apache suele ser más tolerante con cambios desde el panel y con el ecosistema de plugins que “espera” .htaccess; NGINX exige una administración más “infra‑centrada”, pero a cambio pone las reglas en un punto central y controlable. [9]
Arquitectura y rendimiento en condiciones típicas de WordPress
A nivel arquitectónico, NGINX se describe oficialmente con un proceso maestro que mantiene procesos worker, usando un modelo orientado a eventos para distribuir solicitudes de forma eficiente. [19]
Apache, por su parte, utiliza módulos de multiprocesamiento (MPMs). En su documentación de escalado, Apache explica los modelos (prefork/worker/event) y remarca que en 2.4 el MPM por defecto es event, además de recomendar event cuando Apache actúa como capa fina entre cliente y backends y cuando no está ejecutando “código de terceros” embebido (ejemplos: mod_php). [20]
Para WordPress, la clave se resume así:
Si tu WordPress no está cacheado, cada visita “normal” implica ejecutar PHP y consultar base de datos; ahí el servidor web importa, pero a menudo el cuello de botella real es PHP y la query stack, no si el frontal era Apache o NGINX. Un ejemplo empírico reciente (noviembre 2025) en un entorno limitado (Raspberry Pi) muestra que sin caché, la diferencia práctica en solicitudes por segundo entre Apache y NGINX fue mínima (≈108–109 rps). [21]
Si tu WordPress sí está cacheado a nivel de servidor (HTML ya generado), el servidor web cobra muchísimo peso porque sirve “documentos listos” sin invocar PHP. En ese mismo ejemplo, activar FastCGI cache elevó el rendimiento y redujo la latencia media de forma notable. [21]
WordPress, en su guía NGINX, dedica un apartado a fastcgi_cache y expone condiciones concretas para evitar cachear lo que no debe (POST, query strings, wp-admin, cookies de usuario logueado, etc.), lo que te da una idea de por qué la caché a este nivel es tan poderosa y a la vez tan delicada. [22]
NGINX también ha publicado recomendaciones específicas de rendimiento para WordPress donde presenta el cacheo de respuestas FastCGI (PHP) como un enfoque de alto impacto para reducir carga. [23]
En resumen técnico del resultado: en WordPress, NGINX tiende a destacar en entrega eficiente de estáticos y en escenarios de alta concurrencia, pero el gran salto suele venir de evitar PHP con una caché bien diseñada. Apache puede acercarse mucho cuando se configura con MPM moderno y PHP‑FPM, pero si el sitio vive en “.htaccess por todos lados” y sin caché real, el techo de rendimiento llega antes. [24]
PHP en WordPress: por qué PHP‑FPM cambia el debate
WordPress es PHP. Y, en WordPress moderno, cuando se compara Apache vs NGINX, en realidad se compara mucho más a menudo:
Apache + PHP‑FPM (por FastCGI)
frente a
NGINX + PHP‑FPM (por FastCGI) [25]
PHP‑FPM se describe en el manual de PHP como una implementación FastCGI “primaria” con funcionalidades pensadas (sobre todo) para sitios con carga alta: gestión avanzada de procesos, pools con distintos usuarios/entornos, etc. [26]
Apache puede hablar con FastCGI mediante mod_proxy_fcgi, según su propia documentación. [27]
WordPress, en su guía NGINX, señala directamente que para hacerlo funcionar hay que configurar un backend fastcgi o php-fpm, y da ejemplos de conexión a php-fpm. [28]
Esto tiene una implicación práctica muy WordPress:
Si estás en Apache con un hosting “clásico”, todavía existe la cultura de “toco .htaccess y listo”; si estás en un stack con PHP‑FPM, muchas optimizaciones de concurrencia y de uso de memoria se vuelven más accesibles, y Apache con MPM event se vuelve una configuración coherente para WordPress (moderno) porque el PHP se ejecuta fuera. [29]
Uso real en hosting y “qué se usa más” en 2026
En cuota global de servidores web, W3Techs muestra (fecha 20 febrero 2026) que NGINX aparece con una adopción alrededor de un tercio de los sitios medidos, y Apache alrededor de una cuarta parte. [11]
Pero en WordPress hay un matiz importante: la guía oficial de WordPress sobre NGINX afirma que muchos sitios que “reportan NGINX” en cabeceras pueden ser en realidad Apache detrás de NGINX como reverse proxy, porque lo que ves es el proxy, no necesariamente el servidor que ejecuta la app. [18]
Ese patrón también existe en paneles de hosting: por ejemplo, la documentación de cPanel[30] describe NGINX con reverse proxy en el que el contenido dinámico se pasa a Apache, usando caché para servir más rápido. [31]
En hosting gestionado WordPress, la narrativa dominante suele ser “NGINX para rendimiento” (a menudo con capas de caché). Ejemplos de esa postura aparecen en publicaciones de WP Engine[32] que señalan que ambos funcionan con WordPress, pero que NGINX puede ser preferible cuando buscas mejoras de rendimiento. [33]
En conjunto, el resultado “de mercado” es este: NGINX está muy presente (y sube) en la web en general, y en WordPress se usa mucho, especialmente en managed hosting y arquitecturas con reverse proxy; Apache sigue siendo muy común, sobre todo donde .htaccess y la facilidad de configuración por directorio son clave. [34]
Problemas reales que te encuentras con WordPress según servidor
Con Apache, los problemas “típicos WordPress” están muy conectados a .htaccess:
Coste de rendimiento: la documentación oficial de Apache advierte que permitir .htaccess implica que el servidor busca esos archivos en cada directorio durante una petición, y que además el .htaccess se carga cada vez que se solicita un documento, lo que introduce un impacto de rendimiento incluso aunque “no lo uses mucho”. [35]
Riesgo de “configuración por plugin”: WordPress reconoce que plugins pueden dejar .htaccess en mal estado (la razón por la que ofrece una página para restaurarlo). [17]
Con NGINX, los problemas reales suelen ser “operación y exactitud de configuración”:
Reescrituras y permalinks: si no configuras correctamente la reescritura (por ejemplo try_files), se rompen URLs, aparecen 404 o se cuela index.php. WordPress lo señala como diferencia clave. [36]
Ausencia de .htaccess: WordPress recalca que no hay capacidad tipo .htaccess, por lo que el CMS no puede modificar el servidor y no puede generarte reglas automáticamente. Eso afecta a plugins que “esperan” poder escribir reglas (caché, seguridad, redirecciones). [18]
Riesgo de error humano: la guía de WordPress sobre NGINX incluye un aviso directo de que un error tipográfico en archivos de restricciones globales puede abrir agujeros y recomienda probar que directorios como “uploads” no puedan ejecutar PHP. [28]
Caché mal aplicada: el mismo documento muestra una lista explícita de exclusiones necesarias (cookies de login, wp-admin, xmlrpc.php, feeds, sitemaps, etc.) para no cachear contenido que no debe. Esto refleja un problema muy habitual en WordPress: una caché agresiva puede “servir páginas equivocadas” si no se ajusta. [22]
En la práctica, esto se traduce en una frase útil: Apache tiende a fallar por “exceso de facilidad” (todo el mundo toca .htaccess); NGINX tiende a fallar por “exceso de manualidad” (todo depende de una configuración central correcta). [37]
Plugins habituales, autopublicación social y WP‑Cron como carga real
En WordPress, plugins de cache, SEO, seguridad y autopublicación social suelen traer dos tipos de carga:
Carga del lado visitante (HTML/JS/CSS) y carga del lado servidor (PHP y tareas programadas). [38]
Un punto frecuentemente ignorado es WP‑Cron: el propio Plugin Handbook de WordPress explica que WP‑Cron funciona comprobando tareas programadas en cada carga de página, y que las tareas vencidas se ejecutan durante esa misma carga. [39]
Esto importa mucho para “autopublicación social” (y en general automatizaciones): si tienes eventos frecuentes (publicar, reintentos, actualizaciones de feeds, colas), WP‑Cron puede sumar latencia y consumo, especialmente si coinciden con tráfico. [40]
¿Apache vs NGINX lo arregla? No directamente: el cuello de botella suele ser PHP‑FPM, base de datos y el propio plugin. Pero el servidor web sí influye en cómo se sostienen picos de conexiones y en cuánto margen queda para que PHP ejecute. Por eso, en entornos WordPress exigentes, es común empujar páginas al máximo hacia caché (para liberar PHP) y cuidar pools de PHP‑FPM. [41]
Discusión
SEO: lo que realmente afecta y lo que es mito
A nivel SEO técnico, la pregunta “Apache o NGINX” no es un factor de ranking directo, pero sí influye en lo que Google mide como “experiencia de página”:
Google documenta que Core Web Vitals son métricas de experiencia real (carga, interactividad, estabilidad visual) y recomienda conseguir buenos resultados; también indica que estos indicadores se usan por sus sistemas de ranking dentro de las señales de Page Experience. [42]
En WordPress, lo que más suele mejorar LCP/INP/CLS es reducir trabajo del lado cliente, pero el servidor puede mover la aguja en TTFB y en consistencia de entrega, especialmente cuando hay caché de página y estáticos optimizados. Los ejemplos empíricos que comparan con y sin caché ilustran que el mayor salto viene de servir HTML ya listo. [3]
Por tanto, desde SEO, mi lectura técnica es clara: si eliges servidor “por SEO”, te conviene elegir el que te permita sostener mejor caché + mejor estabilidad con menos fricción operativa en tu caso específico, porque eso es lo que se traduce en experiencia de página consistente. [43]
Seguridad: WordPress se rompe por otro sitio, pero el servidor decide cuánto sufres
WordPress, en su documentación de seguridad, es muy explícito: lo más importante es mantener WordPress (núcleo), plugins y temas actualizados, y elegir componentes que reciban actualizaciones activas. [44]
En su guía de hardening, insiste en permisos estrictos y en evitar permisos de escritura/ejecución innecesarios. [45]
¿Dónde entra Apache/NGINX?
En Apache, las medidas “rápidas” en WordPress muchas veces se materializan con reglas en .htaccess: proteger wp-login.php, denegar acceso a wp-config.php, .htaccess, logs, etc. (la guía de WordPress lo muestra como práctica típica). [46]
En NGINX, esas mismas medidas existen, pero son reglas de servidor; WordPress advierte que, al no haber .htaccess, toda la seguridad por reglas depende del administrador y de la corrección del archivo (y el propio handbook alerta sobre fallos de configuración). [47]
Aquí, mi valoración práctica es: NGINX tiende a favorecer un modelo “menos editable por plugins” (porque no hay .htaccess), lo que puede reducir el caos accidental; Apache tiende a favorecer un modelo “más editable por aplicación/usuario”, que en hosting compartido es casi necesario, pero también aumenta la probabilidad de que algo toque configuración de formas inesperadas. El manual de Apache explica precisamente que .htaccess está pensado para cuando no tienes acceso a la configuración principal, y también advierte del coste de rendimiento y de por qué, en general, se debería evitar si puedes usar configuración central. [48]
La trampa del “NGINX es siempre mejor” en WordPress
La parte más interesante (y más útil) de la documentación oficial de WordPress sobre NGINX es que desmonta dos simplificaciones:
Primera: NGINX no es “intercambiable” con Apache para WordPress porque cambia el modelo de configuración y automatización (sin .htaccess, sin reglas autogeneradas). [18]
Segunda: muchas veces “usar NGINX” significa usarlo como reverse proxy delante de Apache, y eso es tan común que incluso puede falsear estadísticas basadas en cabeceras. [49]
Esto conecta con una decisión muy WordPress: si tú dependes de plugins que escriben reglas, de redirecciones en .htaccess, o de un flujo donde el panel “se autoajusta”, NGINX “puro” puede darte más trabajo. En cambio, si tu prioridad es soportar picos (por ejemplo, un post que se viraliza en redes), servir mucha caché y estáticos con eficiencia y tener una configuración central controlada, NGINX se vuelve muy atractivo. [50]
Conclusiones
La mejor respuesta para WordPress es condicional, pero no ambigua:
Apache suele ser “mejor” cuando tu WordPress vive en un entorno donde .htaccess es parte del flujo normal (hosting compartido, cambios frecuentes desde plugins, administración sin acceso root). WordPress usa .htaccess para permalinks y reconoce el papel central de ese archivo. [1]
NGINX suele ser “mejor” cuando tu objetivo real es rendimiento estable bajo concurrencia y, sobre todo, un enfoque fuerte en caché a nivel de servidor, aceptando que la configuración no la hace WordPress y que hay que gestionarla centralmente. La guía de WordPress para NGINX y su apartado de fastcgi_cache muestran exactamente esa dirección. [51]
En WordPress, el mayor salto de rendimiento no suele venir de “cambiar Apache por NGINX” sin más, sino de reducir ejecuciones de PHP con caché bien aplicada; el ejemplo empírico con y sin FastCGI cache ilustra que el diferencial grande aparece cuando el servidor deja de invocar PHP en cada petición. [52]
Para SEO y seguridad, el servidor influye indirectamente: en SEO, por estabilidad de rendimiento y experiencia de página (Core Web Vitals); en seguridad, por el modelo de “quién puede tocar configuración” y por la facilidad de imponer reglas coherentes. Pero WordPress sigue enfatizando que la base de la seguridad está en mantenimiento y permisos, independientemente del servidor web. [53]
Referencias bibliográficas
Documentación de WordPress sobre Apache y .htaccess (Advanced Administration Handbook). [17]
Lección oficial de Learn WordPress sobre permalinks y reescrituras en Apache y NGINX. [54]
Documentación de WordPress sobre NGINX, diferencias clave, reverse proxy y fastcgi_cache. [55]
Documentación oficial de Apache sobre cuándo (no) usar .htaccess y su impacto en rendimiento. [35]
Documentación oficial de Apache sobre escalado, MPMs y recomendaciones (MPM event). [20]
Guía oficial de NGINX sobre procesos y modelo orientado a eventos. [19]
Manual de PHP sobre PHP‑FPM como implementación FastCGI principal y características útiles en carga alta. [26]
Documentación de Apache sobre mod_proxy_fcgi para FastCGI. [27]
WordPress Plugin Handbook sobre WP‑Cron y su ejecución ligada a page loads. [39]
Documentación de Google sobre Page Experience y Core Web Vitals en sus sistemas de ranking. [13]
Guías de seguridad y hardening de WordPress (Advanced Administration Handbook). [56]
Estadísticas de uso de servidores web (W3Techs) a fecha 20 febrero 2026. [11]
Documentación de cPanel[30] sobre NGINX con reverse proxy hacia Apache y uso de caché. [31]
Ejemplo empírico con metodología y métricas comparando Apache, NGINX y NGINX con FastCGI cache en WordPress (noviembre 2025). [21]
Publicación técnica de NGINX sobre recomendaciones de rendimiento para WordPress (FastCGI cache). [23]
Postura de WP Engine[32] sobre Apache vs NGINX en hosting WordPress (como ejemplo de percepción de la industria). [33]
Guía de decisión por escenarios
Si tu WordPress es un blog o web corporativa con plugins habituales (SEO, seguridad, formularios, integración social) y buscas minimizar fricción, Apache tiende a encajar mejor cuando dependes de .htaccess: permalinks y reglas se integran de forma “nativa” en el flujo WordPress, y el propio proyecto valida ese uso. [1]
Si tu prioridad es aguantar picos y servir la mayor parte del contenido como HTML cacheado, NGINX suele destacar, especialmente cuando adoptas FastCGI cache con excepciones correctas para sesiones y administración; la documentación de WordPress para NGINX expone el patrón de exclusión que suele ser necesario para no romper el sitio. [57]
Si necesitas compatibilidad tipo .htaccess pero quieres la eficiencia de NGINX para servir estáticos y actuar como “director de tráfico”, una arquitectura muy común es NGINX como reverse proxy delante de Apache; WordPress la describe como un enfoque potente y además señala que esto es tan habitual que puede confundir estadísticas basadas en cabeceras. [49]
Si tu mayor dolor es autopublicación social, colas o automatizaciones, mira WP‑Cron y PHP‑FPM antes que el servidor: WordPress indica que WP‑Cron comprueba y dispara tareas durante cargas de página, lo que puede afectar a rendimiento según tráfico y número de eventos. En ese caso, el servidor web ayuda por margen de concurrencia, pero el núcleo del problema está en planificación de tareas y capacidad de PHP. [58]
Conclusión final
Para WordPress, Apache es la opción “más directa” cuando quieres compatibilidad y cambios fáciles (especialmente si tu entorno y tus plugins “esperan” .htaccess), mientras que NGINX es la opción “más eficiente” cuando tu enfoque es servir caché y estáticos con máxima estabilidad y asumir configuración central administrada. WordPress lo deja bastante claro: con NGINX no hay .htaccess, WordPress no puede reconfigurar el servidor por ti y las reescrituras se gestionan de forma distinta; con Apache, WordPress usa .htaccess para permalinks y hasta contempla el caso de plugins que lo estropean. [59]
Mi valoración técnica, estrictamente enfocada a WordPress, es que “mejor” casi nunca significa “un nombre u otro” sino “qué arquitectura te permite aplicar mejor lo que de verdad mejora WordPress”: caché de página bien diseñada, PHP‑FPM bien dimensionado, reglas de seguridad coherentes y mantenimiento riguroso. Por eso, si tienes control de servidor y buscas rendimiento sostenido, NGINX con FastCGI cache suele ofrecer el mayor potencial; si priorizas facilidad operativa y compatibilidad con el ecosistema de WordPress en entornos menos administrables, Apache suele ser la elección más pragmática. [60]
[1] [4] [7] [9] [17] [32] [46] Apache HTTPD / .htaccess – Advanced Administration Handbook | Developer.WordPress.org
https://nginx.org/en/docs/beginners_guide.html
[3] [21] [52] WordPress benchmark: Apache vs. Nginx – Ostrich blog
[5] [30] [39] [40] [58] Cron – Plugin Handbook – WordPress Developer Resources
[6] [23] 9 Tips for Improving WordPress Performance
[8] [12] [18] [22] [28] [36] [47] [49] [50] [51] [55] [57] [59] [60] Nginx – Advanced Administration Handbook | Developer.WordPress.org
[10] [35] [37] [48] Apache HTTP Server Tutorial: .htaccess files – Apache HTTP Server Version 2.4
https://httpd.apache.org/docs/current/howto/htaccess.html
[11] [34] Usage statistics and market shares of web servers
https://w3techs.com/technologies/overview/web_server?utm_source=chatgpt.com
[13] [43] [53] Understanding page experience in Google Search results
https://developers.google.com/search/docs/appearance/page-experience?utm_source=chatgpt.com
[14] [44] [56] Security – Advanced Administration Handbook
[15] [16] [54] Permalinks, rewriting urls on Apache and Nginx | Learn WordPress
[20] [24] [29] Performance Scaling – Apache HTTP Server Version 2.5
https://httpd.apache.org/docs/trunk/misc/perf-scaling.html
[25] [26] [41] FastCGI Process Manager (FPM) – Manual
https://www.php.net/manual/en/install.fpm.php?utm_source=chatgpt.com
[27] mod_proxy_fcgi – Apache HTTP Server Version 2.4
https://httpd.apache.org/docs/current/mod/mod_proxy_fcgi.html?utm_source=chatgpt.com
[31] NGINX® with Reverse Proxy
https://docs.cpanel.net/knowledge-base/nginx/nginx-with-reverse-proxy/?utm_source=chatgpt.com
[33] Nginx vs Apache: Best Web Server for WordPress?
[38] [42] Understanding Core Web Vitals and Google search results
https://developers.google.com/search/docs/appearance/core-web-vitals?utm_source=chatgpt.com
[45] Hardening WordPress – Advanced Administration Handbook
