Global static content delivery: setting up Cloud CDN in GCP

Setting Up GCP Cloud CDN: Where Static Delivery Breaks

Setting up GCP Cloud CDN solves one specific problem: when static assets are served from the application server, every request for an image, stylesheet, or font occupies a handler that at that moment is not serving dynamic content.

While traffic is moderate, this goes unnoticed, but the bottleneck under peak load appears exactly when the number of concurrent requests exceeds the handler pool and the queue starts growing faster than it can be drained.

Then response time increases nonlinearly: some requests reach the load balancer timeout and return an error, even though the server itself is alive. The markup arrives quickly, while heavy files arrive with a delay, so the page assembles in fits and starts.

Repeated requests for the same objects increase the load on the origin, and it stops responding even to what it previously handled calmly.

A separate class of failures is slow image delivery on long-haul routes. Without a delivery node near the user, every file travels halfway around the world, loses packets on mobile connections, and is cut off mid-transfer. The browser requests the object again, and the origin receives double the load for the same frame.

Deploying a new site version adds a burst of errors: while the cache contents and origin diverge, some visitors get new markup with old files or vice versa. This mismatch persists from a few minutes to an hour, and during that entire time some pages look broken.

Below we break down how this is solved at the delivery layer — from choosing the caching mode to purge rules during deployment.

What Caching at the Network Edge Provides

Network edge caching is an intermediate layer between the user and the origin: static assets are served from the point of presence closest to the visitor, not from the server.

The first request pulls the object from the origin and places it in the cache; all subsequent responses bypass the application. Cloud CDN connects to the same external load balancer, so routing rules and certificates do not have to be maintained in two places.

Response Time and Page Load Completeness

The benefit is visible not in the average but in the tail of the distribution: the 95th percentile response time is reduced severalfold because the request no longer travels across the ocean to the origin.

The basis for this is file name versioning and a long object lifetime in the cache: a release update changes the names, the old and new versions live in parallel, and the browser does not pull a stale file.

A side effect is that pages load more completely: all resources come from one nearby location instead of waiting in turn for a slow origin.

Offloading the Origin and Behavior Under Peaks

The cache hit ratio for static assets usually stays above 90%, and the origin stops being a bottleneck: it handles dynamic content rather than serving files.

When an update is released and thousands of users request the new version simultaneously, identical requests collapse into a single origin fetch — the class of errors during mass content updates disappears.

Independent measurements when compared with direct delivery show the same picture: traffic peaks are absorbed at the edge and do not reach the servers.

Static Delivery Methods: What to Choose for the Task

Static delivery methods differ not in speed in general, but in where content is cached and who is responsible for invalidation. Below are the options that teams actually choose between when moving to global delivery.

Direct Serving from Object Storage

Object storage serves files directly, without an intermediate cache: this is a workable option for internal builds, artifacts, and an audience in a single region.

Limitations appear as you grow — latency increases with client distance, each request consumes read operations, and frequent access to a single object hits a ceiling.

Custom Cache Layer vs. Managed Delivery

A custom cache layer gives full control over caching rules, but requires nodes in every region, on-call support, and updates. Managed delivery moves edge nodes and invalidation to the provider — the team is left with configuration.

The choice is determined by constraints, not capabilities: a hybrid is justified when part of the content is cached for a long time, while part changes with every release and requires cache purging by file name.

Setup Procedure: From Audit to Handover

We set up delivery step by step: until content types and the routing scheme are fixed, any caching rules will have to be rewritten after the very first update.

The procedure below eliminates rework during domain connection and makes Cloud CDN behavior predictable from the first request.

What We Fix During the Audit Stage

We build a map: which paths are served as static, which as dynamic, where file versions live, and what changes with each release. Separately, we list requests with parameters and headers that must not enter the shared cache key.

1. Content inventory. File types, retention periods, file name versioning scheme — this determines whether a file can be cached for a long time.
2. Request routing scheme. A map of paths to backend buckets and services, rule order, and behavior for non-existent addresses.
3. Caching rules. What goes into the cache key, which headers and parameters are ignored, default TTLs, and overrides for individual paths.
4. Domain and certificate connection. Binding the domain to delivery, issuing a managed certificate, validation checks, and traffic switching.
5. Testing against control scenarios. Cold and repeat requests, file updates, forced cache purge, and correctness of response headers.
6. Observability. Request logs, cache hit ratio, and edge response time — these show that the setup works rather than merely looks configured.
7. Handover and training. Deployment and cache purge procedures, test environment scheme, and walkthrough with the team that will subsequently run delivery on its own.

Delivery Configurations, Schemes, and Procedures

We hand over not a set of panel settings but a reproducible kit: configurations in version control, a traffic routing scheme, and procedures according to which the client's team can subsequently work independently.

Every artifact is tested on a staging environment — during incident analysis, it is clear which rule governs cache behavior.

• Distribution and origin configuration files — with a description of each parameter's purpose.
• Routing scheme: which paths and content types go to cache and which go directly to the origin.
• Content access policies: signed URLs, restrictions by region and request headers.
• Cache invalidation rules: what is purged selectively and what is purged by path mask.
• Delivery documentation: domains, entry points, responsible parties, and diagnostic procedure.
• Procedure for version updates and incident analysis.

