Government Portal: zamki-szkocji.com

#zamki-szkocji.com, o seu guia para os castelos mágicos da Escócia

Num portal sobre castelos, a fotografia é o conteúdo, e é também aquilo que torna o site pesado. Essa tensão esteve presente em quase todas as decisões técnicas deste projeto. O zamki-szkocji.com é um portal informativo sobre os castelos da Escócia: artigos históricos, mapa interativo, galerias de fotografia e vídeo e notas práticas para quem prepara uma viagem. Entrou em produção em 2012, assenta em WordPress com Redis como cache de objetos e em infraestrutura AWS com uma CDN à frente dos ficheiros multimédia. A implementação demorou cerca de seis semanas. O cliente entregou a maquete e a disposição dos elementos; a minha parte foi transformar essa maquete num modelo de conteúdo, em templates e em integrações que aguentassem anos de novas fichas.

#Desempenho quando não se pode aligeirar a página

A tentação habitual perante um site lento é retirar peso. Aqui isso significaria retirar as galerias, ou seja, resolver a medição eliminando a razão pela qual alguém visita o site. O problema teve de ser atacado pela infraestrutura e não pelo âmbito.

A primeira camada é 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 arquivo com dezenas de fichas e respetivos campos, o número dessas leituras cresce mais depressa do que a quantidade de elementos visíveis faria supor. Com os resultados guardados fora da base de dados, o pedido seguinte não repete o mesmo trabalho. É exatamente onde a cache de página completa não chega: vistas com parâmetros, o endpoint do mapa, qualquer pedido feito por um editor autenticado.

A segunda camada é a CDN à frente dos ficheiros multimédia. As fotografias são grandes e o público está espalhado entre a Polónia, as ilhas britânicas e qualquer lugar de onde alguém planeie férias. Servir esses ficheiros a partir de uma única origem obriga metade dos leitores a esperar por uma transferência que atravessa a Europa de cada vez. Entregá-los a partir de pontos próximos do leitor retira ainda ao servidor aplicacional trabalho que nunca lhe pertenceu.

O tráfego de um site de viagens não é uniforme, e isso muda o que vale a pena afinar. Sobe com a época do ano e dá saltos depois de uma referência na imprensa ou de uma partilha num grupo temático grande. Afinar para a média mensal rende pouco. O que conta é a hora em que chegam muitas vezes mais visitas do que o habitual, e nessa hora não é o código mais rápido que salva, mas o facto de a maioria das respostas nem sequer chegar à aplicação.

Os tempos de cache foram decididos e não herdados do valor por omissão de um plugin. A descrição de um castelo pode ficar horas em cache, muda poucas vezes por ano. Um aviso de encerramento temporário não pode, porque é precisamente a informação que alguém procura na véspera da viagem. Separar os dois casos fica mais barato do que encurtar o tempo de vida global, o que degrada o desempenho em todo o lado para corrigir uma única vista.

Todas estas medições foram feitas contra uma cópia de produção e não contra uma instalação vazia. Um WordPress acabado de instalar, com um tema e duas publicações, responde sempre depressa, independentemente de como as consultas estão escritas. Só uma base com o conjunto completo de fichas, os metadados, as relações de taxonomia e o histórico de comentários mostra que consulta percorre meia tabela e qual aproveita um índice.

#Principais funcionalidades e soluções técnicas

Por baixo de tudo isto está a decisão que determina a longevidade do arquivo: um castelo é um registo com campos próprios e não uma publicação de blogue. Coordenadas, indicações de acesso, região, período histórico, estilo arquitetónico, galeria, material em vídeo e uma linha do tempo dos acontecimentos ligados ao edifício. Em WordPress, isto traduz-se num tipo de conteúdo personalizado com taxonomias próprias.

Com vinte fichas, as etiquetas comuns chegam e qualquer alternativa parece excesso de engenharia. Com várias centenas, as etiquetas deixam de ser uma classificação e passam a ser um monte de quase sinónimos: umas fichas dizem Highlands, outras dizem norte, algumas dizem ambas as coisas, e ninguém consegue já demonstrar que uma lista está completa. Uma taxonomia fechada obriga a decidir no momento em que a ficha é criada, enquanto quem escreve ainda tem a fonte aberta à frente.

O preço é a rigidez. O vocabulário tem de ser pensado antes, e alterá-lo mais tarde é uma migração de dados e não uma correção de texto. Neste projeto a troca compensava, porque nem a geografia da Escócia nem a classificação da arquitetura defensiva mudam de ano para ano. Num portal de eventos ou de ofertas, em que o vocabulário acompanha o mercado, a mesma decisão seria um erro.

