Usar JavaScript para menús, botones, formularios o avisos que HTML y CSS resuelven añade peso y puntos de fallo innecesarios en una tienda online.
Revisa el código que afecta a la compra móvil
Revisa ficha de producto, carrito y pago en móvil para localizar esperas que pueden costar ventas. Prioriza la ruta de compra: Google considera bueno un LCP de hasta 2,5 segundos, pero también importa que los botones respondan rápido y que la página no salte mientras carga.
Mide las páginas que venden
Abre PageSpeed Insights y revisa una ficha de producto, el carrito y el checkout, empezando por los datos reales de usuarios cuando estén disponibles. Prueba las mismas URLs con Wi‑Fi y datos móviles, sin iniciar sesión, y anota LCP, retrasos al pulsar y movimientos del botón de compra.
Identifica scripts sin retorno
Carga la ficha en una ventana privada y observa si aparecen antes el chat, un mapa o un carrusel que la foto y el botón de compra. Cada píxel, herramienta de pruebas o plugin debe justificar su impacto en ventas, soporte o medición.
Para una revisión inicial, separa los elementos en tres grupos: imprescindibles para cobrar, necesarios para medir ventas y prescindibles hasta demostrar su utilidad. Esta lista evita discutir sobre gustos visuales.
El rendimiento web no depende solo del LCP. Los Core Web Vitals también incluyen INP, que mide la rapidez con la que la página responde a una interacción, y CLS, que refleja si los elementos se desplazan de forma inesperada durante la carga. En una tienda online, un INP alto puede hacer que parezca que el selector de talla o el botón de añadir al carrito no funciona, mientras que un CLS elevado puede mover el botón de compra justo cuando la persona va a pulsarlo.
Revisa estas tres métricas en PageSpeed Insights y Search Console con datos reales de usuarios, y prioriza la URL o plantilla que concentre más tráfico y más conversiones.
Usa HTML semántico para cada acción y bloque
Usa etiquetas que describan cada parte de la página para mejorar comprensión, accesibilidad y mantenimiento. Un button ejecuta una acción, un enlace a lleva a otra URL y un div solo agrupa contenido; no deben intercambiarse por motivos visuales.
Prueba Tab, Enter y Espacio desde el teclado: el foco debe llegar al menú, variantes, compra y formulario, y debe verse siempre. Cada campo necesita una etiqueta visible, y el servidor debe validar los datos aunque el navegador ya compruebe los campos obligatorios.
Ordena títulos y zonas de página
Mantén un H1 para nombrar la página y emplea H2 y H3 para organizar sus bloques, sin elegir encabezados por tamaño. Usa header, nav, main y footer cuando correspondan; ARIA complementa controles complejos, pero no corrige HTML mal elegido.
La accesibilidad web exige que los formularios comuniquen con claridad qué debe hacer la persona y qué ha fallado. Además de asociar cada campo con una etiqueta visible, agrupa opciones relacionadas, como método de envío o talla, mediante fieldset y legend; indica los campos obligatorios sin depender solo del color; y muestra los errores cerca del campo correspondiente con un texto comprensible. Los botones nativos, creados con button, conservan por defecto foco, navegación por teclado y activación con Enter o Espacio.
Si un formulario falla, el foco debe llevar a la primera incidencia y el mensaje debe explicar cómo corregirla, por ejemplo: «Introduce un código postal de cinco cifras».
Deja que CSS haga su trabajo antes de usar scripts
Resuelve con CSS los cambios visuales y reserva JavaScript para interacciones que realmente requieran datos o comportamiento dinámico. La mejora progresiva permite que el contenido, los enlaces y las acciones básicas sigan funcionando aunque un script tarde, falle o esté bloqueado.
Aplica CSS mobile-first
Pide estilos pensados primero para móvil y ampliados después para pantallas mayores. Define variables CSS para colores, tamaños y espaciados repetidos; además, fija ancho y alto de las imágenes para evitar saltos y aplica carga diferida solo a las que quedan fuera del primer pantallazo.
Orden de decisión para cada función de la tienda
1. HTML
¿Hay un elemento nativo?
Enlace, botón o formulario.
2. CSS
¿Solo cambia el aspecto?
Color, tamaño, orden o respuesta móvil.
3. JavaScript
¿Requiere datos o una acción dinámica?
Carrito, filtro o autocompletado.
Justifica cada script añadido
Pide una lista con nombre, función, página donde carga y resultado esperado de cada script. JavaScript tiene sentido para actualizar el carrito, filtrar muchos productos o mostrar disponibilidad en tiempo real, siempre que no bloquee la compra básica.
| Función | Primera opción | Impacto esperado | Señal de alarma |
|---|
| Ir a una categoría | Enlace HTML | Carga inmediata | Solo responde al clic |
| Enviar contacto | Formulario HTML | Mejor uso con teclado | Campos sin etiqueta |
| Cambiar color del botón | CSS | Sin descarga extra | Script para un efecto visual |
| Actualizar carrito | JavaScript | Respuesta ágil | No funciona si falla el script |
La optimización web también requiere decidir cuándo se descarga cada recurso. Los scripts que no son necesarios para pintar la ficha inicial, como un chat, un mapa, recomendaciones o herramientas de prueba, pueden cargarse después de la interacción o solo en las páginas donde aportan valor. Para archivos propios que no modifican el HTML mientras se analiza, defer evita bloquear el renderizado y conserva el orden de ejecución; los módulos JavaScript también se cargan de forma diferida por defecto.
Conviene comprobar en el panel de red del navegador qué archivos se descargan antes de que aparezca el contenido principal y eliminar duplicados, bibliotecas sin uso y etiquetas de terceros que retrasen la experiencia móvil.
Aclara confusiones antes de aprobar cambios
Separa los problemas técnicos de los comerciales para no pagar cambios que no atacan la causa de una venta perdida. Una oferta confusa, fotos pobres, costes ocultos o tráfico mal segmentado no se arreglan solo con código; compara siempre el mismo recorrido antes y después de cada cambio.
Mejorar HTML, CSS y JavaScript no basta si el problema principal es una oferta poco clara, fotos deficientes, precios poco competitivos, tráfico mal segmentado o un checkout limitado por la plataforma. Tampoco conviene tocar código de producción sin copia de seguridad, pruebas y una persona responsable de validar el cobro, las cookies y los formularios.
Dudas habituales
¿Hay que eliminar todo JavaScript?
No, debe quedarse cuando mejora una tarea real, como actualizar un carrito o filtrar productos.
¿Un tema de WordPress garantiza velocidad?
No, imágenes grandes, plugins y scripts externos pueden volver lento cualquier tema.
¿ARIA arregla una web inaccesible?
No, primero usa HTML semántico y añade ARIA solo si un control complejo lo necesita.
¿Qué páginas debo probar primero?
Ficha de producto, carrito, checkout y formulario de contacto.
¿Qué es un LCP bueno para una tienda?
Un LCP bueno es de 2,5 segundos o menos en datos reales de usuarios.
¿La carga diferida sirve para todas las imágenes?
No, úsala en imágenes fuera del primer pantallazo, no en la foto principal.
¿Qué debo pedir a una agencia por escrito?
Lista de scripts, pruebas móviles, resultados antes y después y responsable de validar pagos.
Convierte esta revisión en un plan de cambios
Empieza por la ruta de compra y deja los efectos decorativos para el final. Una web mantenible permite actualizar campañas y promociones sin romper el carrito, los formularios ni el pago.
- Lo esencial: mide primero producto, carrito y pago desde un móvil real.
- Lo esencial: usa HTML para significado, CSS para apariencia y JavaScript para interacción necesaria.
- Lo esencial: conserva solo los scripts que justifican su coste en carga, soporte o ventas.
- Lo esencial: prueba cada cambio antes de publicar y comprueba que se puede comprar.
