El rendimiento es importante

Hola, ¿qué tal? ¿Cómo estás? Espero que todo vaya muy bien.

Te saluda Alex Ávalos y te doy la bienvenida a Web en Línea,

el podcast que te enseña a elegir con criterio,

desarrollar una web potente y lanzarla siguiendo las buenas prácticas

que garantizan el éxito.

Dos segundos.

Dos segundos.

Es lo que tarda la mayoría de la gente en decidir si se queda en tu sitio web o se va.

Dos segundos.

Si tu web tarda más de dos segundos en cargar, el 53% de los usuarios, bye bye, ya se fueron.

No esperaron. No les importó qué tan bonito o qué tan bueno es tu contenido. Ya se fueron. Y en el peor de los casos, se fueron al sitio web de la competencia, que ese sitio sí cargó en un segundo.

La mayoría de los dueños de sitios web no tienen ni la más remota idea de qué tan lenta es su web, de qué tan lento es su sitio web.

Porque ellos lo prueban desde su computadora del escritorio de su oficina, con ese internet mega premium y por supuesto, como ya han entrado antes, con la web en caché.

Y para ellos, en su computadora, en sus condiciones particulares, carga en un segundo.

Y se piensan que todo va perfecto.

Pero los usuarios que están desde su teléfono, un teléfono antiguo, un teléfono mínimo de hace unos cuatro años, con conexiones 4G, lentas, 3G, que posiblemente van en el transporte público en un país donde toda la infraestructura de internet es lenta, como El Salvador.

Y la web tarda 8 segundos en cargar completamente. Por supuesto, estos usuarios no van a esperar y sí, se van.

El rendimiento no es un accesorio. No es algo que... vamos a ver si lo ponemos si nos queda tiempo.

No. El rendimiento es un requisito porque una web lenta pierde visitas, pierde conversiones, pierde posiciones en Google, pierde dinero, lo pierde todo.

Y por eso vamos a hablar en este episodio de por qué tu web es lenta y principalmente también vamos a dar los esbozos para que puedas solucionarlo.

El rendimiento importa, importa muchísimo.

Y no solo porque la gente sea impaciente, hombre que también.

Hay razones concretas, medibles y de peso.

Vamos a verlas.

Razón número uno, por supuesto, las conversiones.

Amazon descubrió que por cada 100 milisegundos de demora pierden 1% en sus ventas.

100 milisegundos, eso es un décimo de segundo.

Walmart encontró que por cada segundo de mejora en el tiempo de carga, las conversiones aumentan un 2%.

Google descubrió que si la búsqueda tarda medio segundo más, las búsquedas caen un 20%.

Estos son datos reales de empresas que mueven millones y si les afecta a ellos, te afecta a vos y por supuesto me afecta a mí.

Razón número 2. El SEO. Desde el 2010, Google usa la velocidad de carga como factor de ranking. Desde el 2018, la velocidad en celulares es muy, muy, bueno, mucho más importante. Y desde el 2021, las Core Web Vitals son parte oficial ya del algoritmo.

Una web lenta no rankea. Por supuesto, una web lenta no va a rankear nunca en Google. Y punto. Puedes tener el mejor contenido, puedes tener el diseño más wow, pero si tu web es lenta, Google no te va a mostrar en los primeros resultados porque Google quiere dar la mejor experiencia a sus usuarios.

Y una web lenta, no es una buena experiencia.

Razón número 3.

Experiencia del usuario.

Ya que estamos hablando, mira cómo te lo oí.

La gente, ya dijimos, no tiene paciencia.

Estamos en el 2025 y estamos acostumbrados a que todo sea instantáneo.

Netflix, cargue un segundo.

Instagram, cargue un segundo.

Twitter, bueno, X, carga en un segundo. Y si tu web tarda en cargar cinco segundos, lo siento, my friend, la percepción, el sentir... es que algo no va bien, que algo probablemente esté roto o no está funcionando.

Y eso causa frustración y nadie se quiere frustrar y prefieren irse.

Y si el usuario se va, no va a volver.

¿Por qué? Porque hay miles de opciones más que cargan en menos de dos segundos.

Razón número cuatro.

Cost de hosting.

Una web mal optimizada consume más recursos, consume más CPU, consume más memoria y por supuesto mucho más ancho de banda. Esto significa altos costos de hosting o llegar al límite de tu plan y tener que pagar más porque vas a subir al siguiente nivel.

