Website corporativo: centrum-csr.com

#Portal WordPress sobre responsabilidade social das empresas

O centrum-csr.com é um portal sobre responsabilidade social das empresas e desenvolvimento sustentável, dirigido a empresas, organizações não governamentais e a quem introduz estas práticas na própria organização. Entrou em produção em 2012, assenta em WordPress com Redis como cache de objetos e uma camada REST API, a interface foi feita em HTML5, CSS3 e SASS, e os ficheiros multimédia são servidos por CDN. A implementação demorou cerca de seis semanas e o cliente entregou a maquete e a disposição dos elementos.

#Como a cache de objetos Redis acelera o WordPress para editores

Há uma ideia arrumada sobre desempenho em WordPress que resolve metade do problema e deixa a outra metade intacta. A cache de página completa serve o leitor anónimo: a página é montada uma vez e devolvida muitas. Do lado de quem lê, o assunto fica fechado.

Não faz nada por um editor autenticado, por vistas com parâmetros nem por respostas de API, e é exatamente aí que a redação passa o dia. Um site rápido para quem lê e lento no painel desmotiva a publicação, e num portal cujo produto é o texto isso custa mais do que algumas centenas de milissegundos na página inicial.

Por isso a camada que interessa aqui é a cache de objetos em Redis. Uma página WordPress é montada a partir de muitas leituras pequenas: opções, metadados, relações de taxonomia. Numa vista de listagem com categorias, etiquetas e resumos, o número dessas leituras cresce mais depressa do que a quantidade de elementos visíveis sugere. Com os resultados guardados fora da base de dados, o pedido seguinte não repete o mesmo trabalho, e beneficiam disso precisamente os pedidos que a cache de página nunca cobre.

Os ficheiros multimédia, fotografias, infografias e vídeo sobre as iniciativas, seguem por CDN. A razão é prosaica: são os maiores ficheiros do projeto e servi-los a partir do servidor aplicacional ocupa capacidade que faz falta para gerar páginas.

As medições foram feitas contra uma cópia de produção e não contra uma instalação limpa. Um WordPress vazio responde sempre depressa, porque não há nada para percorrer. Só uma base com o conjunto completo de artigos, relatórios, relações de categoria e histórico de comentários mostra que consulta percorre meia tabela.

#Separar base de conhecimento e notícias no WordPress

A decisão editorial mais importante foi separar a base de conhecimento do fluxo de atualidade. São parecidos, ambos são texto com título e data, e comportam-se de forma diferente em tudo o que conta.

Uma notícia vale uma semana, merece a página inicial e não precisa de voltar. Um guia da base de conhecimento vale exatamente aquilo que valer a sua exatidão dois anos depois: precisa de revisão, de uma data visível da última verificação e de um lugar na estrutura que não dependa de quando foi publicado. Na prática, o material duradouro recebe categorias temáticas próprias, como ecologia e ética empresarial, e templates próprios, enquanto a atualidade continua a ser um fluxo.

O preço é disciplina editorial. Alguém tem de decidir em que gaveta entra cada texto, e essa decisão não se automatiza, porque o mesmo material pode ser escrito como nota de um evento ou como introdução a um tema. O ganho aparece anos mais tarde, quando uma revisão abrange vinte guias e não duzentas publicações das quais a maioria já é história.

A mesma lógica sustenta a secção com exemplos de aplicações práticas. Não é enfeite, é um conjunto de casos para o qual os textos de fundo remetem. Para se manter, cada caso precisa dos seus próprios campos em vez de ser mais um parágrafo com uma fotografia colada.

#Quem lê um portal de responsabilidade social e o que procura

O público nunca foi o público geral: eram responsáveis de empresas, pessoas de recursos humanos e de marketing, especialistas em sustentabilidade e consultores. Chegam com uma pergunta concreta e pouca paciência, e querem saber o que exige determinada norma, como se costuma relatar uma iniciativa e o que fizeram de facto organizações comparáveis.

Esse perfil molda a construção inteira. O leitor chega de um resultado de pesquisa ou de uma newsletter, aterra no interior do arquivo e não na página inicial, e decide no primeiro ecrã. Por isso as páginas profundas têm de se aguentar sozinhas, a navegação tem de funcionar de dentro para fora, e a data de publicação tem de estar visível, porque nesta área um documento sem data é um documento que ninguém pode citar.

#Carregamento assíncrono e REST API sem esconder conteúdo aos rastreadores

O site carrega conteúdo de forma assíncrona: as listagens e as secções trazem mais entradas sem recarregar a página inteira. Com uma base extensa de artigos e relatórios isso é uma comodidade real, porque quem lê percorre a lista, restringe-a e não paga de cada vez o custo completo de construir uma página.

