Ejemplos y consejos de sitios web estáticos

En esta página, se muestran ejemplos y consejos sobre usar buckets para alojar un sitio web estático.

Páginas especializadas

Páginas de índice

Una página de índice (también llamada índice de directorio de servidor web) es un archivo que se entrega a los visitantes cuando solicitan una URL que no tiene un archivo asociado. Cuando asignas una propiedad MainPageSuffix, Cloud Storage busca un archivo con ese nombre cuyo prefijo coincida con la URL que solicitó el visitante.

Por ejemplo, supongamos que configuraste el MainPageSuffix de tu sitio web estático como index.html. Además, supongamos que no tienes un archivo llamado directory en tu bucket www.example.com. En esta situación, si un usuario solicita la URL http://www.example.com/directory, Cloud Storage intenta entregar el archivo www.example.com/directory/index.html. Si ese archivo tampoco existe, Cloud Storage muestra una página de error.

El MainPageSuffix también controla el archivo que se entrega cuando los usuarios solicitan el sitio de nivel superior. En el mismo ejemplo anterior, si un usuario solicita http://www.example.com, Cloud Storage intenta entregar el archivo www.example.com/index.html.

Cuando intentas acceder a una URL con una barra diagonal, como http://www.example.com/dir/, consulta Solución de problemas.

Página de error

La página de error es el archivo que se muestra a los visitantes del sitio estático que solicitan una URL que no corresponde a un archivo existente. Si asignaste un MainPageSuffix, Cloud Storage solo muestra la página de error si no hay un archivo con el nombre solicitado ni una página de índice aplicable.

Cuando se muestra una página de error, el código de respuesta HTTP es 404. La propiedad que controla qué archivo actúa como página de error es NotFoundPage. Si no configuras NotFoundPage, los usuarios reciben una página de error genérica.

Ejemplos de configuración del sitio web

Bucket de tres objetos

Supongamos que un depósito llamado www.example.com se configuró como un sitio web con los siguientes archivos y opciones de configuración:

• MainPageSuffix = “index.html”
• NotFoundPage = "404.html"
• El bucket contiene tres objetos compartidos públicamente: "index.html", "404.html" y "dir / index.html"

Nota: Es posible que exista un objeto vacío en http://www.example.com/dir/. Si existe un objeto vacío, este se muestra en lugar del archivo index.html del directorio. Consulta el tema sobre la solución de problemas si obtienes una respuesta HTTP 301 cuando intentas acceder a http://www.example.com/dir/.

En la siguiente tabla, se muestra el contenido entregado para las URL seleccionadas:

URL solicitada	Contenido entregado	Código de respuesta HTTP
http://www.example.com http://www.example.com/ http://www.example.com/index.html	El objeto "index.html"	200
http://www.example.com/hello	El objeto "404.html"	404
http://www.example.com/dir/index.html	El objeto "dir / index.html"	200
http://www.example.com/dir	El objeto "dir / index.html"	301
http://www.example.com/dir/	El objeto "dir / index.html", si suponemos que no existe ningún objeto de cero bytes para / dir /	200
	Un objeto vacío de cero bytes, si existe para / dir /. Consulta el tema sobre la solución de problemas para quitar este objeto de cero bytes.	301

Bucket de dos objetos

Supongamos que un depósito llamado www.example.com se configuró como un sitio web con los siguientes archivos y opciones de configuración:

• MainPageSuffix = “main.html”
• NotFoundPage = "404.html"
• El bucket contiene dos objetos compartidos de manera pública: “main.html” y “404.html”

En la siguiente tabla, se muestra el contenido entregado para las URL seleccionadas:

URL solicitada	Contenido entregado	Código de respuesta HTTP
http://www.example.com http://www.example.com/	El objeto "main.html"	200
http://www.example.com/index.html	El objeto "404.html"	404

Si un objeto se comparte de manera pública, también puedes ver ese objeto con la siguiente URL:

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

Por ejemplo, la siguiente sería la URL de un objeto index.html:

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

Para obtener más información sobre cómo trabajar con datos de acceso público, consulta Acceso a datos públicos.

Sugerencias para trabajar con un bucket configurado como sitio web

Las siguientes son algunas sugerencias que debes tener en cuenta cuando uses un bucket para alojar un sitio web estático.

Agrega subdominios

Supongamos que también deseas entregar contenido en test.example.com desde un bucket diferente del que entrega contenido en www.example.com. Para ello, deberás hacer lo siguiente:

1. Crea un bucket nuevo para publicar tu contenido adicional.

