Dicas e exemplos de sites estáticos

Nesta página, mostraremos exemplos e dicas sobre como usar buckets para hospedar um site estático.

Páginas especializadas

Páginas de índice

Uma página de índice (também chamada de índice de diretórios do servidor da Web) é um arquivo disponibilizado aos visitantes quando eles solicitam um URL sem arquivo associado. Quando você atribui uma propriedade MainPageSuffix, o Cloud Storage procura um arquivo com esse nome e com o prefixo correspondente ao URL solicitado pelo visitante.

Por exemplo, digamos que você defina MainPageSuffix do seu site estático como index.html. Além disso, digamos que você não tenha um arquivo chamado directory no seu bucket www.example.com. Nessa situação, se um usuário solicitar o URL http://www.example.com/directory, o Cloud Storage tenta veicular o arquivo www.example.com/directory/index.html. Caso esse arquivo também não exista, o Cloud Storage retornará uma página de erro.

O MainPageSuffix também controla o arquivo exibido quando os usuários solicitam o site de nível superior. Continuando com o exemplo acima, se um usuário solicitar http://www.example.com, o Cloud Storage tenta veicular o arquivo www.example.com/index.html.

Ao tentar acessar um URL com uma barra no final, como http://www.example.com/dir/, consulte Solução de problemas.

Página de erro

A página de erro é o arquivo retornado aos visitantes do site que solicitarem um URL que não corresponde a um arquivo existente. Se você tiver atribuído um MainPageSuffix, o Cloud Storage só retornará a página de erro se não houver um arquivo com o nome solicitado nem uma página de índice aplicável.

Ao retornar uma página de erro, o código de resposta http é 404. A propriedade que controla qual arquivo atua como a página de erro é NotFoundPage. Se você não definir NotFoundPage, os usuários recebem uma página de erro genérica.

Exemplos de configuração do site

bucket de três objetos

Suponha que um bucket denominado www.example.com tenha sido configurado como um site com as seguintes configurações e arquivos:

  • MainPageSuffix = "index.html"
  • NotFoundPage = "404.html"
  • O bucket contém três objetos compartilhados publicamente: “index.html”, “404.html” e “dir/index.html”.

Na tabela a seguir, veja o conteúdo exibido para URLs selecionados:

URL solicitado Conteúdo disponibilizado Código de resposta HTTP
http://www.example.com
http://www.example.com/
http://www.example.com/index.html		 O objeto "index.html". 200
http://www.example.com/hello O objeto "404.html". 404
http://www.example.com/dir/index.html O objeto "dir/index.html". 200
http://www.example.com/dir O objeto "dir/index.html". 301
http://www.example.com/dir/ O objeto "dir/index.html", presumindo que não haja objeto de zero bytes para /dir/ 200
Um objeto vazio de zero bytes, se existir para /dir/. Consulte o tópico solução de problemas para remover este objeto zero bytes. 301

bucket de dois objetos

Suponha que um bucket denominado www.example.com tenha sido configurado como um site com as seguintes configurações e arquivos:

  • MainPageSuffix = "main.html"
  • NotFoundPage = "404.html"
  • O bucket contém dois objetos compartilhados publicamente: "main.html" e "404.html".

Na tabela a seguir, veja o conteúdo exibido para URLs selecionados:

URL solicitado Conteúdo disponibilizado Código de resposta HTTP
http://www.example.com
http://www.example.com/		 O objeto "main.html". 200
http://www.example.com/index.html O objeto "404.html". 404

Se um objeto for compartilhado publicamente, você também poderá vê-lo com o URL: 

http://storage.googleapis.com/BUCKET_NAME/OBJECT_NAME

Por exemplo, o URL de um objeto index.html seria: 

http://storage.googleapis.com/www.example.com/index.html

Para mais informações sobre como trabalhar com dados acessíveis publicamente, consulte Como acessar dados públicos.

Dicas sobre como trabalhar com um bucket configurado como um site

A seguir, algumas dicas a serem lembradas ao usar um bucket para hospedar um site estático.

Adicionar subdomínios

Suponha que você também queira disponibilizar conteúdo em test.example.com, de um bucket diferente do que exibe conteúdo em www.example.com. Sendo assim:

  1. Crie um novo bucket para veicular seu conteúdo adicional.

  2. Se você seguiu o tutorial em Como hospedar um site estático para exibir o conteúdo por HTTPS, edite o balanceador de carga no console do Google Cloud da seguinte maneira:

    1. Em Configuração de back-end, crie um novo bucket de back-end test-bucket selecionando o novo bucket criado.
    2. Em Regras de host e caminho, adicione uma nova regra desta forma: 
      Hosts                  Paths     Backends
