Website corporativo: BALTIC PALACE

#Baltic-palace.com, tecnologia para um local excepcional no mar Báltico

A fotografia é o argumento comercial principal de um alojamento, e quase tudo o que este projeto decidiu do lado técnico decorre daí. Baltic Palace foi projetado pelo atelier MTA Architekci e a sua forma é, a par da localização, aquilo que faz alguém parar na página. Comprimir imagens de arquitetura até a textura do reboco virar uma mancha retira ao alojamento o seu melhor argumento, e servi-las em tamanho integral afasta quem abre o site com rede fraca. Todo o trabalho vive nessa tensão.

O edifício fica em Pobierowo, no cordão dunar da Pomerânia Ocidental, a cerca de cem metros do acesso à praia, e tem quarenta e quatro quartos e apartamentos. No piso térreo estão o átrio, o bar, o restaurante, os gabinetes de tratamento e uma zona de SPA com duas piscinas e saunas, e o alojamento dispõe ainda de espaço para reuniões. Essa combinação pesa mais do que parece: significa pelo menos três leitores sem nada em comum, um casal a planear um fim de semana, uma família a reservar duas semanas de agosto e quem organiza uma formação e precisa de saber quantas pessoas cabem na sala.

O projeto decorreu em 2017 e demorou cerca de seis semanas. O cliente forneceu a maqueta e a disposição dos elementos, pelo que a minha parte foi traduzir isso em templates, num modelo de conteúdo e em comportamento responsivo, e não decidir a estética.

#Objetivo de baltic-palace.com e o seu público-alvo

A encomenda não era criar procura. O tráfego de marca já existia e o site tinha de deixar de o perder. Um alojamento desta dimensão não compete em alcance com os portais de reserva, compete em margem: cada reserva que passa por um intermediário deixa lá a comissão, por isso o site próprio tem uma tarefa mensurável em dinheiro, convencer quem já conhece o nome a concluir a reserva na origem.

Na prática isso significa que o percurso de reserva tem de aguentar o que as pessoas realmente fazem, e não o que uma demonstração faz. Abrem dois separadores e comparam datas. Carregam em retroceder a meio do formulário. Começam no telemóvel, num comboio com rede intermitente, e terminam no portátil três dias depois. Um percurso de reserva que só funciona quando nada de estranho acontece é um percurso que funciona na demonstração.

Há também a sazonalidade, que moldou as decisões técnicas mais do que qualquer outra coisa. O tráfego de um alojamento na costa báltica não é uma linha, é uma série de picos estreitos: o planeamento em janeiro, o feriado prolongado de maio e depois o verão. Entre eles o site serve algumas dezenas de visitas por dia. Uma infraestrutura dimensionada para o pico queima dinheiro na maior parte do ano, e uma dimensionada para a média cai exatamente na semana em que o alojamento ganha.

Vale a pena dizer o que não está nesta página. Não há indicadores de resultado, nem percentagem de aumento de reservas, nem taxa de ocupação, nem classificação em cinco pontos. Os dados comerciais pertencem ao alojamento e não ao estudo de caso do seu fornecedor, e nenhum desses números poderia aqui ser sustentado por uma fonte. O que se pode contar com honestidade, e o que de facto transita para o projeto seguinte, são as decisões e os motivos que as sustentaram.

#Funcionalidades técnicas de baltic-palace.com

A camada de interface assenta em Tailwind CSS e media queries, com atenção à WCAG 2.1. A acessibilidade não é aqui uma formalidade. Uma parte significativa dos hóspedes tem idade avançada, e um formulário de reserva lido no telemóvel ao sol precisa de um contraste que o cinzento claro elegante sobre branco simplesmente não dá. Pela mesma razão os campos têm etiquetas visíveis em vez de textos de exemplo que desaparecem à primeira tecla.

As galerias e a apresentação do volume do edifício são a parte mais pesada do site. O volume é mostrado como modelo tridimensional em Three.js e as galerias carregam dinamicamente através de GraphQL com tratamento de srcset. O GraphQL tem aqui uma razão concreta: um endpoint convencional devolve todos os campos de cada imagem, incluindo os que uma vista de lista nunca usa, e um único pedido por uma dúzia de objetos com metadados completos pode pesar mais do que as próprias miniaturas. Uma consulta que declara precisar de três campos desloca esse custo da rede para a base de dados, onde é mais barato.