En cambio, una web optimizada hace más con menos. Y eso está muy bien.

Razón número cinco, accesibilidad.

Mira, te lo cuento en mis propias carnes.

No todo el mundo tiene un internet rápido.

No todo el mundo tiene un teléfono de alta gama y última generación.

En muchos países, la mayoría de gente, me incluyo, navega con conexiones lentas y paupérrimas en dispositivos muy viejos.

Si tu web solo funciona bien con internet rápido, estás excluyendo a un porcentaje enorme de potenciales clientes y usuarios.

Y me estás excluyendo a mí también.

El rendimiento es accesibilidad. Y ojo, el rendimiento no es solo qué tan rápido carga tu web, es qué tan rápido se vuelve usable, qué tan rápido puedo comenzar a trabajar en ella.

Porque puedes mostrar contenido rápido, pero si el usuario no puede hacer clic en nada, porque el JavaScript todavía está cargándose, la web simplemente no es usable.

Puedes cargar texto rápido, pero por ejemplo, si las imágenes tardan 10 segundos más, la experiencia es mala.

Y por eso el rendimiento es la experiencia que buscamos, es la experiencia correcta, es la experiencia completa.

Son las cinco estrellitas totalmente recomendado, ¿no?

Y desde que el usuario escribe tu URL hasta que puede hacer algo o hasta que puede hacer lo que vino a hacer, cada milisegundo cuenta.

Bueno, entonces ya estamos en este punto que entendemos que el rendimiento es importante.

¿Ok? Muy bien.

Ahora hagámonos la pregunta.

¿Qué hace lenta a una web?

¿Qué hace lenta a tu web?

Bueno, la mayoría de veces no es solo un solo problema.

Son múltiples problemas que se van ahí acumulando.

Ay, se me lengua la clava.

Te lo vuelvo a decir, no es un solo problema, son múltiples problemas ahí acumulados.

Vamos a ver algunos.

Problema número uno.

Imágenes sin optimizar.

Este es el problema, creo yo que es el más común de todos,

Porque parece obvio, pero al final del día no lo es tanto.

Porque tal vez vos no, ni yo, pero posiblemente tu usuario o tus usuarios, o el de marketing, o el que crea el contenido, o incluso hasta el propio dueño del sitio web, sube fotos directamente desde la galería de su celular a la web.

10, 20, 30 megas por cada una.

Bueno, quedémonos con 10 para que se nos haga más fácil la matemática.

Digamos que son 10 megas cada uno.

De 4,000 por 3,000 píxeles, algo así, ¿no?

Y lo más triste es que se muestra en el sitio web a 400 píxeles de ancho.

Estás obligando al navegador a descargarse 10 megas para mostrar una imagen que debería de pesar máximo 100 kilobytes.

Ahora, multiplica eso.

Multiplica los 10 megas por 10 imágenes.

Hombre, ya son 100 megas.

Solo en imágenes.

Con una conexión de 10 MB por segundo, eso es más de un minuto de descarga.

Bueno, solución, optimizar las imágenes, obviamente optimizar las imágenes antes de subirlas.

Pero además usar el tamaño correcto.

Si las vas a mostrar en 400 píxeles, subí como máximo en 800 píxeles.

si tus usuarios usan pantalla retina o si te interesa que la imagen se vea lo mejor posible.

También puedes comprimirlas con herramientas como TinyPNG.

Y te recomiendo sí o sí usar formatos modernos como WebP o AVIF.

Esto también, por supuesto, cuando sea posible, porque en algunos proyectos es mejor, bueno, el WebP.

También puedes implementar el lazy loading para cargar imágenes solo cuando ya son visibles.

Y esto es solo el inicio.

Vamos con el problema número 2.

Demasiadas peticiones HTTP.

Cada archivo que tu web necesita es una petición HTTP.

HTML, CSS, JavaScript, imágenes, fuentes, íconos.

Si tenés, digamos, para que se nos haga sencilla la matemática, si tenés 100 archivos, son 100 peticiones.

Cada petición con su overhead.

Tarda tiempo.

Y si tu servidor solo puede procesar 6 peticiones simultáneamente, las otras 94 van a estar ahí en cola, en espera.

Solución.