Existe uma única fronteira e é melhor conhecê-la antes da implementação. Conteúdo que só existe depois de um script correr não existe para uma parte do público: no caso benigno para um rastreador, no caso grave para um leitor de ecrã. Por isso cada artigo e cada relatório tem endereço próprio e texto completo num documento HTML normal, e a camada assíncrona limita-se a acelerar a navegação nas listagens.

A REST API cumpre aqui o mesmo papel que um endpoint bem recortado em qualquer outro projeto: devolve exatamente os dados necessários para desenhar uma parte da interface. Se a listagem pedisse as publicações completas, cada carregamento adicional arrastaria todo o corpo do texto para mostrar um título, uma categoria e duas linhas de resumo. A resposta mais pequena não é apenas mais rápida, também se comporta melhor em cache, porque esse recurso muda bastante menos vezes do que o texto do artigo.

#Entregabilidade e spam no formulário de contacto de um portal

Um formulário de contacto num portal temático faz um trabalho diferente do de uma loja. Não recebe encomendas, recebe pedidos de consultoria, pedidos de materiais e mensagens de organizações que querem apresentar a sua própria prática. As mensagens são longas e quem escreve espera resposta, não um comprovativo.

Há três pontos a resolver. A entregabilidade primeiro: correio enviado pelo servidor do próprio site com o endereço do visitante no campo de remetente vai parar ao lixo eletrónico muito mais vezes do que se supõe, por isso o endereço de envio tem de pertencer ao domínio do site e o endereço do visitante pertence ao campo de resposta. O spam a seguir: qualquer formulário acessível publicamente é encontrado por tráfego automatizado em poucas semanas, logo filtragem e limite de frequência são condição para a caixa de correio continuar legível. O comprimento dos campos por fim: cortar o corpo da mensagem num limite de caracteres é o tipo de defeito que só aparece quando alguém descreveu o caso em três parágrafos e chegaram dois.

#Porque é que o frontend em HTML5, CSS3 e SASS envelhece primeiro

A camada visual foi escrita em HTML5, CSS3 e SASS. O SASS foi uma decisão de manutenção e não estética: mantém cores, espaçamentos e pontos de quebra num só sítio em vez de espalhados pelas folhas de estilo, o que num site ampliado durante anos é a diferença entre uma alteração de quinze minutos e uma tarde a ler CSS.

Convém dizê-lo sem rodeios: esta camada envelhece mais depressa do que qualquer outra parte do projeto. As convenções de desenho adaptável de 2012 e as grelhas sobre as quais se montavam então os layouts são hoje exatamente aquilo que uma reconstrução séria substitui por inteiro. O modelo de conteúdo e a forma de entregar dados pela API aguentaram bastante melhor. A observação transfere-se para qualquer projeto novo: o dinheiro aplicado na estrutura de dados trabalha mais tempo do que o aplicado na apresentação.

Do lado dos motores de busca, o trabalho foi marcação semântica, metadados arrumados, endereços legíveis, dados estruturados schema.org e um mapa do site em XML. O objetivo é limitado: descrever a uma máquina aquilo que uma pessoa lê da disposição da página. Dados estruturados não põem um texto fraco à frente de um bom; impedem que um bom passe despercebido porque o rastreador não percebeu que tipo de página tinha à frente. Não tenho medições do efeito que possa citar honestamente, por isso não cito nenhuma.

#Testar atualizações do WordPress e restauros numa cópia do site

O acompanhamento cobre atualizações do núcleo, do tema e dos plugins, revisão de registos, cópias de segurança e pequenas alterações funcionais ou visuais. As atualizações são testadas numa cópia, porque um projeto com templates próprios, integração de API e formulários públicos tem vários pontos em que uma alteração num plugin muda o comportamento sem gerar erro: desaparece um filtro de que uma vista dependia, uma consulta passa a ser montada de outra maneira, o envio do formulário para em silêncio.

Uma cópia de segurança é um procedimento de restauro e não um ficheiro num disco. Vale a que já serviu para levantar uma versão funcional do site, com registo do tempo que demorou.

#Resumo

No centrum-csr.com o conteúdo de fundo é o produto e a técnica existe para o manter legível durante anos. O que definiu a sua forma é invisível do lado de fora: a base de conhecimento separada do fluxo de notícias, o carregamento assíncrono tratado como aceleração e não como única via para o texto, uma cache de objetos afinada para o trabalho de quem publica, e uma estrutura de dados mantida à parte de uma apresentação que sempre iria envelhecer primeiro.

O que transita para o projeto seguinte é a camada técnica e o método: WordPress, Redis, REST API, CDN e medição contra uma cópia de produção. O que não transita é o modelo de conteúdo deste portal nem as suas integrações, escritos para um material e uma rotina editorial concretos. Um trabalho novo começa pela análise do âmbito, e o orçamento vem depois dela.