Media & Publishing: olshtyn.com

#Um arquivo mais antigo do que o site

olshtyn.com é um portal informativo sobre Olsztyn, feito para quem vive na cidade e para quem planeia visitá-la. O projeto foi entregue em 2012, incluiu também a identidade visual e a execução demorou cerca de seis semanas.

Convém começar pelo trabalho que não se vê na página final, porque foi ele que condicionou o calendário. Parte dos conteúdos vinha de versões anteriores do serviço e tinha de ser transferida com o histórico intacto. Importar material a partir de cópias arquivadas, entre outras do Web Archive, parece uma hora de trabalho e leva vários dias, sempre pelos mesmos motivos.

Os sistemas antigos usavam outra codificação de caracteres, pelo que os diacríticos polacos regressam de uma importação como sequências de bytes sem sentido, visíveis apenas quando alguém lê de facto aquele parágrafo. Os endereços antigos têm outra forma, portanto cada peça importada precisa de um redireccionamento a partir do endereço anterior, caso contrário o site deita fora todas as ligações recebidas e todas as posições que construiu ao longo de anos. As imagens arquivadas chegam muitas vezes incompletas e as legendas vivem dentro do texto em vez de um campo próprio.

A ordem das operações foi decisiva: primeiro o mapeamento dos endereços antigos para os novos, depois a importação do conteúdo e, no fim, a verificação manual de uma amostra sobre uma cópia da produção. A ordem inversa acaba numa segunda importação, porque corrigir endereços depois do arranque significa que parte do tráfego já caiu no vazio.

Nesta secção costuma aparecer uma tabela de resultados. Aqui não aparece nenhuma, e é uma decisão: os números de audiência pertencem ao editor do portal e não a uma descrição de projeto no nosso site. O que se pode contar com honestidade são as decisões e as suas consequências, e é isso que se transfere para o projeto seguinte.

#Dois leitores, uma página inicial

Olsztyn é a capital da voivodia de Vármia-Masúria, tem cerca de cento e setenta mil habitantes, vários lagos dentro dos limites da cidade e uma época turística claramente concentrada no verão. Isto parece informação geográfica e foi, na prática, o ponto de partida da arquitetura.

O residente volta pela atualidade. Interessa-lhe o que aconteceu ontem e o que acontece no fim de semana, visita o portal com frequência e fica pouco tempo. O visitante entra uma vez, normalmente pelo telemóvel, normalmente de fora da região, e procura o que é duradouro: o que vale a pena ver, como se chega lá, onde fica o quê. O primeiro precisa de um fluxo, o segundo de uma estrutura. Um portal que serve apenas o fluxo tem, ao fim de um ano, um arquivo ilegível. Um portal que serve apenas a estrutura deixa de dar motivo para regressar.

#Modelo de conteúdos, o verdadeiro trabalho

O esquema e a colocação dos elementos vieram do cliente. Do nosso lado ficou a tradução disso em templates, comportamento responsivo e uma estrutura de dados que uma redação consegue manter sem programador.

O material de um portal urbano vive a três velocidades. Uma notícia tem valor durante alguns dias e depois só interessa ao motor de busca. Um anúncio de evento vale até ao dia do evento e depois inverte o sinal: deixa de ser convite e passa a arquivo. Um texto sobre um monumento ou um percurso junto ao lago não envelhece e é ele que traz tráfego de pesquisa durante anos. O WordPress padrão coloca os três no mesmo saco ordenado por data, o que faz desaparecer primeiro precisamente aquilo que dura mais.

Existem, por isso, três tipos de conteúdo: a notícia, o evento com data e local, e o material de guia sem prazo de validade. A consequência só se nota ao fim de um ano de operação. Um evento terminado sai sozinho das listagens em vez de ficar lá até alguém se lembrar de o retirar. O material de guia deixa de competir por espaço com a notícia do dia, pelo que ninguém tem de o empurrar para cima todos os meses com uma data de publicação artificialmente renovada. A redação responde uma vez à pergunta sobre o tipo de material, no momento da criação, em vez de vigiar a sua visibilidade todas as semanas.

A taxonomia foi mantida deliberadamente estreita. O modelo tentador descreve tudo ao mesmo tempo por bairro, tema, acontecimento, pessoa e local. Parece flexível no dia do arranque e desfaz-se ao sexto mês, porque dois editores classificam o mesmo texto de maneiras diferentes e o arquivo deixa de filtrar. O conjunto de categorias é curto e fechado, e aquilo que é realmente móvel fica em etiquetas livres das quais nenhuma navegação depende.

