Por qué empiezo por la parte frontal
Cuando empiezas una web puedes ir a lo rápido y montar páginas sueltas, o puedes construir primero una base sólida para todo. En iCrafters me quedo con la segunda opción. Arranco por el frontend y dejo claro el estilo, los componentes y cómo debe rendir el sitio. Eso trae calma al diseño, menos mantenimiento y una experiencia más ágil.
Un estilo claro que funciona en todas las páginas
Lo primero fue un marco de estilo sencillo. Sin manuales eternos. Definí tamaños de texto, jerarquía de titulares, espacios, botones, tarjetas y cómo se ven los estados interactivos. Con eso ya puedes maquetar cualquier página sin inventar reglas nuevas. A partir de ahí monté piezas reutilizables: héroes con titular y CTA, tarjetas para servicios, listas, pestañas para procesos y secciones de “cómo trabajamos”. Si repites bien estas piezas, todo se siente coherente aunque el contenido cambie.
Tailwind bien organizado, sin ruido
En código uso Tailwind con disciplina. Un input.css limpio, sin comentarios innecesarios, reglas en una sola línea y sin clases fantasmas. Cada sección tiene su propio “scope” para que los estilos no se escapen. Cuando aparece HTML heredado de builders, aplico los estilos desde el contenedor y organizo el resto con selectores anidados. Resultado: marcado limpio y fácil de mantener.
Velocidad primero: WebP, tamaños correctos y lazy loading
El rendimiento no es un extra, es un requisito. Las imágenes van en WebP, con dimensiones definidas y lazy loading cuando procede. El simple hecho de pasar imágenes pesadas a WebP ya marca la diferencia. En nuestro caso, un hero pasó a rondar los 0,2 MB, que es perfectamente asumible si el resto también está optimizado. Evito librerías de JavaScript cuando lo mismo se puede lograr con HTML o CSS. Esto ayuda a que LCP y CLS se mantengan estables y que la interacción sea fluida.
Accesibilidad que se nota al navegar
La accesibilidad la integro desde el principio. Los titulares siguen un orden lógico, los enlaces tienen estados claros, el contraste de color se revisa y los formularios tienen etiquetas entendibles para lectores de pantalla. No es algo que “se vea” a simple vista, pero se nota al usar la web y también en SEO.
Responsive sin romper nada
El responsive lo pruebo en varios tamaños reales. En español y neerlandés los titulares pueden ser largos, así que dejo aire y una altura de línea cómoda para que no se rompan mal. Las imágenes recortan bien en móvil, los botones siguen siendo fáciles de pulsar y las tarjetas mantienen ritmo y proporción. Nada de efectos raros cuando cambias de dispositivo.
Interacciones sutiles, nada que distraiga
La animación está para ayudar, no para distraer. Una sombra suave al pasar por una tarjeta, una transición corta en los botones, una pequeña aparición al cambiar de pestaña. Sin artificios que pesen. La sensación que busco es de rapidez y fiabilidad, no de espectáculo.
Listo para WordPress y para crecer
La ventaja de este planteamiento es que luego todo encaja en WordPress sin sobresaltos. Cada componente ya tiene una estructura HTML clara, así que puedo convertirlo en bloque de Gutenberg sin peleas. En el siguiente artículo cuento cómo quedó el tema y los bloques. Si te interesa solo esta capa visual, echa un vistazo a Desarrollo Frontend y, si te preocupa el rendimiento, a Optimización de velocidad web. Para mantener la web afinada con el tiempo, la ruta natural es Mantenimiento WordPress. Y si quieres amarrarlo todo en un solo proyecto, lo tuyo es un Tema WordPress a medida.
La idea es simple. Un frontend bien hecho te ahorra tiempo en cada cambio, acelera la web y evita sorpresas. Inviertes una vez en la base y luego todo va más rápido.