Sitio Web Corporativo: centrum-csr.com

#centrum-csr.com, tu centro de conocimiento sobre responsabilidad social corporativa

Un formulario de contacto es, en un sitio temático, la pieza que más trabajo da y la que menos atención recibe en las presentaciones de proyecto. En centrum-csr.com no recoge pedidos: recoge solicitudes de consultoría, peticiones de materiales y mensajes de organizaciones que quieren mostrar su propia práctica. Los mensajes son largos y quien escribe espera una respuesta, no un justificante.

El sitio se dedica a la responsabilidad social corporativa y al desarrollo sostenible, y está dirigido a empresas, organizaciones no gubernamentales y a cualquiera que implante estas prácticas en su propia organización. Entró en producción en 2012 sobre WordPress, con Redis como caché de objetos y una capa REST API, con la interfaz construida en HTML5, CSS3 y SASS y los archivos multimedia servidos a través de una CDN. La implementación llevó alrededor de seis semanas y el cliente entregó la maquetación y la disposición de los elementos.

#Lo que hay que resolver en un formulario público

Hay tres asuntos técnicos, y ninguno es cosmético. El primero es la entregabilidad: el correo que envía el propio servidor del sitio con la dirección del visitante en el campo de remitente acaba en la carpeta de correo no deseado mucho más a menudo de lo que se supone, así que la dirección de envío debe pertenecer al dominio del sitio y la del visitante debe ir en el campo de respuesta.

El segundo es el correo basura. Cualquier formulario accesible públicamente es descubierto por tráfico automatizado en cuestión de semanas desde el lanzamiento, de modo que el filtrado y la limitación de frecuencia no son un refinamiento sino la condición para que el buzón siga siendo legible.

El tercero es la longitud de los campos. Cortar el cuerpo del mensaje en un límite de caracteres es el tipo de defecto que solo aparece cuando alguien ha descrito su situación en tres párrafos y han llegado dos. Es barato de evitar antes de salir a producción y caro de descubrir después, porque nadie vuelve a escribir para avisar de que su mensaje llegó truncado.

#Conocimiento y actualidad envejecen a ritmos distintos

La decisión editorial más importante fue separar la base de conocimiento del flujo de actualidad. Se parecen, porque ambos son texto con título y fecha, y se comportan de forma distinta en todo lo que importa.

Una noticia vale una semana, merece estar en portada y no necesita volver. Una guía de la base de conocimiento vale exactamente lo que valga su exactitud dos años después: necesita revisión, una fecha visible de última comprobación y un lugar en la estructura que no dependa de cuándo se publicó. En la práctica, el material duradero recibe sus propias categorías temáticas, como ecología o ética empresarial, y sus propias plantillas, mientras que la actualidad sigue siendo un flujo.

El precio es disciplina editorial. Alguien tiene que decidir en qué cajón entra cada texto, y esa decisión no se automatiza, porque el mismo material puede escribirse como nota de un acto o como introducción a un tema. La ganancia aparece años después, cuando una revisión afecta a veinte guías y no a doscientas entradas de las que la mayoría ya es historia.

La misma lógica sostiene la sección con ejemplos de implantaciones. No es decoración, sino un conjunto de casos al que se remite desde los textos de fondo. Para que se pueda mantener, cada caso necesita sus campos propios en lugar de ser otro párrafo con una fotografía pegada.

#Quién lee y qué se deduce de ello

El público nunca fue el público general: eran responsables de empresa, personal de recursos humanos y de marketing, especialistas en sostenibilidad y consultores. Llegan con una pregunta concreta y poca paciencia, y quieren saber qué exige un estándar, cómo se informa habitualmente de una iniciativa y qué han hecho realmente organizaciones comparables.

Ese perfil condiciona toda la construcción. El lector llega desde un resultado de búsqueda o desde un boletín, aterriza en el interior del archivo y no en la portada, y decide en la primera pantalla. Por eso las páginas profundas tienen que sostenerse solas, la navegación tiene que funcionar de dentro hacia fuera y la fecha de publicación tiene que verse, porque en esta materia un documento sin fecha es un documento que nadie puede citar.

#Carga asíncrona, API y el límite que conviene conocer

El sitio carga contenido de forma asíncrona: las listas y las secciones incorporan más entradas sin recargar la página entera. Con una base amplia de artículos e informes eso es una comodidad real, porque el lector recorre la lista, la acota y no paga cada vez el coste completo de construir una página.

Existe un único límite y conviene conocerlo antes de la implementación. El contenido que solo existe después de ejecutar un script no existe para una parte del público: en el caso benigno para un rastreador, en el grave para un lector de pantalla. Por eso cada artículo y cada informe tiene su propia dirección y su texto completo en un documento HTML normal, y la capa asíncrona se limita a acelerar la navegación por los listados.