As reservas passam por um módulo dedicado com integração da API Stripe, validação do lado do servidor e armazenamento em PostgreSQL com cifragem AES-256. A validação no servidor não é redundante face à do navegador. O formulário aceita um intervalo de datas, e um intervalo de datas é o campo mais fácil de partir em qualquer sistema de reservas: o botão de retroceder, dois separadores abertos, uma data livre quando a página carregou e ocupada quando o formulário foi submetido. Do lado do cliente, os três casos parecem um formulário perfeitamente válido.

A secção informativa sobre Pobierowo e o alojamento está escrita para as pesquisas que realmente se fazem naquela zona, com notificação acelerada de alterações através da Google Indexing API. As cópias de segurança seguem automaticamente para Amazon S3 com replicação entre regiões, versionamento e compressão Zstandard. O versionamento pesa mais do que a própria cópia, porque a falha que de facto acontece a alojamentos não é um servidor em baixo, é uma tabela de preços sobreposta pelo ficheiro errado dois dias antes de um feriado.

O desempenho assenta em Varnish para a cache de servidor e em Cloudflare para a otimização multimédia, com WebP e preconnect para os recursos críticos em HTTP/3. A localização é resolvida por um módulo com Mapbox GL JS, dados GeoJSON e mosaicos. Num alojamento costeiro, o mapa responde a uma pergunta que ninguém faz em voz alta: a que distância fica realmente o mar, quando todos os estabelecimentos num raio de um quilómetro escrevem sobre si que ficam junto à praia.

#Desafios técnicos e as respetivas soluções

O peso da galeria apareceu logo nos testes. Um número elevado de imagens em alta resolução atrasava a primeira pintura. O Redis trata da cache de consultas e o Fastly funciona como segunda camada de CDN para servir os media em paralelo. Separar os media faz sentido porque a galeria e o documento HTML têm perfis de invalidação distintos: o texto da oferta muda de poucas em poucas semanas, as fotografias de uma sessão praticamente nunca. Manter ambos sob a mesma política obriga a recarregar imagens a mais ou a atualizar texto a menos.

O modelo tridimensional travava os navegadores móveis, o que num alojamento com público maioritariamente móvel era um problema real e não teórico. A redução de polígonos e a compressão de texturas com Draco resolveram o lado da transferência. O compromisso merece ser dito com clareza: cada redução dessas retira detalhe, e o detalhe é a única razão pela qual o modelo existe. A fronteira está onde o volume continua a ler-se como este volume concreto e não como um bloco qualquer.

O sistema de reservas engasgava nos picos. A causa é estrutural. Uma reserva tem de verificar disponibilidade, bloquear as datas, cobrar e enviar a confirmação, e quem reserva espera pelo último passo apesar de só lhe interessar o primeiro. Separá-los com RabbitMQ faz com que o bloqueio e a resposta aconteçam de imediato, enquanto a confirmação e a sincronização posterior passam para uma fila. O rate limiting ao nível do Nginx protege o mesmo endpoint do duplo clique e dos bots que varrem disponibilidades durante toda a época.

A cache desatualizada foi o último destes problemas e o mais caro em termos comerciais. Uma alteração na oferta que ninguém vê é um telefonema de um hóspede irritado. O Varnish com purge despoletado por webhook, mais Edge Side Includes para as secções dinâmicas, resolve isso sem abdicar da cache no resto. O ESI responde a uma tensão concreta: uma página de quarto é em noventa por cento conteúdo que não muda durante meses e numa pequena percentagem preço e disponibilidade que mudam todos os dias. Sem separar essas camadas, o tempo de vida da cache do documento inteiro teria de ser fixado pelo fragmento mais efémero, o que equivale a desligá-la.

#Tecnologias utilizadas