Routing Scheme and Caching Rules

We describe which paths are cached and for how long, how requests with parameters are handled, and what happens when the origin is unavailable. The scheme shows the chain from the user to storage — using it, an engineer without us can find where the cache is being lost.

Procedure for Version Updates and Invalidation

We fix the release order: build the artifact, upload it, warm the new version, switch traffic, purge stale content. A separate section covers the rollback rule and the procedure if the cache serves the previous version, with verification steps and expected system behavior.

Origin Offload: Implementation Results

A project with a large volume of media and high peak traffic served static assets directly from the origin: script and style bundles, fonts, images.

At peaks, the origin hit its ceiling, static response time grew, and publishing a new version sometimes served clients a mix of old and new files and ended in a wave of errors. We connected Cloud CDN as a separate delivery layer and reworked cache handling.

The key change was asset name versioning: a hash in the file name made it possible to keep a long TTL for static assets and a short TTL for pages, while invalidation was reduced to updating a single manifest.

The cache key was cleaned of random query parameters, prewarming was configured for popular files, and rules for different paths were separated into distinct policies.

Metrics Before and After

Measurements were taken on real traffic, comparing origin metrics, cache hits, and publication errors over identical periods before and after.

The origin stopped being a bottleneck and returned to handling dynamic content, while releasing a new version is no longer accompanied by sorting through complaints about "broken" layout.

What to Do If Static Assets Are Already Served Through a Third-Party CDN?

Delivery can be migrated without downtime if the addresses that clients and search engines access are not changed.

The domain remains the same; only the target it points to changes: first a third-party service, then an external load balancer with an origin bucket and caching enabled. The record is switched last, after the new configuration has been tested on a separate test name.

Pre-switch testing is a shadow run: some requests go to the new delivery via a test domain or a separate header, and we compare response codes, caching headers, miss behavior, compressed file delivery, and range requests.

We separately review large and infrequently requested objects — discrepancies most often surface there.

Accumulated rules — redirects, object TTLs by file type, signed URL restrictions, request source filters — are transferred into cache policies and routing rules.

If a rule has no direct equivalent, it is moved to the application layer: preserving behavior matters more than neatly completing the migration.

A rollback plan is prepared in advance: the old delivery remains operational and populated until the end of migration, the DNS record TTL is lowered ahead of time, and rollback is a reverse target change that takes minutes. Main traffic is switched in waves: first one share of requests or one direction, then the rest.

Technical Doubts Before Implementation

An engineer's questions before deployment are almost always the same: how quickly will a change reach the user, what happens if the origin goes down, will this break the build. We answer each one at the configuration level, not with generalities.

What is served if the origin is unavailable?

As long as the cached copy is alive, the edge node serves it without contacting the origin — the user does not notice the bucket being down. Errors are cached separately and with a short TTL so that a 404 does not stick for hours.

Additionally, we keep object versioning and a backup bucket that can be switched by changing the origin address.

Does CDN affect the build and deployment?

The build does not change — a step for publishing artifacts and, if necessary, cache purging is added. If file names contain a content hash, they are immutable: we deploy the new version without invalidation, and keep a short TTL only for the entry point. This way, the release does not depend on the purge quota.

How to restrict access and avoid hotlinking?

A private bucket plus signed URLs with a limited lifetime: an external resource cannot embed your file and consume traffic. For streaming video, the signature is issued per session via cookie. Additionally, we block third-party domains by checking the request source.

Where to view cache statistics?

The key metric is the cache hit ratio, broken down by response code and object type. For static assets it stays high, for pages with a short TTL it is low — and that is normal. We look at delivery volume, top addresses, and misses; per-request detail is enabled in cloud logs.

Let's Discuss the Static Delivery Task and Work Plan

To come back with a work plan and estimate, you do not need to prepare a technical specification — what you already have is enough: delivery schemes, logs, and an audience description.

The more specific the input data, the fewer assumptions in the estimate and the more predictable the timelines. Below is what is useful to have on hand for discussing the delivery task.

• Content types and volume: static pages, images, video, fonts, storage volume, and daily growth — this determines the caching strategy and the number of origins.
• User geography: where the main audiences are and their shares of traffic — this determines the composition of points of presence and request routing rules.
• Current delivery scheme: where content is served from now, which caching headers are set, and what is already configured on the origin side.
• Access requirements: private files, signed URLs, country restrictions, and protection of the origin from direct requests.
• Target metrics: static response time, expected cache hit ratio, and acceptable content staleness after publication.
• Publication process: how and how often content is updated, whether a forced cache purge by button is needed, and who is responsible for deployment.
• Organizational inputs: access to cloud projects, security policies, and a convenient window for production changes.

With this set, we assemble a work plan: stages, the scope of changes in the delivery configuration, a post-switch verification scheme, and the points where your participation will be required. Describe the delivery task in free form — we will come back with an estimate and a plan.