La REST API cumple aquí la misma función que un endpoint bien recortado en cualquier otro proyecto: devuelve exactamente los datos necesarios para dibujar una parte de la interfaz. Si el listado pidiera las entradas completas, cada carga adicional arrastraría todo el cuerpo del texto para mostrar un título, una categoría y dos líneas de entradilla. La respuesta más pequeña no solo es más rápida, también se comporta mejor en caché, porque ese recurso cambia con mucha menos frecuencia que el texto del artículo.

#Rendimiento y a quién ayuda realmente la caché

Redis se ocupa de la caché de objetos. Una página de WordPress se arma con muchas lecturas pequeñas: opciones, metadatos, relaciones de taxonomía. En una vista de listado con categorías, etiquetas y entradillas, el número de esas lecturas crece más deprisa de lo que sugiere la cantidad de elementos visibles.

La pregunta interesante es a quién ayuda esa caché. La caché de página completa atiende al lector anónimo y, desde su lado, zanja el asunto. No hace nada por un editor autenticado, por las vistas con parámetros ni por las respuestas de la API, que es justo donde trabaja el equipo que publica. Un sitio rápido para quien lee y lento en el panel desanima a publicar, y eso cuesta más que unos cientos de milisegundos en la portada.

Los archivos multimedia, las fotografías, las infografías y el material en vídeo sobre las iniciativas, se entregan por CDN. El motivo es prosaico: son los archivos más grandes del sitio y servirlos desde el servidor de aplicación consume capacidad que conviene dejar para generar páginas.

Las mediciones se hicieron sobre una copia de producción y no sobre una instalación limpia. Un WordPress vacío responde rápido siempre, porque no hay nada que recorrer. Solo una base con el conjunto completo de artículos, informes, relaciones de categoría e historial de comentarios muestra qué consulta recorre media tabla.

#La interfaz es donde se acumula la deuda

La capa visual se escribió en HTML5, CSS3 y SASS. SASS fue una decisión de mantenimiento y no estética: mantiene colores, espaciados y puntos de ruptura en un solo lugar en vez de repartidos por las hojas de estilo, lo que en un sitio que se amplía durante años es la diferencia entre un cambio de quince minutos y una tarde leyendo CSS.

Conviene decirlo sin rodeos: esta capa envejece más rápido que ninguna otra parte del proyecto. Las convenciones de diseño adaptable de 2012 y las rejillas sobre las que entonces se montaban los diseños son hoy exactamente lo que una reconstrucción seria sustituye por completo. El modelo de contenido y la forma de entregar datos por la API han aguantado bastante mejor. Esa observación se traslada a cualquier proyecto nuevo: el dinero invertido en la estructura de datos trabaja más tiempo que el invertido en la presentación.

El trabajo para buscadores consistió en marcado semántico, metadatos ordenados, direcciones legibles, datos estructurados de schema.org y un mapa del sitio en XML. El propósito es acotado: describirle a una máquina lo que una persona lee de la disposición. Los datos estructurados no ponen un texto flojo por delante de uno bueno; evitan que uno bueno pase inadvertido porque el rastreador no supo qué tipo de página tenía delante. No dispongo de mediciones del efecto que pueda citar con honestidad, así que no cito ninguna.

#Soporte y mantenimiento del sitio

El acompañamiento cubre actualizaciones del núcleo, el tema y los plugins, revisión de registros, copias de seguridad y cambios funcionales o visuales menores. Las actualizaciones se prueban sobre una copia, porque un proyecto con plantillas propias, integración de API y formularios públicos tiene varios puntos donde un cambio en un plugin altera el comportamiento sin emitir ningún error: desaparece un filtro del que dependía una vista, una consulta se arma de otra forma, el envío del formulario se detiene en silencio.

Una copia de seguridad es un procedimiento de restauración y no un archivo en un disco. Vale la que ya ha servido para levantar una versión funcional del sitio, anotando cuánto tiempo llevó.

#Resumen

En centrum-csr.com el contenido de fondo es el producto y la tecnología existe para mantenerlo legible durante años. Lo que decidió su forma es invisible desde fuera: la base de conocimiento separada del flujo de noticias, la carga asíncrona entendida como aceleración y no como única vía al texto, una caché de objetos ajustada al trabajo de quien publica, y una estructura de datos mantenida aparte de una presentación que iba a envejecer primero.

Lo que pasa al siguiente encargo es la capa técnica y el método: WordPress, Redis, REST API, CDN y medición contra una copia de producción. Lo que no pasa es el modelo de contenido de este sitio ni sus integraciones, escritos para un material y una rutina editorial concretos. Un proyecto nuevo empieza por revisar el alcance, y el presupuesto viene después.