Fix markdown formatting for improving-varnish-hit-rate-on-hypernode.md

Author: Jonathan Visser

docs/hypernode-platform/varnish/improving-varnish-hit-rate-on-hypernode.md

@@ -1,7 +1,7 @@
 ---
 myst:
   html_meta:
-    description:  Learn how to improve your Varnish cache hit rate on Hypernode by identifying automatic cache purges, analyzing hit/miss patterns, and optimizing URL normalization to boost performance and efficiency.
+    description: Learn how to improve your Varnish cache hit rate on Hypernode by identifying automatic cache purges, analyzing hit/miss patterns, and optimizing URL normalization to boost performance and efficiency.
     title: Improving Varnish Cache Hit Rate on Hypernode
 ---
 
@@ -17,13 +17,15 @@ This guide takes you step-by-step from verifying that your cache is active to di
 ## Before You Begin
 
 Typical cache hit rates:
-- **Below 10%** → Cache is barely reused  
-- **30–70%** → Improvement possible (depends on shop type and traffic patterns) 
-- **Above 80%** → Generally healthy for most shops 
+
+- **Below 10%** → Cache is barely reused
+- **30–70%** → Improvement possible (depends on shop type and traffic patterns)
+- **Above 80%** → Generally healthy for most shops
 
 Keep in mind:
-- Staging environments typically have low hit rates  
-- B2B webshops often have lower hit rates due to personalization  
+
+- Staging environments typically have low hit rates
+- B2B webshops often have lower hit rates due to personalization
 - Recently flushed caches temporarily reduce hit rates until the cache warms up
 
 Cache hit rate should always be evaluated in context. Traffic volume, personalization, and recent deployments directly affect cache reuse.
@@ -32,11 +34,11 @@ Cache hit rate should always be evaluated in context. Traffic volume, personaliz
 
 A low hit rate does not always indicate a problem. It is normal when:
 
-- Traffic volume is low  
-- The cache was recently flushed  
-- Most visitors are logged in  
-- The shop uses heavy personalization  
-- You are working in a staging environment  
+- Traffic volume is low
+- The cache was recently flushed
+- Most visitors are logged in
+- The shop uses heavy personalization
+- You are working in a staging environment
 
 Investigate further only if traffic is stable, the cache is warmed up, and the hit rate remains consistently low.
 
@@ -46,7 +48,8 @@ Ensure Varnish is properly enabled on your vhost and configured in your
 application (e.g. Magento 2).
 
 For Magento 2, verify:
-- That Varnish is enabled on the vhost  
+
+- That Varnish is enabled on the vhost
 - Varnish is selected as the caching application
 - The correct VCL is generated and loaded
 - Full Page Cache (FPC) is enabled
@@ -60,10 +63,13 @@ Tip: The [elgentos/magento2-varnish-extended](https://github.com/elgentos/magent
 ## Step 2 — Check if Pages Are Being Cached
 
 Using `varnishncsa` from the CLI to see in real time which pages are cached and which are not:
-```console 
+
+```console
 varnishncsa -F '%U%q %{Varnish:hitmiss}x'
 ```
+
 Look for:
+
 - `hit` → Served from Varnish
 - `miss` → Served from backend
 
@@ -75,16 +81,16 @@ curl -I https://yourdomain.com
 
 Review the following headers:
 
-- **`Set-Cookie`**  
+- **`Set-Cookie`**\
   If a Set-Cookie header (such as PHPSESSID) is present, Varnish will typically not cache the response.
 
-- **`Cache-Control`**  
+- **`Cache-Control`**\
   Should **not** contain `private`, `no-store`, or `no-cache`.
 
-- **`Age`**  
+- **`Age`**\
   Indicates how long (in seconds) the object has been cached.
 
-- **`X-Magento-*`**  
+- **`X-Magento-*`**\
   Provides Magento cache/debug information (visible in developer mode).
 
 If most responses return `MISS` (for example in `X-Magento-Cache-Debug` or similar headers), caching is not being reused effectively.
@@ -101,6 +107,7 @@ varnishstat -1 -f MAIN.cache_hit -f MAIN.cache_miss
 ```
 
 This shows:
+
 - `MAIN.cache_hit` → Cached responses served
 - `MAIN.cache_miss` → Requests sent to backend
 
@@ -113,6 +120,7 @@ varnishlog
 ```
 
 Look for:
+
 - `VCL_call HIT` → Served from Varnish
 - `VCL_call MISS` → Served from backend
 - `Age` → Indicates how long (in seconds) the object has been cached.
@@ -125,6 +133,7 @@ Alternatively, reuse the varnishncsa command from Step 2 for live hit/miss monit
 ### 1. Pages Bypassing Varnish
 
 Some pages are intentionally not cached:
+
 - Checkout
 - Customer account pages
 - Requests containing `Set-Cookie` headers
@@ -136,6 +145,7 @@ This is expected behavior.
 If cache clears happen frequently, cache reuse becomes nearly impossible.
 
 Common causes:
+
 - Stock or pricing integrations
 - Magento cron jobs performing full cache purges
 - Extensions invalidating excessive cache entries
@@ -149,12 +159,14 @@ flushes.
 Tracking parameters create separate cache entries for identical content.
 
 Examples:
+
 - `utm_source`
 - `utm_medium`
 - `gclid`
 - `fbclid`
 
 Example problem:
+
 - /product-x
 - /product-x?utm_source=google
 
@@ -172,6 +184,7 @@ The [elgentos/magento2-varnish-extended](https://github.com/elgentos/magento2-va
 Different URL formats fragment your cache.
 
 Examples:
+
 - `/category` vs `/category/`
 - `?Color=Red` vs `?color=red`
 - Unsorted query parameters
@@ -190,6 +203,7 @@ grep -R "cacheable=\"false\"" app/code vendor
 ```
 
 If found:
+
 - Verify the block truly needs to be dynamic
 - Remove cacheable="false" if unnecessary
 - Use AJAX or Customer Data Sections for dynamic content
@@ -204,7 +218,7 @@ Enable developer mode temporarily for debugging purposes:
 magerun2 deploy:mode:set developer
 ```
 
-Or: 
+Or:
 
 ```console
 php bin/magento deploy:mode:set developer
@@ -215,25 +229,31 @@ php bin/magento deploy:mode:set developer
 ### varnishlog
 
 Inspect detailed request handling:
+
 ```console
 varnishlog
 ```
+
 Look for recurring MISS patterns on pages that should be cacheable.
 
 ### varnishncsa
 
 Show hit/miss per URL:
+
 ```console
 varnishncsa -F '%U%q %{Varnish:hitmiss}x'
 ```
+
 Filter for hits:
+
 ```console
 varnishncsa -F '%U%q %{Varnish:hitmiss}x' | grep hit
 ```
 
 ### Hypernode Insights (If Available)
 
 Use Hypernode Insights to:
+
 - Monitor hit/miss ratios
 - Detect purge spikes
-- Correlate cache drops with deployments or cron jobs
+- Correlate cache drops with deployments or cron jobs