Hace unos días vi esta conversación en un grupo de WhatsApp:
"Con lo mala que está la conexión pa tener q abrir un sitio pa ver un catálogo."
Después alguien respondió:
"Es mejor mandar un txt al grupo 😂"
Y otro:
"Una foto."
La conversación seguía con una idea bastante lógica:
"Ahora dime tú un sitio web pa un catálogo y cuando no haya conexión hasta ahí llego."
Y pensé: ¿tienen razón?
Así que decidí comparar.
¿Cuánto cuesta ver un catálogo?
Para empezar, tomemos como referencia una foto enviada por WhatsApp.
Una foto puede pesar aproximadamente 100 KB.
Eso significa que:
10 fotos ≈ 1 MB
50 fotos ≈ 5 MB
Ahora comparemos eso con algunas páginas reales.
| Datos descargados | Tiempo de carga | |
|---|---|---|
| 📱 Una foto por WhatsApp | ~100 KB | — |
| 📄 PDF de catálogo con muchas imágenes | ~40 MB* | ~10 minutos |
| 🌐 Página analizada | 4.5 MB | ~4 minutos |
| 🌐 Turbo SaaS Template | ~500 KB | ~35 segundos |
| 🌐 TallerWeb | ~700 KB | ~9 segundos |
- 40 MB es un ejemplo para un catálogo PDF con muchas imágenes. El tamaño real depende de cómo se prepare el documento.
Hay una diferencia bastante grande entre esos números.
La primera página que analicé necesitaba descargar aproximadamente 45 veces el tamaño de una foto de WhatsApp.
Y lo más curioso es que esa página solamente tenía cuatro fotos pequeñas, una imagen grande en el fondo y un mapa.
Entonces sí: una página web puede ser una mala idea
Si para ver un catálogo tengo que esperar cuatro minutos, entiendo perfectamente que alguien diga:
"Mándame las fotos por WhatsApp."
Yo probablemente haría lo mismo.
Pero aquí hay algo importante.
Eso no demuestra que una página web sea innecesaria.
Demuestra que esa página web está mal preparada para sus usuarios.
Porque también podemos construir una página que descargue mucho menos.
TallerWeb, por ejemplo, descarga alrededor de 700 KB en una visita.
Y eso incluye contenido de la página, imágenes, analíticas y hasta la terminal que tenemos como juego nerd "escondido".
Otra página que hice, Turbo SaaS Template, descarga alrededor de 500 KB, incluso teniendo varias imágenes grandes y bastante información.
La diferencia no está en que una página tenga muchas cosas y otra no.
Está en cómo se construye.
¿Y si usamos un PDF?
Un PDF parece una solución sencilla.
Preparas un catálogo, pones las fotos y lo mandas al grupo.
Perfecto.
Pero imaginemos un catálogo grande que termina ocupando unos 40 MB.
Si alguien quiere saber solamente cuánto cuesta un producto, tiene que descargar un documento enorme para encontrar esa información.
Y si mañana cambias diez precios, tienes que modificar el documento y volver a distribuirlo.
Una página web puede funcionar de otra manera.
Puedes tener:
Catálogo
→ Ropa
→ Zapatos
→ Accesorios
→ Ofertas
Y el cliente entra directamente en lo que quiere.
No tiene que recibir 40 MB para consultar un solo producto.
Entonces, ¿WhatsApp es malo?
No.
Todo lo contrario.
WhatsApp es probablemente una de las mejores herramientas para hablar con un cliente.
Si tienes cinco productos y tus clientes ya tienen tu número, quizás no necesitas nada más.
Pero imagina que tienes cien productos.
Ahora cada cliente puede preguntarte:
¿Cuánto cuesta este?
¿Tienes talla M?
¿Qué colores tienes?
¿Cuál es el horario?
¿Dónde están?
¿Qué otros modelos tienes?
Puedes responder todo por WhatsApp.
Pero estarías utilizando una conversación como catálogo.
Y cada cliente tendría que preguntarte cosas que podrías mostrar directamente.
Ahí es donde una página web empieza a tener sentido.
No porque sea "más moderna".
Porque puede organizar información que de otra manera tienes que repetir.
La web no tiene que competir con WhatsApp
De hecho, pueden trabajar juntas.
La página puede responder:
¿Qué vendes?
¿Cuánto cuesta?
¿Dónde estás?
¿Qué tienes disponible?
Y WhatsApp puede responder:
"Quiero comprar esto."
Una no tiene que sustituir a la otra.
Puedes tener un catálogo web y un botón:
¿Te interesa? Escríbenos por WhatsApp.
Así el cliente encuentra la información por su cuenta y utiliza WhatsApp cuando realmente necesita hablar contigo.
El problema no es la mala conexión
La mala conexión es una realidad.
Por eso precisamente tenemos que construir pensando en ella.
Una página que tarda cuatro minutos en abrir no debería convertirse en el argumento de que las páginas web no sirven.
Debería convertirse en una pregunta:
¿Por qué estamos construyendo páginas que necesitan cuatro minutos para mostrar información sencilla?
Si una persona tiene una conexión limitada, cada megabyte importa.
Y si podemos mostrar la misma información utilizando una fracción de esos datos, ¿por qué no hacerlo?
No se trata de quitarle cosas a una página.
Se trata de no hacer que el cliente descargue cosas que no necesita.
¿Y mañana?
Hoy muchas personas pueden pensar:
"Mis clientes están en WhatsApp."
Y puede ser verdad.
Pero eso no significa que siempre vaya a ser así.
Un negocio puede empezar con WhatsApp.
Después puede necesitar un catálogo.
Después puede querer aparecer cuando alguien busque su producto.
Después puede necesitar recibir pedidos.
Después puede necesitar una tienda.
No todos necesitan todo desde el primer día.
Pero tampoco conviene confundir:
"Hoy no lo necesito"
con:
"Nunca lo voy a necesitar."
Internet ha cambiado muchas veces la forma en que encontramos negocios.
Y probablemente seguirá cambiando.
No sabemos exactamente cuál será la próxima herramienta que utilicen nuestros clientes.
Por eso no creo que la pregunta correcta sea:
"¿Para qué quiero una página web?"
La pregunta debería ser:
"¿Qué problema de mi negocio podría resolver una página web?"
Si la respuesta es "ninguno", perfecto.
Pero si estás enviando las mismas fotos, los mismos precios y las mismas explicaciones todos los días por WhatsApp, quizás ya tienes la respuesta.
Una última curiosidad
Todo esto de intentar utilizar la menor cantidad de datos posible es algo que también estoy experimentando en otro proyecto.
Estoy construyendo una pizarra colaborativa que permite compartir dibujo, audio y video intentando mantenerse alrededor de 120 Kbps.
La idea técnica es sencilla de explicar:
En lugar de enviar continuamente toda la información, intento enviar solamente aquello que cambió.
Por ejemplo, si una pizarra tiene 100 elementos y solamente mueves uno, no tiene mucho sentido enviar nuevamente los otros 99.
En el código, esto se traduce en trabajar con cambios en lugar de enviar constantemente el estado completo:
type Change =
| { type: "add"; item: Item }
| { type: "update"; id: string; changes: Partial<Item> }
| { type: "remove"; id: string };
Así, en lugar de transmitir:
estado completo de la pizarra
se puede transmitir:
"el elemento 42 cambió"
Esto es solo un ejemplo; obviamente, también estoy usando mi propio protocolo de datos binarios para reducir aún más el payload y la comprensión de datos con gzip y RLU cuando conviene.
Es un experimento distinto, pero parte de la misma idea:
Cuando la conexión es limitada, no puedes permitirte desperdiciar datos.
Puedes probarlo aquí:
Whiteboard — experimento de bajo ancho de banda
Una página web no tiene que ser más pesada porque tenga más información.
Y una conexión lenta no significa que tengamos que conformarnos con malas experiencias.
Significa que tenemos que construir pensando en las personas que realmente van a utilizar lo que hacemos.
