# Web Performance para WordPress > WordPress es el gestor de contenidos (CMS) más utilizado en Internet y aunque su núcleo es muy potente y permite muchas optimizaciones, no siempre se configura para que así sea. --- ## Páginas - [Plugins de caché de página](https://www.webperformanceoptimization.es/plugins-cache-pagina/): Última revisión: 11 de enero de 2022 WordPress es un gestor de contenidos ligero, pero que permite ampliar sus funcionalidades... - [Web Performance para WordPress](https://www.webperformanceoptimization.es/): WordPress es el gestor de contenidos (CMS) más utilizado en Internet y aunque su núcleo es muy potente y permite... - [Web Performance Optimization](https://www.webperformanceoptimization.es/wpo/): Última revisión: 20 de diciembre de 2021 Internet es tecnología Cuando hablamos de mejorar el rendimiento de un WordPress no... - [Dominios](https://www.webperformanceoptimization.es/dominio/): Última revisión: 20 de diciembre de 2021 El dominio Un dominio de internet es un nombre único que identifica a... - [DNS](https://www.webperformanceoptimization.es/dns/): Última revisión: 20 de diciembre de 2021 Las DNS Las DNS permiten que un dominio apunte a la dirección IP... - [Certificados TLS](https://www.webperformanceoptimization.es/certificados/): Última revisión: 20 de diciembre de 2021 Versiones de SSL y TLS Los sistemas de cifrado SSL (Secure Sockets Layer)... - [Servidor Web](https://www.webperformanceoptimization.es/web/): Última revisión: 20 de diciembre de 2021 El Servidor Web El servidor web es el que se encarga de que... - [Base de Datos](https://www.webperformanceoptimization.es/datos/): Última revisión: 20 de diciembre de 2021 La Base de Datos La base de datos es un servicio dentro de... - [PHP](https://www.webperformanceoptimization.es/php/): Última revisión: 28 de diciembre de 2021 Lenguaje de programación PHP PHP es el lenguaje de programación principal sobre el... - [WordPress](https://www.webperformanceoptimization.es/wordpress/): Última revisión: 28 de diciembre de 2021 Configurar WordPress Cuando instalamos WordPress tenemos una configuración básica pensada para funcionar en... - [Caché](https://www.webperformanceoptimization.es/cache/): Última revisión: 28 de diciembre de 2021 Caché Cuando hablamos de Web Performance un elemento clave tras la optimización de... - [CDN](https://www.webperformanceoptimization.es/cdn/): Última revisión: 29 de diciembre de 2021 Qué es una CDN Una Content Delivery Network (CDN) es una red de... - [Imágenes](https://www.webperformanceoptimization.es/imagenes/): Última revisión: 30 de diciembre de 2021 Optimización de imágenes Cuando hablamos de la web, sin duda uno de los... - [CSS](https://www.webperformanceoptimization.es/css/): Última revisión: 31 de diciembre de 2021 Código CSS Los CSS son los elementos que dan estilo a nuestros WordPress,... - [JavaScript](https://www.webperformanceoptimization.es/javascript/): Última revisión: 31 de diciembre de 2021 Sobrecarga de JavaScript Si el CSS es crítico en cuanto a la carga... - [Tipografía](https://www.webperformanceoptimization.es/tipografia/): Última revisión: 31 de diciembre de 2021 Carga de Fuentes Desde hace un tiempo que gracias al mecanismo de font-face... - [Cookieless](https://www.webperformanceoptimization.es/cookieless/): Última revisión: 12 de diciembre de 2021 Eliminar cookies innecesarias Como cada vez que se hace una petición se han... - [Herramientas](https://www.webperformanceoptimization.es/herramientas/): Última revisión: 12 de diciembre de 2021 Estándar El Web Performance Working Group es el equipo que plantea distintas especificaciones... --- ## Entradas --- # # Detailed Content ## Páginas Última revisión: 11 de enero de 2022 WordPress es un gestor de contenidos ligero, pero que permite ampliar sus funcionalidades mediante plugins. Estos plugins permiten modificar el comportamiento y la optimización del núcleo y de su funcionamiento principal. Listado de plugins de caché de página All-in-one Performance AcceleratorBreezeCache EnablerCachifyComet CacheezCacheHyper CacheLiteSpeed CacheNitroPackPantheon Advanced Page CachePegasaas Accelerator WPPowered CacheRedis Page Cache for WordPressSimple CacheSiteGround OptimizerSurgeSwift Performance LiteTorqueWPCacheOnWP Fastest CacheWP RocketWP Spider CacheWP Super Cache Comparativa de plugins de caché de página Pruebas de estrés y análisis es un Plesk con WordPress 5. 9, Apache HTTPD, PHP 8. 0 y MariaDB 10. 3. Las pruebas de estrés se han hecho con este comando: wrk --connections 100 --duration 30s --threads 64 --batch_latency --timeout 10s --rate 1024 https://example. com/ Por defecto, en el plugin, solo se ha activado la función de caché. PluginTTFBTiempoPeticiones/segSin plugin0. 236s1. 969s18. 05All-in-one Performance Accelerator0. 324s1. 901s16. 86Breeze0. 272s2. 144s235. 63Cache Enabler0. 324s2. 332s132. 42Cachify0. 157s2. 204s395. 49Comet Cache0. 341s2. 361s109. 76ezCache0. 163s1. 845s136. 27Hyper Cache0. 117s1. 918s116. 28LiteSpeed Cache*0. 307s2. 226s15. 96Powered Cache0. 150s2. 097s213. 92Redis Page Cache for WordPress0. 227s2. 097s16. 22Surge0. 123s2. 070s117. 23Swift Performance Lite0. 148s1. 986s61. 38Torque0. 292s2. 147s16. 07WPCacheOn0. 110s2. 083s111. 56WP Fastest Cache0. 147s2. 029s366. 89WP Spider Cache0. 256s2. 149s16. 60WP Super Cache0. 107s1. 997s387. 78 * El plugin necesita de algún elemento especial (servidor web, alojamiento, etc). Top 3 mejores plugins de caché de página Los 3 mejores plugins de caché, son los siguientes (ordenados alfabéticamente): Cachify https://es. wordpress. org/plugins/cachify/ Es un plugin muy sencillo, con pocas opciones de configuración, pero que requiere incluir la configuración en el . htaccess de forma manual. WP Fastest Cache https://es. wordpress. org/plugins/wp-fastest-cache/ Este plugin, además de cachear la página, permite optimizar hojas de estilo y scripts. La gestión de exclusión no es muy sencilla de utilizar. Permite generar una precarga del sitio de forma asíncrona. WP Super Cache https://es. wordpress. org/plugins/wp-super-cache/ El plugin centrado exclusivamente en la caché de página y con más opciones creado por Automattic. Su configuración avanzada permite configuración para móvil, cuándo refrescar, además de las páginas de exclusión o cuándo limpiar la caché. Tiene un sistema de precarga. --- WordPress es el gestor de contenidos (CMS) más utilizado en Internet y aunque su núcleo es muy potente y permite muchas optimizaciones, no siempre se configura para que así sea. En este sitio vas a encontrar información sobre cómo optimizar un sitio WordPress por completo, desde lo más base hasta lo más visual para los usuarios. Los elementos que encontrarás en el sitio están basados en la documentación general de Web Performance publicada por Javier Casares. Este material se encuentra bajo licencia EUPL v1. 2. Puedes usarlo para su distribución y crear tu propio contenido, pero siempre cumpliendo la licencia. En caso de no mencionar el material, o producir material derivado sin cumplir la licencia, se procederá a tomar las medidas necesarias. Performance Dominios DNS Certificados TLS Servidor Web Base de Datos PHP WordPress Caché CDN Imágenes CSS JavaScript Tipografía Cookieless Herramientas --- Última revisión: 20 de diciembre de 2021 Internet es tecnología Cuando hablamos de mejorar el rendimiento de un WordPress no hemos de olvidar nunca que Internet es tecnología y que WordPress funciona con componentes básicos de la mayoría de proyectos en Internet. Y es que, al igual que pasa en el SEO (Search Engine Optimization), en el WPO (Web Performance Optimization) la relación entre infraestructura (hosting), los motores de búsqueda (Google, Bing, Yandex... ) y los usuarios que navegan por tu WordPress tienen mucho que ver. El SEO y el WPO se basa en elementos y algoritmos creados por ingenieros, por lo que, si quieres que un algoritmo te considere mejor, has de hacer que la tecnología esté de tu lado. El WPO implica el uso de un 100 % mejoras tecnológicas, más o menos fáciles de aplicar. Lo que sin duda es, son mejoras abiertas y que ayudan a que Internet sea mucho mejor, así que hay que ponerse el sombrero del Open-Source y compartir. Por qué hacer mejoras de rendimiento Hablar de Web Performance es hablar de mejorar un proyecto web a todos los niveles. ¿Qué significa esto? Rapidez por defecto: En el caso de WordPress, su núcleo está pensado para que la velocidad tenga un peso considerable, pero quizá no lo están otros elementos que hay su alrededor como extensiones o temas. Maquetación del navegador: Con el fin de hacer que las páginas web más rápido los desarrolladores necesitan la capacidad de encontrar qué partes son más lentas. Esto requiere revisar el tiempo que tarda en cargar y ejecutarse el JavaScript, los CSS, la maquetación de los elementos, la gestión del DOM (Document Object Model)... Estándar: Hay que establecer un estándar sobre las formas de medir, los datos, las pruebas... El Web Performance Working Group es un primer ejemplo a tener presente. Datos: Hacer seguimiento de los resultados y encontrar nuevas oportunidades de rendimiento requiere un gran análisis de datos. Verde: Los estudios realizados que cuantifican cómo mejorar el funcionamiento web confirman la reducción del consumo de energía y por ello la contaminación que generan los centros de datos. Algunos datos sobre WPO Los datos lo dicen todo: Amazon: 0,1 segundos de retraso implican una pérdida del 1 % de los ingresos. AOL: hizo una revisión del número de páginas vistas en muchos sitios web y concluyó que aquellos que funcionan rápido tienen unas 7-8 páginas vistas por usuario y que las lentas tan solo 3-4 páginas vistas por usuario. Bing: 1 segundo de retraso implica una caída del 2,8 % de los ingresos; 2 segundos de retraso implican una bajada del 4,3 % de los ingresos por usuario. Facebook: 0,5 segundos más lento provoca una caída de tráfico del 3 %; 1 segundo provoca una caída del 6 %. Google: 0,4 segundos de retraso causan una caída del 0,59 % de las búsquedas por usuario; 0,5 segundos más en cargar implica un 25 % menos de búsquedas. Google Maps: redujo un 30 % el tamaño de sus ficheros y el número de peticiones aumentó un 30 %. Hotmail: 6 segundos de retraso en la carga implica 40 millones de anuncios menos al mes, lo que supone 6 millones de dólares menos al año. Mozilla: hizo su página de descargas 2,2 segundos más rápida y hubo un crecimiento de descargas de un 15,4 %. Netflix: activó el sistema gzip en sus servidores consiguiendo un aumento de entre el 13 % y 25 % de velocidad de carga y reducción de un 50 % del volumen de tráfico. Shopzilla: consiguió reducir el tiempo de carga de las páginas de 7 segundos a 2 segundos y la conversión se incrementó entre un 7 % y un 12 %, además de aumentar un 25 % las páginas vistas del sitio y pudiendo reducir la cantidad de servidores a la mitad. Yahoo! : 0,4 segundos de retraso causan una caída entre el 5 % y el 9 % del tráfico. De forma general ya nos encontramos con: El 47 % de los usuarios esperan que una página cargue en menos de 2 segundos. El 14 % cambia de tienda en línea si la página tarda en cargar. El 40 % de los usuarios abandona una página que tarda más de 3 segundos en cargar. El 64 % de los compradores que no están satisfechos cambia de sitio para su próxima compra. El 52 % de los compradores afirman que un sitio que carga rápido los fideliza. Qué significa que un sitio web sea rápido Cuando hablamos de la velocidad de carga de un sitio hay que normalizar el uso de las palabras o conceptos que utilizamos para que todos "hablemos el mismo idioma". El tiempo de carga de un sitio no se puede medir en un momento en concreto, sino que se ha de hacer en varios. Cada uno de estos momentos tiene unas implicaciones distintas y requiere de optimizaciones muy distintas, por lo que "mi sitio tarda x. xx segundos en cargar" es una frase que debemos eliminar de nuestro discurso WPO. Podríamos hacernos unas primeras preguntas: ¿Está pasando algo? ¿La navegación del sitio inicia correctamente? ¿Responde el servidor? ¿Es útil lo que tenemos delante? ¿Se ha iniciado la carga del sitio lo suficiente como para comenzar a interactuar? ¿Es usable el sitio? ¿Pueden los usuarios interactuar o está cargando todavía? ¿Funciona sin problemas? ¿Son las interacciones con el sitio correctas, sin tiempo de carga y veloces? Para resumir estas preguntas podemos aplicarnos un punto de medición en cada uno, en lo que se refiere a la carga de la página: Primera impresiónCarga de primeros contenidosCarga de contenidos útilesTiempo para ser interactiva Además de estos momentos que son los más básicos y que cada uno de ellos permite saber qué se debe mejorar en cada una de las partes de WordPress, podemos añadir los Core Web Vitals, que ayudan a encontrar puntos de dolor en la carga de un sitio. Una de las razones por la que es importante la velocidad de carga de un sitio es la conversión. La conversión es un concepto muy variable, porque puede ser distinto en un blog, donde... --- Última revisión: 20 de diciembre de 2021 El dominio Un dominio de internet es un nombre único que identifica a una subárea de internet, por ejemplo un sitio web con WordPress. Sin la ayuda del sistema de nombres de dominio, los usuarios de Internet tendrían que acceder a cada servicio web utilizando su dirección IP (por ejemplo, sería necesario utilizar 172. 217. 10. 110 en vez de google. com). Hay varios factores a la hora de revisar qué dominio es bueno para un proyecto o no. Registrar un dominio en un registrador oficial. Esto va a permitir que los cambios que se realicen y la información que haya documentada sea de primera mano. Listado de Administradores de dominioListado de Acreditados cualificadosQue la resolución a primer nivel sea buena. En general los gTLD y newTLD están gestionados a nivel global. El problema principal está en los ccTLD. Se puede ver la forma en la que se gestionan los "Root DNS" de cada extensión desde la Root Zone Database. Performance Dominios DNS --- Última revisión: 20 de diciembre de 2021 Las DNS Las DNS permiten que un dominio apunte a la dirección IP qué va a servir el sitio web. Es importante que esta resolución sea muy rápida. Su función más importante es "traducir" nombres inteligibles para las personas en identificadores binarios asociados con los equipos conectados a la red, esto con el propósito de poder localizar y direccionar estos equipos mundialmente. Con este sistema, cuando haces una llamada a un dominio como wpsysadmin. com, el dispositivo buscará la dirección IP a la que ha de conectarse y el navegador dirigirá las peticiones allí. Optimización de las DNS Cuando hacemos una petición a los servidores DNS lo que buscamos, en la mayoría de las ocasiones, es la dirección IP a la que corresponde dicho dominio o subdominio. Esto hace que podamos relacionar ese dominio o subdominio en concreto con su IP y almacenarla en la caché de DNS. Pero en muchas ocasiones se configuran datos en las DNS como si se tratase de entradas CNAME, que no dejan de ser "alias" de otros resultados de estas. Esto significa que, si yo hago una petición de un subdominio y me devuelve un CNAME, tendré que realizar otra petición al servidor DNS para resolver la dirección IP de ese alias. Esta doble petición provoca que el proceso vaya más lento, por lo que se recomienda reducir el uso de CNAME a aquellas entradas de direcciones IP que no podamos controlar, como podrían ser servicios que nos dan terceros. Aunque por norma general las DNS vienen configuradas por defecto, en un proyecto nuevo e importante nunca está de más configurar de forma personalizada los servidores DNS. TTL: El TTL es el tiempo de vida (caché) de las DNS. Las DNS no es algo que cambie con frecuencia, hay que pensar en poner unos valores medianamente razonables y altos. Como mínimo hay que poner 60 minutos (3600) y no está de más plantearse incluso indicar 1 día (86400). Dominios "exóticos": Hay que tener cuidado con algunos dominios (por ejemplo los . LY), ya que se encuentran "lejos" de los usuarios finales. Estos dominios a nivel global suelen tener un TTL muy elevado (incluso 2 días) y puede haber problemas cuando el servicio falla. Además, la dependencia de los países es demasiado elevada. Los . LY tienen 2 servidores en Libia, 2 servidores en EE.  UU. y 1 en Países Bajos, lo que hace tener mucha dependencia. Distribución geográfica: Una forma de mejorar las peticiones DNS es hacer una especie de CDN de DNS, y distribuirlas geográficamente. A este sistema se le puede encontrar como Anycast. DNS Públicas y Privadas: En las entradas DNS se pueden incluir IP privadas y públicas. Esto puede hacer que haya muchas resoluciones incorrectas. Lo mejor es separar las IP públicas de las corporativas o privadas en distintos dominios. Desactivar la Recursividad: Por norma general los servidores DNS de un dominio concreto no son servidores DNS públicos, por lo que no es necesario tener activada la recursividad. Elegir proveedor DNS A la hora de optimizar las peticiones DNS deberemos partir de varias opciones. La primera de las opciones es el uso de las propias DNS donde tengamos todo el servidor. Este caso es interesante en aquellos casos en los que la mayoría (80%) del tráfico se encuentra en el mismo país donde está el servidor y los usuarios. La segunda opción es el uso de un proveedor de DNS gratuito aunque en estos casos debería ser un sistema Anycast. Aquí una lista de servicios gratuitos de DNS que existen en la red (ordenados alfabéticamente): 1984: Aunque se centran en dar alojamiento, tienen su servicio de Free DNS para cualquier usuario. BuddyNS: Aunque solo ofrecen 300K peticiones/mes, es más que suficiente y tienen una buena infraestructura distribuida. ClouDNS: Aunque la versión gratuita no es muy amplia, no deja de ser otra opción distribuida importante y conocida. Cloudflare: Ofrecen varios servicios y parece que ahora mismo tienen cerca del 40 % de la gestión de DNS del mundo. FreeDNS: Es de estos servicios que la comunidad pone a disposición de todo el mundo, siempre actualizado y a la última. Geoscaling: Lo interesante de este servicio es que permite distribuir las entradas dependiendo del punto de origen del usuario. Si un usuario está en América, lo mandas a un servidor en US, si está en Europa, a uno en DE... Hurricane Electric Free DNS: Personalmente, el que más me gusta y uno de los que utilizo. Es visualmente feo, pero funcional y si sabes de DNS te deja hacer prácticamente de todo. Además, acaban de añadir soporte a las CAA y tienen servicio dinámico. Ofrecen 50 entradas gratuitas. Namecheap FreeDNS: Aunque se centran en registrar dominios, puedes usar sus servicios de DNS de forma gratuita aunque el dominio no esté con ellos. NS1: Tiene buena pinta, y su servicio de pago parece muy interesante. Ofrecen 50 entradas gratuitas con 500K consultas gratuitas. Rackspace: Tienen el servicio simplemente gratis por darte de alta con ellos. Usan el estándar de BIND9 en modo Anycast. La mayoría de estos servicios también disponen de una versión de pago. Otros servicios habituales de DNS globales son: Amazon Route 53: El servicio de Cloud DNS de Amazon AWS. Azure Cloud DNS: El servicio de Cloud DNS de Microsoft Azure. Google Cloud DNS: El servicio de Cloud DNS de Google Cloud. Dominios DNS Certificados TLS --- Última revisión: 20 de diciembre de 2021 Versiones de SSL y TLS Los sistemas de cifrado SSL (Secure Sockets Layer) y TLS (Transport Layer Security) añaden una capa en la que la información entre dos puntos va cifrada. Esto hace que si alguien intercepta las comunicaciones tenga más difícil saber sus contenidos, ya que necesitará la clave para descifrar la información. Esta es una razón por la que si quieres mejorar la seguridad de tu WordPress deberías tener todo el sitio bajo un certificado. En Europa, por defecto, debería ser obligatorio en todo sitio web debido al RGPD (Reglamento General de Protección de Datos). Existen muchas versiones de estos sistemas de cifrado: SSL 1. 0 nunca llegó a ver la luz. SSL 2. 0 lanzado en 1995 y válido hasta 2014, que quedó obsoleto. SSL 3. 0 lanzado en 1996 y válido hasta 2015 tras la aparición de POODLE (un fallo de seguridad muy grande que afectaba a todas las versiones de SSL). TLS 1. 0 (RFC 2246) se consideraba una evolución de SSL 3. 0 para ser compatibles. En junio de 2018 se recomendó subir a TLS 1. 1. TLS 1. 1 (RFC 4346) incluía, principalmente, mejoras sobre los ataques CBC (Cipher Block Chaining). Apple, Google, Microsoft y Mozilla dejaron de darle soporte en marzo de 2020. TLS 1. 2 (RFC 5216) lanzado en 2008 incluye unas cuantas mejoras y posteriormente los TLS dejas de ser compatible con SSL (RFC 6176). TLS 1. 3 (RFC 8446) lanzado en agosto de 2018 y es la versión que incluye más cambios de todas las versiones en cuanto a seguridad. Hoy en día, gracias al lanzamiento de OpenSSL 1. 1. 1 que da soporte a TLS 1. 3, todos los sitios web deberían intentar usar esta versión del sistema. Si no se dispone de esta versión, se debe utilizar el TLS 1. 2. Si quieres analizar la versión y seguridad de tu sitio según sus certificados, puedes usar la herramienta de SSL Labs. Gratuito vs. Pago En los últimos tiempos se ha extendido el uso de certificados TLS gratuitos. Desde el punto de vista técnico no hay ninguna diferencia con los certificados de pago, aunque habitualmente los gratuitos se han de renovar cada 3 meses, y los de pago cada año. Un certificado de pago suele ir asociado con un seguro de entre $10. 000 y $250. 000. Este seguro viene dado por si se rompe el cifrado que hay entre el servidor y el navegador del usuario. En la mayoría de casos, a menos que gestiones información altamente sensible, no sería necesario el uso de un certificado de pago. Creación de un certificado Let's Encrypt Un ejemplo para generar los certificados con validación de ficheros es: certbot certonly --authenticator webroot -d example. com,www. example. com --webroot-path /webs/example. com/ --cert-name example. com Configuración para Apache HTTPD Una configuración para Apache HTTPD puede ser similar a la siguiente: SSLEngine on SSLCertificateFile /etc/letsencrypt/live/example. com/cert. pem SSLCertificateKeyFile /etc/letsencrypt/live/example. com/privkey. pem SSLCertificateChainFile /etc/letsencrypt/live/example. com/fullchain. pem SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384 SSLProtocol All -SSLv2 -SSLv3 -TLSv1 BrowserMatch "MSIE " nokeepalive ssl-unclean-shutdown downgrade-1. 0 force-response-1. 0 BrowserMatch "MSIE " ssl-unclean-shutdown Configuración para nginx Una configuración para nginx puede ser similar a la siguiente: server { listen 443 ssl http2; listen :443 ssl http2; # SSL ssl_certificate /etc/letsencrypt/live/example. com/fullchain. pem; ssl_certificate_key /etc/letsencrypt/live/example. com/privkey. pem; ssl_trusted_certificate /etc/letsencrypt/live/example. com/chain. pem; ssl_session_cache shared:example:15m; ssl_session_timeout 720m; ssl_session_tickets off; ssl_protocols TLSv1. 2 TLSv1. 3; ssl_prefer_server_ciphers off; ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384"; # SSL OCSP Stapling ssl_stapling on; ssl_stapling_verify on; resolver 9. 9. 9. 9 8. 8. 8. 8 valid=300s; resolver_timeout 2s; DNS Certificados TLS Servidor Web --- Última revisión: 20 de diciembre de 2021 El Servidor Web El servidor web es el que se encarga de que un sitio web se sirva, ni más ni menos. Suele ir en conjunción con distintos elementos como PHP para poder procesar los sitios en tiempo real en el lado del servidor, ya que el Servidor Web solo sirve los contenidos; toma un HTML físico o generado y lo envía, recupera una imagen y la envía... Servidores web hay muchísimos y cada uno tiene ciertas ventajas e inconvenientes. Los más conocidos y habituales son Apache HTTP, nginx y LiteSpeed, en Linux y Microsoft IIS en Windows. Lo principal de los servidores web es que tengan muy buena integración con sistemas de procesamiento de código como PHP. Además, hay que analizar que den soporte al menos a HTTP/2. 0 y, por defecto, tenerlo activado, lo que significa que necesitaremos un certificado TLS para nuestro dominio. NOTA: Recuerda comprobar los requisitos de WordPress para los Servidores Web. La versión de HTTP En la actualidad existen 3 versiones del protocolo HTTP, que es el sistema por el que se comunica el navegador con el servidor web. Estas versiones son la 1, la 2 y la 3. La versión 1 ha estado gestionando Internet durante 15 años, y para sacarle partido a los cifrados y certificados TLS, deberíamos usar al menos la versión 2. 0. La versión 1. 0 y 1. 1 establecieron los elementos básicos que conocemos, como por ejemplo los códigos 2xx, 3xx, 4xx o 5xx, que son los que resuelven si la carga de una web ha sido correcta, hay una redirección, hay un error en la página o un error en el servidor. La versión 2. 0 requiere del uso de un sistema de cifrado si se quiere aprovechar al máximo. Sigue funcionando por el sistema TCP y añade un sistema principal de streams. Esto permite mejorar la paralelización de peticiones, lo que permite que se hagan muchas más peticiones a la vez sin que se sature la conexión. La versión 3. 0 mejora el sistema funcionando por UDP mediante QUIC. Al reducir la cantidad de validaciones en la conexión, se gana algo de velocidad. La mayor diferencia entre el HTTP2 y el HTTP3 es el protocolo sobre el que funciona. El protocolo TCP tiene sistemas que permiten saber que algo que se manda a un usuario desde un servidor llega a su destino, mientras que UDP no, aunque el protocolo UDP, al no tener estos sistemas de verificación funciona mucho más rápido. Con el sistema QUIC se añaden ciertas medidas de fiabilidad en la interconexión de datos. Hoy en día en el que las telecomunicaciones son bastante fiables, pierde bastante el sentido de estar validando todo el rato que la información llega según se recibe. HTTP/0. 9 – 1991HTTP/1. 0 – 1996 (RFC 1945)HTTP/1. 1 – 1997 (RFC 2616)HTTP/2. 0 – 2015 (RFC 7540)HTTP/3. 0 – 2019 (Propuesta) Si quieres saber si un sitio web funciona con HTTP3 se puede usar el sitio http3check. net. Usar HTTP/2. 0 o HTTP/3. 0 Una de las primeras decisiones a la hora de optimizar el servidor web es elegir correctamente qué protocolo de HTTP vamos a utilizar, ya que posteriormente a eso se derivarán muchas de las optimizaciones en otros elementos. Esto podría desbloquear, por ejemplo, situaciones con la paralelización o carga de contenidos de CSS o JavaScript. Actualmente nos encontramos que: Apache HTTP da soporte a HTTP/1. 0, HTTP/1. 1 (por defecto) y HTTP/2. 0. nginx da soporte a HTTP/1. 0, HTTP/1. 1 y HTTP/2. 0 (por defecto). LiteSpeed da soporte a HTTP/1. 0, HTTP/1. 1, HTTP/2. 0 y HTTP/3. 0 (por defecto). En cualquier caso, hay que recordar que se han de abrir los puertos de los cortafuegos 80 (HTTP) para TCP y 443 (HTTPS) para TCP y UDP si queremos que funcionen todas las versiones. Con esto conseguiremos un primer paso importante en cuanto a la mejora de velocidad de carga del sitio. Se deberán utilizar sistemas de cifrado TLS 1. 2 o TLS 1. 3 para el correcto funcionamiento del HTTP/2. 0 o HTTP/3. 0. Para mayor seguridad, además, se deberían deshabilitar los sistemas de SSL 2. 0, SSL 3. 0, TLS 1. 0 y TLS 1. 1. Activar HTTP/2. 0 en Apache HTTPD Si queremos que nuestro sitio tenga soporte a HTTP/2. 0 en Apache HTTPD, deberemos configurar el soporte en el VirtualHost. Para ello deberemos tener al menos la versión 2. 4. 17. Protocols h2 http/1. 1 ServerAdmin example@example. com ServerName example. com ... Añadir la línea de protocolos e incluir el h2 es el sistema para dar soporte a esta versión. Activar HTTP/2. 0 en nginx Si queremos que nuestro sitio tenga soporte a HTTP/2. 0 en nginx, deberemos configurar el soporte en el VirtualHost. Para ello deberemos tener al menos la versión 1. 9. 5. server { listen 443 ssl http2; server_name example. com; ... } En la línea en la que se escucha el puerto añadiremos el http2 es el sistema para dar soporte a esta versión. Activar HTTP/2. 0 en LiteSpeed En LiteSpeed el protocolo HTTP/2. 0 viene activo por defecto, por lo que no es necesario hacer ningún cambio. Activar HTTP/3. 0 en LiteSpeed Para que el protocolo HTTP/3. 0 funcione en LiteSpeed solo es necesario abrir el puerto 443 por UDP (normalmente solo está activo por TCP). Por defecto LiteSpeed lleva activo QUIC, lo que hace que, de forma automática, funcione esta versión del protocolo. Si no está abierto el puerto, pasará a funcionar solo con HTTP/2. 0. Dispones de más información en How to Enable QUIC on LiteSpeed Web Server. Sistemas de compresión Una forma de hacer que los sitios web vayan más rápidos es hacer que la velocidad de descarga sea menor. Para eso muchos servidores y navegadores permiten el uso de la compresión gzip / DEFLATE que comprime los contenidos antes de enviarlos y los descomprime al ser recibidos. Existen sistemas más avanzados como Brotli (RFC 7932) pensados para... --- Última revisión: 20 de diciembre de 2021 La Base de Datos La base de datos es un servicio dentro de un servidor en el que se almacenan los datos, en este caso, de un WordPress. Existen muchos tipos de bases de datos, pero para el caso de WordPress es necesario el uso de una base de datos compatible con SQL y, más concretamente, compatible con el estándar de MySQL. NOTA: Revisa los requisitos de Bases de Datos para WordPress. En principio lo más habitual en WordPress es utilizar MySQL o MariaDB, aunque se puede usar sistemas Cloud que ofrecen un servicio compatible. En la base de datos se almacenará toda la información correspondiente a WordPress, en las que se incluye la mayoría de la configuración del sitio, entradas, páginas, configuración de plugins o temas y otros muchos más elementos. Mantener al día El protocolo SQL es un sistema que varía con muy poca frecuencia, por lo que disponer de una versión más antigua o moderna de la base de datos suele influir bastante poco para WordPress. En lo que sí que afecta es al rendimiento. Por norma general, cada nueva versión de MySQL o MariaDB suelen incluir mejoras de rendimiento y mejoras en cuanto a nuevas funcionalidades que pueden ser necesarias por alguno de los plugins. Es por eso que es muy recomendable siempre mantener al menos la versión menor de lo que tengamos instalado y mantener siempre una versión lo más alta posible de las que estén soportadas por cada proveedor en cada momento. Diferencias entre MySQL y MariaDB Desde el punto de vista propio de WordPress, no debería haber ninguna diferencia entre el uso de una edición u otra, aunque hay que tener presente que cada vez más las diferencias entre un sistema y otro van aumentando por lo que es posible que llegue un momento en el que sí que influya. La mayoría de proveedores que trabaja con WordPress suele instalar MariaDB. Esta última es 100% GPL, por lo que la licencia es la misma que WordPress, a diferencia de la licencia que usa MySQL desde que fue adquirida por Oracle. También hay que tener en cuenta que MySQL, en su edición Comunidad, tiene limitaciones en cuanto al uso de la escalabilidad, ya que, para eliminar la limitación de 200. 000 conexiones, has de conseguir una edición empresarial de pago. Este es un elemento muy importante sobre todo para aquellos sitios que trabajan con comercio electrónico o plugins de un coste tecnológico elevado. Tipos de hosting Hosting Compartido / Hosting Cloud Cuando hablamos de bases de datos en un entorno compartido o gestionado, en general hay poco margen para su configuración u optimización. La gestión la tiene el proveedor y ha de aplicar una configuración general para todos los sitios que pueden encontrarse en el proveedor, por lo que nunca estará optimizado para lo que requiere tu WordPress. Hosting Dedicado / VPS En los casos en los que tenemos control absoluto de la configuración de la base de datos hemos de decidir cómo repartir los recursos con respecto a otros servicios que pueda haber en la propia máquina o si vamos a separar en una máquina exclusiva la base de datos. En estos casos en los que tenemos control de la base de datos hemos de encontrar una configuración adecuada según el tipo de sitio WordPress que vayamos a tener. Por norma general un WordPress dispone de mucha carga de lectura y mucho menor de escritura, pero si tenemos un medio en el que se hacen muchas ediciones de los contenidos o una carga más grande en el panel de administración, deberemos ajustar las configuraciones. Configuración para MariaDB Para una máquina con Ubuntu 20. 04 LTE, con MariaDB 10. 6, un ejemplo de configuración puede ser el siguiente. # # # Global / Idioma # basedir = /usr bind_address = 127. 0. 0. 1 server-id = 1 log_bin = /var/log/mysql/mysql-bin. log character_set_server = utf8mb4 collation_server = utf8mb4_general_ci connect_timeout = 60 datadir = /var/lib/mysql default_storage_engine = InnoDB default_tmp_storage_engine = InnoDB lc_messages = es_ES lc_messages_dir = /usr/share/mysql lc_time_names = es_ES pid_file = /run/mysqld/mysqld. pid skip_external_locking = 1 skip_name_resolve = 1 sync_binlog = 128 tmpdir = /tmp user = mysql # # General # div_precision_increment = 6 expire_logs_days = 7 host_cache_size = 128 join_buffer_size = 256M lock_wait_timeout = 3600 max_allowed_packet = 128MB max_connections = 2048 max_connect_errors = 1024 max_digest_length = 1024 max_error_count = 1024 max_prepared_stmt_count = 16382 max_sort_length = 8M max_user_connections = 0 preload_buffer_size = 128M query_alloc_block_size = 32K range_alloc_block_size = 32K sort_buffer_size = 256M stored_program_cache = 1024 table_cache = 2048 table_definition_cache = 1024 table_open_cache = 1024 table_open_cache_instances = 4 thread_cache_size = 205 thread_stack = 1M tmp_table_size = 64M transaction_alloc_block_size = 8K transaction_prealloc_size = 2K # # Logs # log_error = /var/lib/mysql/mysql-error. log log_queries_not_using_indexes = 0 long_query_time = 5 slow_query_log = 1 slow_query_log_file = /var/lib/mysql/mysql-slow. log # # MyISAM # bulk_insert_buffer_size = 16M concurrent_insert = 1 delay_key_write = on key_buffer_size = 512M key_cache_age_threshold = 300 key_cache_block_size = 1024 key_cache_division_limit = 100 myisam_data_pointer_size = 6 myisam_max_sort_file_size = 256M myisam_mmap_size = 512M myisam_recover_options = FORCE,BACKUP myisam_repair_threads = 1 myisam_sort_buffer_size = 64M read_buffer_size = 256M read_rnd_buffer_size = 64M # # InnoDB # innodb_adaptive_flushing = 1 innodb_adaptive_flushing_lwm = 10 innodb_adaptive_hash_index = 1 innodb_adaptive_hash_index_parts = 32 innodb_adaptive_max_sleep_delay = 120000 innodb_autoextend_increment = 64 innodb_autoinc_lock_mode = 2 innodb_buffer_pool_chunk_size = 64M innodb_buffer_pool_dump_at_shutdown = 1 innodb_buffer_pool_dump_now = 0 innodb_buffer_pool_dump_pct = 25 innodb_buffer_pool_instances = 8 innodb_buffer_pool_load_abort = 0 innodb_buffer_pool_load_at_startup = 1 innodb_buffer_pool_load_now = 0 innodb_buffer_pool_size = 512M innodb_change_buffer_max_size = 25 innodb_change_buffering = 5 innodb_cmp_per_index_enabled = 0 innodb_commit_concurrency = 0 innodb_concurrency_tickets = 2176 innodb_deadlock_detect = 1 innodb_disable_sort_file_cache = 0 innodb_doublewrite = 1 innodb_fast_shutdown = 1 innodb_file_per_table = 1 innodb_fill_factor = 80 innodb_flush_log_at_timeout = 1 innodb_flush_log_at_trx_commit = 1 innodb_flush_method = 4 innodb_flush_neighbors = 1 innodb_flush_sync = 1 innodb_flushing_avg_loops = 100 innodb_force_load_corrupted = 0 innodb_force_recovery = 0 innodb_ft_cache_size = 16M innodb_ft_enable_diag_print = 0 innodb_ft_enable_stopword = 1 innodb_ft_max_token_size = 84 innodb_ft_min_token_size = 3 innodb_ft_num_word_optimize = 4000 innodb_ft_result_cache_limit = 512M innodb_ft_sort_pll_degree = 4 innodb_ft_total_cache_size = 512M innodb_idle_flush_pct = 100 innodb_io_capacity = 8800 innodb_io_capacity_max = 9312... --- Última revisión: 28 de diciembre de 2021 Lenguaje de programación PHP PHP es el lenguaje de programación principal sobre el que funciona WordPress. Al ser el sistema principal de cálculo, debe estar optimizado para que el tiempo de carga del sitio sea el menor posible. ¿Qué versión utilizar? Hay que tener en cuenta que cada versión mayor de WordPress es compatible con las versiones que había en la época en la que se desarrolló, pero que no tiene porqué dar soporte con versiones nuevas. Podemos ver la compatibilidad en el PHP matrix de WordPress. Hay que tener en cuenta 2 factores para decidir qué versión de PHP instalar en tu sitio. La primera es saber qué versiones de PHP soporta WordPress en ese momento. Si tomamos como ejemplo WordPress 5. 8, en su documentación nos dice que funciona con versiones entre PHP 5. 6. 20 y PHP 8. 0. También sabemos que oficialmente no es 100% compatible con PHP 8. 0, aunque se le da un soporte para controlar posibles errores. En su fecha de lanzamiento existían PHP 7. 3, 7. 4 y 8. 0. Teniendo esto en cuenta, la opción lógica para elegir versión de PHP sería la 7. 4. Con este sistema deberíamos siempre tener en cuenta que cada versión mayor de WordPress funciona bien con una versión de PHP, pero que con el paso del tiempo, cada 3 años esa versión de PHP dejará de tener soporte, por lo que deberemos ir manteniendo las versiones de PHP mayores al día con las versiones de PHP. PHP: CGI vs. FPM A la hora de configurar PHP para trabajar con el servidor web existen, principalmente, dos formas de hacerlo: en Modo CGI y en Modo FPM. Una forma sencilla de entender cuál es el funcionamiento de estos dos modos es que el sistema CGI funciona como un programa ejecutable, de forma que el servidor web, cuando recibe un código PHP, llama a ese programa y ejecuta el código, y que el sistema CGI funciona como un servicio, de forma que siempre está en memoria como algo independiente, y cuando se recibe una petición al servidor web, este llama al servicio que está a la escucha y pendiente de ser ejecutado. Cada uno de estos sistemas tiene sus pros y contras y cada servidor web tiene sus preferencias de configuración. Por norma general nos encontramos que Apache HTTPD suele venir integrado para funcionar en modo CGI, y que nginx viene mejor preparado para FPM. Si lo que buscamos es mejorar el rendimiento y poder configurar de una forma concreta el propio PHP, la opción ideal será la de usar PHP en modo FPM, para así poder asignar recursos de una forma más detallada a cada usuario o sitio web. Extensiones de PHP Aunque para que funcione WordPress en sí mismo son necesarias unas mínimas extensiones, la mayoría de plugins requieren algunas extensiones extra que no vienen por defecto en muchas instalaciones. Por ejemplo, en Ubuntu podríamos hacer una instalación de PHP 8. 0 con las siguientes extensiones para tener una cobertura bastante amplia. add-apt-repository -y -s ppa:ondrej/php apt-get -y install php8. 0 php8. 0-{fpm,common,dev,cli,bcmath,curl,gd,intl,imap,mbstring,mysql,opcache,readline,soap,xml,zip,imagick} imagemagick libmagickwand-dev Posteriormente, pondríamos por defecto esta versión de PHP. update-alternatives --set php /usr/bin/php8. 0 update-alternatives --set php-config /usr/bin/php-config8. 0 update-alternatives --set phpize /usr/bin/phpize8. 0 update-alternatives --set phar /usr/bin/phar8. 0 update-alternatives --set phar. phar /usr/bin/phar. phar8. 0 Extensiones PHP necesariasExtensiones PHP recomendablesExtensiones PHP alternativasExtensiones PHP de subidaExtensiones del Sistema Módulos PHP en Salud del Sitio Dentro de las Herramientas de WordPress podemos encontrar el Salud del Sitio que nos indicará si alguna extensión de PHP (entre otras cosas) no está instalada o configurada correctamente. Para solucionar los problemas que puedan sugir, puedes revisar esta documentación: El módulo opcional, curl, no está instalado, o ha sido desactivado. El módulo opcional, dom, no está instalado, o ha sido desactivado. El módulo opcional, exif, no está instalado, o ha sido desactivado. El módulo opcional, fileinfo, no está instalado, o ha sido desactivado. El módulo opcional, filter, no está instalado, o ha sido desactivado. El módulo opcional, gd, no está instalado, o ha sido desactivado. El módulo opcional, hash, no está instalado, o ha sido desactivado. El módulo opcional, iconv, no está instalado, o ha sido desactivado. El módulo opcional, imagick, no está instalado, o ha sido desactivado. El módulo opcional, intl, no está instalado, o ha sido desactivado. El módulo requerido, json, no está instalado, o ha sido desactivado. El módulo opcional, libsodium, no está instalado, o ha sido desactivado. El módulo opcional, mbstring, no está instalado, o ha sido desactivado. El módulo opcional, mcrypt, no está instalado, o ha sido desactivado. El módulo opcional, mysqli, no está instalado, o ha sido desactivado. El módulo opcional, openssl, no está instalado, o ha sido desactivado. El módulo opcional, pcre, no está instalado, o ha sido desactivado. El módulo opcional, mod_xml, no está instalado, o ha sido desactivado. El módulo opcional, simplexml, no está instalado, o ha sido desactivado. El módulo opcional, xmlreader, no está instalado, o ha sido desactivado. El módulo opcional, zip, no está instalado, o ha sido desactivado. El módulo opcional, zlib, no está instalado, o ha sido desactivado. Ficheros de configuración de PHP Si tomamos de base un PHP 8. 0, podríamos tener 3 ficheros de configuración base. El primero de ellos es el de PHP, general (php. ini); el segundo la configuración general del PHP-FPM; finalmente, la configuración del pool que estará escuchando. php. ini Es importante tener en cuenta que esta configuración puede variar dependiendo de cada sistema operativo e instalación. En este caso destacamos los siguientes parámetros. Configuración general max_execution_time = 300 max_input_time = 300 memory_limit = 256M max_input_vars = 1500 error_reporting = E_ALL display_errors = Off log_errors = On post_max_size = 128M upload_max_filesize = 128M A destacar que los tiempos de ejecución deben ir en la misma línea que otros servicios, como por ejemplo el servidor web. No tiene sentido que el servidor web tenga un límite de 30 segundos y PHP de... --- Última revisión: 28 de diciembre de 2021 Configurar WordPress Cuando instalamos WordPress tenemos una configuración básica pensada para funcionar en cualquier alojamiento web, pero no viene optimizado ni configurado para obtener su máximo rendimiento. Es por esto que lo primero que deberemos hacer es optimizar la configuración de algunos de sus elementos para mejorar el rendimiento en varios aspectos, y todo pasa por la configuración en el fichero WP-Config. WP-Config WordPress dispone de un fichero de configuración llamado wp-config. php que por defecto encontramos en la carpeta raíz de su instalación. Este fichero incluye algunas configuraciones básicas como el usuario y contraseña de la base de datos, el prefijo de las tablas, y las claves de cifrado de las cookies. Pero este fichero permite mucha más configuración, gran parte de ella que permite la optimización o la no-saturación de algunos elementos como partes de la base de datos o de los tiempos de respuesta del editor. Si quieres facilitarte el proceso, puedes utilizar el Generador de ficheros WP-Config. Conexión a base de datos define( 'DB_NAME', 'your_own_database_name' ); define( 'DB_USER', 'your_own_database_user' ); define( 'DB_PASSWORD', 'your_own_database_password' ); define( 'DB_HOST', 'localhost' ); define( 'DB_CHARSET', 'utf8mb4' ); define( 'DB_COLLATE', 'utf8mb4_general_ci' ); De estas configuraciones, es importante configurar correctamente el DB_CHARSET y el DB_COLLATE. Lo mejor es configurarlos según lo que haya configurado por defecto ya en la propia base de datos, aunque actualmente para WordPress la configuración óptima es la de usar UTF8mb4 y su edición "general". Con UTF8mb4 podremos almacenar códigos UTF8 de 4 bytes, lo que incluiría, entre otras cosas, que elementos como los emojis o caracteres como cirílico, árabes o kanjis puedan almacenarse de forma nativa en la base de datos. El DB_COLLATE permite facilitar cómo se van a ordenar los contenidos en un listado. Por ejemplo, si nuestro sitio principal va a estar en español, y queremos que tras la N se ordene la Ñ, podríamos usar un utf8mb4_spanish_ci en vez del utf8mb4_general_ci. Contenido define( 'AUTOSAVE_INTERVAL', 30 ); define( 'WP_POST_REVISIONS', 5 ); define( 'MEDIA_TRASH', true ); define( 'EMPTY_TRASH_DAYS', 7 ); define( 'WP_MAIL_INTERVAL', 86400 ); Por defecto WordPress tiene un sistema de autoguardado de los contenidos del editor cada 60 segundos. Podemos gestionar el tiempo si queremos que guarde con más o menos frecuencia con el AUTOSAVE_INTERVAL, por ejemplo cada 30 segundos. Un elemento importante que deberíamos limitar siempre, es el de las revisiones de un contenido. Cuando creamos, por ejemplo, una entrada, cada vez que le damos a guardar se hace una copia del contenido previo en el que podemos ver los cambios de lo antiguo con lo nuevo. Esto va generando para cada versión una fila más en la base de datos, lo que hace que pueda crecer mucho si editamos mucho los contenidos. Puede ser interesante que en grandes medios se almacenen muchas copias de un contenido, pero nunca deberían dejarse de forma ilimitada. Para un uso normal, las revisiones de WP_POST_REVISIONS pueden ser 5, 10 o si queremos poner ago muy grande, 100. Cuando gestionamos los contenidos del Media, y los borramos, por defecto los contenidos se eliminan directamente del disco, no quedan en la papelera como otros elementos. Podemos activar o desactivar la papelera del Media mediante MEDIA_TRASH. Los contenidos que dejamos en la papelera, por defecto quedan allí durante 30 días. Si no queremos que esos contenidos ocupen mucho espacio en la base de datos, podemos forzar su vaciado a otra cantidad de días, por ejemplo poniendo EMPTY_TRASH_DAYS en 7 días. Por norma general no mucha gente utiliza el sistema de lectura del correo. Este sistema permite que WordPress acceda a una cuenta de correo y publique los contenidos que encuentra en ese buzón como entradas. Este proceso de lectura se ejecuta cada 5 minutos por defecto, pero si no lo usamos, podemos decirle que solo lo ejecute una vez al día cambiando WP_MAIL_INTERVAL a 86400 segundos. Memoria En la sección de optimización de PHP se comenta la posibilidad de limitar los consumos de memoria de PHP por parte de WordPress. Tenemos la posibilidad de limitar el consumo (los picos) tanto en el frontal como en el panel de administración. El valor para el consumo de memoria del frontal es: define( 'WP_MEMORY_LIMIT', '128M' ); El valor para el consumo de memoria del panel de administración es: define( 'WP_MAX_MEMORY_LIMIT', '256M' ); En cualquier caso dependerá mucho de los plugins que utilices, pero si se configura esto desde un principio, y en algún momento, tras la instalación de un plugin, todo va mal, es más probable que sea el plugin el que esté generando alguna situación con el sistema. Actualizaciones define( 'AUTOMATIC_UPDATER_DISABLED', false ); define( 'WP_AUTO_UPDATE_CORE', 'minor' ); define( 'CORE_UPGRADE_SKIP_NEW_BUNDLED', true ); Si queremos tener la máxima seguridad y rendimiento de WordPress deberemos mantener al día cada una de las versiones que tengamos. Es por esto que, al menos, deberíamos permitir que WordPress mantenga al día ls versiones menores de la rama en la que estemos. Si por ejemplo tenemos WordPress 5. 8. x, que se actualice de forma automática de 5. 8. 1 a 5. 8. 2. Estas actualizaciones menores solo corrigen los elementos actuales, por lo que no deben afectar a ningún plugin ni configuración. Tampoco deberíamos desactivar las actualizaciones y, si queremos mantener limpio de plugins y temas (porque solo tenemos los que necesitamos), podemos deshabilitar la instalación de nuevos contenidos en actualizaciones mayores. Rendimiento define( 'WP_CACHE', true ); define( 'WP_CACHE_KEY_SALT', 'bli6w8w9zrqufbfz79:' ); define( 'COMPRESS_CSS', true ); define( 'COMPRESS_SCRIPTS', true ); define( 'ENFORCE_GZIP', true ); WordPress incorpora una serie de sistemas que permiten la optimización de parte del código y de la caché. Lo primero que debemos hacer es activar la caché interna (WP_CACHE), y configurar un prefijo (WP_CACHE_KEY_SALT) para el almacenamiento de datos. Puede ser cualquiera Lo siguiente que podemos indicar es si queremos que se ejecute un simple sistema de optimización de ficheros CSS (COMPRESS_CSS) y JavaScript (COMPRESS_SCRIPTS) que por defecto viene desactivado. Finalmente, el sistema será capaz de generar la respuesta al usuario de los contenidos con compresión gzip (ENFORCE_GZIP) si... --- Última revisión: 28 de diciembre de 2021 Caché Cuando hablamos de Web Performance un elemento clave tras la optimización de todos los contenidos previos es la de la caché. Un sistema de caché es aquel que permite almacenar elementos ya calculados y repetitivos, pudiendo ser servidos de una forma mucho más rápida que de la habitual. En WordPress podemos configurar varias capas de caché que harán que nuestro sitio funcione mucho más rápido. Algunas de estas configuraciones son generales del servidor web, otras propias de WordPress, y otras que se pueden mejorar mediante plugins. Capas de Caché de WordPress Caché del navegador, caché local o Web App Manifest Los navegadores web que usamos para visitar los sitios permiten almacenar información que se puede necesitar en varias ocasiones a lo largo de la navegación por el sitio. Por eso es muy probable que la primera visita a un sitio web vaya más lenta, pero posteriormente la velocidad de carga aumente, ya que parte de la información queda almacenada. Podemos optimizar estos contenidos estáticos directamente desde la configuración de Apache HTTP, nginx o LiteSpeed (o el servidor web que utilices). Revisa la sección Sistemas de Compresión del Servidor Web. Caché PHP OPcode El software del lenguaje de programación PHP, si tiene la extensión correcta, puede habilitar una caché interna que ayuda a la mejora y optimización de código. Por norma general la caché que viene activa es el OPcache. Puedes ver cómo se activa desde el php. ini. La caché es interna del PHP, es decir, no tiene nada que ver con WordPress por sí misma, pero sí que afecta el código de WordPress. Al ser propia de PHP, si WordPress actualiza su código (por ejemplo con la actualización de un plugin), el propio PHP por sí mismo no será capaz de saberlo, y por ello necesitaremos un sistema que avise que se ha producido el cambio. Este sistema es importante por varias razones. La primera es que se cacheará el código fuente de WordPress de forma que sea más rápido de procesar. Un ejemplo fácil es que el código incluye ficheros variados (por ejemplo, en muchos lugares se incluye el código del WP-Config). Estos "includes" quedarán cacheados de forma que en la memoria tendremos ficheros con todo el código completo a ejecutar sin que se tenga que estar incluyendo en cada petición. Otra de las razones es el funcionamiento de muchos de los plugins de caché de página, que generan contenidos resultantes en PHP y que acabarán sirviéndose como HTML. Este código PHP pre calculado que se genera también pasará a formar parte de la caché de OPcaché, por lo que tendremos código generado y cacheado previamente. Los plugins, básicamente, lo que hacen es vaciar la caché de PHP correspondiente cuando hay una actualización del código PHP, por ejemplo, con una actualización del núcleo, plugins o temas. https://es. wordpress. org/plugins/flush-opcache/ https://es. wordpress. org/plugins/opcache-reset/ https://es. wordpress. org/plugins/opcache-manager/ Caché de objetos WordPress incorpora un sistema interno, que siempre está activo, pero no es permanente, en el que se cachean las peticiones a la base de datos o las que algunos plugins pueden activar en su código. La caché de objetos es una caché intermedia que principalmente se usa para almacenar resultados de algunas peticiones o contenidos calculados. El uso principal y más habitual es el resultado de las peticiones a la base de datos. Un ejemplo sencillo y muy fácil de comprender lo tenemos en un sitio en el que en su página principal tenga los 10 últimos contenidos de las entradas. Estos contenidos, mientras algo no cambie (nuevos comentarios, nuevas entradas... ) la respuesta de la base de datos siempre será la misma y devolverá los mismos resultados. Aquí es donde entraría esa capa de caché de objetos en la que el resultado de los contenidos que se van a mostrar queda almacenado y se utilizaría hasta que algo no cambie o el contenido caduque. Al no realizar peticiones a la base de datos (lento) sino a la caché (rápido) mejoramos los tiempos de carga. WordPress incorpora de serie funciones para el uso de dos servicios pensados para optimizar la caché de objetos como son memcached y Redis. Estos son dos servicios que hay que instalar (solo uno de ellos, a elección) en paralelo a lo habitual en WordPress (como son el servidor web o la base de datos). El funcionamiento de ambos es similar, aunque suelen funcionar de una forma distinta. Por norma general memcached se configura para que el almacenamiento sea en memoria RAM, lo que lo convertiría en un sistema rápido, más caro y que no tiene porqué ser permanente, y Redis sería un sistema que almacenaría la información en disco (por eso se recomienda su uso sobre disco SSD o NVMe) lo que lo hace más barato y permitiría una configuración permanente, de forma que si se reinicia el servicio, podrían quedar almacenados los objetos cacheados previamente. Este sistema es que no cachea toda la página calculada, sino partes de ella, lo que hace que en páginas que no se pueden cachear por completo, sí que lo hagan ciertas partes que no tienen porqué cambiar. Plugins para Redis que pueden ser útiles. https://es. wordpress. org/plugins/redis-cache/ https://es. wordpress. org/plugins/wp-redis/ Plugins para memcached que pueden ser útiles https://es. wordpress. org/plugins/memcached/ Caché de objetos en disco En caso de no disponer de servidores de almacenamiento externos, se puede utilizar un sistema que utiliza el disco como sistema de almacenamiento de objetos, y lo hace en ficheros PHP, sin necesidad de codificar los contenidos. En los sistemas Linux, además se puede configurar la memoria como disco, por lo que podemos convertir el espacio en disco donde se almacena la caché en un espacio de memoria. Es importante saber que hay que reservar espacio en memoria RAM, por lo que necesitarás tener este espacio disponible. https://es. wordpress. org/plugins/docket-cache/ cd wp-content/ mount -t tmpfs -o size=512m tmpfs . /cache/docket-cache En este caso accederemos a la carpeta de wp-content de nuestro WordPress, y allí montaremos... --- Última revisión: 29 de diciembre de 2021 Qué es una CDN Una Content Delivery Network (CDN) es una red de servidores pensados para servir contenidos estáticos de forma masiva y rápida. Las CDN están pensadas inicialmente sólo para servir determinados tipos de contenidos, principalmente los contenidos estáticos que no varían en el tiempo. Esta red de servidores está habitualmente distribuida alrededor del mundo, en varios países, de forma que los contenidos se almacenan en muchos lugares y se pueden servir de una forma mucho más rápida a los usuarios que residen cerca de esa infraestructura. Hay que tener muy presente que, si un contenido está mal optimizado de origen, una CDN no va a solucionar el problema de optimización (a menos que ofrezcan ese servicio que quedará fuera de tu control) ya que estos sistemas se dedican simplemente a retransmitir la información. Si tienes un proyecto internacional o con alcance en varios países, es muy probable que este sistema sea muy útil para mejorar tu proyecto. WordPress y CDN Las redes de distribución de contenidos están pensadas para reducir la latencia, los tiempos de respuesta, a la hora de servir contenidos en distintas zonas geográficas. Si tu proyecto WordPress es internacional, sin duda es una buena opción para, al menos, contenidos estáticos como JavaScript o CSS ademas de imágenes y contenidos media. Si tu proyecto es bastante local, lo mejor es disponer de una infraestructura conectada en ese país. Además, por lo general, los CDN también actual como una capa de caché, ya que al disponer de los contenidos y solo servir los estáticos, no han de hacer cálculos y están optimizados para servirse lo más rápido posible. En caso de trabajar con varias capas de caché, has de asegurarte que se purga en todos los niveles, porque puede hacerse una limpieza en un nivel, pero no en otro, y seguir sirviéndose algo que no ha sido invalidado. WordPress, en la actualidad, no incluye ningún sistema nativo para la gestión de CDN, por lo que es muy probable que debas configurar un plugin concreto para la red CDN que utilices. Redes CDN y plugins Aquí tienes plugins para algunas de las redes CDN más conocidas. esta lista está ordenada alfabéticamente. https://es. wordpress. org/plugins/5centscdn/ https://es. wordpress. org/plugins/akamai/ https://es. wordpress. org/plugins/bootstrapcdn/ https://es. wordpress. org/plugins/bunnycdn/ https://es. wordpress. org/plugins/cdnsun/ https://es. wordpress. org/plugins/cloudflare/ https://es. wordpress. org/plugins/cloudimage/ https://es. wordpress. org/plugins/cloudinary-image-management-and-manipulation-in-the-cloud-cdn/ https://es. wordpress. org/plugins/fastly/ https://es. wordpress. org/plugins/g-core-labs-cdn/ https://es. wordpress. org/plugins/gocache-cdn/ https://es. wordpress. org/plugins/hostry-pagespeed-booster/ https://es. wordpress. org/plugins/imageboss/ https://es. wordpress. org/plugins/incapsula/ https://es. wordpress. org/plugins/cdn-enabler/ https://es. wordpress. org/plugins/wpcdnkoloss/ https://es. wordpress. org/plugins/pagecdn/ https://es. wordpress. org/plugins/rocketdeliver/ https://es. wordpress. org/plugins/sandcage/ https://es. wordpress. org/plugins/shift8-cdn/ https://es. wordpress. org/plugins/sirv/ https://es. wordpress. org/plugins/smartvideo/ https://es. wordpress. org/plugins/sparevideos/ https://es. wordpress. org/plugins/statically/ https://es. wordpress. org/plugins/tencentcloud-cdn/ Caché CDN Imágenes --- Última revisión: 30 de diciembre de 2021 Optimización de imágenes Cuando hablamos de la web, sin duda uno de los elementos principales, además del texto, son las imágenes. Y es por esto por lo que cuando hablamos de Web Performance hemos de dedicarle mucho cariño a este elemento. El primer paso a tener en cuenta es el de la calidad y tamaño de las imágenes. En ocasiones se ve como tomamos una fotografía directamente desde nuestra cámara de fotos o dispositivo móvil y, tal y como está, se sube a Internet. Tamaño de imagen Tenemos cámaras de fotos que hacen fotografías a calidades de 4K, lo que significa una resolución de 3840×2160. La mayoría de las pantallas y de webs están hechas para un tamaño de Full HD, lo que significa que el tamaño que por defecto vemos (sin ampliar) es de 1920×1080. Ya de serie estamos hablando que la imagen es el doble de tamaño y que cuando la pongamos no se va a aprovechar. Así que, para empezar, deberíamos poner la imagen en un tamaño máximo que queramos. Podemos subir la imagen original, pero cuando se presente, usemos una adaptada al tamaño de la pantalla. De la misma manera podemos hablar de las pantallas móviles. Hoy en día mediante el sistema de media-query de CSS podemos mostrar una imagen u otra dependiendo de la pantalla en la que estamos trabajando, por lo que esa imagen original que hemos subido en 4K se podría mostrar en FullHD en pantallas de escritorio, pero en HD (1280×720) en dispositivos móviles. En cualquier caso, también podemos usar los sistemas de "retina" gestionados por HTML o CSS. En resumen, analiza el tamaño de pantalla de tu sitio y de tus usuarios y adapta el tamaño de las imágenes al necesario para cada caso. No redimensiones las imágenes por código. Una forma sencilla de hacerlo puede ser gracias a las mejoras en la etiqueta del HTML5: Una forma de usar este sistema de mejor forma puede ser hacer una pre carga de las distintas imágenes. De esta manera se cargarán todas las imágenes de forma asíncrona, pero sin alterar la velocidad del sitio. Para ello podríamos añadir en la cabecera del sitio algo tal que así: También podemos ejecutar el sistema si usamos el mecanismo de . En este caso podríamos cargar las distintas imágenes con un código tal que este: Y para acelerar la pre carga, podríamos añadir a la cabecera del sitio un código tal que este: Formato de imagen Lo siguiente que hemos de revisar es la compresión y eliminar los datos innecesarios. Con respecto a la compresión, en formatos de imagen como JPEG hay que ver si la compresión está en el 85 % (que reduce bastante sin mucha pérdida) o si en otros formatos podemos reducir la cantidad de colores de la paleta. Usar un formato apropiado en cada ocasión también es importante, ya que cada uno tiene sus puntos a favor y en contra. No es lo mismo un GIF que un PNG, un JPEG o un WebP. Metadatos Además, hemos de intentar reducir la cantidad de información incrustada en las imágenes como pueden ser los datos EXIF, que pueden incluir información como la de geolocalización). Si no son necesarios (podrían serlo en un medio de comunicación, por ejemplo) podrían eliminarse. Imágenes animadas Ahora que los GIF animados vuelven a estar de moda gracias a los memes también es importante recordar que un fichero GIF no deja de ser una serie de imágenes que se muestran una tras otra con un tiempo de frecuencia. Esto puede hacer que esta serie de imágenes se convierta en un fichero de muchos megabytes. En estos casos hay que plantearse si es mejor convertir ese GIF animado en un formato de vídeo de tipo MP4 o WebM que podría estar optimizado y ocupar mucho menos espacio. Si queremos el mismo efecto de loop, podemos cargar el vídeo de la siguiente manera. Además, ten en cuenta que el orden en el que se cargan los vídeos importa, por lo que pondremos el en el orden óptimo de carga ya que si un navegador no puede cargar un formato, pasará al siguiente, pero no al revés. Optimización dinámica de imágenes En ocasiones generar todos los tamaños y formatos de imágenes puede ser harto complicado, por lo que lo ideal sería generarlas en tiempo real, pero sin un coste tecnológico elevado. Y para hacer esto podemos trabajar con Thumbor. Gracias a esta tecnología de código abierto tenemos la posibilidad de aplicar ciertos filtros como optimizar nuestras imágenes pidiéndole que las recorte, encaje, redimensione, alinee... incluso dispone de tecnología de detección facial o de elementos importantes para que al recortar use esos puntos como centro. También dispone de filtros como convertir a escala de grises o añadir una marca de agua. Una opción rápida podría hacerse de esta manera: Codificación de los JPEG Los archivos JPEG (Joint Photographic Experts Group), que más que un formato de archive de imagen, es un sistema de compresión, permiten varias formas de compresión. Tras varios análisis sobre la mejor forma de comprimir, los resultados dicen que, si el archivo ocupa menos de 10 kilobytes, la mejor forma de comprimir es usando el algoritmo "baseline" o "estándar". En cambio, en aquellos archivos que ocupen más de 10 kilobytes, la mejor forma de compresión es la de "progresive". Un detalle del sistema de compresión de los archivos JPEG es que se basa en los bloques de 8×8 de forma que se puede comprimir con base en esta regla. En la imagen, el primer recuadro está alineado en el bloque de 8×8, pero el segundo bloque no lo está. Otro detalle importante de la calidad de los JPEG es que hay ciertos límites. Por ejemplo, comprimir una imagen al 95% o al 100% es inapreciable, pero el tamaño del fichero varía muchísimo. De la misma forma, comprimir a un 50% puede provocar una pérdida excesiva de calidad y, sin embargo, comprimir a un... --- Última revisión: 31 de diciembre de 2021 Código CSS Los CSS son los elementos que dan estilo a nuestros WordPress, y los encontramos en los temas, núcleo, plugins y bloques. Aunque históricamente siempre se planteaba que era mejor hacer pocas peticiones grandes que muchas pequeñas, las últimas versiones de HTTP han mejorado esto de forma que ahora lo importante es el sistema de bloqueos cuando hablamos de CSS. Es por esto por lo que deberíamos separar los CSS en 3 bloques: CríticosGeneralesEspecíficos El objetivo es cargar la menor cantidad de código según el lugar donde nos encontremos. Los CSS críticos son los básicos para crear la estructura del sitio de base. Aquí podríamos plantear que son aquellos que deben dar el esqueleto de la página, los que definen la cabecera, el cuerpo, los menús y los pies de nuestro sitio web, pero sin colores ni nada parecido, simplemente el esqueleto. Este CSS que debería ser común para todo el sitio es lo primero que debería cargarse, y el resto (los generales) se podrían cargar con un sistema de "preload". Para acabar, en páginas concretas en las que tengamos código específico para esa plantilla de página, podríamos también hacer un "preload" de los CSS. Para no bloquear los elementos que no tocan se pueden usar sistemas de "defer" de CSS. No son muy estándar (todavía) pero un código similar al siguiente debería funcionar para todos los casos. Minify de CSS Ahora que ya tenemos todo nuestro código CSS generado en varios ficheros, lo siguiente es reducir el tamaño y eliminar componentes no útiles. A este sistema le llamaremos minimización (minify). El objetivo es eliminar todos los bytes sobrantes del fichero, como por ejemplo comentarios o espacios innecesarios. Un ejemplo de código original sería el siguiente: #lione { font-size: 2em; color: steelblue; } #first { font-size: 1em; color: red; } Que quedaría así: #lione{font-size:2em;color:#4682b4}#first{font-size:1em;color:red} Hay multitud de herramientas por la web que realizan este trabajo. Sólo hay que buscar . Por el funcionamiento en el que se procesa el CSS, hay que evitar el uso de CSS-inline (el CSS que se incluye en el código HTML). Además, para que la carga de la página sea mayor, lo mejor es separar el código CSS de lo que se ve en el "primer pantallazo" de lo que se carga por debajo del punto de corte. Como este sistema puede ser bastante complejo de ejecutar, lo mejor sigue siendo aplicar un CSS muy reducido de esqueleto y posteriormente hacer los cambios, una vez ya se haya cargado el mínimo visual. El CSS en WordPress WordPress, al ser un gestor de contenidos, dispone de sus propios sistemas de gestión de CSS. Por norma general el sistema carga una serie de CSS que vienen con el tema, además de los CSS que pueda cargar el propio WordPress, y posteriormente carga los CSS de plugins y bloques. Esto puede hacer que se encadenen una decena de peticiones con contenido CSS que habría que evitar. En este proceso deberíamos conseguir 4 pasos. El primero de ellos es eliminar las cadenas de versión que muchas veces llevan las peticiones CSS (? ver=5. 8. 2). El segundo sería el de reducir la cantidad de peticiones a ficheros CSS, para conseguir una o dos peticiones. A partir de aquí sería conveniente hacer un minify del contenido, para reducir su tamaño y, finalmente, conseguir que ese fichero CSS resultante quede cacheado para siguientes llamadas. En general hay muchos plugins que hacen esta tarea, pero son un "todo en uno", es decir, no están pensados solo para esta acción, sino que intervienen otras optimizaciones. Por eso es importante elegir un plugin correctamente y que no afecte a otras configuraciones. https://es. wordpress. org/plugins/autoptimize/ https://es. wordpress. org/plugins/fast-velocity-minify/ https://es. wordpress. org/plugins/wp-optimize/ https://es. wordpress. org/plugins/wp-asset-clean-up/ Imágenes CSS JavaScript --- Última revisión: 31 de diciembre de 2021 Sobrecarga de JavaScript Si el CSS es crítico en cuanto a la carga de un sitio se refiere, el JavaScript lo es aún más. Una primera base para tener presente es hacer que el sitio no dependa de JavaScript al menos hasta que esté cargado, y más si depende de bibliotecas externas como jQuery. Cuando hablamos de la carga de JavaScript lo primero es separar los distintos elementos y no cargar todo a la vez, ya que se generaría un bloqueo sobre todo el sitio. Es por esto que la base inicial es cargar las diferentes bibliotecas de elementos que simplemente se carguen, pero sin que se ejecute nada. Todo el JavaScript ha de ejecutarse una vez se haya producido el "Load del DOM". En general este tipo de ficheros, una vez cargados no ejecutan nada, por lo que no bloquean de por sí. Lo siguiente que haremos es minimizar el contenido de los ficheros de JavaScript, al igual que se hace con los CSS. El objetivo es eliminar bytes que no son útiles y reducir el tiempo de descarga. Un ejemplo de código podría ser el siguiente: $(document). ready(function { $("p"). click(function { $(this). hide; }); }); Que quedaría de la siguiente manera: $(document). ready(function{$("p"). click(function{$(this). hide})}); Otro de los elementos principales hoy en día en JavaScript son los códigos de terceros. Aquí podemos incluir los códigos de Google Analytics, los de botón de compartir en Twitter, o los Likes de Facebook. Estos códigos no los alojamos nosotros, ni los hemos programado nosotros ni marcamos los tiempos nosotros. Como en general la mayoría de los problemas que aparecen en los datos de WebPageTest o de PageSpeed Insights vienen derivados de estos scripts, hay que plantearse varias opciones con lo que respecta a ellos. Lo primero que haremos es identificar estos scripts. Por norma general estas herramientas ya te lo permiten ver, ya que suelen ser todos aquellos que hacen llamadas fuera de tu hostname. Algunas cosas que podemos hacer para mejorar los tiempos de respuesta vienen principalmente en cómo se cargan estos scripts. Para ello tenemos una primera opción que es la de cargar los scripts de forma asíncrona (async) o aplazada (defer). En ocasiones funciona, en ocasiones no. A ser posible lo mejor es cargarlos de manera asíncrona, y si no funciona, aplazada. En caso de no funcionar deberíamos plantear otras estrategias. Por defecto los scripts bloquean la carga del HTML. Esto significa que el HTML no empieza a ser funcional hasta que todo el script está funcionando y activo. En el caso del aplazado lo que se hace es cargar los scripts, y comenzar a ejecutarlos una vez se ha acabado de cargar el HTML, de forma que va por pasos. El caso óptimo es el asíncrono, que en paralelo a la carga del HTML va cargando los scripts sin bloquearse unos a otros. Otra forma de optimizar la carga de elementos externos, como se ha comentado antes, es la precarga de los elementos con preconnect y prefetch. De esta manera haremos llamadas a elementos que se cargarán en el navegador para que, posteriormente cuando sean necesarios, ya estén disponibles. Otra opción que puede ser interesante para reducir los tiempos de carga es descargar los scripts de terceros y servirlos directamente desde tu propio servidor, pudiéndoles aplicar sistemas de minimización automática. El funcionamiento, algo más complejo técnicamente, sería el de: Descargar el fichero JS del servidor original con cierta frecuencia (cada hora, cada día) de forma programada. Optimizar el fichero descargado con sistemas automáticos de compresión y minimizado. Servir el script directamente desde nuestro sitio web y no desde el sitio original. Posteriormente, serviríamos el script como si de cualquier otro script nuestro se tratase, pudiéndolo cargar de forma asíncrona sin problema. Optimización general de JavaScript JavaScript, como cualquier otro lenguaje de programación, tiene sus cosas buenas y malas, pero, sobre todo, al ser un lenguaje que se puede interpretar y que se ejecuta en el navegador cliente, vale la pena aplicar una serie de reglas básicas. Evitar las variables globales es una idea bastante buena ya que el rendimiento de dichas variables es bastante bajo. En el caso de ejecutar varios códigos es probable que se sobrescriban dichas variables. Para ello podríamos tener elementos de este estilo que se protegen de accesos externos o la posibilidad de ser sobrescritos. miNameSpace = function { var current = null; function init {... } function change {... } return { init:init, set:change } }; Otro detalle importante es el uso de un código lo más estricto posible, es decir, un código que se ajuste a cualquier motor que interprete JavaScript y sea fácilmente interpretable. Para verificar que estamos usando un código correcto podemos hacer uso de herramientas como JSLint. Es mejor no cambiar valores por defecto del DOM en los valores de los elementos (sobre todo en aquellos que hacen referencia a los estilos), sino modificarlos haciendo cambios en clases que se aplican a dichos elementos. Por ejemplo, podemos aplicar unos cambios tales que: inputs. style. borderColor = '#f00'; inputs. style. borderStyle = 'solid'; inputs. style. borderWidth = '1px'; O podemos hacer un cambio más sencillo, tal que este: inputs. className += ' error'; Y que esta clase “error” sea la que haga el cambio en el estilo, sin modificar directamente los elementos. Es mejor utilizar la anotación corta para crear objetos o arrays. De esta forma, un objeto tal que este: var perro = new Object; perro. color = 'negro'; perro. tamano = 'grande'; Podría crearse mucho más eficiente así: var perro = { color: 'negro', tamano = 'grande' }; Con un array pasaría lo mismo. Si tenemos algo así: var series = new Array; series = 'Fringe'; series = 'The Big Bang Theory'; Sería mucho más eficiente creándose así: var series = ; Otra forma de optimizar código puede ser reduciendo los condicionales. De esta forma un condicional habitual tal que: var direccion; if(x > 10) { direccion = 1;... --- Última revisión: 31 de diciembre de 2021 Carga de Fuentes Desde hace un tiempo que gracias al mecanismo de font-face del CSS podemos usar casi cualquier tipografía que queramos en nuestro sitio web, pero este sistema implica ciertas limitaciones. Cada sistema operativo dispone de unas fuentes de sistema que son con las que, habitualmente se cargan los sitios web. Ahora, mediante este sistema, podemos cargar las fuentes que queramos, pero eso implica hacer una llamada a un fichero externo y descargar la fuente para que pueda ser ejecutada por el navegador. Y en ocasiones las fuentes pueden tener un peso excesivo, dependiendo de la conexión a Internet que tengamos. Dependiendo del tipo de navegador que usemos, el comportamiento de carga es distinto: Chrome: Oculta por defecto el texto de toda la web durante 3 segundos a menos que la fuente se haya cargado. Si tras 3 segundos sigue sin haberse cargado, mostrará una tipografía de sistema. Posteriormente hará el cambio. Edge: Usa una Fuente de Sistema desde el primer momento hasta que la fuente se haya cargado. Posteriormente hará el cambio. Firefox: Oculta por defecto el texto de toda la web durante 3 segundos a menos que la fuente se haya cargado. Si tras 3 segundos sigue sin haberse cargado, mostrará una tipografía de sistema. Posteriormente hará el cambio. Safari: Oculta todo el texto hasta que la fuente esté disponible. Este comportamiento por defecto hace que la carga de la página haga “cosas raras” si no se plantea correctamente. Por eso lo mejor es forzar que el cambio se haga cuando la fuente esté, pero previamente se muestre el texto con una fuente de sistema y la web sea interactiva. Para ello, añadiremos el valor del font-display del CSS en modo swap. @font-face { font-family: "Open Sans", Arial, Helvetica, sans-serif; font-display: swap; } Si eres de los que utiliza Google Fonts, puedes aplicar esta mejora también ya que han incorporado la posibilidad de cargarla mediante un parámetro. Añadir tipografías a WordPress WordPress está integrando una API Webfont para la gestión de fuentes al más puro estilo Google Fonts de forma nativa, ya que hasta ahora esta gestión quedaba relegada a los temas o a plugins. Tipografías en temas A la hora de añadir una fuente externa a un tema tenemos distintas maneras de hacerlo. Lo primero es separar aquellas fuentes que tenemos en nuestro propio sitio (es decir, que tenemos los ficheros alojados nosotros) y que se cargarían mediante una llamada de font-face desde el CSS. En este caso, es importante que la carga se haga de forma separada al resto de CSS y que se haga de forma asíncrona si es posible o incluyendo un sistema de swap. La segunda manera de cargar fuentes suele ser mediante el sistema de personalización de los temas que permiten incluir una fuente de Google u otro proveedor. En estos casos el sistema suele incluir la fuente ya de forma correcta mediante un sistema de swap, pero suele incluirlo en la misma hoja de estilo, lo que hace que la carga pueda bloquear. Es importante que, en el momento que WordPress incorpore la API de Webfont, tu tema utilice este sistema para que se puedan usar herramientas de optimización. Tipografías en plugins Para aquellos temas que no incorporan una gestión de tipografías, existen infinidad de plugins que permiten añadir una fuente de este proveedor mediante una serie de menús desplegables. En este caso, al ser un plugin el que gestiona la carga de los CSS, por norma general usará el sistema de encolado de CSS y añadirá la fuente al listado de CSS. Este sistema puede no ser óptimo, ya que no priorizará la carga del CSS de la fuente como primer elemento, lo que puede provocar un bloqueo de la carga. JavaScript Tipografía Cookieless --- Última revisión: 12 de diciembre de 2021 Eliminar cookies innecesarias Como cada vez que se hace una petición se han de enviar todas las cookies de nuevo, está claro que lo mejor es utilizar cuanta menos información en las cookies sea posible. Es por esto que, si las utilizamos, debemos cuidar la cantidad de información que guardamos. En muchos casos es probable que según vaya pasando el tiempo el usuario interactúe cada vez más con nuestro sitio y de ahí que vayamos guardando más información en las cookies, por lo que es muy razonable tener un sistema que, cada cierto tiempo, vaya eliminando aquella información que no sea absolutamente necesaria para trabajar. Reducir el tamaño de las cookies Aunque en muchas ocasiones no podremos eliminar información de las cookies, sí que podemos hacer que estas ocupen menos de lo que lo hacen. Para ello, usaremos las cookies como si fueran un identificador de sesión. El hecho de que la información se tenga que enviar y recibir cada vez puede generar una ralentización del sitio, por lo que no es nada descartable el poder guardar simplemente un identificador y que la información quede almacenada en el propio servidor web, en la base de datos... De esta forma conseguiremos que la cookie simplemente sea un número o una pequeña combinación de letras y números que no signifiquen nada (y así también aumentar la privacidad), de forma que sólo se envíen unos pocos bytes en cada petición. Aplicar las cookies al nivel necesario Por cómo funcionan las cookies hay que tener muy en cuenta cómo se utilizan en cuanto a sus limitaciones. Es por eso que normalmente cuando se utilizan subdominios, el tratamiento de la información es muy distinto. Si bien es cierto que algunas cookies, como podría ser un identificador, pueden ser útil en cualquier subdominio, lo más probable es que cada uno de ellos tenga algunas peculiaridades que hacen que no sea necesario su uso. Muchos de los navegadores por defecto no limitan el uso de las cookies a los subdominios, por lo que la información, y la velocidad de intercambio de datos, puede ralentizar el sistema si no se trabaja correctamente con ello. Dominios sin cookies para estáticos Por norma general, y como he comentado en la parte del CDN o del Domain Sharding, es interesante que los contenidos estáticos estén en un dominio distinto al que se usa para la programación o el sitio web navegable por el usuario. Teniendo en cuenta esto, se plantea como un tema interesante que los contenidos estáticos (o sea, los dominios para estáticos) no tengan cookies, ya que no van a ser utilizadas y vamos a reducir el ancho de banda de cada una de las peticiones. Para conseguir esto necesitamos un dominio (es mejor no usarlo con un subdominio o similar) y que el servidor web no acepte cookies. Para ello, por ejemplo, en Apache podemos usar una codificación tal que: Header set Cache-Control "max-age=2592000" Header always unset Set-Cookie Header unset ETag FileETag None Para eliminarlo, esta vez en Internet Information Server 6 hay que seguir los pasos: En el sitio web pulsar botón de propiedades y entrar en propiedades. Entrar en la pestaña HTTP Headers / Cabeceras HTTPAñadir una entrada nueva: Etag de nombre y vacío el contenido. Tipografía Cookieless Herramientas --- Última revisión: 12 de diciembre de 2021 Estándar El Web Performance Working Group es el equipo que plantea distintas especificaciones que utilizar a la hora de trabajar con mediciones y buenas prácticas de Web Performance. Navigation Timing – RecommendationThis document provides an interface for web applications to access timing information related to navigation and elements. Page Visibility (Second Edition) – RecommendationThis specification defines a means for site developers to programmatically determine the current visibility state of the page in order to develop power and CPU efficient web applications. Performance Timeline – RecommendationThis specification defines an interface for web applications to access timing information related to navigation and elements. It is used by other specifications, like User Timing. Resource Timing Level 1 – Candidate RecommendationThis specification defines an interface for web applications to access timing information related to HTML elements. Navigation Timing Level 2 – Working DraftThis document provides an interface for web applications to access timing information related to navigation and elements. Beacon – Candidate RecommendationThis specification defines an interoperable means for site developers to asynchronously transfer data from the user agent to a web server, with the user agent taking the responsibility to eventually send the data. High Resolution Time Level 2 – RecommendationThis specification defines a JavaScript interface that provides the current time in sub-millisecond resolution and such that it is not subject to system clock skew or adjustments. Network Error Logging – Working DraftNavigation Error Logging defines an API to store and retrieve error data related to the previous navigations of a document. Resource Hints – Working DraftResource Hints provides hints that authors may use to assist the user agent in fetching resources to improve page performance. Frame Timing – Group NoteFrame Timing helps web developers measure the performance of their applications by giving them access to frame performance data to facilitate smoothness measurements. Server Timing – Working DraftServer Timing, part of the performance timeline metrics, provides API access to request-response cycle performance metrics communicated from the server to the user agent. Performance Timeline Level 2 – Working DraftThis specification extends the High Resolution Time specification by providing methods to store and retrieve high resolution performance metric data. Preload – Candidate RecommendationThis specification defines the relationship of the HTML Link Element . preloadCooperative Scheduling of Background Tasks – Proposed RecommendationThe requestIdleCallback method is a more appropriate way for scheduling background tasks during times when the browser would otherwise be idle. Reporting API – Working DraftThe reporting API provides a generic reporting framework which allows Web developers to associate a set of named reporting endpoints with an origin. Various platform features (like Content Security Policy, Network Error Reporting, and others) will use these endpoints to deliver feature-specific reports in a consistent manner. Page Visibility Level 2 – Proposed RecommendationPage Visibility defines a means to programmatically determine the visibility state of a document. This can aid in the development of power and CPU efficient web applications. User Timing Level 2 – RecommendationThis specification defines an interface to help web developers measure the performance of their applications by giving them access to high precision timestamps. Resource Timing Level 2 – Working DraftThis specification defines an interface for web applications to access the complete timing information for resources in a document. Long Tasks API 1 – Working DraftThis document defines an API that web page authors can use to detect presence of “long tasks” that monopolize the UI thread for extended periods of time and block other critical tasks from being executed – e. g. reacting to user input. Paint Timing 1 – Working DraftThis document defines an API that can be used to capture a series of key moments (First Paint, First Contentful Paint) during pageload which developers care about. Device Memory – Working DraftThis document defines a HTTP Client Hint header to surface device capability for memory i. e. device RAM, in order to enable web apps to customize content depending on device memory constraints. User Timing Level 3 – Working DraftThis specification defines an interface to help web developers measure the performance of their applications by giving them access to high precision timestamps. Timing Entry Names Registry – Working DraftThis registry is intended to provide a central location for enumerating identified interface types of PerformanceEntry objects, which contain various data metrics for the the full lifecycle of a web application. Herramientas Existen multitud de herramientas que pueden ayudarte con las mejoras de Web Performance. Aquí algunas (ordenadas alfabéticamente): Apache JMeter permite hacer pruebas Web, SOAP, bases de datos... OctaGate SiteTimer permite monitorizar el tiempo de descarga de cada uno de los elementos de una página. PageSpeed para Apache HTTP es un módulo que lleva la configuración por defecto de muchas opciones (compresión, agrupar CSS y JS... ). PageSpeed para nginx es un módulo que lleva la configuración por defecto de muchas opciones (compresión, agrupar CSS y JS... ). PageSpeed Insights hace un análisis de los distintos elementos de tu sitio con tiempos agregados y avisos. Telerik Fiddler es un Web Debugging Proxy que permite monitorizar todo el tráfico contra Internet. Test My Site analiza la versión móvil de tu sitio y te da información para mejorarla. WebPageTest permite el análisis del rendimiento de sitios web desde múltiples puntos del mundo y simulando múltiples dispositivos. YSlow analiza páginas web y sugiere formas de mejorar el rendimiento, en base a un conjunto de 34 reglas de optimización con las que puedes mejorar el rendimiento de tu web y hacerla considerablemente más rápida. Haciendo un primer análisis Para hacer un análisis lo primero que hemos de decidir es qué vamos a analizar. Esto significa que no solo hemos de elegir la página principal de nuestro sitio, sino también otras páginas de muestra del resto de plantillas del sitio. Por ejemplo, en un blog podríamos tomar de base la página principal, la página de una categoría, una entrada y una página estática. En un comercio electrónico podríamos tomar la página principal, el listado de productos de una categoría, una ficha de producto,... --- --- ## Entradas ---