Sobre el estudio
Una práctica digital. No una agencia.
DSEO Marketing nace alrededor de una idea sencilla: una presencia digital debe hacer que el negocio sea más fácil de entender.
El trabajo conecta diseño web, desarrollo, visibilidad, contenido y estrategia. Pero esas son herramientas, no el producto. El producto real es comprensión.
Qué significa que el producto sea comprensión
Cuando decimos comprensión no hablamos de una idea bonita. Hablamos de cuatro cosas concretas que o pasan, o no pasan.
Una persona tiene que entender qué hace el negocio, en la primera pantalla y sin esforzarse.
Un buscador tiene que entender cómo se relacionan las páginas entre sí, porque las lee sin verlas.
Alguien en un teléfono tiene que poder llegar hasta el final sin pelearse con la interfaz.
Y un cliente tiene que saber cómo hablar con una persona real, sin formularios que se pierden.
Si esas cuatro se cumplen, el sitio funciona aunque el diseño no gane premios. Si fallan, no hay estética que lo salve.
Qué no es DSEO Marketing
No es una agencia grande. No hay departamentos, ni un equipo de cuentas entre tú y quien hace el trabajo. Hablas directamente con quien lo construye.
Eso tiene ventajas y tiene un límite, y conviene decir los dos. La ventaja es que no se pierde nada en la traducción, y que las decisiones se toman rápido y con criterio técnico. El límite es la capacidad: no aceptamos más proyectos de los que se pueden atender bien a la vez.
Tampoco es una tienda de horas. No vendemos paquetes de mantenimiento por si acaso, ni complementos que hay que seguir pagando para que la web siga funcionando.
La regla de la casa
No afirmar más de lo que se puede demostrar.
Suena obvio, pero descarta la mayor parte de lo que se dice en este sector. Descarta prometer posiciones en buscadores. Descarta inventar cifras de clientes o de resultados. Descarta las reseñas fabricadas y las valoraciones metidas en los datos estructurados para que salga una estrellita en Google.
Esa regla también decide qué aparece en esta web. Aquí no vas a encontrar un número de proyectos entregados, ni un porcentaje de mejora, ni un logotipo de cliente que no exista. Si algo no se puede comprobar, no se publica.
Cuesta más escribir así. Es más fácil presumir de una cifra redonda de clientes satisfechos que explicar cómo trabajas. Pero lo primero se lo puede inventar cualquiera y lo segundo no.
Por qué el código decide si te encuentran
Un buscador no mira tu página. La descarga, la lee y decide. Y el orden en que hace esas tres cosas explica casi todo lo que la gente atribuye a la suerte.
Primero rastrea: pide el archivo HTML y lo lee tal y como llega. Después, si la página necesita ejecutar JavaScript para mostrar su contenido, la aparta a una cola de renderizado y vuelve más tarde, cuando tenga recursos disponibles. Sólo entonces indexa lo que haya encontrado.
Ese «vuelve más tarde» es donde se pierde media web. Si tu texto, tus enlaces y tus títulos viven dentro de un script que hay que ejecutar, no estás compitiendo: estás esperando turno. Si el contenido ya viene en el HTML, te leen en el primer paso, sin cola y sin depender de que ese día haya presupuesto de renderizado para ti.
Por eso aquí el contenido se sirve escrito en el HTML, y el JavaScript sólo añade comportamiento encima de algo que ya funciona sin él.
El hilo principal es uno solo
Cada kilobyte de JavaScript hay que descargarlo, analizarlo, compilarlo y ejecutarlo. Y eso no ocurre en un servidor potente: ocurre en el teléfono de quien te visita, que casi siempre es bastante más lento que el ordenador donde se diseñó la página.
Mientras el navegador procesa ese código, no hace ninguna otra cosa. No pinta, no responde a un toque, no descarga la imagen siguiente. Es un carril único. Por eso una web puede verse instantánea en la oficina con fibra y tardar una eternidad en la calle con cobertura regular.
La diferencia entre tres kilobytes y trescientos no es un número para presumir en una reunión. Es la diferencia entre que alguien vea tu propuesta o cierre la pestaña antes de leerla.
Y hay una consecuencia menos evidente: lo que no cargas no se puede romper. Un constructor visual tiene que servir para todos los casos posibles, así que envía el código de todos ellos aunque tú uses tres. Cada uno de esos scripts se actualiza por su cuenta, y cada actualización es una oportunidad de que algo deje de funcionar un martes por la mañana sin que nadie haya tocado nada.
Lo que sí se mide, y lo que nadie puede prometer
Google publica tres indicadores de experiencia. Uno mide cuánto tarda en aparecer el contenido principal. Otro mide si los elementos saltan mientras la página carga: ese momento en que vas a pulsar un botón y se te mueve debajo del dedo. El tercero mide cuánto tarda la página en responder cuando interactúas con ella.
Los tres empeoran con cada librería que no hacía falta, con cada tipografía pedida a un servidor ajeno y con cada imagen servida sin dimensiones.
Ahora la parte honesta: ninguno de esos indicadores garantiza una posición. Son objetivos de ingeniería y de experiencia, no una palanca de posicionamiento. Quien te prometa el primer puesto a cambio de mejorarlos te está vendiendo algo que no controla. Lo que sí describen con precisión es por qué alguien se queda o se va, y eso sí depende de cómo esté construida la página.
Lo mismo con el resto del oficio. Los datos estructurados ayudan a que un buscador entienda qué tipo de entidad eres, pero no garantizan que aparezca un resultado enriquecido. Un mapa del sitio ayuda al descubrimiento, pero no garantiza la indexación. Decirlo así es menos vendedor y es lo único cierto.
Estructura antes que estilo
Una máquina que lee sin ver necesita jerarquía. Un titular que es un titular de verdad y no un texto grande pintado con estilos. Enlaces que son enlaces y no bloques con un detector de clics encima. Secciones marcadas como secciones.
Cuando esa estructura está bien puesta pasan tres cosas a la vez, y las tres importan. El buscador entiende de qué va cada página y cómo se relaciona con las demás. Un lector de pantalla puede recorrer el sitio de forma ordenada. Y la página sigue funcionando aunque el JavaScript falle, se bloquee o simplemente tarde.
Eso último no es un detalle teórico. Conexiones malas, extensiones del navegador, redes corporativas que filtran scripts: hay muchas maneras de quedarse sin JavaScript. Una página bien construida se degrada; una mal construida se queda en blanco.
Las piezas, explicadas
Si has llegado hasta aquí y quieres entender de qué se habla cuando se habla de desarrollo web, esta parte es para ti. Son cuatro piezas y cada una tiene un trabajo distinto.
HTML: la estructura
El HTML es el esqueleto. No decide colores ni movimiento: decide qué es cada cosa. Esto es un titular, esto un párrafo, esto una lista, esto un enlace, esto un formulario.
Parece poca cosa y es la pieza más importante, porque es la única que leen todos: el navegador, el buscador y el lector de pantalla de una persona ciega. Un titular escrito como titular se entiende en los tres sitios. Un titular hecho con un texto grande y en negrita sólo se entiende en uno, el visual.
A eso se le llama HTML semántico: usar el elemento que corresponde al significado, no al aspecto. Es gratis, no pesa nada, y es la diferencia entre una página que se puede interpretar y una que hay que adivinar.
CSS: la presentación
El CSS decide cómo se ve. Tipografías, colores, espacios, y sobre todo la colocación de las cosas en pantalla.
Tiene dos mecanismos que conviene conocer. La cascada, que hace que varias reglas puedan afectar al mismo elemento y gane la más específica o la última escrita. Y las consultas de medios, que permiten cambiar la disposición según el ancho de la pantalla: por eso la misma página puede ser una columna en el teléfono y tres columnas en el escritorio, sin duplicar contenido.
Un detalle que casi nadie sabe: el CSS bloquea el pintado. El navegador no dibuja nada hasta tener los estilos, para no enseñarte la página desnuda y luego vestirla delante de tus ojos. Por eso una hoja de estilos enorme o pedida a un servidor lento retrasa lo que ve el visitante, aunque el texto ya estuviera descargado.
JavaScript: el comportamiento
El JavaScript es lo único de los tres que ejecuta. Los otros dos se leen; éste corre.
Sirve para lo que pasa después de cargar: abrir un menú, validar un formulario antes de enviarlo, reproducir un vídeo cuando entra en pantalla. Todo eso es comportamiento, y es su terreno.
El error común es usarlo para lo que no le toca. Si el contenido de la página sólo existe cuando el JavaScript se ejecuta, has convertido algo que se leía en el primer paso en algo que hay que esperar. Y si falla, no queda nada.
La forma correcta se llama mejora progresiva: primero que funcione sin JavaScript, después añadirle comportamiento encima. Un menú que sin JavaScript sigue siendo una lista de enlaces que funcionan. Un vídeo que sin JavaScript muestra su imagen de portada en vez de un hueco.
Node: JavaScript fuera del navegador
Node es JavaScript ejecutándose en un ordenador en lugar de en una pestaña. Eso abre dos usos completamente distintos, y confundirlos es el origen de muchos malentendidos.
El primero es herramienta de construcción. Node trabaja en tu máquina antes de publicar: junta archivos, comprime imágenes, genera las páginas y comprueba que nada esté roto. Ese trabajo se hace una vez y el resultado son archivos terminados. Node no viaja con la web.
El segundo es servidor: un programa que responde a cada visita en el momento, calculando la página al vuelo.
Esta web usa el primero. Cada página se genera al publicar y se sirve ya hecha. Un visitante no espera a que nadie calcule nada, y no hay un servidor de aplicación que mantener, actualizar ni proteger.
Estático, dinámico y el CDN
Un sitio estático es un conjunto de archivos terminados que el servidor entrega tal cual. Uno dinámico construye la respuesta en cada visita, normalmente consultando una base de datos.
Lo dinámico hace falta cuando el contenido cambia por usuario: un carrito, un panel privado, un catálogo con existencias. Cuando no cambia, es peso y riesgo a cambio de nada. Casi toda la web de un negocio de servicios entra en el segundo grupo, y sin embargo se publica sobre sistemas dinámicos por costumbre.
Encima de eso está el CDN, que son copias de tus archivos repartidas por el mundo para que el visitante reciba la más cercana. Sanabria Property Group se sirve a través de Cloudflare; USA Luxury Cleaning, desde Railway. Ambas con archivos ya construidos, sin cálculo por visita.
Cómo se nota en esta misma web
La manera más rápida de saber si alguien cumple lo que dice es mirar su propia casa.
Esta web está escrita a mano, sin constructores visuales ni plantillas compradas. Lo que llega a tu navegador son entre 5,8 y 8,9 kilobytes de JavaScript propio, según la página, y ninguna librería de interfaz: ni React, ni Vue, ni jQuery.
Cada cambio se comprueba de forma automática en dieciocho combinaciones de idioma y ancho de pantalla, desde 320 hasta 1920 píxeles, verificando que ningún elemento se salga de la pantalla, que los objetivos táctiles lleguen a 44 píxeles y que no aparezca ninguna violación de accesibilidad.
No lo decimos para presumir. Lo decimos porque es comprobable en el código fuente de esta misma página. En el portafolio está el desglose de esta web y de las otras dos, con el detalle de qué se cuenta y qué no.
Quién está detrás
DSEO Marketing está dirigida directamente por Daniel Sanabria, profesional licenciado en Florida con experiencia en bienes raíces, administración de asociaciones e inspección de propiedades.
Su formación técnica comenzó en Cuba, donde estudió Ingeniería Informática en CUJAE. Hoy combina esa base con experiencia directa operando negocios, desarrollo web, sistemas digitales, automatización e inteligencia artificial.
Esa mezcla explica el enfoque: la parte técnica viene de la ingeniería, y el criterio sobre qué merece la pena construir viene de haber llevado negocios donde un error cuesta dinero de verdad.