A linha do tempo merece nota própria. É tentador colá-la no corpo do texto como marcação já resolvida. No primeiro dia fica bem e em qualquer outro sítio é inútil. Guardada como datas e acontecimentos, pode ser apresentada em vários formatos, ordenada e corrigida num único lugar no dia em que alguém repara que duas fontes datam de forma diferente a remodelação de uma ala.

As galerias e a troca de media funcionam com AJAX, pelo que passar de uma fotografia para a seguinte não recarrega a página. O benefício é evidente, o custo nem tanto. Conteúdo que só existe depois de um script correr não existe para uma parte dos visitantes: no mau caso para um rastreador, no pior para um leitor de ecrã. O endereço de cada imagem e a descrição do objeto têm de estar no documento HTML normal, com o AJAX a acelerar a navegação em vez de a substituir.

Os comentários e as avaliações deixam os visitantes registar a sua própria experiência de um lugar. É uma funcionalidade rápida de ligar e cara de manter, porque qualquer formulário aberto num site visível nos motores de busca é encontrado por tráfego automatizado em poucas semanas. A lição prática deste projeto é moderar com rigor no início e aliviar depois, em vez de limpar meses de ligações indesejadas por baixo da descrição de uma fortaleza medieval.

#Desafios e soluções de programação implementadas

O mapa interativo usa a API do Google Maps em conjunto com endpoints próprios que devolvem os dados de localização num formato adequado a desenhar marcadores. A separação não é cosmética. Se o mapa pedisse as publicações completas, cada carregamento arrastaria todo o texto histórico apenas para desenhar um ponto e três frases numa caixa. Um endpoint dedicado devolve só aquilo que o mapa desenha: resposta pequena, fácil de colocar em cache e indiferente a cada correção feita no artigo.

A segunda razão é de manutenção. Os dados de localização passam por um único ponto, por isso regras como não mostrar um objeto sem coordenadas, ou não publicar no mapa uma ruína sem indicações de acesso, vivem no código e não no hábito de quem edita. Num site que cresce durante uma década, essa é a diferença entre um mapa que reflete a base de dados e um mapa que alguém tem de rever à mão uma vez por ano.

Qualquer serviço externo de mapas traz o mesmo compromisso. O fornecedor dá os mosaicos, a geocodificação e um comportamento que o utilizador já conhece de outras páginas, e em troca prende o projeto a quotas e políticas de chaves alheias. Em vez de fingir que esse custo não existe, limita-se o número de chamadas: o mapa só carrega quando é preciso, não em todas as páginas de listagem, e as respostas do endpoint próprio ficam em cache para que percorrer uma lista não gere tráfego para o fornecedor.

Do lado dos motores de busca, o trabalho foi HTML5 semântico, metadados arrumados, endereços legíveis derivados da estrutura em vez de identificadores e dados estruturados schema.org para os artigos sobre castelos. O objetivo é limitado: descrever a uma máquina aquilo que uma pessoa lê da disposição da página. Dados estruturados não colocam um texto fraco à frente de um bom. Impedem que um texto bom passe despercebido porque o rastreador não conseguiu perceber que tipo de página tinha à frente. Não tenho medições do efeito deste trabalho que possa citar honestamente, por isso não cito nenhuma.

#Apoio e manutenção do site

O acompanhamento corrente inclui 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. Num site em funcionamento desde 2012, a manutenção é a maior parte da história e deve ser orçamentada como tal, e não tratada como reflexão tardia depois da entrega.

As atualizações são testadas numa cópia. Um projeto com tipo de conteúdo próprio, taxonomias próprias e integração externa de mapas tem vários pontos em que uma alteração no núcleo ou num plugin muda o comportamento sem gerar qualquer erro: uma consulta passa a ser construída de outra forma, um filtro em que uma vista assentava desaparece, o fornecedor do mapa retira um método antigo de autenticação.

Uma cópia de segurança é um procedimento de restauro e não um ficheiro num disco. A cópia de que nunca ninguém restaurou é uma declaração de intenções. Valor tem aquela a partir da qual já se levantou uma versão funcional do site, com registo de quanto tempo isso demorou.

#Resumo

O zamki-szkocji.com aguenta-se por causa de escolhas invisíveis do lado de fora: castelos modelados como registos e não como artigos, dados do mapa separados no seu próprio endpoint, cache de objetos mantida à parte da entrega de multimédia e conteúdo que permanece no documento HTML mesmo onde o AJAX torna a navegação mais rápida.

O que transita para o projeto seguinte é a camada técnica e o método: WordPress, Redis, AWS e CDN, dados estruturados 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 conjunto de dados e uma forma de leitura. Um novo trabalho começa pela análise do âmbito, e o orçamento vem depois dessa análise, não antes.