Hospede um arquivo HTML como link ao vivo

O caso clássico: você codificou manualmente um index.html, uma página «em breve», um RSVP para evento, um link-in-bio, uma página de detalhes de casamento, e todo guia de hospedagem quer que você compre um domínio, aponte nameservers e aguarde a propagação. Aqui a página fica ao vivo no segundo em que o upload termina, em um link que você pode compartilhar por mensagem. Como renderiza ao vivo em vez de mostrar o código, os visitantes veem a página real com seu layout, fontes e estados hover intactos. O limite honesto: é genuinamente um único arquivo. Se seu site é index.html mais uma pasta /css e uma pasta /images, ou você integra tudo nesse único arquivo ou esta não é a ferramenta certa, um conjunto de assets não se conecta sozinho.

Muitas ferramentas exportam um .html autocontido: um relatório de cobertura do pytest ou Jest, uma execução do Playwright, um resumo do Allure ou pandas-profiling, uma auditoria do Lighthouse, um notebook Jupyter salvo como HTML. Esses já são projetados para ser um único arquivo com tudo integrado, o que os torna uma opção quase perfeita. Em vez de compactar o relatório e enviá-lo por e-mail, onde o destinatário precisa baixar, descompactar e encontrar o arquivo de entrada, você envia um único link que abre o relatório interativo no navegador. O contador de visualizações indica que o cliente ou colega realmente o abriu, e o link continua funcionando para a próxima pessoa que precisar. Gráficos interativos e tabelas recolhíveis continuam funcionando desde que o JS tenha sido integrado na exportação.

E-mail HTML é seu próprio formato trabalhoso, tabelas aninhadas, estilos inline, sem folhas de estilo externas, e antes de lançar uma campanha você quer que um responsável veja o resultado renderizado, não o código-fonte. Cole a saída do Mailchimp, Klaviyo ou MJML compilado em um arquivo .html, hospede e envie o link para aprovação. Dois avisos honestos que valem a pena mencionar: uma renderização no navegador não é uma renderização real na caixa de entrada (Gmail e Outlook reescrevem o HTML do jeito deles, então use para revisar layout e texto, não para QA final de entregabilidade), e quaisquer pixels de rastreamento ou links de rastreamento de cliques na exportação ainda apontarão para o seu ESP. Remova-os da cópia de revisão se não quiser que suas próprias aberturas de teste sejam contabilizadas.

Quando você está prototipando, frequentemente tem um único arquivo que é tudo: um hero de landing com Tailwind via CDN, uma animação CSS da qual você se orgulha, um sketch em canvas, uma pequena demo de D3 ou Three.js, um componente que você criou para mostrar a um cliente. Um link ao vivo supera um CodePen ou captura de tela quando você quer que pareça uma página real em uma URL real, sem o ambiente do editor ao redor, abre em tela cheia no celular. Enquanto suas bibliotecas carregarem de um CDN via https e seu código estiver integrado, funciona. Esta é a forma mais rápida de transformar «aqui está uma ideia aproximada» em «abra isso no seu celular» sem um pipeline de deploy.

Seu HTML é servido dentro de um frame em sandbox sem acesso de mesma origem. Isso protege tanto você quanto cada visitante: marcação não confiável não pode ler cookies, não pode acessar a página pai e não pode agir como se fizesse parte do host. Para 95% das páginas, layout, estilos, animações, bibliotecas CDN, scripts autocontidos, você nunca vai notar. Onde você vai notar: código que assume que controla a janela de nível superior, que precisa de cookies de primeira parte ou localStorage, ou que se comunica com uma API que permite apenas uma origem específica (CORS). Essas são preocupações de apps personalizados, e para eles um host real é a escolha certa. Em qualquer plano você pode colocar uma página hospedada no seu próprio domínio na barra de endereços com SSL automático, mas a página ainda renderiza em sandbox, então os mesmos limites de scripts se aplicam. Para hospedar uma página para ser visualizada, o sandbox é um recurso, não uma limitação.

Ótimo para: desenvolvedores, designers, estudantes, profissionais de marketing e criadores sem código que têm um único .html pronto e precisam de uma URL agora, uma demo para um cliente, um relatório para um gerente, um trecho para um colega, uma página única para um evento. Não é a opção certa para: um site de várias páginas com links internos entre arquivos .html, um app que precisa de backend ou variáveis de ambiente, qualquer coisa que exija seu próprio domínio na barra de URL, ou uma etapa de build que gera uma pasta /dist com assets separados. Para isso, use um host real. Se seu único obstáculo era «não quero configurar hospedagem para um único arquivo», isso remove exatamente esse obstáculo e nada mais.