# Web Performance > Mejora el rendimiento de tu sitio web --- ## Páginas - [Web Performance](https://www.webperformance.es/): El Web Performance parte de la base de crear un sitio web más veloz y funcional para los usuarios. Aprende las técnicas para optimizar tu sitio web. - [Internet es Tecnología](https://www.webperformance.es/internet-es-tecnologia/): Internet se basa en tecnología, y cuando hablamos de motores de búsqueda y de cualquier tipo de sistema relacionado con... - [Por qué aplicar WPO](https://www.webperformance.es/por-que-aplicar-wpo/): Hablar de Web Performance es hablar de mejorar un proyecto web a todos los niveles. ¿Qué significa esto? Rapidez por... - [Algunos datos sobre WPO](https://www.webperformance.es/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... - [¿Cuánto sabes de Internet?](https://www.webperformance.es/cuanto-sabes-de-internet/): Antes de comenzar estaría bien saber cuatro detalles mínimos, y para ello vamos a hacer un pequeño juego a modo... - [Qué es el Web Performance Optimization](https://www.webperformance.es/que-es-el-web-performance-optimization/): Como su nombre indica, es la optimización del rendimiento de la web. Esto significa, en resumen, que se hace una... - [Por dónde empezar](https://www.webperformance.es/por-donde-empezar/): El Web Performance no se mejora cambiando o poniendo un elemento en concreto, sino que es la suma de bastantes... - [El dominio](https://www.webperformance.es/el-dominio/): Hay varios factores a la hora de revisar qué dominio es bueno para un proyecto o no. Registrar un dominio... - [Las DNS](https://www.webperformance.es/las-dns/): Las DNS permiten que un dominio apunte a la dirección IP qué va a servir el sitio web. Es importante... - [La versión de HTTP](https://www.webperformance.es/la-version-de-http/): Sin entrar en muchos detalles, hay que decir que existen 3 versiones de HTTP, la 1, la 2 y la... - [La versión de TLS](https://www.webperformance.es/la-version-de-tls/): Los sistemas de cifrado SSL (Secure Sockets Layer) y TLS (Transport Layer Security) añaden una capa en la que la... - [El servidor Web](https://www.webperformance.es/el-servidor-web/): El servidor web es el que se encarga de que un sitio web se vea, ni más ni menos. Suele... - [El software y versiones](https://www.webperformance.es/el-software-y-versiones/): Es muy importante que cuando lancemos un proyecto en Internet se tenga cierto mantenimiento sobre él por muchas razones. Hay... - [Protección y Alta Disponibilidad](https://www.webperformance.es/proteccion-y-alta-disponibilidad/): Cuando hablamos de SEO y de WPO hemos de tener presente otro elemento importante y es el tiempo de disponibilidad... - [Qué significa que un sitio web sea rápido](https://www.webperformance.es/que-significa-que-un-sitio-web-sea-rapido/): Cuando hablamos de la velocidad de carga de un sitio hay que medir muy correctamente en qué palabras y concetos... - [Cómo medir](https://www.webperformance.es/como-medir/): A la hora de medir y obtener datos hay que tener presentes que hay dos grandes grupos de datos. Los... - [Haciendo un primer análisis](https://www.webperformance.es/haciendo-un-primer-analisis/): Para hacer un análisis lo primero que hemos de decidir es qué vamos a analizar. Esto significa que no sólo... - [Usar HTTP/2.0 o HTTP/3.0](https://www.webperformance.es/usar-http-2-0-o-http-3-0/): Uno de los primeros elementos a tener en cuenta cuando hay algún problema es asegurarse de que estamos trabajando con... - [Optimización de las DNS](https://www.webperformance.es/optimizacion-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... - [Sistemas de compresión](https://www.webperformance.es/sistemas-de-compresion/): Una forma de hacer que los sitios web vayan más rápidos es hacer que la velocidad de descarga sea menor.... - [Prefetch, preload y preconnect](https://www.webperformance.es/prefetch-preload-y-preconnect/): En muchos casos cuando cargamos nuestro sitio web sabemos que vamos a hacer llamadas a elementos externos, a otros hostname,... - [Código CSS](https://www.webperformance.es/codigo-css/): Los CSS son los elementos que dan estilo a nuestros sitios web. Aunque históricamente siempre se había comentado que era... - [Sobrecarga de JavaScript](https://www.webperformance.es/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... - [Optimización general de JavaScript](https://www.webperformance.es/optimizacion-general-de-javascript/): JavaScript, como cualquier otro lenguaje de programación, tiene sus cosas buenas y malas, pero, sobre todo, al ser un lenguaje... - [Optimización para jQuery](https://www.webperformance.es/optimizacion-para-jquery/): jQuery es una biblioteca de funciones preestablecidas de JavaScript que permite interactuar de forma más sencilla con los elementos DOM... - [Limpiar el código](https://www.webperformance.es/limpiar-el-codigo/): Puede parecer algo básico y de sentido común, pero hay que intentar eliminar todo el código innecesario. En este caso... - [Optimización de imágenes](https://www.webperformance.es/optimizacion-de-imagenes/): Cuando hablamos de la web, sin duda uno de los elementos principales además del texto son las imágenes. Y es... - [Optimización dinámica de imágenes](https://www.webperformance.es/optimizacion-dinamica-de-imagenes/): En ocasiones generar todos los tamaños y formatos de imágenes puede ser harto complicado, por lo que lo ideal sería... - [Codificación de los JPEG](https://www.webperformance.es/codificacion-de-los-jpeg/): Los archivos JPEG (Joint Photographic Experts Group), que más que un formato de archive de imagen, es un sistema de... - [Codificación de los PNG](https://www.webperformance.es/codificacion-de-los-png/): El formato de imágenes PNG (Portable Network Graphics) se creó como sustitución del sistema GIF que tiene licencia propietaria y,... - [CSS Sprites](https://www.webperformance.es/css-sprites/): En muchas ocasiones los sitios web tienen pequeños iconos que se van repitiendo a lo largo de las distintas páginas.... - [El data URL scheme](https://www.webperformance.es/el-data-url-scheme/): Siguiendo el mismo sistema que los CSS Sprites, podemos plantearnos que también son algo inefectivos en aquellos casos en los... - [Lazy load](https://www.webperformance.es/lazy-load/): Una de las formas que se suele aplicar a las imágenes para no sobrecargar el sistema es el llamado lazy-load.... - [Carga de Fuentes (tipografía)](https://www.webperformance.es/carga-de-fuentes-tipografia/): Desde hace un tiempo que gracias al mecanismo de font-face del CSS podemos usar casi cualquier tipografía que queramos en... - [Optimización de vídeos](https://www.webperformance.es/optimizacion-de-videos/): Vídeos hay de muchos tipos, aunque pueda parecer lo contrario, aunque por norma general en Internet se suelen usar dos... - [Eliminar cookies innecesarias](https://www.webperformance.es/eliminar-cookies-innecesarias/): Como cada vez que se hace una petición se han de enviar todas las cookies de nuevo, está claro que... - [Reducir el tamaño de las cookies](https://www.webperformance.es/reducir-el-tamano-de-las-cookies/): Aunque en muchas ocasiones no podremos eliminar información de las cookies, sí que podemos hacer que estas ocupen menos de... - [Aplicar las cookies al nivel necesario](https://www.webperformance.es/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... - [Automatizar la barra “/” al final de la URL](https://www.webperformance.es/automatizar-la-barra-al-final-de-la-url/): Gracias a sistemas como el Apache Mod_rewrite tenemos la posibilidad de crear URLs amigables para usuarios y máquinas, pero en... - [Uso del Meta-Refresh](https://www.webperformance.es/uso-del-meta-refresh/): De forma histórica los navegadores son capaces de gestionar una meta-etiqueta que permite redirigir la carga de la página a... - [Caché](https://www.webperformance.es/cache/): Cuando hablamos de Web Performance un elemento clave tras la optimización de todos los contenidos previos es la de la... - [Redirecciones acompañadas de tiempo de caché](https://www.webperformance.es/redirecciones-acompanadas-de-tiempo-de-cache/): Por norma general cuando se hace una redirección no se le indica la duración de esta. Esto significa que tanto... - [CDN – Content Delivery Network](https://www.webperformance.es/cdn-content-delivery-network/): Una Content Delivery Network (CDN) es una red de servidores (en general que usan sistemas de proxy-caché, como se comentaba... - [Dominios sin cookies para estáticos](https://www.webperformance.es/dominios-sin-cookies-para-estaticos/): Por norma general, y como he comentado en la parte del CDN o del Domain Sharding, es interesante que los... - [Velocidad de la conexión](https://www.webperformance.es/velocidad-de-la-conexion/): Aunque en estos momentos es una tecnología todavía en desarrollo, la Network Information API, permitiría al navegador saber qué tipo... - [Tiempo de Indisponibilidad del sitio](https://www.webperformance.es/tiempo-de-indisponibilidad-del-sitio/): Uno de los problemas más habituales que nos podemos encontrar a la hora de actualizar un sitio es qué hacer... - [Estándar](https://www.webperformance.es/estandar/): El Web Performance Working Group es el equipo que plantea distintas especificaciones que utilizar a la hora de trabajar con... - [Herramientas](https://www.webperformance.es/herramientas/): Existen multitud de herramientas que pueden ayudarte con las mejoras de Web Performance. Aquí algunas (ordenadas alfabéticamente): Apache JMeter permite... --- ## Entradas - [¡Hola, mundo!](https://www.webperformance.es/hola-mundo/): Bienvenido a WordPress. Esta es tu primera entrada. Edítala o bórrala, ¡luego empieza a escribir! --- # # Detailed Content ## Páginas El objetivo de este sitio es saber cómo funcionan determinados aspectos de Internet que afectan al SEO (Search Engine Optimization), WPO (Web Performance Optimization) y en general a los sitios Web desde el punto de mejorar su rendimiento. Es una Guía WPO y no plantea sentar cátedra. Para aquellos no técnicos, se busca que se conozcan o suenen los conceptos, pero no aprenderse todo sobre ellos. Simplemente que a la hora de lanzar un sitio web se tengan en cuenta la mayoría de ellos para hacerlo de la manera óptima posible. Esta versión dispone de un 80% actualizado o nuevo con respecto a la Guía WPO (descarga gratuita en PDF) lanzada en 2011, en la que la mayoría de tecnologías actuales no existían. IMPORTANTE: Este documento tiene elementos técnicos que se van a usar a modo principalmente informativo. Si no eres desarrollador web o administrador de sistemas, no deberías hacer cambios en tu sitio sin hacer copias de seguridad previamente. Lo que se indica en este documento son guías, por lo que pueden no ser óptimas para tu sitio web en concreto y no me puedo responsabilizar de su uso o tu interpretación. NOTA: Este documento está revisado con fecha de enero de 2020. NOTA: Este material se encuentra bajo licencia EUPL v1. 2. Puedes usarlo para su distruibución y crear tu propio contenido, pero siempre cumpliendo la licencia. En caso de no mencionar el material, o crear material derivado sin cumplir la licencia, se procederá a tomar las medidas necesarias. Temario --- Internet se basa en tecnología, y cuando hablamos de motores de búsqueda y de cualquier tipo de sistema relacionado con la Web, el SEO y el WPO. 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 es 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é aplicar WPO » --- Hablar de Web Performance es hablar de mejorar un proyecto web a todos los niveles. ¿Qué significa esto? Rapidez por defecto: muchas aplicaciones que se construyen para CMS, lenguajes de programación, “la nube”, bibliotecas de JavaScript, navegadores, servidores... ya están pensadas para ir rápido. 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... Consolidación: las herramientas de rendimiento de la web, servicios y similares no han llevado un único camino, sino que cada uno ha puesto sus esfuerzos de forma separada. Eso va a cambiar y pronto veremos herramientas que combinan la depuración de JavaScript, el perfil de JavaScript, DOM, el uso de la red... todo en una sola herramienta. Las métricas de rendimiento se gestionarán desde un único panel en lugar de tener que visitar múltiples servicios separados. La consolidación también va a ocurrir a nivel de empresa, donde las empresas más pequeñas relacionados con el rendimiento son adquiridos por las grandes empresas de consultoría y servicios. TCP y HTTP: Los protocolos por los que funciona Internet deben ser optimizados. Cualquier mejora en la red llegará a todos los sitios y usuarios. 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. Organizaciones en la industria: dentro del mundillo de la WPO veremos nacer y crecer organizaciones profesionales, formación, certificaciones, organismos de normalización... Un ejemplo podría ser que los editores web compartan información acerca de los anuncios de publicidad lentos. Los datos: hacer seguimiento de los resultados y encontrar nuevas oportunidades de rendimiento requiere un gran análisis de datos. Es probable que comiencen a verse repositorios públicos de datos relacionados con el rendimiento. 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. Rendimiento móvil: es como un nuevo punto de partida, se necesita recopilar todo tipo de información hasta encontrar los principales problemas, las causas y encontrar soluciones y crear herramientas para así poder ofrecer información sobre todo esto. La velocidad como elemento diferenciador: muchas de las decisiones que se tomarán sobre Internet se basarán en el rendimiento. Cuando alguien adquiera un dispositivo, elija un proveedor, se revise un sitio web, la lealtad de los usuarios será un factor importante a la hora de hacer mediciones. « Internet es Tecnología 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 sólo 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 online 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. « Por qué aplicar WPO ¿Cuánto sabes de Internet? » --- Antes de comenzar estaría bien saber cuatro detalles mínimos, y para ello vamos a hacer un pequeño juego a modo de test. Qué es un dominio 127. 0. 0. 1example. comwww. example. com Un dominio es la representación sencilla de un sitio. Inicialmente sólo se podrían usar direcciones IP, que no son sencillas de recordar. Respuesta: 2. example. com Cuál es un TLD . com. es. barcelona Existen extensiones de dominio de primer nivel (TLD), de país (ccLD) o dominios nuevos (newTLD) entre otros. Respuesta: 1. . com Cuál es una entrada DNS 127. 0. 0. 1 A example. comjavier@casares. orgOAuth Una entrada DNS es un registro que indica y relaciona algo de un nombre de dominio con un servicio. Por ejemplo, las entradas A relacionan un hostname (dominio con o sin subdominio) con una IP. Las entradas MX relacionan un hostname con un servidor de correo. Respuesta: 1. 127. 0. 0. 1 A example. com Cuál es un Servidor Web Microsoft VisionginxFilezilla Un servidor web es aquel programa que permite que un sitio web se pueda servir en Internet. Los más conocidos son Apache HTTP, nginx, LiteSpeed, lighthpd... Respuesta: 2. nginx Qué versión de seguridad debes usar con HTTP TLS 1. 3SSL 3. 0TLS 2. 0 Existen sistemas de cifrado de tipo SSL y TLS. Los SSL han quedado obsoletos y los más usados han sido el SSL 2. 0 y, durante poco tiempo, el SSL 3. 0 que tenía un agujero de seguridad muy importante. Posteriormente se lanzaron otros sistemas de cifrado de tipo TLS. Los más habituales hoy en día, y son los únicos seguros, el TLS 1. 2 y TLS 1. 3. Respuesta: 1. TLS 1. 3 Cuántas versiones mayores de HTTP hay 2 versiones3 versiones5 versiones Ha habido 4 versiones principales de HTTP. La inicial fue la HTTP/0. 9, posteriormente la HTTP/1. 0 que fue mejorada con la HTTP/1. 1 (año 1999). Hace unos años (en 2015) se lanzó el HTTP/2. 0 que debería ser la versión mínima de uso hoy en día, y se está comenzando a implantar la HTTP/3. 0 (lanzada en 2019). Respuesta: 3. 5 versiones « Algunos datos sobre WPO Qué es el Web Performance Optimization » --- Como su nombre indica, es la optimización del rendimiento de la web. Esto significa, en resumen, que se hace una web mejor. El objetivo es optimizar todos los elementos de un sitio web con la tecnología disponible para que los usuarios sean capaces de percibir que el sitio funciona de la mejor manera posible. « ¿Cuánto sabes de Internet? Por dónde empezar » --- El Web Performance no se mejora cambiando o poniendo un elemento en concreto, sino que es la suma de bastantes elementos. Por norma general el WPO se debería integrar de forma nativa en cualquier proyecto web, pero si comienzas uno, puedes fijarte en elementos básicos que posteriormente pueden ser más complejos. « Qué es el Web Performance Optimization El dominio » --- Hay varios factores a la hora de revisar qué dominio es bueno para un proyecto o no. Registrar un dominio en un registrador oficial. Listado de Administradores de dominioListado de Acreditados cualificadosQue la resolución a primer nivel sea buena. En general los TLD 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. « Por dónde empezar 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. « El dominio La versión de HTTP » --- Sin entrar en muchos detalles, hay que decir que existen 3 versiones de HTTP, 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, 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. 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 (por ejemplo). La versión 3. 0 mejora el sistema funcionando por UDP mediante QUIC. La mayor diferencia entre el HTTP2 y el HTTP3 es el protocolo sobre el que funciona. El sistema 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 sistema 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 Si quieres saber si un sitio web funciona con HTTP3 se puede usar el sitio http3check. net. « Las DNS La versión de 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. En Europa, por defecto, debería ser obligatorio en todo sitio web debido al RGPD. Existen muchas versiones de estos sistemas: 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 Cipher Block Chaining (CBC). Apple, Google, Microsoft y Mozilla dejarán 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 usa, al menos usar la 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. « La versión de HTTP El servidor Web » --- El servidor web es el que se encarga de que un sitio web se vea, 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 sólo 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 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 o ASP. 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. « La versión de TLS El software y versiones » --- Es muy importante que cuando lancemos un proyecto en Internet se tenga cierto mantenimiento sobre él por muchas razones. Hay que tener en cuenta que a los motores de búsqueda no les gusta enviar tráfico a sitios que pueden generar problemas a los usuarios, por lo tanto, sitios inseguros o lentos no son de su prioridad. Es por esto que, si utilizas algún sistema tipo CMS, has de mantenerlo al día y actualizarlo. Esto es válido para cualquier tipo de software (WordPress, Magento, Prestashop, etcétera). Pero lo mismo ocurre con el sistema, no sólo con el software. Es muy recomendable mantener al día la parte de sistemas como el Sistema Operativo, el servidor web, el procesador, la base de datos, las caché. La mejor forma de estar seguro es mantener al día todas las capas de tu proyecto. Esto, además de incluir mejoras de producto, también incluyen mejoras de seguridad y velocidad. « El servidor Web Protección y Alta Disponibilidad » --- Cuando hablamos de SEO y de WPO hemos de tener presente otro elemento importante y es el tiempo de disponibilidad del sitio. Que un sitio no tenga códigos de error HTTP de tipo 5xx es muy importante, ya que este tipo de error indican que hay un problema en el lado del servidor y se consideran los errores más graves. Es por esto que es importante tener presente dos elementos. El primero de ellos es el de poner capas de seguridad por encima de tu sitio (cortafuegos) ya sea a nivel de software o de hardware. Es muy recomendable usar siempre sistemas de tipo WAF (Web-Application Firewall) para proteger ante ataques y que el sitio no se sature. Como segundo elemento hemos de hablar de la Alta Disponibilidad. Esto significa que un sitio debería estar el mayor tiempo disponible sin caídas (lo más cercano al 100%). Para esto hay que preparar el sitio para que tenga soporte para ello y esté gestionado de forma distribuida, como veremos más adelante. « El software y versiones Qué significa que un sitio web sea rápido » --- Cuando hablamos de la velocidad de carga de un sitio hay que medir muy correctamente en qué palabras y concetos trabajamos todos. El tiempo de carga de un sitio no se puede medir en un momento en concreto, sino en varios. Cada uno de estos momentos tiene unas implicaciones distintas y requiere de optimizaciones muy distintas en cada paso, 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? ¿La navegación del sitio inicia correctamente? ¿Responde el servidor? ¿Es útil? ¿Se ha iniciado la carga del sitio lo suficiente como para comenzar a interactuar? ¿Es usable? ¿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? Una forma de resumir esto se podría plantear en 4 momentos en lo que se refiere a la carga de la página: Primera impresiónCarga de primeros contenidosCarga de contenidos útilesTiempo para ser interactiva 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 quizá la conversión es el tiempo que pasa un usuario y la cantidad de entradas que se leen, o la de un comercio electrónico donde el tiempo implicará más ventas. Algunas métricas que se pueden tener en cuenta (entre muchas) pueden ser las siguientes: Aumento de la tasa de reboteDisminución de las conversiones relativasDejando de lado el compromisoUsando promedios o medianasContenido de terceros « Protección y Alta Disponibilidad Cómo medir » --- A la hora de medir y obtener datos hay que tener presentes que hay dos grandes grupos de datos. Los primeros son los que se podrían considerar “datos de laboratorio”, los segundos son los “datos sobre el terreno”. Los primeros datos son los que nos dan las herramientas. Estos datos son primordiales para poder solventar datos de base de los proyectos y que tienen más que ver con la parte de infraestructura y del software. Los segundos son datos recogidos por sistemas, normalmente, externos tipo Google Analytics en los que se recuperan puntos de medida de los usuarios que navegan por el sitio y que, dependiendo de muchos factores, hay que analizar caso a caso. Aquí pueden influir cosas tan distintas como el dispositivo, el navegador, el tamaño de pantalla, algo tan variable como usuarios distintos existentes. Cuando se desarrolla y lanza un sitio, hay que tener los distintos puntos de medición y, sobre todo, establecer los tiempos que se quieren conseguir y llegar a ellos, de forma que, posteriormente cuando se hagan revisiones, se mantengan esas cifras de forma correcta. Por ejemplo, se pueden establecer 4 puntos como inicio: Time to First Byte (TTFB): El tiempo que se tarda desde que se envía la solicitud hasta que se reciben los primeros datos desde el servidor. DOMContentLoaded: Como momento en el que se carga el HTML y permite trabajar con ello, sin necesidad de esperar a los CSS o scripts. First Contentful Paint (FCP): Momento en el que se cargan os primeros elementos del DOM (texto, imágenes o cualquier contenido). Time to Interactive (TTI): Momento en el que el sitio es completamente interactivo y usable por el usuario. Como cifras iniciales que se podrían tener en cuenta tenemos que el TTI debería estar por debajo de los 5 segundos y que los recursos críticos deberían estar por debajo de los 200 KB (comprimido y minimizado). « Qué significa que un sitio web sea rápido 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 sólo 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, la pantalla de pago o el carrito, y una página estática (términos y condiciones, contacto... ). Los primeros análisis se podrían hacer en 3 lugares distintos. El primero es un análisis rápido en las herramientas para desarrolladores que incorporan todos los navegadores (Chrome, Edge, Firefox... ). Aquí veremos el tiempo de carga en un entorno controlado y lo más parecido a un usuario. Es muy recomendable tomar muestras en distintos navegadores, ya que cada uno puede trabajar de una forma distinta a la hora de cargar y procesar un sitio. La segunda herramienta para probar, similar a la que podemos tener en nuestro navegador, es la de WebPageTest. Este sistema emula un navegador web (Firefox, Chrome... ) pero en distintas localizaciones del mundo y con distintas conexiones. Para acabar, podemos usar la herramienta PageSpeed Insights que nos dará otra serie de datos mucho más calculados y con menos datos en crudo. En cualquier cosa, en estas herramientas siempre se han de interpretar los datos, ya que cada uno de ellos puede significar una cosa distinta y hay que contextualizarlos. Sobre todo, hay que poner siempre en contexto las peticiones más lentas que, habitualmente, son elementos externos sobre los que no se pueden tener control ya que suelen ser scripts third-party. « Cómo medir Usar HTTP/2. 0 o HTTP/3. 0 » --- Uno de los primeros elementos a tener en cuenta cuando hay algún problema es asegurarse de que estamos trabajando con las últimas versiones activas de HTTP como son HTTP/2. 0 o HTTP/3. 0. No todos los servidores web les dan soporte o viene activados por defecto, por lo que hay que estudiar bien el cambio. Es importante esto como primer elemento ya que puede desatascar algunos problemas de bloqueos por paralelización de peticiones que suelen ser uno de los factores principales en cuanto a la optimización del sitio. Actualmente (enero de 2020): 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. Hay que recordar que 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. « Haciendo un primer análisis 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. Esto implica 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. Teniendo en cuenta que las DNS no es algo que se actualice con frecuencia, hay que pensar en poner unos valores medianamente razonables y altos. Como mínimo hay que poner 60 minutos y no está de más plantearse incluso indicar 1 día. 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 USA y 1 en Holanda, 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. DNS Públicas y Privadas: En las entradas DNS se pueden incluir IPs internas y externas. Esto puede hacer que haya muchas resoluciones incorrectas. Lo mejor es separar las IPs 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. « Usar HTTP/2. 0 o HTTP/3. 0 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 HTTP/2. 0 en adelante. Aunque esto pueda parecer una contradicción, ya que supone cierto tiempo el comprimir y descomprimir los elementos, si le sumamos los sistemas de caché el tiempo de realizar esta acción es menor que el tiempo que tarda en enviarse la información sin comprimir. Además, hay que tener en cuenta que la compresión principalmente se ha de aplicar a los contenidos textuales (que son los que tienen más posibilidades de comprimirse) por lo que la carga de las páginas es mucho más rápida. Entre estos ficheros podemos encontrar TXT, JS, CSS, HTML o PHP. « Optimización de las DNS Prefetch, preload y preconnect » --- En muchos casos cuando cargamos nuestro sitio web sabemos que vamos a hacer llamadas a elementos externos, a otros hostname, tanto nuestros como de terceros. Estas llamadas a otros hostname requerirán que se hagan peticiones a las DNS en el momento en el que se encuentre el elemento. Para esto usaremos el sistema de preconnect que básicamente lo que harán es hacer una llamada para precalcular las DNS antes de que se haga la petición real. Esta llamada, al hacerse previamente y en paralelo a otros elementos permitirá que se reduzca el tiempo a la hora de cargar el otro elemento. Cualquier hostname que no sea el propio de dominio debería encontrarse en este sistema de preconnect. Un ejemplo de llamada podría ser similar a esta: Por otro lado, podemos presuponer que cuando un usuario entra en una página que no s la principal del sitio pueda llegar a entrar en ella. O por ejemplo que un artículo que tenemos paginado, tras la página 1 va a cargar la página 2, o que un usuario que está en una tienda acabará llegando al carrito. Para estos casos podemos plantear cargar en la caché del navegador otra página o contenido para que, en caso de que ello ocurra, lo haga mucho más rápido. Un ejemplo podría ser similar a este: Para acabar, también podemos precargar elementos que se van a usar posteriormente en la página. En este caso se puede aplicar con cierta frecuencia a elementos que sabemos que pueden bloquear la carga de la página, como ciertos scripts. Los valores validos del parámetro “as” son: audio: document: y embed: font: CSS @font-faceimage: y object: script: style: y CSS @importtrack: video: worker: Workers « Sistemas de compresión Código CSS » --- Los CSS son los elementos que dan estilo a nuestros sitios web. Aunque históricamente siempre se había comentado 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 cargase, 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. 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). E 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. « Prefetch, preload y preconnect 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 forma 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 forma 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. « Código CSS 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; } else { direccion = -1; } Podría llegar a reducirse a un código tal que: var direccion = (x > 100) ? 1 : -1; Otra acción sencilla que permite mejorar el rendimiento es el de optimizar los bucles. Un bucle habitual podría ser este: var beatles = ; for(var i=0; i --- jQuery es una biblioteca de funciones preestablecidas de JavaScript que permite interactuar de forma más sencilla con los elementos DOM de una página, además de conseguir trabajar de una forma más sencilla gracias a las ampliaciones de código que existen. Existen algunas reglas que permiten trabajar de forma más rápida y mejorada con jQuery: La forma más rápida de acceder a un elemento del DOM es hacerlo mediante un selector ID en vez de hacerlo con un descendiente suyo. Esto es debido a la existencia y uso de la función getElementById. Esto significa que es óptimo hacer uso de algo así: var boton1 = $('#boton1'); que no hacer uso de algo así: var boton1 = $('#botones . boton1'); La siguiente forma de acceder rápidamente a un elemento es hacerlo a través de un “tag” ya que se aprovecha el uso de la función getElementsByTagName. Otro detalle a tener en cuenta es el uso de variables para almacenar información de un elemento y no aplicar cambios directamente sobre él. De esta forma tendríamos una función optimizada tal que así: var $activar = $('#light input. on'); $activar. css('border', '3px dashed yellow'); $activar. css('background-color', 'orange'); $activar. fadeIn('slow'); Sobre unas no optimizadas que podrían ser así: $('#light input. on). css('border', '3px dashed yellow'); $('#light input. on). css('background-color', 'orange'); $('#light input. on). fadeIn('slow'); Este sistema podría mejorar incluso un poco más haciendo uso de encadenamiento: var $activar = $('#light input. on'); $activar. css('border', '3px dashed yellow'). css('background-color', 'orange'). fadeIn('slow'); Otra forma de acceder rápidamente a subelementos es utilizar la función find. var $activar = $('#light'), $activo = $activar. find('input. on'), $inactivo = $activar. find('input. off'); Los eventos son uno de los elementos que más se utilizan en jQuery y debemos aprovechar la delegación de estos para generar el llamado Bubbling. Por ejemplo, podemos tener una función sencilla como: $('#lista li). bind('click', function { $(this). addClass('clicked'); }); Esto implica tener que trabajar enormemente con el DOM, algo que podríamos reducir utilizando una función algo más compleja aparentemente, pero más efectiva: $('#lista). bind('click', function(e) { var pulsa = e. pulsa, $ pulsa = $( pulsa); if (pulsa. nodeName === 'LI') { $pulsa. addClass('clicked'); } }); Cargar las funciones tras la carga de la ventana y no del estado del documento. Por norma general las funciones se cargan tras el $(document). ready pero se pueden cargar de una forma más eficiente con $(window). load. « Optimización general de JavaScript Limpiar el código » --- Puede parecer algo básico y de sentido común, pero hay que intentar eliminar todo el código innecesario. En este caso hablamos del que tenemos en HTML (que también se puede minimizar) además del CSS o el JavaScript. Con la limpieza d código también hay que revisar bibliotecas JavaScript u otros elementos que no se usan siempre. Un ejemplo sencillo podría ser el del sistema recaptcha de Google. En su documentación original te indican que cargues el script para que funcione, y en muchas ocasiones se coloca en todas las páginas, aunque sólo se utiliza realmente en las que hay formularios. En estos casos deberíamos sólo cargar el script en los lugares en los que sean necesite. « Optimización para jQuery 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 punto. El primer paso para 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. Últimamente 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 precarga de las distintas imágenes. De esta forma 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 precarga, podríamos añadir a la cabecera del sitio un código tal que este: 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 (puedes comprobar si el formato WebP es compatible con el navegador). 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. 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 MB. 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. « Limpiar el código 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: « Optimización de imágenes 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 8x8 de forma que se puede comprimir en base a esta regla. En la imagen, el primer recuadro está alineado en el bloque de 8x8 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 51% puede llegar a ocupar menos tamaño el fichero y una menor pérdida. « Optimización dinámica de imágenes Codificación de los PNG » --- El formato de imágenes PNG (Portable Network Graphics) se creó como sustitución del sistema GIF que tiene licencia propietaria y, además, se mejoró ya que se conocían muchos problemas de los GIF y JPEG. Este tipo de imágenes tiene 5 posibilidades de almacenamiento: Grayscale (escala de grises), Truecolor (color verdadero), Indexed-color (color indexado), Grayscale with alpha (escala de grises con canal alfa) y Truecolor with alpha (color verdadero con canal alfa). Además, el Indexed-color permite almacenar información como bit transparency (cada píxel puede ser totalmente transparente o totalmente opaco) o palette transparency (cada píxel puede ser semitransparente). Uno de los mayores problemas es que la mayoría de los programas no acaba de permitir elegir entre todos estos formatos y opciones, por lo que siempre será recomendable el uso de herramientas como OptiPNG o pngcrush que convertirán la imagen a la mejor opción posible. En este caso, lo mejor será guardar la imagen en escala de grises si es el caso, o en color verdadero si es en color, ya que estas herramientas automáticamente comprueban si se puede reducir a color indexado. Otra de las formas de reducir el tamaño de los ficheros en PNG sin perder una cantidad excesiva de calidad es utilizando la posterización (por ejemplo, a un 40%). Aunque este sistema implique una pérdida de calidad, puede reducir sobre un 25% el tamaño final del fichero. « Codificación de los JPEG CSS Sprites » --- En muchas ocasiones los sitios web tienen pequeños iconos que se van repitiendo a lo largo de las distintas páginas. Esta cantidad de iconos puede producir el efecto de un exceso de peticiones y, por ello, un número elevado de conexiones inútiles. Como la tecnología lo permite, una buena solución es la de integrar varias imágenes en una imagen única. Esta imagen, que suele ser un PNG8, contiene una cantidad de imágenes pequeñas suficiente para no tener un tamaño excesivo y con una única imagen poder gestionar todos los elementos desde el CSS. Este sistema, conocido como CSS Sprites permite que carguemos una única URL (que se usará en distintas zonas de la página) de forma rápida y con una única petición HTTP. Para gestionar las imágenes, podemos hacer uso de códigos similares a los siguientes: #nav li a {background-image:url('imagen. png')} #nav li a. item1 {background-position:0px 0px;} #nav li a:hover. item1 {background-position:0px -72px;} #nav li a. item2 {background-position:0px -143px;} #nav li a:hover. item2 {background-position:0px -215px;} « Codificación de los PNG El data URL scheme » --- Siguiendo el mismo sistema que los CSS Sprites, podemos plantearnos que también son algo inefectivos en aquellos casos en los que estos pequeños iconos se utilicen de forma muy concreta. En esos momentos casi se puede considerar que incluir la imagen directamente en el código fuente del HTML sería más rápido. El caso del data: URL scheme (RFC 2397) viene a resolver esta situación, y es que en 1998 ya se planteó este estándar que no cumplen todos los navegadores, por lo que deberemos probar en cada caso. La idea es incluir en el propio código el elemento en sí, codificado en Base64 que hará que no tengamos que realizar peticiones externas, sino que va incorporado en el propio código fuente, ya sea del HTML como del CSS. El funcionamiento de este elemento sería algo tal que así: data:, El primero de los elementos corresponde con el MIME Type del contenido a mostrar (por ejemplo, un image/png). Al final, en codificación Base64 irá el contenido. Quedaría algo parecido a esto: Lo interesante es que se puede utilizar dentro de los CSS, por lo que las imágenes pasarían a formar parte de un CSS de un tamaño mayor y reduciendo la cantidad de peticiones. « CSS Sprites Lazy load » --- Una de las formas que se suele aplicar a las imágenes para no sobrecargar el sistema es el llamado lazy-load. La idea de esto es que se vayan cargando los distintos elementos según se vayan necesitando. De esta forma al entrar en una página veríamos todas las imágenes de la primera pantalla, pero el resto de las imágenes (las que están más abajo) no se cargan. Según vamos bajando, se van cargando los elementos. Este sistema se ve también en algunos sitios que van cargando los contenidos inferiores según se va bajando por la pantalla, de forma que se hace una carga rápida de elementos, y sólo se van haciendo llamadas según se van necesitando. Desde abril de 2019 existe una forma nativa de carga en algunos navegadores de Internet que permiten el sistema de loading de forma nativa. Este parámetro permite varias opciones: auto: Es el comportamiento por defecto y dependerá de la configuración del navegador. lazy: El contenido se retrasa hasta que el sistema acerca el viewport (indicador de cercanía de elementos a la visualización del usuario). eager: Carga los elementos de forma forzada e inmediata. Un ejemplo de cómo se podría ejecutar es la siguiente: « El data URL scheme Carga de Fuentes (tipografía) » --- 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. « Lazy load Optimización de vídeos » --- Vídeos hay de muchos tipos, aunque pueda parecer lo contrario, aunque por norma general en Internet se suelen usar dos tipos: los MPEG (habitualmente en MP4) y los WebM. Cada uno tiene sus ventajas e inconvenientes. Por otro lado, otro elemento a tener en cuenta, al igual que las imágenes, es la resolución del vídeo. No tiene ningún sentido emitir un vídeo en 4K en una pantalla de resolución HD. Y por supuesto, cuando hablamos de vídeos, hemos de tener en cuenta la velocidad de la conexión a Internet del usuario. Al igual que en el caso de las imágenes, podemos cargar distintos formatos según sea necesario. Hay que tener también presente que podemos pedirle al sistema que vaya cargando o no el vídeo. Para esto la etiqueta permite el parámetro de preload con los siguientes valores: none: Sin precarga. auto: Con precarga. metadata: Carga solo metadatos (como la duración). « Carga de Fuentes (tipografía) 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. « Optimización de vídeos 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. « Eliminar cookies innecesarias 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. « Reducir el tamaño de las cookies Automatizar la barra “/” al final de la URL » --- Gracias a sistemas como el Apache Mod_rewrite tenemos la posibilidad de crear URLs amigables para usuarios y máquinas, pero en muchas ocasiones no se controla correctamente si las URL finalizan con una “/” barra final o no. Hay que tener en cuenta que llevarla o no es totalmente distinta, ya que la URI deja de ser única y genera contenidos duplicados. Es por esto que existen distintos métodos para que, en muchos casos, se añada o elimine de forma automática dejando al sistema solucionar esta situación. La principal es el uso del Apache Mod_dir con su directiva DirectorySlash, gracias a la cual podremos configurar si queremos la corrección automática o no. « Aplicar las cookies al nivel necesario Uso del Meta-Refresh » --- De forma histórica los navegadores son capaces de gestionar una meta-etiqueta que permite redirigir la carga de la página a otro. Para ello se utiliza un código similar al siguiente: El uso de este sistema, dependiendo del navegador que se utilice, necesita validar de forma condicional e incondicional algunos elementos, por lo que el tiempo de la redirección aumenta. Además, en el caso de usar proxy, se pueden incluir entradas Pragma: no-cache a los encabezados. Aun así, encabezados como el If-Modifies-Since pueden mantenerse y seguir devolviendo códigos 304. « Automatizar la barra “/” al final de la URL 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. La primera caché que podemos aplicar y que debería estar activa en cualquier proyecto es la caché del navegador. Esta caché está pensada para que una vez un usuario haya descargado un contenido no se tenga que volver a descargar, sino que se utilice la versión descargada previamente. Por norma general cuando subimos una imagen o un vídeo a un servidor no suele modificarse, ese fichero es siempre el mismo. Por lo tanto, si un usuario lo descarga una vez no debería necesitar descárgalo más, aunque se vuelva a solicitar más veces. Por eso le indicaremos que lo almacene un tiempo prudencial (1 día, 1 semana, 1 mes, 1 año... ). Tenemos cabeceras generales que se pueden usar, como el Cache-Control en el que podemos informar cómo queremos que se gestione, o no, la caché. Existen parámetros de request y de response, según queramos que afecte a los elementos. Por otro lado, para los distintos elementos podemos enviar la cabecera Last-Modified y trabajar con ella con If-Modified-Since. Con esto le diremos al sistema cuál es la fecha del último cambio del contenido, y cuándo queremos que deje de estar en caché. Otra opción puede ser la del uso de ETag y su correspondiente If-None-Match para la validación de cambios. Con este sistema le damos un identificador único al contenido, de forma que, si por alguna razón cambia, automáticamente el identificador es distinto. Otro nivel de caché es la de generar de forma física los contenidos dinámicos y almacenarlos durante un tiempo concreto. De esta forma alguien genera la página, esta se almacena físicamente en el servidor. Mientras los tiempos correspondan, se sirve la versión generada hasta que toque regenerarse. En estos sistemas también se suelen usar sistemas de invalidación, de forma que por alguna acción concreta se puede regenerar la página. Por ejemplo, en un diario digital, si se actualiza la noticia, se podría eliminar y regenerar ese fichero en ese momento. Existen capas de caché a otros niveles y para otros elementos que afectan a un sitio web, como por ejemplo las capas de caché en PHP (usando Opcode caché) o caché de base de objetos, del tipo Redis o Memcached. Aunque si hablamos de caché lo más probable es que se optimice todo gracias a un sistema de web-proxy. Estos sistemas son una capa intermedia entre el usuario y tu servidor, lugar donde se almacena una copia de todos los contenidos de tu sitio. Mediante una serie de reglas el sistema guardará copias generadas que se podrán invalidar o que se podrán utilizar, aunque tu servidor esté saturado, quitando una gran carga de trabajo. Este sistema es muy útil sobre todo en aquellos proyectos en los que los usuarios no han de interactuar con extrema frecuencia. Como todo el sistema está pre calculado, el foco principal de este servicio es servir los contenidos lo más rápido posible. Algunos de los más conocidos son nginx, squid, Traffic Server o Varnish. « Uso del Meta-Refresh Redirecciones acompañadas de tiempo de caché » --- Por norma general cuando se hace una redirección no se le indica la duración de esta. Esto significa que tanto los robots como los usuarios, cada vez que visiten la página “antigua” han de hacer la petición porque no se le ha indicado el fin de esta. En principio el código 301 no debería necesitar de este sistema de indicación de caducidad o caché, pero es recomendable indicarlo ya que no deben ser indefinidas, sino que los 301 hay que eliminarlos pasado un tiempo prudencial (entre 6 meses y un año). Una vez pasado este tiempo esa redirección se debería convertir en un código 404 Not Found. Un ejemplo en PHP de una redirección correcta podría ser esta: --- Una Content Delivery Network (CDN) es una red de servidores (en general que usan sistemas de proxy-caché, como se comentaba anteriormente) en la que se sirven los contenidos de forma optimizada. 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. « Redirecciones acompañadas de tiempo de caché 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. « CDN – Content Delivery Network Velocidad de la conexión » --- Aunque en estos momentos es una tecnología todavía en desarrollo, la Network Information API, permitiría al navegador saber qué tipo de conexión tiene el usuario en todo momento, y, además saber si esta cambia. A nivel general el sistema nos devuelve varios datos, el principal de ellos sería el tipo de conexión de forma básica con ConnectionType: bluetoothcellularethernetmixednoneotherunknownwifiwimax Aunque podríamos obtener los datos de la conexión efectiva con EffectiveConnectionType: 2g3g4gslow-2g Con este sistema, y gracias a JavaScript, podríamos tomar decisiones a la hora de mostrar o no determinados elementos, como por ejemplo un vídeo. let preloadVideo = true; var connection = navigator. connection || navigator. mozConnection || navigator. webkitConnection; if (connection) { if (connection. effectiveType === 'cellular') { preloadVideo = false; } } « Dominios sin cookies para estáticos Tiempo de Indisponibilidad del sitio » --- Uno de los problemas más habituales que nos podemos encontrar a la hora de actualizar un sitio es qué hacer en el tiempo en el que la web está caída debido a la actualización. En muchos casos podemos hacer una actualización transparente, pero en otros casos no. En estos casos deberíamos aplicar el código HTTP 503 Service Unavailable que evitará que los usuarios puedan acceder a contenidos indebidos, o que los motores de búsqueda comiencen a indexar el mensaje de error como páginas correctas. Este código deberá ir acompañado siempre de la fecha siguiente en la que el sitio debería comenzar a ser rastreado de nuevo. Por ejemplo, tendríamos un código en PHP tal que así: --- 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. « Tiempo de Indisponibilidad del sitio 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. « Estándar --- --- ## Entradas Bienvenido a WordPress. Esta es tu primera entrada. Edítala o bórrala, ¡luego empieza a escribir! --- ---