Minimizar archivos CSS y JavaScript.

combinar archivos cuando sea posible y para los íconos usar SVG inline o bibliotecas de íconos.

Son más livianas y además son más escalables que los PNGs individuales.

Además, por supuesto, muy recomendable eliminar recursos innecesarios.

Problema número 3. Bloqueo de JavaScript.

Los scripts y los atributos correctos van a bloquear la carga de tu web.

El navegador se detiene, descarga el script, lo ejecuta y después de eso continúa y sigue mostrando tu contenido.

La solución, utilizar los atributos correctos. Por ejemplo, defer en tus scripts.

Se descargan en paralelo mientras el HTML se procesa y se ejecutan al final sin bloquear nada.

Para script independientes como Analytics, usar Async. Y en proyectos modernos, Code Splitting carga solo el JavaScript que realmente necesita en cada página.

Problema número 4. CSS no optimizado.

No sé si ya te ha tocado, pero a mí me ha tocado encontrarme con CSS gigantes con miles y miles y miles de líneas de códigos que al final ni usan.

Frameworks como Bootstrap completos cuando solo vas a usar el 5% de las clases.

La solución, usar solo el CSS que realmente se necesita.

El Purge CSS para eliminar el CSS no usado y la carga de CSS crítico inline y el resto puede ser async.

Problema número 5. Tipografías o fuentes webs pesadas.

Google Font, Custom Font y iconfont.

Cada fuente son cientos de kilobytes.

Y si cargas 3, 4, 5 pesos de la misma fuente, ya estos son megas.

¿Cuál es la solución?

Usar solo los pesos de la fuente de la tipografía que realmente vas a utilizar.

Y cargar fuentes con el font-display: swap para mostrar texto inmediatamente.

Podría ser muy buena idea considerar las System Fonts que no requieren descarga o alojar las fuentes o tipografías en tu propio servidor.

En vez de estar usando Google Fonts por cada una de las webs y cada una de las peticiones.

Problema número 6. Servidor lento.

Bueno, hosting barato.

Ves y vas a comenzar y lanzar el proyecto y en el Google pone cuál es el hosting más barato del mercado.

O le preguntas al GPT, cuál es el hosting más económico.

Claro, no sabes que estás compartiendo recursos con 5,000 webs y con 500,000 clases.

No, no lo sabes, ¿verdad? Pero bueno, además de esto, además de que es barato, es compartido y es malo,

Los recursos son muy, muy limitados.

Y ahí está tu pobre web, perfectamente optimizada en el frontend.

Pero si el servidor tarda tres segundos en responder, no importa y no sirve de nada todo tu trabajo y toda la optimización que has hecho.

¿Cuál es la solución?

Por supuesto, un hosting decente.

No el más barato, ni tampoco te vas a hipotecar para lanzar tu proyecto, pero hombre, un hosting decente.

Y ha de ser posible un hosting VPS.

Y también, también muy importante, utilizar CDN para servir contenido estático.

Así además no cargas innecesariamente tu hosting y tenés servidores, puntos de presencia más cerca de tus usuarios,

lo que hace que cargue mucho más rápido.

Problema número 7.

No usar caché.

Cada visita genera las páginas desde cero.

Consulta a la base de datos.

Procesamiento PHP.

Todo, todo, todo desde cero.

¿Cuál es la solución?

Caché en diferentes niveles.

Caché de página para servir HTML estático.

Caché de objetos para la base de datos.

Caché de navegador para archivos estáticos.

Y así. Y por último, porque si no, nos vamos a llevar horas aquí. Problema número 8. Plugins o dependencias innecesarias o excesivas. En WordPress tenés 30 plugins activos. Bueno. En JavaScript tenés 50 dependencias en NPM. Bueno. El caso cuál es? Que cada uno suma peso, suma código y suma tiempo de carga.

Solución, usa lo esencial. Evalúa si realmente necesitas cada plugin o cada dependencia. ¿Realmente lo necesitas? ¿Sí o no? ¿Hay alguna alternativa más ligera? ¿Sí o no? ¿Podés hacer esa funcionalidad tal vez con código personalizado o con menos código?

Bueno, no se te olvide que lo menos es más, incluso en el rendimiento web.

Bueno, ya hice mis tareas, ya me di cuenta de mis errores, pero y ahora, ¿cómo podemos medir y optimizar?