Os endereços foram tratados como valor de longo prazo. O endereço de uma peça contém o título legível, sem data e sem identificador numérico, e a categoria não faz parte do caminho. As categorias acabam por ser reorganizadas, e mudar o endereço de um texto publicado há um ano custa posição e obriga a um redireccionamento. Um endereço que não depende da arrumação editorial sobrevive a qualquer reorganização sem trabalho nenhum.

#Cache numa publicação que tem de ficar visível já

A base técnica é WordPress sobre PHP com MySQL, Redis e Memcached como camadas de cache, um CDN à frente e HTML5, CSS3, SASS e JavaScript do lado do navegador. O código está versionado em Git e a troca de dados com a interface passa por AJAX e endpoints REST.

Comparado com uma loja, um portal de notícias tem uma vantagem grande: quase todas as vistas são iguais para todos os visitantes. Não há carrinho, não há preços por cliente, não há sessão a escorrer para dentro da página. A esmagadora maioria das visualizações pode, portanto, ser entregue sem sequer arrancar o PHP. O difícil não é guardar em cache, é invalidar.

A expiração por tempo é a ferramenta errada aqui. Se for longa, a redação não vê o próprio artigo e começa a exigir que a cache seja desligada, normalmente na hora de maior tráfego do ano. Se for curta, a cache deixa de ajudar exatamente quando é precisa. A invalidação está por isso ligada a um acontecimento e não a um relógio: guardar um artigo limpa a página inicial, as listagens de categoria afetadas e o endereço do próprio artigo, deixando o resto do site intacto. A publicação passa a ser o gatilho, a redação vê o resultado de imediato e ninguém precisa de alargar o efeito a todo o site.

O Redis e o Memcached carregam tarefas diferentes. A cache de objetos encurta as consultas que qualquer pedido paga de qualquer forma, ou seja, menus, listagens de categorias e as consultas de arquivo mais pesadas. Os dados voláteis, que não precisam de sobreviver a um reinício, ficam à parte. Esta separação tem um benefício operacional: esvaziar a cache de objetos durante um incidente não expulsa ninguém da administração.

O CDN acrescenta a terceira camada e conta sobretudo para o leitor de fora. Quem lê a partir de outra cidade ou de um telemóvel em roaming recebe os ficheiros estáticos de um nó próximo, e o servidor de aplicação nunca chega a ver esses pedidos. No material de guia, pesado em imagens, é a maior poupança isolada de toda a implementação.

#Carregamento assíncrono, mapas e imagens

As listagens de notícias carregam entradas adicionais de forma assíncrona, por AJAX e endpoints REST dedicados, em vez de recarregar a página. O ganho de conforto é evidente; os custos são dois e, em 2012, ambos passavam facilmente despercebidos.

O primeiro é a descoberta. Conteúdo que só aparece depois de um clique pode ser invisível para um rastreador, por isso a primeira porção de qualquer listagem está no código da página, o carregamento assíncrono trata apenas das páginas seguintes, e a paginação numerada permanece na marcação mesmo quando a interface não a mostra. É esse o caminho do rastreador e de qualquer visitante sem JavaScript.

O segundo custo é a cache. Um endpoint que devolve uma fatia de listagem é um endereço próprio: ou tem política de cache própria, ou torna-se o buraco por onde o tráfego de pico entra no PHP. As respostas desses endpoints são guardadas como páginas e invalidadas pelo mesmo acontecimento de publicação.

Os mapas seguem o mesmo raciocínio. Um mapa de fornecedor externo são algumas centenas de kilobytes de script mais uma ligação a um servidor alheio, paga independentemente de alguém olhar para o mapa. Só carrega quando o visitante chega à secção com a localização e, até lá, fica no seu lugar uma imagem estática com a morada. Para um leitor no telemóvel, parado na rua a confirmar uma informação, essa diferença decide se a página chega sequer a abrir.

