Tu visitante en Bogotá no «siente el disco». Siente el tiempo de ida y vuelta hasta el servidor que tiene el HTML. Si ese origen está en otro país, el paquete ya gastó decenas de milisegundos antes de que PHP mire la base. El eslogan del almacenamiento no borra un hop a Miami. En Conexcol la operación está en Colombia, conectada al NAP Colombia: el camino corto para quien te compra desde acá.

Esto no sustituye a cómo elegir hosting en Colombia. Ahí está el mapa. Aquí está el porqué de la latencia, y cómo medirla sin un laboratorio. El producto de todos los días sigue siendo el sitio elástico con cPanel; si necesitas root, el cloud; si un nodo no puede ser el fallo, el cluster.

El spot del 7 de mayo de 2026 dura dos minutos: origen cerca, el camino corto. No es un how-to de panel.

Qué vas a tener al terminar

Una distinción clara: RTT de red versus I/O de disco. Qué hace el NAP. Qué nota alguien en Bogotá. Y un enlace para medir, no para creer un banner.

RTT: lo que el navegador espera sin que lo veas

RTT (round-trip time) es el tiempo que tarda un paquete en ir y volver. Cada petición HTTP —el documento, el CSS, una API del carrito— paga al menos un viaje. Si el RTT al origen es de 60 u 80 ms, tres o cuatro idas ya son un tercio de segundo antes de pintar. El disco, en esa película, ni aparece en los créditos: lee en fracciones de milisegundo. Mezclar las dos capas es el truco del anuncio.

TTFB (el primer byte) incluye RTT más cola del servidor más PHP más base. Puedes tener PHP rápido y LiteSpeed Cache en HIT y, aun así, perder contra un origen cerca si el visitante está aquí y el servidor está lejos. Al revés también: un origen local con un plugin desbocado se siente lento. Son dos palancas. Primero ubícate; después afina el stack.

El disco no cancela un hop a otro país

El almacenamiento serio importa bajo carga: muchas escrituras, WooCommerce con reportes, un cron que toca mil filas. Ahí el I/O se nota. Para el home de una pyme en Colombia, lo que cambia la cara del visitante es dónde está el origen, no el microbenchmark del fabricante del disco. No vamos a inventarte un modelo de unidad. Vamos a decirte que el camino de red pesa más, y que eso se mide.

Si te venden «velocidad» con una gráfica de IOPS y no te dicen ciudad ni punto de intercambio, estás comprando un número de laboratorio. Pide ruta. Pide NAP o nombre de peering. Pide un ping desde Bogotá, no desde un probe en Virginia.

NAP Colombia: el cruce, no un eslogan

El NAP es el punto donde los operadores del país se entregan tráfico. Si tu hosting sale por ahí y el ISP del visitante también llega ahí, el paquete no tiene que ir a un intercambio en el exterior para volver. Nosotros operamos en Colombia y salimos por el NAP Colombia. Eso no es poesía de brochure: es el camino que recorre el paquete cuando tu cliente en Medellín pide el home.

Facturar en pesos no pone el origen en Colombia. Un panel en español tampoco. La pregunta es: ¿el servidor que responde el A de tu dominio está aquí, o el DNS te manda a otra latitud? Cobrar en COP y servir desde afuera es legal; no es lo mismo para el RTT.

Visitante en Bogotá (y en Cali, Barranquilla, Bucaramanga)

Imagina un checkout. El navegador pide el HTML, luego CSS, luego tres XHR de la pasarela. Cada uno paga RTT. Con origen local, esos viajes se quedan en el dígito o poco más de diez milisegundos típicos de una ruta nacional bien peerada. Con origen en Estados Unidos o Europa, cada viaje se come el tramo internacional. El usuario no dice «RTT alto». Dice que la tienda «se siente pesada». Google, en CrUX, lo ve como TTFB y LCP desde esa geografía.

Por eso el hosting para audiencia colombiana no se elige con un test corrido desde un portátil en Miami. Se elige con un visitante aquí —o con un probe aquí—. Si tu público está en España, la cuenta cambia: entonces un origen en Europa puede ser la ruta corta. Este artículo asume lo que asume el negocio de Conexcol desde 1999: clientes y visitantes en Colombia.

Qué sí acelera después de ubicar el origen

Cuando el RTT ya es corto, el stack deja de ser adorno. LiteSpeed y LiteSpeed Cache recortan PHP en HIT. Imágenes pesadas se comen el LCP aunque el ping sea bajo: eso va en otro artículo del catálogo. HTTP/3 (QUIC) ayuda en redes móviles con pérdida. Nada de eso sustituye poner el origen cerca. El orden es: geografía, luego servidor web, luego plugin, luego peso de la página.

En los sitios elásticos el techo LVE también se siente: si PHP se queda en cola (508), el RTT era irrelevante. El mapa de producto —sitio elástico, cloud, cluster, Windows— está en sitios elásticos, cloud, cluster o Windows. WordPress bien servido en esta línea: requisitos de hosting WordPress.

Cómo medirlo (sin creer el banner)

Dos pruebas distintas, no las mezcles. Una es tu enlace hasta nuestros servidores: ping, descarga y subida contra el servidor Conexcol en Speedtest. Eso está en test de velocidad hacia los servidores de Conexcol. Si el ping se dispara en Wi‑Fi, prueba cable antes de abrir un ticket.

La otra es tu web: TTFB y LCP con un probe en Colombia, o con el celular en Bogotá con caché fría. Cómo leer el número —y qué no es el disco— va en medir la velocidad de tu web desde Colombia. Un PageSpeed corrido desde un probe en Iowa te dice otra geografía. Úsalo para JS y peso; no lo uses para decidir si el origen debe estar en Colombia.

Qué no vas a leer aquí

No hay «la latencia más baja del país» ni milisegundos grabados en piedra. Hay un hecho que puedes comprobar: origen en Colombia, salida por el NAP, y un test que tú corres. El SLA cubre soporte y disponibilidad según el contrato; no es un poster de ping. Si otro proveedor te muestra ciudad, peering y un probe local con la misma claridad, compara en serio. Si te muestra una gráfica de disco y un precio a 48 meses, ya sabes qué está vendiendo.

¿La web ya está afuera y quieres el origen acá? Migrar WordPress o cambiar de hosting. Si no quieres tocarlo, ticket de migraciones.

Contratar Cloud Web Hosting · /hosting/ · /cloud/ · /hosting/cluster/ · Windows · medir velocidad · abrir un ticket