2. Si seguiste el instructivo en Aloja un sitio web estático para entregar el contenido a través de HTTPS, edita tu balanceador de cargas en la consola de Google Cloud de la siguiente manera:

   1. En Configuración de backend, crea un bucket de backend nuevo test-bucket, para ello, selecciona el bucket nuevo que creaste.
   2. En Reglas de host y ruta de acceso, agrega una regla nueva de la siguiente manera:

      Hosts                  Paths     Backends
      test.example.com       /*        test-bucket
      

   3. Para la Configuración de frontend, agrega una IP y puerto de frontend nuevos con los mismos valores que la primera configuración, con las siguientes excepciones:

      • En Dirección IP, crea y reserva una dirección IP nueva.
      • En Certificado, crea un certificado SSL nuevo para test.example.com.

3. Después de actualizar el balanceador de cargas, agrega un registro A nuevo a tu servicio de registro de dominio mediante la dirección IP de la configuración de frontend nueva:

   NAME                  TYPE     DATA
   test                  A        IP_ADDRESS
   

Nota: Si entregas sin un balanceador de cargas mediante un redireccionamiento CNAME, el nombre de tu bucket debe coincidir con el subdominio test.example.com. En esta situación, debido a que ya verificaste el dominio example.com, puedes crear buckets para admitir subdominios sin verificación adicional. Una vez que hayas creado tu bucket nuevo, agrega un registro CNAME nuevo para el subdominio:

NAME                  TYPE     DATA
test                  CNAME    c.storage.googleapis.com.

Comportamiento de la API

La configuración de sitios web MainPageSuffix y NotFoundPage solo se usa para solicitudes que llegan a Cloud Storage a través de un redireccionamiento CNAME o A. Por ejemplo, con una solicitud a www.example.com, se muestra la página de índice, pero con una solicitud equivalente a storage.googleapis.com/www.example.com, no.

Por lo tanto, se conserva el comportamiento de la API para las solicitudes a dominios de Cloud Storage, como storage.googleapis.com/www.example.com. Por ejemplo, puedes continuar enumerando objetos del bucket www.example.com, como lo harías con cualquier otro bucket. En el caso del bucket www.example.com, la lista de objetos que recibes incluye 404.html y index.html.

Aloja elementos estáticos en un sitio web dinámico

Puedes usar Cloud Storage para alojar elementos estáticos en un sitio web dinámico alojado, por ejemplo, en Google App Engine o en Google Compute Engine. Algunos beneficios de alojar tus elementos estáticos, como imágenes o archivos JavaScript, en un bucket incluyen los siguientes:

• Cloud Storage se comporta como una red de distribución de contenido (CDN) porque los objetos legibles de forma pública se almacenan en caché en la red de Cloud Storage de forma predeterminada.

• Generalmente, el costo de los cargos de ancho de banda para acceder al contenido es menor con Cloud Storage.

• La carga en tus servidores web se reduce cuando se entrega el contenido estático de Cloud Storage.

Cuando alojas elementos estáticos para un sitio web dinámico, no necesitas crear registros DNS y apuntar a un bucket o balanceador de cargas como lo haces con un sitio web estático. Por ejemplo, podrías tener un bucket llamado www_example_com_assets con los elementos apropiados configurados como compartidos públicamente y, luego, acceder a esos elementos con el dominio de Cloud Storage. Por ejemplo, si tienes un archivo JavaScript library.js en el bucket www_example_com_assets, el cual se comparte de forma pública, puedes acceder a él como http://storage.googleapis.com/www_example_com_assets/library.js.

Configura parámetros de caché

Cuando configuras los metadatos Cache-Control, puedes controlar si los elementos del sitio web se almacenan en caché o cómo lo hacen. En general, solo configura los metadatos de control de caché con los objetos que son accesibles a todos los usuarios anónimos, lo cual es un requisito para cualquier objeto entregado desde un bucket de Cloud Storage como parte de un sitio web estático.

Cloud Storage aplica una configuración de control de caché de 3,600 segundos a los objetos a los que pueden acceder todos los usuarios anónimos, a menos que especifiques una configuración de control de caché explícita. Consulta Ve y edita metadatos para obtener instrucciones sobre cómo configurar metadatos de objetos, como Cache-Control.

También puedes usar Cloud CDN para almacenar en caché contenido con balanceo de cargas HTTP(S) externo cerca de tus usuarios, lo que a menudo reduce los costos de servicio. Para obtener más información, consulta Almacenamiento en caché.

Supervisa tus cargos

Si entregas elementos de un bucket configurado como un sitio web estático o entregas elementos estáticos de un bucket para un sitio web dinámico alojado fuera de Cloud Storage, debes supervisar los cargos al proyecto que contiene el bucket. La entrega de contenido genera costos de Cloud Storage por almacenar el contenido, usar la red y realizar operaciones de recuperación. Para obtener más información, consulta la página Precios de Cloud Storage.

También puedes generar cargos de red si usas un balanceador de cargas de aplicaciones externo para configurar HTTPS. Para obtener más detalles, consulta Precios de red.

El ejemplo simple de precios en la página de ejemplos de precios se puede usar como una aproximación para el caso de uso de un sitio web estático de tráfico bajo. Sin embargo, ten presente que en el ejemplo no se tienen en cuenta los cargos asociados con el balanceador de cargas de aplicaciones externo, que suele ser el mayor cargo por el hosting de sitios web estáticos. Puedes usar la calculadora de precios para generar una estimación de costos según el uso previsto.

Es posible que los usuarios nuevos de Google Cloud sean aptos para obtener una prueba gratuita.

Si eres un usuario actual de Google Cloud, puedes obtener un desglose detallado de los costos de tu proyecto en la página de facturación.

Soluciona problemas

Consulta Solución de problemas a fin de obtener más información sobre problemas comunes asociados con el uso de un depósito configurado para entregar contenido de sitios web estáticos.

¿Qué sigue?

• Prueba otros instructivos de Google Cloud que usan Cloud Storage.
• Obtén información sobre otras opciones de entrega web en Google Cloud.

Pruébalo tú mismo

Si es la primera vez que usas Google Cloud, crea una cuenta para evaluar el rendimiento de Cloud Storage en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.

Probar Cloud Storage gratis