O Yoast SEO trata de metadados, mapas XML e avisos aos motores de busca. O UpdraftPlus executa as cópias para Amazon S3 com replicação entre regiões e cifragem AES-256. A Cloudflare fornece a camada de CDN com Argo Smart Routing, compressão Brotli e proteção contra tráfego volumétrico. O Redis mantém a cache de objetos com sharding e persistência para consultas e sessões. O Varnish opera a cache de páginas sobre VCL próprio, com modo grace e suporte de ESI.

O modo grace merece uma frase própria, porque é a definição mais subestimada desta configuração. Permite servir uma página ligeiramente desatualizada quando o backend não responde, em vez de mostrar um erro. Em época alta, a diferença entre uma página de há dois minutos e uma mensagem de erro é a diferença entre uma reserva e nenhuma.

O Lighthouse corre automaticamente no processo de CI/CD sobre GitHub Actions, de modo que uma regressão de desempenho aparece na alteração e não numa queixa. O RabbitMQ coloca em fila o trabalho de reservas e as confirmações com repetições. O Fastly acrescenta uma segunda via de distribuição multimédia com otimização geográfica. O Mapbox GL JS desenha o mapa com mosaicos. O GraphQL resolve o carregamento de dados de galeria e de informação com agrupamento de consultas, e o Git com o respetivo processo mantém o histórico num estado em que se reverte uma coisa e não uma semana inteira.

Importa dizer o que esta lista não diz. Não diz como o mesmo conjunto se comporta noutro alojamento. Três camadas de cache para quarenta e quatro quartos com sazonalidade acentuada justificam-se por esta forma de tráfego e por nenhuma outra. Num estabelecimento com procura estável ao longo do ano, a mesma configuração seria peso morto cuja manutenção supera o benefício.

#Gestão e apoio técnico

O site exige acompanhamento contínuo. As atualizações de sistema e de extensões passam por um ambiente de testes com cópia integral, e não pela produção com otimismo. A diferença vê-se melhor no módulo de reservas do que em qualquer outro lado: uma atualização testada numa instalação vazia passa sempre, porque não há nada para partir, ao passo que a mesma atualização contra uma cópia de produção revela de imediato que a extensão mudou o formato de data nos registos existentes.

A Cloudflare, o Redis e o Fastly sustentam o desempenho sob carga; o Varnish e o RabbitMQ sustentam a estabilidade dos processos dinâmicos. As consultas SQL passam por índices compostos, porque uma pesquisa de disponibilidade filtra sempre por data e tipo de quarto ao mesmo tempo, e um índice sobre qualquer dessas colunas isoladamente não serve para essa consulta. A cache é limpa de forma cirúrgica nas atualizações de conteúdo e não em bloco, porque uma limpeza total antes de um feriado prolongado significa que as primeiras centenas de visitas caem sobre cache fria.

O público de reuniões e de grupos lê as mesmas páginas com outros olhos. Procura restrições e não ambiente: lotação por disposição de cadeiras, se as pausas podem decorrer no restaurante, a que distância fica a estação mais próxima. Esse leitor decide sobre uma especificação, e uma especificação enterrada num parágrafo de prosa é uma especificação que ninguém encontra. Por isso esses valores vivem em campos estruturados, podendo aparecer como tabela num sítio e como cartão noutro sem ninguém os escrever duas vezes.

Há ainda uma tensão que regressa em todos os projetos de alojamento e que é melhor nomear antes da construção do que depois. O site próprio e o portal de reservas descrevem o mesmo quarto em duas línguas diferentes. O portal impõe um formato de descrição, uma lista fixa de comodidades e regras próprias de corte, pelo que fica igual para todos os alojamentos da mesma terra. O site próprio é o único sítio onde se pode mostrar aquilo que o formulário do portal não transporta: o recorte de um terraço, a vista de um piso específico, a forma como a luz da tarde entra na sala de refeições. Quem copia a estrutura do portal abdica da sua única vantagem e fica com uma pesquisa de datas pior.

O site pode crescer para uma integração com o sistema hoteleiro na receção, um módulo de promoções sazonais ou uma secção de opiniões de hóspedes. Cada uma dessas direções é um âmbito próprio, orçamentado depois da análise e não acrescentado pelo caminho.