test.example.com       /*        test-bucket

    3. Em Configuração de front-end, adicione um novo IP e uma porta de front-end com os mesmos valores da primeira configuração, com as exceções a seguir:

      • Em Endereço IP, crie e reserve um novo endereço.
      • Em Certificado, crie um novo certificado SSL para test.example.com.

  3. Depois de atualizar o balanceador de carga, adicione um novo registro A ao seu serviço de registro de domínio usando o endereço IP da nova configuração de front-end: 

    NAME                  TYPE     DATA
test                  A        IP_ADDRESS

Comportamento da API

As configurações de site MainPageSuffix e NotFoundPage são usadas apenas para solicitações que chegam ao Cloud Storage por meio de um redirecionamento CNAME ou A. Por exemplo, uma solicitação para www.example.com mostra a página de índice, mas uma solicitação equivalente para storage.googleapis.com/www.example.com não.

Assim, o comportamento da API para solicitações de domínios do Cloud Storage, como storage.googleapis.com/www.example.com, é preservado. Por exemplo, é possível listar objetos no bucket www.example.com como faria com qualquer outro No caso do bucket www.example.com, a listagem de objetos que você recebe inclui 404.html e index.html.

Hospedar recursos estáticos para um site dinâmico

É possível usar o Cloud Storage para hospedar recursos estáticos de um site dinâmico hospedado, por exemplo, no Google App Engine ou no Google Compute Engine. Algumas vantagens de hospedar em um bucket seus recursos estáticos, como imagens ou arquivos JavaScript, incluem:

  • O Cloud Storage se comporta como uma rede de fornecimento de conteúdo (CDN) porque os objetos legíveis publicamente são armazenados em cache na rede do Cloud Storage por padrão.

  • As taxas de largura de banda para acessar o conteúdo geralmente custam menos com o Cloud Storage.

  • A carga nos servidores da Web é reduzida ao disponibilizar o conteúdo estático do Cloud Storage.

Ao hospedar recursos estáticos para um site dinâmico, não é preciso criar registros DNS e apontar para um bucket ou balanceador de carga como para um site estático. Por exemplo, é possível ter um bucket chamado www_example_com_assets com recursos apropriados configurados como compartilhados publicamente e acessar esses recursos usando o domínio do Cloud Storage. Por exemplo, se você tiver o arquivo JavaScript library.js no bucket www_example_com_assets compartilhado publicamente, será possível acessá-lo como http://storage.googleapis.com/www_example_com_assets/library.js.

Definir parâmetros de cache

É possível controlar como ou se os recursos de seu site são armazenados em cache configurando os metadados Cache-Control. Em geral, apenas defina metadados de controle de cache para objetos acessíveis a todos os usuários anônimos, o que é um requisito para qualquer objeto exibido de um bucket do Cloud Storage como parte de um site estático.

O Cloud Storage aplica uma configuração de controle de cache de 3600 segundos a objetos acessíveis a todos os usuários anônimos, a menos que você especifique configurações explícitas de controle de cache. Consulte Visualização e edição de metadados para mais instruções sobre como configurar metadados de objetos, como Cache-Control.

Também é possível usar o Cloud CDN para armazenar em cache conteúdo externo com balanceamento de carga HTTP(S) perto dos usuários, o que geralmente reduz os valores gastos. Para mais informações, consulte Como armazenar em cache.

Monitorar suas cobranças

Se você estiver exibindo recursos de um bucket configurado como um site estático ou exibindo recursos estáticos de um bucket para um site dinâmico hospedado fora do Cloud Storage, monitore as cobranças do projeto que contém o bucket. A exibição de conteúdo gera custos de armazenamento, uso da rede e operações de recuperação do Cloud Storage. Saiba mais na página de preços do Cloud Storage.

Você também pode ter cobranças de rede caso use um balanceador de carga de aplicativo externo para configurar o HTTPS. Para mais detalhes, consulte Preços de rede.

O exemplo de precificação simples na página de exemplos de preços pode ser usado como uma aproximação para o caso de uso de um site estático de baixo tráfego. No entanto, o exemplo não considera cobranças associadas ao balanceador de carga de aplicativo externo, que geralmente pode ser a maior cobrança para hospedagem de sites estáticos. Use a calculadora de preços para gerar uma estimativa de custo com base no uso projetado.

Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Se você já é um usuário do Google Cloud, veja uma análise detalhada dos custos do projeto na página de faturamento.

Solução de problemas

Consulte Solução de problemas para problemas comuns relacionados ao uso de um bucket configurado para disponibilizar conteúdo estático do site.

A seguir

Faça um teste

Se você começou a usar o Google Cloud agora, crie uma conta para avaliar o desempenho do Cloud Storage em situações reais. Clientes novos também recebem US$ 300 em créditos para executar, testar e implantar cargas de trabalho.

Faça uma avaliação gratuita do Cloud Storage