Countdown para TYPO3

Las extensiones de cuenta regresiva resuelven un problema de comunicación que el texto plano no resuelve

Cuando una feria empieza en 23 días, cuando la oferta de madrugador vence a medianoche o cuando la nueva tienda sale en vivo el 1 de mayo, una frase como “quedan pocos días” no basta. Los usuarios reaccionan con mucha más fuerza a relojes que tictaquean que a fechas estáticas, y en una página TYPO3 la variante más sencilla es incrustar un temporizador visible. Varias extensiones TYPO3 del TER ofrecen esa funcionalidad; la más conocida se llama simplemente “countdown”. Para cualquier sitio corporativo con anuncios de eventos, lanzamientos de producto o acciones limitadas, ese es un requisito recurrente que sin extensión suele acabar en JavaScript hecho a medida. La elección entre extensión y solución propia pocas veces depende de la técnica, sino de quién debe poder mantener el contador desde la redacción.

Escenarios típicos: de ferias a acciones de comercio electrónico

El primer escenario son ferias y congresos. Una asociación anuncia su jornada anual con seis meses de antelación y quiere hacer visible el tiempo restante, idealmente con días, horas, minutos y segundos. El contador corre en la landing page, cambia de registro en las últimas 24 horas y desaparece automáticamente tras el cierre del evento, sin que un redactor tenga que retocar la página. Eso no solo ahorra mantenimiento, sino que evita situaciones embarazosas como un contador que sigue mostrando un valor negativo después del evento.

Un segundo escenario son los lanzamientos de producto y las ventanas de reserva. Proyectos de comercio electrónico basados en aimeos o en tiendas externas utilizan countdowns en landing pages para fijar a los clientes la fecha de inicio. En las reservas anticipadas el countdown actúa como señal de urgencia y eleva de forma demostrable la conversión.

Un tercer escenario son los plazos de candidatura y solicitud. Las universidades muestran en la página de admisión un countdown hasta el cierre, las asociaciones lo usan para precios de madrugador, las instituciones públicas para plazos de presentación a licitaciones públicas. Aquí no se trata de marketing, sino de servicio: los visitantes deben reconocer de un vistazo cuánto tiempo les queda. Para portales de solicitud del ámbito científico eso es prácticamente estándar, porque las convocatorias de ayudas trabajan con plazos fijos y una hora de corte estricta.

Arquitectura técnica: combinación de plantilla Fluid y JavaScript mínimo

Las extensiones de countdown clásicas en TYPO3 constan de dos partes. La parte backend es un elemento de contenido o plugin en el que el redactor mantiene la fecha y hora objetivo, la zona horaria, la etiqueta y, opcionalmente, un mensaje final. La parte frontend renderiza esos datos en una plantilla Fluid y engancha un pequeño JavaScript que calcula la diferencia con el momento actual y la actualiza en el DOM.

La mayoría de las extensiones traen además una configuración para el renderizado: número de posiciones (días, horas, minutos, segundos), representación como gráfico circular o como flip clock, colores y animación. El JavaScript corre típicamente con un setInterval de 1000 ms y calcula del lado del cliente, de modo que el caché del servidor queda intacto. Es importante que el contador no termine en un valor negativo, sino que mediante un evento muestre un mensaje de “evento iniciado” u “oferta caducada”.

Para proyectos sensibles al RGPD merece la pena revisar las dependencias JavaScript. Algunas extensiones cargan jQuery o MomentJS, lo que provoca un render path adicional. Las variantes modernas se conforman con unas pocas líneas de JS vanilla y un CSS Grid que funciona también sin extensión.

Problemas frecuentes: zonas horarias, caché y SEO

El tema de soporte más habitual es la zona horaria. El redactor introduce una fecha en el backend, el servidor está en UTC, el visitante vive en hora de Madrid, y el countdown muestra una hora de más. La extensión debe distinguir limpiamente entre hora del servidor, hora editorial del backend y hora del navegador. Recomendamos siempre pasar la fecha objetivo en ISO-8601 con zona horaria explícita (“2026-05-01T12:00:00+02:00”) al JavaScript.

El segundo problema es el Page Cache. Cuando la página HTML renderizada está cacheada durante una hora, el countdown no puede contener un “23 días 7 horas” calculado en el servidor, porque el cache hit congela ese valor. La solución: la parte Fluid solo renderiza la fecha objetivo como atributo data, y el cálculo de la diferencia corre exclusivamente en el navegador.

En tercer lugar, el SEO es un punto. Un countdown puramente JavaScript no muestra a Google ni la fecha objetivo ni el motivo. Para los buscadores corresponde incluir un schema:Event JSON-LD en la página, con startDate, endDate y name, para que los resultados de Google muestren el evento como rich snippet. Quien instala la extensión debería, por tanto, no solo pasar la fecha objetivo al temporizador, sino escribirla adicionalmente como datos estructurados en la cabecera de la página. Sin ese marcado el countdown queda invisible para Google y pierde su efecto de marketing ya en el resultado de búsqueda.

TYPO3 v12 y v13: extensión o construcción alternativa ligera

Si una extensión de countdown todavía tiene sentido en TYPO3 v12 y v13 depende del alcance del proyecto. Para una única página de evento basta un pequeño elemento de contenido con un atributo data y 30 líneas de JavaScript, completamente sin sobrecarga de extensión. Para redacciones con muchos eventos que quieren mantener el temporizador ellos mismos con regularidad, la extensión se justifica porque los redactores necesitan un elemento de interfaz conocido en el backend.

Gosign construye en la práctica ambas cosas: para lanzamientos puntuales entregamos un elemento de contenido ligero sin extensión, que consta solo de una plantilla Fluid y un mini JS. Para casos recurrentes integramos una extensión mantenida y sobrescribimos la plantilla Fluid para adaptar el diseño al resto del proyecto. Al actualizar extensiones countdown antiguas, casi siempre tiene sentido el cambio a la variante vanilla, porque las versiones antiguas basadas en jQuery no pueden seguir el ritmo ni en TYPO3 v12 ni en los presupuestos de rendimiento modernos.