As imagens merecem uma frase própria, porque num portal urbano são a maior parte dos bytes transferidos. A redação publica diretamente a partir da máquina fotográfica, num tamanho muitas vezes superior a qualquer vista do site. O processamento no carregamento gera variantes para a listagem, para a vista do artigo e para a galeria, e o template indica ao navegador qual a variante a usar em cada largura de ecrã. Sem isso, o leitor móvel descarrega uma fotografia preparada para um monitor, paga-a em dados e em tempo, e a redação nunca fica a saber, porque na ligação dela tudo é rápido.

#A marca tem de funcionar num cabeçalho

O projeto incluiu a identidade visual, e o símbolo foi desenhado para o sítio onde vive de facto. O logótipo de um portal passa a maior parte do tempo numa barra de topo com algumas dezenas de pixéis de altura, num telemóvel, ao lado de um botão de menu, e tem de continuar reconhecível como ícone num separador do navegador. Isso inverte as prioridades de uma marca pensada para impressão: legibilidade em escala pequena, comportamento sobre fundo uniforme e uma variante simplificada que não se desfaz com uma dúzia de pixéis de largura. Uma marca apenas horizontal, com detalhes finos, apresenta-se bem num documento e desaparece num cabeçalho real, por isso as variantes nasceram ao mesmo tempo que os templates e não antes.

#Manutenção e uma regra sobre plugins

Um serviço noticioso não tem estado de repouso, portanto a manutenção foi planeada com a implementação e não depois dela: atualizações do núcleo, do tema e dos plugins, revisão dos registos do sistema, cópias de segurança cuja reposição é efetivamente ensaiada e não apenas agendada, e pequenas alterações funcionais que resultam do modo como a redação trabalha na realidade.

Há uma regra que vale a pena dizer diretamente. A segurança é tratada em código e na configuração do servidor, não com mais um plugin de proteção. Um plugin desse tipo corre dentro do PHP, ou seja, depois de o pedido já ter arrancado a aplicação, torna-se com frequência ele próprio uma vulnerabilidade e cobra um custo em cada pedido. Num portal com tráfego irregular, que tem de aguentar um pico no dia em que acontece algo na cidade, é uma má troca. A filtragem à entrada, a verificação de permissões no código e uma configuração de servidor apertada custam menos e agem mais cedo.

Remover um comentário sobre um assunto municipal é uma decisão editorial e não técnica, e por isso a moderação ficou com pessoas e não com um filtro. A redação recebeu ferramentas de moderação e uma fila para mensagens retidas. A discussão sob as notícias locais é a parte mais viva de um portal urbano e a que mais vezes precisa de alguém que leia com atenção. Um filtro automático teria saído mais barato a operar e teria errado exatamente nos casos que contam, aqueles em que um residente acusa a câmara de alguma coisa.

Os testes anteriores ao arranque correram contra uma cópia da produção e não contra uma instalação vazia. Uma instalação vazia tem dez artigos, portanto qualquer listagem cabe num ecrã, qualquer consulta é instantânea e não existe arquivo. Os problemas de um portal começam aos milhares de peças, quando as páginas de categoria abrandam, a pesquisa interna devolve resultados com ordenação inútil e a paginação chega à página vinte, que ninguém abriu durante os testes. Uma cópia da produção mostra tudo isso em poucos minutos, e é por isso que a diferença entre as duas formas de testar não é uma questão de rigor mas de resultado.

#Resumo e o que a análise fixou

A fase de análise fechou quatro pontos que passaram a ordenar todas as decisões seguintes. O público foi definido em duplicado, residente e visitante, com a aceitação explícita de que querem coisas diferentes e de que a página inicial tem de servir ambos. O âmbito cobriu gestão de conteúdos, calendário de eventos, mapas de localização, galerias e comentários. O calendário foi dividido em etapas, o que permitiu à redação começar a encher o site antes de os últimos trabalhos terminarem. As referências indicadas pelo cliente eram portais com forte ligação à comunidade local, e daí resultou que comentários e eventos ficaram no topo e a camada decorativa em baixo.

Nenhum destes quatro pontos era técnico, e cada um deles decidiu mais tarde uma questão técnica. É essa a razão pela qual a fase de análise não se resume a um documento arrumado numa pasta.

Para uma implementação seguinte transfere-se a camada técnica e a forma de raciocinar sobre cache em conteúdo editorial, enquanto o modelo de conteúdos deste projeto não transita, por ter sido escrito para uma cidade, uma redação e um ritmo de publicação. O portal seguinte começa pela pergunta sobre quem o lê e com que frequência, e só depois pelo que vai para a base de dados.