Porque bien sabes que no se puede mejorar aquello que no se ha medido.

Vamos a ver, herramientas para medir el rendimiento. Hay varias. Podemos mencionar la todapoderosa Google PageSpeed Insight, que es la más conocida. Te da una puntuación y recomendaciones específicas. Con esta, lo importante es mirar las Core Web By Tiles, que no solo son la puntuación. No solo es ver la puntuación, sino que también ver estas recomendaciones.

Por supuesto, tenemos a GTmetrix, que te da un análisis detallado con el Waterfall de carga, que puede ver exactamente qué archivos tardan más y solucionar lo que haga falta.

También está WebPageTest, que es mucho más completa.

Puedes testear desde diferentes ubicaciones, diferentes dispositivos,

diferentes velocidades de conexión y te va a dar un resultado, pues ya ves, más amplio.

Y por supuesto, el Lighthouse integrado en Chrome DevTools,

para testear localmente mientras lo desarrollas sin depender de servicios externos.

A todo esto, no te obsesiones con la puntuación perfecta.

Una web con 100 de sobre 100 en PageSpeed no necesariamente va a convertir más.

Porque si tienes 100 de 100, pero nadie compra, no sirve de nada.

Y puede ser que una web 70 de 100 carga rápido en el mundo real y cumple con su objetivo, pues entonces esa sí es una web exitosa.

Las métricas que importan de verdad son solo un punto de partida, pero no te tienes que obsesionar con esto.

Por ejemplo, LCP - Largest Contentful Paint.

Es que mira, my English is the very good looking.

Y esto que todo está en inglés.

Largest Contentful Paint.

Hoy sí.

¿Qué tan rápido se carga el contenido principal?

Esto debe ser menos a 2.5 segundos.

El INP - Interaction to Next Paint.

¿Qué tan rápido responde la página a las interacciones de los usuarios?

Debe ser menor a 200 milisegundos.

El CLS - Cumulative Layout Shift, ya dije yo una mala palabra.

So sorry, my friend.

Shift.

¿Qué tanto se mueve el contenido mientras va cargando?

Debe de ser menor a 0.1.

Estas son las Core Web Vitals.

Google las usa para el ranking y representan la experiencia real de los usuarios.

Así que hay que tenerlo en consideración.

Pero vamos a ver, también deberíamos de plantearnos una estrategia de optimización. ¿Te parece? Quiero ver. Son seis pasos y esto lo vamos a dar corto porque ya llegamos al tiempo. Paso uno, medí el estado actual. Usa las herramientas, toma nota de las métricas.

Paso 2. Identificar los problemas principales. ¿Cuáles son? Las imágenes, archivos, las fuentes, el javascript, el servidor es lento. ¿Cuál? Paso 3. Priorizar por impacto. Empezar por lo que más afecta. Si tenés imágenes de 5 o 10 megas, hombre, comienza por ahí.

Paso 4. Implementa cambios uno a uno. No hagas todo en una sola sentada, todo junto, todo de golpe, porque no vas a saber cómo se solucionó y qué funcionó. Paso a paso, tomando nota de las mejoras. Es lo recomendable. Paso 5. Medí después de cada cambio. Compará. ¿Mejoró o no mejoró? ¿Cuánto mejoró? Ok.

Paso 6. Monitoreo constante. El rendimiento no es, bueno, ya está hecho, lo optimicé y ya quedó. Forever. No. Cada actualización puede afectar el rendimiento. Cada nuevo plugin, cada nueva función, todo hace que cambie. Vos tenés que monitorear, mantener y optimizar continuamente.

Y recordá, el rendimiento es un proceso, no es un destino. Siempre va a haber algo que se puede optimizar y mejorar. Pero hay un punto de rendimiento que es lo suficientemente bueno.

Yo te recomiendo para cerrar este episodio que encontres ese punto de equilibrio y trabajes ahí.

No vas a bajar y si puedes subir está bien, pero no vayas buscando el 100 sobre 100.

Busca siempre que se cumplan los requerimientos y que tu web cumpla con su objetivo.

Y bueno, ya estamos listos para el commit y hacer push.

Si tenés dudas o querés ponerte en contacto, me podés encontrar en webenlinea.org/contacto

Te espero en el próximo episodio.

Salud.