Smart shield docs initial

.github/CODEOWNERS

@@ -175,6 +175,7 @@
 /src/content/docs/cache/ @angelampcosta @cloudflare/pcx-technical-writing
 /src/content/docs/health-checks/ @angelampcosta @cloudflare/pcx-technical-writing
 /src/content/docs/load-balancing/ @angelampcosta @cloudflare/pcx-technical-writing
+src/content/docs/smart-shield/ @RebeccaTamachiro @cloudflare/pcx-technical-writing
 /src/content/docs/spectrum/ @angelampcosta @cloudflare/pcx-technical-writing
 /src/content/docs/speed/ @angelampcosta @cloudflare/pcx-technical-writing
 /src/content/docs/web3/ @cloudflare/pcx-technical-writing

src/content/docs/aegis/about/reuse-and-coalescing.mdx

@@ -6,21 +6,11 @@ sidebar:
   label: Reuse and coalescing
 ---
 
-import { Details } from "~/components";
+import { Render } from "~/components";
 
 Aside from [concurrent connections](/aegis/about/ips-allocation/#connections-to-your-origin)[^1], connection reuse and connection coalescing are also important concepts. They both have impact on latency and are considered when allocating your Aegis IPv4 addresses.
 
-Implemented by HTTP/1.1, connection reuse describes multiple requests passing through one same connection (between one source IP:port and one destination IP:port). It is commonly the case even for simple websites nowadays.
-
-<Details header="Example">
-When a connection is initiated for `shop.example.com`, several embedded subresources may be requested - CSS, image files, advertisement, etc. This can mean hundreds of requests just for the website to load. Instead of having a one to one ratio of request per connection, a single connection is used for multiple requests.
-</Details>
-
-With HTTP/2, requests can use the same connection even if they are for different domains.
-
-<Details header="Example">
-A connection initiated for `shop.example.com` can be used for requests for `blog.example.com` as well - as long as the requests have the same destination IP:port and the server TLS certificate is authoritative for both hostnames.
-</Details>
+<Render file="connection-reuse" product="aegis" />
 
 Refer to the [Cloudflare blog post](https://blog.cloudflare.com/aegis-deep-dive/) for further details.
 

src/content/docs/argo-smart-routing/analytics.mdx

@@ -6,13 +6,15 @@ sidebar:
 
 ---
 
+import { Render } from "~/components";
+
 Cloudflare provides analytics to show the performance benefits of Argo Smart Routing.
 
 You can access Argo analytics for your domain in the [Cloudflare dashboard](https://dash.cloudflare.com/) at **Analytics** > **Performance**. For information on all analytics in the dashboard, refer to [Analytics](/analytics/).
 
 ## How it works
 
-Analytics collects data based on the time-to-first-byte (TTFB) from your origin to the Cloudflare network. TTFB is the delay between when Cloudflare sends a request to your server and when it receives the first byte in response. Argo Smart Routing optimizes your server's network transit time to minimize this delay.
+<Render file="argo-analytics" product="smart-shield" />
 
 :::note
 

src/content/docs/argo-smart-routing/index.mdx

@@ -13,12 +13,18 @@ import { CardGrid, Description, Feature, LinkTitleCard, Plan, RelatedProduct, Re
 
 <Description>
 
-Speed up your global traffic with a single click 
+Speed up your global traffic with a single click
 </Description>
 
 <Plan id="traffic.argo.properties.availability.summary" />
 
-Argo Smart Routing detects real-time network issues and routes your web traffic across the most efficient network path, avoiding congestion. This results in faster loading times, increased reliability, and reduced costs. These benefits are most apparent for users farthest from your origin server.
+<Render
+  file="argo-intro"
+  product="smart-shield"
+	params={{
+		conditional: "dedicated-argo-tile"
+	}}
+/>
 
 Learn more about the [benefits of Argo Smart Routing](https://www.cloudflare.com/application-services/products/argo-smart-routing/).
 
@@ -40,15 +46,15 @@ Argo Smart Routing includes comprehensive analytics to compare performance impro
 ## Related products
 
 <RelatedProduct header="Tiered Cache" href="/cache/how-to/tiered-cache/" product="cache">
-Increase cache hit ratios to reduce requests to your origin server. 
+Increase cache hit ratios to reduce requests to your origin server.
 </RelatedProduct>
 
 <RelatedProduct header="China Network" href="/china-network/" product="china-network">
-Improve security and performance within mainland China. 
+Improve security and performance within mainland China.
 </RelatedProduct>
 
 <RelatedProduct header="Magic Transit" href="/magic-transit/" product="magic-transit">
-Reduce latency and protect from DDoS attacks using the Cloudflare network. 
+Reduce latency and protect from DDoS attacks using the Cloudflare network.
 </RelatedProduct>
 
 ***

src/content/docs/cache/advanced-configuration/cache-reserve.mdx

@@ -5,7 +5,7 @@ pcx_content_type: concept
 
 import { Render, TabItem, Tabs, APIRequest } from "~/components";
 
-Cache Reserve is a large, persistent data store [implemented on top of R2](/r2/). By pushing a single button in the dashboard, your website’s cacheable content will be written to Cache Reserve. In the same way that [Tiered Cache](/cache/how-to/tiered-cache/) builds a hierarchy of caches between your visitors and your origin, Cache Reserve serves as the ultimate [upper-tier cache](/cache/how-to/tiered-cache/) that will reserve storage space for your assets for as long as you want. This ensures that your content is served from cache longer, shielding your origin from unneeded egress fees.
+<Render file="cache-reserve-intro" product="cache" />
 
 ![Content served from origin and getting cached in Cache Reserve, and Edge Cache Data Centers (T1=upper-tier, T2=lower-tier) on its way back to the client](~/assets/images/cache/content-being-served.png)
 
@@ -41,21 +41,11 @@ If you are an Enterprise customer and are interested in Cache Reserve, contact y
 
 ## Cache Reserve asset eligibility
 
-Not all assets are eligible for Cache Reserve. To be admitted into Cache Reserve, assets must:
-
-- Be cacheable, according to Cloudflare's standard [cacheability factors](/cache),
-- Have a freshness time-to-live (TTL) of at least 10 hours (set by any means such as Cache-Control / [CDN-Cache-Control](/cache/concepts/cache-control/) origin response headers, [Edge Cache TTL](/cache/how-to/edge-browser-cache-ttl/#edge-cache-ttl), [Cache TTL By Status](/cache/how-to/configure-cache-status-code/), or [Cache Rules](/cache/how-to/cache-rules/)),
-- Have a Content-Length response header.
-- When using [Image transformations](/images/manage-images/create-variants/), original files are eligible for Cache Reserve, but resized file variants are not eligible because transformations happen after Cache Reserve in the response flow.
+<Render file="cache-reserve-eligibility" product="cache" />
 
 ## Limits
 
-- Cache Reserve file limits are the same as [R2 limits](/r2/platform/limits/). Note that [CDN cache limits](/cache/concepts/default-cache-behavior/#customization-options-and-limits) still apply. Assets larger than standard limits will not be stored in the standard CDN cache, so these assets will incur Cache Reserve operations costs far more frequently.
-- Origin Range requests are not supported at this time from Cache Reserve.
-- [Vary for images](/cache/advanced-configuration/vary-for-images/) is currently not compatible with Cache Reserve.
-- Requests to [R2 public buckets linked to a zone's domain](/r2/buckets/public-buckets/) will not use Cache Reserve. Enabling Cache Reserve for the connected zone will use Cache Reserve only for requests not destined for the R2 bucket.
-- Cache Reserve makes requests for uncompressed content directly from the origin. Unlike the standard Cloudflare CDN, Cache Reserve does not include the `Accept-Encoding: gzip` header when sending requests to the origin.
-- Cache Reserve is bypassed when using the Cloudflare [O2O](/cloudflare-for-platforms/cloudflare-for-saas/saas-customers/how-it-works/) setup.
+<Render file="cache-reserve-limits" product="cache" />
 
 ## Usage
 
@@ -108,27 +98,10 @@ For example:
 
 ### Operations
 
-Operations are performed by Cache Reserve on behalf of the user to write data from the origin to Cache Reserve and to pass that data downstream to other parts of Cloudflare’s network. These operations are managed internally by Cloudflare.
-
-#### Class A operations (writes)
-
-Class A operations are performed based on cache misses from Cloudflare’s CDN. When a request cannot be served from cache, it will be fetched from the origin and written to cache reserve as well as our edge caches on the way back to the visitor.
-
-#### Class B operations (reads)
-
-Class B operations are performed when data needs to be fetched from Cache Reserve to respond to a miss in the edge cache.
-
-#### Purge
-
-Asset purges are free operations.
-
-Cache Reserve will be instantly purged along with edge cache when you send a purge by URL request.
-
-Other purge methods, such as purge by tag, host, prefix, or purge everything will force an attempt to [revalidate](/cache/concepts/cache-responses/#revalidated) on the subsequent request for the Cache Reserve asset. Note that assets purged this way will still incur storage costs until their retention TTL expires.
-
-:::note
-Note this differs from the standard CDN's purge by tag, host, or prefix features which force a cache miss, requiring the origin to deliver the asset in full.
-:::
+<Render
+  file="cache-reserve-operations"
+  product="cache"
+/>
 
 ## Cache Reserve billing examples
 
@@ -171,16 +144,13 @@ Cache Reserve should be used with [Tiered Cache](/cache/how-to/tiered-cache/) en
 
 ## Cache Reserve Analytics
 
-Cache Reserve Analytics provides insights regarding your Cache Reserve usage. It allows you to check what content is stored in Cache Reserve, how often it is being accessed, how long it has been there and how much egress from your origin it is saving you.
-
-In the **Overview** section, under **Cache Reserve**, you have access to the following metrics:
-
-- **Egress savings (bandwidth)** - is an estimation based on response bytes served from Cache Reserve that did not need to be served from your origin server. These are represented as cache hits.
-- **Requests served by Cache Reserve** - is the number of requests served by Cache Reserve (total).
-- **Data storage summary** - is based on a representative sample of requests. Refer to [Sampling](/analytics/graphql-api/sampling/) for more details about how Cloudflare samples data.
-  - **Current data stored** - is the data stored (currently) over time.
-  - **Aggregate storage usage** - is the total of storage used for the selected timestamp.
-- **Operations** - [Class A](/cache/advanced-configuration/cache-reserve/#class-a-operations-writes) (writes) and [Class B](/cache/advanced-configuration/cache-reserve/#class-b-operations-reads) (reads) operations over time.
+<Render
+  file="cache-reserve-analytics"
+	product="cache"
+	params={{
+		conditional: "dedicated-cache-tile"
+	}}
+/>
 
 ## Cache Reserve clear button
 

src/content/docs/cache/how-to/tiered-cache.mdx

@@ -4,7 +4,7 @@ pcx_content_type: concept
 
 ---
 
-import { Details, FeatureTable, APIRequest } from "~/components";
+import { Details, FeatureTable, APIRequest, Render } from "~/components";
 
 Tiered Cache uses the size of Cloudflare’s network to reduce requests to customer origins by dramatically increasing cache hit ratios. With data centers around the world, Cloudflare caches content very close to end users. However, if a piece of content is not in cache, the Cloudflare edge data centers must contact the origin server to receive the cacheable content.
 
@@ -20,29 +20,17 @@ Cloudflare allows you to select your cache topology so that you have control ove
 
 ### Smart Tiered Cache
 
-Smart Tiered Cache dynamically selects the single closest upper tier for each of your website’s origins with no configuration required, using our in-house performance and routing data. Cloudflare collects latency data for each request to an origin, and uses the latency data to determine how well any upper-tier data center is connected with an origin. As a result, Cloudflare can select the data center with the lowest latency to be the upper-tier for an origin.
-
-#### Load Balancing interaction
-
-While Smart Tiered Cache selects one Upper Tier per origin, when using Load Balancing, Smart Tiered Cache will select the single best Upper Tier for the entire Load Balancing Pool.
-
-#### Caveats
-
-Smart Tiered Cache does not work when an origin is behind an [anycast](https://www.cloudflare.com/en-gb/learning/cdn/glossary/anycast-network/) or a regional unicast network because that will prevent us from knowing where the origin is located. As a result, we are unable to select the optimal upper tier and latency may be negatively impacted.
-
-You need to be careful when updating your origin IPs/DNS records while Smart Tiered Cache is enabled. Depending on the changes made, it may cause the existing assigned upper tiers to change, resulting in an increased `MISS` rate as cache is refilled in the new upper tiers. If the origin is switched to a network behind anycast, it will significantly reduce the effectiveness of Smart Tiered Cache.
-
-If you need to use anycast or regional unicast and want to use Smart Tiered cache, please engage your account team.
+<Render file="smart-tiered-cache" product="cache" />
 
 ### Generic Global Tiered Cache
 
 Generic Global topology allows for all of Cloudflare’s global data centers to serve as a network of upper-tiers. This topology may help reduce the long tail latencies for far-away visitors.
 
 ### Regional Tiered Cache
 
-Regional Tiered Cache provides an additional layer of caching for Enterprise customers who have a global traffic footprint and want to serve content faster by avoiding network latency when there is a cache `MISS` in a lower-tier, resulting in an upper-tier fetch in a data center located far away.
+<Render file="regional-tiered-cache" product="cache" />
 
-Regional Cache instructs Cloudflare to check a regional hub data center near the lower tier before going to the upper tier that may be outside of the region. This can help improve performance for **Smart** and **Custom Tiered Cache** topologies with upper-tiers in one or two regions. Regional Tiered Cache is not beneficial for customers with many upper tiers in many regions like Generic Global Tiered Cache.
+This can help improve performance for **Smart** and **Custom Tiered Cache** topologies with upper-tiers in one or two regions. Regional Tiered Cache is not beneficial for customers with many upper tiers in many regions like Generic Global Tiered Cache.
 
 ### Custom Tiered Cache
 

src/content/docs/health-checks/concepts/health-checks-regions.mdx

@@ -6,16 +6,6 @@ sidebar:
 
 ---
 
-Cloudflare has data centers in [hundreds of cities worldwide](https://www.cloudflare.com/network/). Health checks do not run from every single of these data centers as this would result in numerous requests to your servers. Instead, you are able to choose between one and thirteen regions from which to run health checks. Cloudflare will run Health Checks from three data centers in each region that you select.
+import { Render } from "~/components";
 
-:::note
-
-
-The exact location of these data centers are subject to change at any moment.
-
-
-:::
-
-The Internet is not the same everywhere around the world and your users may not have the same experience on your application according to where they are. Running Health Checks from different regions lets you know the health of your application from the point of view of the Cloudflare network in each of these regions.
-
-If you select multiple regions or choose **All Regions** (Business & Enterprise Only), you may increase traffic to your servers. Each region sends individual health checks from three data centers.
+<Render file="health-checks-regions" product="smart-shield" />

src/content/docs/health-checks/get-started.mdx

@@ -6,6 +6,8 @@ sidebar:
 
 ---
 
+import { Render } from "~/components";
+
 This guide will get you started with creating and managing configured Health Checks.
 
 ## Create a Health Check