Blog

  • No te falta tráfico: te sobra fricción

    La cuenta que casi nadie hace

    De cada 100 personas que entran a una tienda online, compran una o dos. Ese es el promedio global, y no es un número que se arregle con más visitas.

    Hagamos la cuenta con eso. Si entran 5.000 personas por mes y compran 50, tenés un 1% de conversión. Para duplicar las ventas tenés dos caminos:

    Camino A: conseguir 5.000 visitas más. Eso significa duplicar la inversión en publicidad, todos los meses, para siempre.

    Camino B: pasar del 1% al 2%. Mismo tráfico, mismo presupuesto, el doble de ventas. Y el arreglo se hace una vez.

    Casi todo el mundo elige el camino A porque es el que se puede comprar con tarjeta. El camino B requiere sentarse a mirar dónde se está perdiendo la gente, y por eso se posterga.

    Dónde se cae la venta

    Alrededor de siete de cada diez carritos armados terminan abandonados. Ojo con ese número: no son curiosos. Son personas que eligieron un producto, lo pusieron en el carrito y a último momento se fueron. Ya estaban decididas. Algo las frenó.

    Y las causas se repiten en casi todas las tiendas que audito:

    El envío aparece al final. Es la razón número uno de abandono en todos los estudios, y la más fácil de arreglar. El cliente vio $50.000, llegó hasta el último paso y descubrió que son $62.000. No es que no pueda pagarlo: es que se siente engañado. Mostrá el costo antes, o al menos calculalo apenas ingresa el código postal.

    Le pedís datos que no necesitás. Cada campo del formulario es una oportunidad de que se arrepienta. ¿De verdad necesitás el DNI para vender una remera? ¿La razón social? ¿El teléfono y el celular? Todo lo que no usás, sacalo.

    Lo obligás a crear una cuenta. Nadie quiere una cuenta en tu tienda. Quiere el producto. La compra como invitado tiene que estar y tiene que ser la opción visible.

    Faltan medios de pago o están mal explicados. Acá pesa el contexto argentino: si vendés algo de ticket alto sin cuotas, perdés. Y si tenés cuotas pero el cliente no las ve hasta el final, es casi lo mismo que no tenerlas.

    No lo probaste en el celular como lo usa la gente. Ahí se pierde la mayoría de las ventas: la conversión en móvil es cerca de la mitad que en computadora. Probá tu propia tienda desde el celular, con datos móviles y no con wifi, y comprá algo de verdad. La mitad de los problemas aparecen recién ahí.

    No sabe quién sos. Sin dirección, sin teléfono, sin política de cambios, sin fotos reales. En una tienda chica, la confianza es parte del producto.

    Los carritos abandonados no son una estadística

    Son una lista de nombres y correos de gente que quiso comprarte y no pudo o no se animó.

    En una tienda WooCommerce eso se puede registrar y recuperar: un mensaje a las pocas horas, amable, sin descuento por defecto —muchas veces alcanza con preguntar si tuvo algún problema—. Es la venta más barata que vas a hacer en tu vida, porque el cliente ya lo decidió una vez.

    Por qué esto se puede arreglar en WooCommerce

    Acá está la ventaja concreta y no tiene que ver con el precio.

    En una plataforma cerrada, el checkout es el que es. Podés cambiar colores y poco más. Si el proceso de compra tiene un paso de sobra, esperás a que la plataforma lo cambie. Si nunca lo cambia, convivís con eso.

    En WooCommerce el checkout es tuyo. Se le sacan campos, se reordenan pasos, se muestra el costo de envío antes, se agregan botones de cantidad que se puedan tocar con el pulgar. Cada una de esas cosas suena menor y todas juntas son la diferencia entre el 1% y el 2%.

    Por dónde empezar

    Antes de tocar nada, hacé una compra completa en tu propia tienda. Desde el celular, con datos móviles, pagando de verdad. Anotá cada momento en el que dudaste, te frenaste o tuviste que volver atrás.

    Esa lista es tu plan de trabajo, y es más valiosa que cualquier informe.


    ¿Querés que la haga yo? Mandame el link de tu tienda y te digo en qué punto se está perdiendo la venta. Sin compromiso.

  • ¿Y si la hago con IA?

    Lo que viste en Instagram es verdad

    Sí, hoy le pedís a una IA que te arme un sitio y en veinte minutos tenés algo en pantalla. Con secciones, con colores, con textos. Se ve bien. Anda.

    No te lo voy a discutir, porque es cierto. Y porque si tu caso es uno de estos, te conviene:

    Estás probando una idea. Todavía no sabés si eso se vende. Armá algo rápido, salí a la calle y fijate qué pasa. Invertir en un sitio serio antes de validar es poner el carro delante del caballo.

    Necesitás una presencia mínima. Un lugar donde figuren tu nombre, qué hacés y cómo te contactan. Si eso es todo, no necesitás un desarrollador.

    Tu negocio pasa entero por WhatsApp. Hay rubros donde el sitio es una formalidad y la venta ocurre en otro lado. Reconocerlo a tiempo te ahorra un montón.

    Si estás en alguno de esos tres, dejá de leer y andá a hacerla. En serio.

    Dónde se rompe

    El problema no aparece el día uno. Aparece al mes.

    Aparece cuando entran visitas y no compra nadie, y no sabés si es el precio, el texto, la foto o que el botón de pago no funciona en iPhone. Aparece cuando tenés que cargar treinta productos nuevos y descubrís que el sistema no estaba pensado para eso. Aparece cuando algo deja de andar un sábado a la tarde y no hay a quién llamar.

    Una IA te construye lo que le pedís. El tema es que vos no sabés todavía qué hay que pedir, y no tenés por qué saberlo: no es tu oficio.

    Nadie le va a decir a la IA que tu cliente promedio tiene 55 años y compra desde el celular con letra chica. Que en tu rubro la gente abandona el carrito si le piden el DNI. Que tu depósito no tiene sistema de stock y por eso el sitio no puede prometer disponibilidad en tiempo real.

    Esas cosas no salen de una herramienta. Salen de alguien que te escuchó.

    Un dato que dice más de lo que parece

    En 2025 se hizo un estudio serio con programadores experimentados: los pusieron a trabajar con IA y sin IA, midiendo el tiempo real de cada tarea.

    Con IA tardaron más. Y lo más interesante: cuando terminaron, estaban convencidos de que habían ido más rápido.

    La lección no es que la IA no sirva —sirve, y mucho—. La lección es que la sensación de que algo salió rápido y barato no garantiza que haya salido bien. Es exactamente lo que pasa con un sitio armado en veinte minutos: se siente como un logro hasta que llega la primera factura de publicidad y no vuelve nada.

    Qué estás pagando cuando me contratás

    Te lo digo sin vueltas: yo también uso IA. Todos los días. Me ahorra las partes repetitivas y me deja tiempo para lo que sí mueve la aguja.

    Así que no me estás pagando por escribir código. Eso hace rato que no es lo caro.

    Me estás pagando por las decisiones: qué construir y qué no, qué se va a romper antes de que se rompa, por dónde tiene que pasar el cliente para que compre. Y por algo que ninguna herramienta te da: alguien que atiende el teléfono cuando tu tienda se cae.

    En resumen

    Si estás arrancando y necesitás algo ya, hacelo con IA y sin culpa.

    Si tu sitio tiene que vender, sostener stock, cobrar en serio y crecer sin romperse, ahí ya no estás comprando una página. Estás comprando criterio.


    ¿No sabés en cuál de los dos casos estás? Escribime, charlamos quince minutos y te lo digo derecho. Si tu caso no me necesita, te lo voy a decir igual.

  • El panel dice que vendiste. El banco dice otra cosa.

    La escena

    Una tienda con campaña activa en Instagram. El panel de WooCommerce muestra un mes fuerte: más pedidos que el anterior, ticket promedio en alza, la curva para arriba. El dueño está contento y decide subir el presupuesto de publicidad.

    El problema aparece cuando cruzás ese número con el extracto bancario. No coinciden. Y no por un poco.

    Al filtrar los pedidos por estado, el panorama se ordena solo: la mayoría estaba en «En espera». Pedidos generados, con productos elegidos y datos de envío completos, que nunca se cobraron.

    Qué es «En espera» y por qué se llena

    En WooCommerce, un pedido pasa a «En espera» cuando el sistema entiende que la venta se concretó pero el dinero todavía no llegó. Es el estado natural de la transferencia bancaria: el cliente confirma, vos esperás el comprobante.

    El problema es que hay varios caminos hacia ese estado, y solo uno es sano:

    La pasarela falla y el cliente elige otra cosa. Si el checkout tira error o tarda, mucha gente vuelve atrás y selecciona transferencia porque es la opción que sí avanza. Nunca transfiere. El pedido queda ahí.

    El webhook no vuelve. El cliente pagó de verdad, pero la notificación de la pasarela no llegó a tu sitio: un timeout, un firewall, un plugin de caché interceptando la URL de callback. La plata está en tu cuenta y el pedido figura impago. Es el caso inverso y también existe.

    El cliente eligió transferencia y se arrepintió. Es la fricción normal de ese medio de pago. Un porcentaje se pierde siempre, y está bien que así sea. El problema no es que exista: es que nadie lo mide.

    Por qué el panel no te avisa

    Acá viene la parte incómoda. El panel de WooCommerce no tiene una definición de «venta»: tiene varias, y no siempre coinciden entre reportes.

    En Analytics → Ajustes hay dos configuraciones que la mayoría nunca abrió. La primera es Estados excluidos, que por defecto deja afuera los pedidos pendientes, cancelados y fallidos, pero no los que están en espera. La segunda es el Tipo de fecha, que por defecto usa la fecha de pago. Y un pedido en espera no tiene fecha de pago, porque nunca se pagó.

    El resultado es que el mismo mes puede darte números distintos según qué pantalla mires. El reporte de pedidos te muestra una cosa, el de ingresos otra, y el resumen de la portada una tercera. Ninguno miente: cada uno responde una pregunta distinta que vos no sabías que estabas haciendo.

    El daño real

    No es solo un número inflado en una pantalla. Tiene tres consecuencias concretas:

    El stock queda comprometido. WooCommerce descuenta inventario cuando el pedido pasa a «En espera». Productos que nadie pagó pueden estar bloqueando unidades que sí podrías vender.

    La campaña se optimiza mal. Si el pixel dispara la conversión al generar el pedido y no al cobrarlo, el algoritmo aprende a traerte gente que completa el checkout sin pagar. Estás pagando por entrenar la campaña en la dirección equivocada.

    Las decisiones se toman sobre datos falsos. Comprar más mercadería, contratar, subir el presupuesto de ads. Todo apoyado en una facturación que no existe.

    Qué hacer esta semana

    Contá los pedidos en espera. En WooCommerce → Pedidos, filtrá por ese estado en los últimos 60 días. Si superan el 15% del total, ahí tenés un problema de cobro, no de ventas.

    Definí una sola fuente de verdad. Para vos, «venta» debería ser un pedido en estado Procesando o Completado, con fecha de pago. Todo lo demás es una intención de compra.

    Probá el checkout de punta a punta. Con una compra real, de monto chico, desde el celular y con datos móviles. La mitad de los problemas de pasarela aparecen recién ahí.

    Automatizá la cancelación de impagos. Un pedido en espera hace 30 días no se va a cobrar: liberá el stock.

    Ponete un alerta. Si el ratio de pedidos en espera pasa cierto umbral en una semana, que te llegue un mail. No hace falta revisar el panel todos los días; hace falta enterarse cuando algo se rompe.

    El punto de fondo

    Una tienda online no falla con estruendo. Falla en silencio, con el panel en verde y la caja vacía. La diferencia entre las dos cifras no es un detalle contable: es la única métrica que importa.


    ¿Sabés cuánto vendió tu tienda el mes pasado y cuánto cobró? Si esos dos números no te cierran, escribime y lo revisamos.

  • WooCommerce, Shopify o Tiendanube: cuál te conviene según cuánto vendés

    La diferencia de fondo: alquilar o ser dueño

    Shopify y Tiendanube son plataformas cerradas. Vos alquilás un espacio, te dan todo resuelto y ellos ponen las reglas: qué se puede tocar, qué no, y cuánto se cobra por cada operación.

    WooCommerce es un plugin de WordPress que corre en tu propio hosting. El código es tuyo, la base de datos es tuya y no hay nadie cobrando un porcentaje sobre lo que vendés. A cambio, alguien tiene que ocuparse de que funcione: actualizaciones, backups, seguridad, velocidad.

    Ninguna de las dos opciones es «mejor». Son modelos distintos y conviene una u otra según en qué etapa esté tu negocio.

    El costo que no aparece en la publicidad

    Cuando comparás, no mires el precio del plan. Mirá las tres capas del costo real:

    1. El plan mensual. Lo único que está a la vista.
    2. La comisión de la plataforma. Tiendanube cobra un porcentaje por transacción que va del 2% en el plan más barato al 0,7% en los superiores. Shopify, como no tiene Shopify Payments habilitado en Argentina, te suma un recargo del 2% (plan Basic) al 0,5% (Advanced) por usar una pasarela externa. Y el plan se factura en dólares.
    3. La pasarela de pago. Existe siempre, en cualquier plataforma. Mercado Pago se lleva su parte según plazo de acreditación y cuotas.

    WooCommerce elimina la capa 2 por completo. Pagás hosting y pagás la pasarela, nada más.

    Hagamos la cuenta gruesa: sobre una facturación de $10.000.000 mensuales, un 1,5% de comisión de plataforma son $150.000 por mes que se van sin contraprestación. En un año, $1.800.000. Ese número es el que tenés que comparar contra el costo de desarrollar tu propia tienda.

    Cuándo NO te conviene WooCommerce

    Te lo digo aunque yo desarrolle en WooCommerce, porque prefiero un cliente conforme a una venta forzada:

    • Estás validando el producto. Si todavía no sabés si eso se vende, arrancá con un plan gratuito de Tiendanube y salí a la calle mañana.
    • Facturás poco. Con volumen bajo, el 2% de comisión son monedas y no justifica una inversión de desarrollo.
    • No tenés a nadie que mantenga el sitio. Una tienda WooCommerce abandonada seis meses es un problema de seguridad, no un activo.

    Cuándo sí, y con ganas

    • Ya tenés facturación estable y las comisiones se volvieron un ítem visible en tus números.
    • Necesitás algo que la plataforma no hace. Buscadores por atributos, packs armables, listas de precios por cliente, descuentos por medio de pago, integración con tu sistema de gestión. En WooCommerce todo eso se programa; en las plataformas cerradas, se espera o no se hace.
    • Te importa el SEO. Control total de URLs, estructura, datos estructurados y velocidad. Sin límites impuestos por el tema.
    • Querés que la tienda sea tuya. Si mañana cambian los precios o las condiciones, no te mudás: ya estás en tu casa.

    En resumen

    Empezá donde sea más barato empezar. Mudate a WooCommerce cuando las comisiones te empiecen a doler o cuando la plataforma te frene una idea. La plataforma correcta es la que no te cuesta más de lo que te devuelve.

    Los porcentajes citados corresponden a los valores publicados a mediados de 2026. Verificá los vigentes antes de decidir, que en Argentina se actualizan seguido.


    ¿Estás pagando comisiones que ya no tienen sentido? Escribime y hacemos juntos la cuenta de cuánto te cuesta hoy tu tienda y cuánto costaría migrarla.

  • Astro: el framework que decidió que el JavaScript era opcional

    El punto de partida

    Un framework como Next.js o Nuxt parte del supuesto de que estás construyendo una aplicación: hay estado, interacción, rutas dinámicas, sesión de usuario. Todo el JavaScript del framework viaja al navegador porque, tarde o temprano, se va a necesitar.

    El problema es que la mayoría de los sitios que se construyen con esas herramientas no son aplicaciones. Son blogs, landings, sitios institucionales, documentación, catálogos. Contenido que se lee. Y ahí estás pagando cientos de kilobytes de runtime para renderizar texto que podría ser HTML plano.

    Astro invierte el supuesto: asume que estás construyendo un sitio de contenido y que la interactividad es la excepción, no la regla. Compila todo a HTML estático y elimina el JavaScript que no se usa. Un blog hecho en Astro puede llegar al navegador con literalmente cero bytes de JS.

    La arquitectura de islas

    Es el concepto central y vale entenderlo bien.

    En lugar de hidratar toda la página, Astro renderiza HTML estático y permite marcar componentes puntuales como «islas» interactivas. Cada isla carga su JavaScript de forma independiente y solo cuando corresponde.

    astro

    ---
    import Header from '../components/Header.astro';
    import Carrusel from '../components/Carrusel.jsx';
    import Calculadora from '../components/Calculadora.jsx';
    ---
    
    <Header />
    
    <Carrusel client:load />
    <Calculadora client:visible />

    Las directivas controlan cuándo se activa cada isla:

    • client:load — hidrata apenas carga la página.
    • client:idle — espera a que el navegador esté ocioso.
    • client:visible — hidrata recién cuando el componente entra en pantalla.
    • client:media — solo si se cumple una media query (ideal para menús que difieren en mobile).
    • client:only — se renderiza únicamente en el cliente.

    El Header del ejemplo no lleva directiva, así que es HTML puro: no cuesta nada. La calculadora, que está al pie de la página, ni siquiera descarga su JavaScript hasta que el visitante llega ahí. Es una diferencia enorme en el Largest Contentful Paint de un sitio con contenido largo.

    Agnóstico de framework

    Otro punto que sorprende a quien viene de React: en Astro las islas pueden estar escritas en React, Vue, Svelte, Solid o Preact, en el mismo proyecto. Se instalan como integraciones y conviven sin problema.

    En la práctica esto significa que podés reutilizar un componente que ya tenías en React sin migrarlo, y escribir el resto del sitio en .astro, que es básicamente HTML con frontmatter y sintaxis tipo JSX. Si sabés HTML y algo de JS, la curva es de un par de horas.

    Colecciones de contenido

    Para blogs y catálogos, esta es la funcionalidad que más trabajo ahorra. Definís un esquema con Zod y Astro te valida cada archivo Markdown en tiempo de build:

    ts

    import { defineCollection, z } from 'astro:content';
    
    const notas = defineCollection({
      schema: z.object({
        titulo: z.string(),
        copete: z.string(),
        fecha: z.date(),
        keywords: z.array(z.string()),
        portada: z.string().optional(),
      }),
    });
    
    export const collections = { notas };

    Si te olvidás la fecha en una nota, el build falla con un mensaje claro en lugar de publicar una página rota. Y todo el contenido queda tipado, así que el editor te autocompleta los campos.

    Dónde está Astro hoy

    La versión 7 salió el 22 de junio de 2026 y el foco fue casi todo rendimiento de build: compilador reescrito en Rust, migración a Vite 8 con Rolldown y un nuevo parser de Markdown, también en Rust. Para proyectos grandes, con cientos de páginas de contenido, la diferencia en tiempos de compilación es la mejora más visible. Requiere Node 22 como mínimo, así que conviene revisar el entorno antes de actualizar.

    También sumó detección de agentes de IA y mejoras de caché en el ruteo, dos temas que ganaron peso este año. Y desde la versión 6 el framework tiene respaldo corporativo de Cloudflare, lo que despeja bastante la duda razonable de «¿esto va a seguir existiendo en tres años?».

    Astro vs. las alternativas

    Contra WordPress: Astro gana en velocidad, seguridad (no hay base de datos ni panel expuesto) y costo de hosting (un sitio estático se sirve gratis o casi). Pierde en gestión de contenido: si el cliente necesita cargar entradas solo desde un panel, sin tocar archivos, necesitás sumarle un CMS headless. Existe la combinación WordPress como backend y Astro como frontend, que resuelve las dos cosas, pero es más infraestructura para mantener.

    Contra Next.js: para una aplicación con sesión, dashboard y estado compartido, Next sigue siendo la elección correcta. Para un sitio de contenido, Next es una herramienta desproporcionada.

    Contra HTML y CSS a mano: Astro te da componentes, layouts, colecciones tipadas y optimización de imágenes sin renunciar al resultado estático. Es lo que uno haría a mano, pero organizado.

    Cuándo conviene

    Sí:

    • Blogs, sitios institucionales, landings, documentación, portfolios.
    • Catálogos que no necesitan carrito.
    • Proyectos donde el SEO y la velocidad de carga son el objetivo principal.
    • Frontends que consumen una API propia y son mayormente de lectura.

    No, o con reservas:

    • Aplicaciones con mucho estado compartido entre pantallas.
    • Sitios donde el cliente necesita autonomía total de edición y no querés sumar un CMS.
    • E-commerce complejo con stock en tiempo real, variantes y checkout propio: es posible, pero WooCommerce o Shopify te ahorran meses.

    En resumen

    Astro no compite por ser el framework más potente, sino por ser el más proporcionado a lo que la mayoría de los sitios necesita. La pregunta que resuelve es simple: si la página es contenido que se lee, ¿por qué le estás mandando al visitante un runtime completo de JavaScript?

    Para un desarrollador que ya trabaja con React o con WordPress, la inversión de aprenderlo es baja y el retorno se nota en la primera medición de PageSpeed. Vale la pena tenerlo en el toolkit aunque no sea la herramienta de todos los proyectos.

  • Tailwind CSS o CSS tradicional: la discusión mal planteada

    Qué está en discusión (y qué no)

    Conviene aclararlo de entrada: Tailwind es CSS. No reemplaza al lenguaje ni te exime de entenderlo. Si no sabés cómo funciona flexbox, flex gap-4 items-center te va a fallar igual que display: flex. Lo que cambia es dónde escribís los estilos y cómo los organizás.

    En el enfoque tradicional escribís reglas en un archivo .css o .scss y las aplicás mediante clases semánticas: .card, .card__title, .btn--primary. En el enfoque utility-first componés el diseño directamente en el marcado con clases atómicas de propósito único: rounded-lg, p-6, text-sm.

    La discusión real no es «cuál es mejor», sino qué problema estás tratando de resolver.

    El problema que Tailwind vino a resolver

    Cualquiera que mantuvo un CSS grande conoce estos síntomas:

    • Nadie borra nada. Ante la duda de si .header-old-v2 se sigue usando, se deja. El archivo solo crece.
    • La especificidad se descontrola. Aparece el primer !important y ya no hay vuelta atrás.
    • Nombrar cuesta más que estilar. Metodologías como BEM existen justamente porque poner nombres consistentes a nivel equipo es difícil.
    • Todo es global. Tocás una regla para arreglar una sección y rompés otra que no estabas mirando.

    Tailwind ataca esos cuatro puntos de raíz. Las clases utilitarias son de alcance local por definición, no hay que inventar nombres, la especificidad es plana y el CSS no crece de forma indefinida: siempre son las mismas utilidades reutilizadas.

    Lo que se pierde en el camino

    Tampoco es gratis:

    El marcado se vuelve ruidoso. Un botón puede terminar con quince clases. Es legible cuando lo escribiste vos, menos cuando abrís un archivo ajeno seis meses después.

    Hay curva de aprendizaje. Aunque sea CSS, hay que memorizar la nomenclatura. mt-4 es margin-top: 1rem, pero eso hay que saberlo.

    Requiere build. Tailwind necesita un paso de compilación. En un entorno donde solo podés subir archivos por FTP a un hosting compartido, eso complica cosas.

    Duplicación en el HTML. Si repetís la misma combinación de veinte clases en diez lugares y no estás trabajando con componentes, cambiar el diseño implica editar diez veces. Tailwind asume que tenés componentes (React, Vue, partials de Blade, bloques de WordPress). Sin esa capa, el argumento se debilita bastante.

    Qué cambió con Tailwind 4

    Vale mencionarlo porque modifica varias objeciones históricas. La versión 4 movió la configuración al propio CSS: en lugar de un tailwind.config.js, se define el sistema de diseño con @theme directamente en la hoja de estilos.

    css

    @import "tailwindcss";
    
    @theme {
      --color-marca: #e5662f;
      --font-display: "Sora", sans-serif;
      --radius-card: 12px;
    }

    Esas variables quedan disponibles como utilidades (bg-marca, font-display) y también como custom properties nativas de CSS, así que se pueden usar en CSS común dentro del mismo proyecto. La frontera entre «usar Tailwind» y «usar CSS» se volvió mucho más porosa. Además el motor nuevo compila bastante más rápido y la detección de clases ya no requiere configurar rutas a mano.

    Comparación práctica

    CriterioCSS tradicionalTailwind
    Velocidad al prototiparMediaAlta
    Curva inicialBajaMedia
    Escalabilidad en equipoDepende de la disciplinaAlta por defecto
    Peso finalCrece con el proyectoEstable
    Legibilidad del marcadoAltaMedia
    Legibilidad de los estilosMediaAlta
    Necesita buildNoSí
    Consistencia del diseñoRequiere convenciónForzada por el sistema

    Cuándo elegir cada uno

    Elegí CSS tradicional cuando:

    • El proyecto es chico y no justifica una toolchain.
    • Trabajás sobre un tema de WordPress clásico sin build, o retocás estilos de un maquetador visual como Elementor.
    • Necesitás animaciones complejas, @supports, selectores muy específicos o control fino que en utilidades se vuelve incómodo.
    • El sitio lo va a mantener alguien que no conoce Tailwind y no va a aprenderlo.

    Elegí Tailwind cuando:

    • Trabajás con componentes: React, Vue, Astro, Livewire, bloques nativos.
    • El proyecto va a crecer y lo van a tocar varias personas.
    • Querés un sistema de diseño consistente sin escribir la documentación de tokens a mano.
    • Estás iterando diseño rápido y necesitás ver cambios sin saltar entre archivos.

    La opción que casi nadie menciona: las dos

    En la práctica, los proyectos que mejor envejecen usan un híbrido. Tailwind para el layout, el espaciado y las variantes de estado, y CSS propio para lo que las utilidades hacen incómodo: keyframes, estilos de contenido generado por un editor, resets específicos, o esos tres componentes que se repiten en todo el sitio y merecen su propia clase.

    Tailwind incluso lo contempla con @apply, aunque conviene usarlo con moderación: abusar de @apply es reconstruir el CSS tradicional con pasos extra.

    En resumen

    CSS tradicional te da libertad total y te cobra en disciplina. Tailwind te quita algo de libertad y te devuelve consistencia y velocidad. Ninguna de las dos cosas es universalmente mejor, y la mayoría de las discusiones online se producen porque cada uno está pensando en un proyecto de escala distinta.

    La pregunta útil no es cuál está de moda, sino: ¿este proyecto tiene componentes?, ¿lo va a tocar más gente?, ¿va a vivir tres años? Si respondés que sí a las tres, Tailwind te va a ahorrar trabajo. Si respondés que no, el archivo .css de siempre sigue siendo una decisión perfectamente profesional.

  • Tu sitio WordPress no está roto: está desatendido

    El problema no suele ser WordPress

    Cuando un cliente me dice «mi página anda lenta», la primera reacción es culpar a la plataforma. Pero WordPress mueve cerca del 40% de la web y no es lento por naturaleza: se vuelve lento por acumulación. Cada plugin que se instaló «para probar» y quedó activo, cada imagen de 4 MB subida directo desde el celular, cada actualización que se pateó para adelante por miedo a romper algo, suma peso.

    La buena noticia es que casi todo eso se revierte. La mala es que si nadie lo revisa, el deterioro es constante.

    Seis señales de que tu sitio necesita mantenimiento

    1. Tarda más de tres segundos en cargar

    Es el número que importa. Después de ese umbral, la tasa de rebote se dispara y Google lo registra en las Core Web Vitals. Probalo en PageSpeed Insights con tu celular y datos móviles, no con la fibra de la oficina.

    Qué hacer: empezá por las imágenes. En la mayoría de los sitios que audito, entre el 60% y el 80% del peso total de una página son imágenes sin comprimir. Convertirlas a WebP y servirlas en el tamaño real que se muestran suele bajar el tiempo de carga a la mitad sin tocar una línea de código.

    2. Tenés más de 20 plugins activos

    No hay un número mágico, pero cada plugin carga sus propios CSS y JavaScript en todas las páginas, incluso donde no se usa. Un plugin de formularios que solo hace falta en «Contacto» está cargando en la home, en el blog y en cada ficha de producto.

    Qué hacer: auditá la lista. Desactivá lo que no reconozcas, eliminá lo que no uses (desactivado sigue ocupando espacio y sigue siendo una puerta de entrada) y buscá superposiciones: es común encontrar dos plugins de caché peleándose o tres soluciones de SEO instaladas.

    3. El panel te muestra actualizaciones pendientes hace meses

    Acá hay un equilibrio real. Actualizar a ciegas puede romper el diseño; no actualizar nunca te deja expuesto. La enorme mayoría de los sitios WordPress hackeados no cayeron por un ataque sofisticado, sino por una vulnerabilidad conocida en un plugin desactualizado con parche disponible.

    Qué hacer: entorno de staging, backup previo, actualizar, revisar, publicar. Si no tenés staging, al menos backup completo antes de tocar nada. Y actualizá de a poco: primero plugins críticos, después el resto.

    4. No sabés cuándo fue el último backup

    Si la respuesta es «creo que el hosting hace uno», no tenés backup. Tenés una esperanza. Muchos planes de hosting compartido guardan copias de siete días y las sobrescriben, así que si el problema apareció hace diez, ya no hay a dónde volver.

    Qué hacer: backups automáticos de archivos y base de datos, con copia fuera del servidor (Drive, Dropbox, S3). Y probá una restauración al menos una vez. Un backup que nunca restauraste es un backup que no sabés si funciona.

    5. La base de datos nunca se limpió

    Cada vez que guardás una entrada, WordPress crea una revisión. Un sitio con tres años de vida puede tener miles de revisiones, transients vencidos, comentarios spam y tablas huérfanas de plugins que borraste. Nada de eso se ve, pero todo pesa en cada consulta.

    Qué hacer: limitá las revisiones desde wp-config.php, limpiá transients y spam periódicamente y optimizá las tablas. Es trabajo de media hora que se nota en el tiempo de respuesta del servidor.

    6. En el celular se ve distinto a como lo diseñaste

    Más de dos tercios del tráfico de un sitio pyme en Argentina llega desde el teléfono. Si el menú se superpone, los botones quedan chicos para el dedo o hay scroll horizontal, estás perdiendo consultas todos los días sin enterarte.

    Qué hacer: revisá el sitio en un dispositivo real, no solo en el modo responsive del navegador. Prestá atención a los formularios y al checkout si vendés online: es donde más plata se cae.

    Un plan mínimo de mantenimiento

    No hace falta un contrato grande para tener el sitio sano. Un esquema realista para una pyme:

    • Semanal: backup automático verificado y revisión rápida de que todo cargue.
    • Mensual: actualizaciones de core, plugins y tema en staging; limpieza de spam y transients.
    • Trimestral: auditoría de rendimiento con PageSpeed, revisión de enlaces rotos y control de plugins que dejaron de tener soporte.
    • Anual: revisión del hosting, del plan contratado y de si el stack sigue siendo el adecuado para lo que el negocio necesita hoy.

    Lo que realmente estás cuidando

    Un sitio lento o caído no es un problema técnico, es un problema comercial. Es el cliente que buscó tu producto, entró, esperó y se fue a la competencia. El mantenimiento no es un gasto que se agrega al desarrollo: es lo que hace que la inversión del desarrollo siga rindiendo dos años después.

    Si hace más de seis meses que nadie mira tu WordPress, empezá por lo más barato: medí la velocidad, contá los plugins y confirmá que existe un backup reciente. Con esas tres respuestas ya sabés en qué estado estás.