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.

Como 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 chamado test.example.com. Como você já verificou o domínio example.com, é possível criar buckets para dar suporte a subdomínios sem verificação adicional.

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

    1. Em Configuração de back-end, crie um novo bucket de back-end test-bucket ao selecionar o bucket test.example.com.
    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]
    

Como configurar 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.

Comportamento da API

As configurações do site MainPageSuffix e NotFoundPage são usadas apenas para solicitações do Cloud Storage por meio do endpoint CNAME ou do Cloud Load Balancing. 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.

Como 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 armazenamento em nuvem se comporta essencialmente como uma Rede de Fornecimento de Conteúdo (CDN, na sigla em inglês) sem nenhum trabalho de sua parte, já que os objetos legíveis publicamente são, por padrão, armazenados em cache na rede do Cloud Storage.

  • 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 quando o conteúdo estático do Cloud Storage é exibido.

Também é possível controlar o armazenamento em cache, como desativar o armazenamento em cache ou definir o tempo de vida do cache, para seus recursos estáticos legíveis publicamente usando cabeçalhos de solicitação de controle de cache. Para mais informações, consulte Como definir parâmetros de cache.

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.

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 para o projeto que contém o bucket. A disponibilização de conteúdo incorre em custos de armazenamento, uso de rede e execução de operações de recuperação do Cloud Storage. Para saber mais, consulte a página de preços do Cloud Storage.

Você também pode ter cobranças de rede caso use o balanceamento de carga HTTP(S) para configurar o HTTPS. Para mais detalhes, consulte Preços de rede.

O exemplo de preço simples na página de preços do Cloud Storage pode ser usado como uma abordagem para o caso de uso de um site estático de baixo tráfego. Use a calculadora de preços para gerar uma estimativa de custo com base no uso previsto.

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 erros comuns relacionados ao uso de um bucket configurado para exibir conteúdo estático do site.

A seguir