From 73f1e4f2bb7e8b5883d2ade85b4057923272a2e3 Mon Sep 17 00:00:00 2001
From: Tim Veluwenkamp <TimVNL@users.noreply.github.com>
Date: Mon, 22 Dec 2025 15:02:02 +0100
Subject: [PATCH 01/10] + Improving Varnish Cache Hit Rate

---
 .../tools/improving-varnish-cache-hit.rate.md | 135 ++++++++++++++++++
 1 file changed, 135 insertions(+)
 create mode 100644 docs/hypernode-platform/tools/improving-varnish-cache-hit.rate.md

diff --git a/docs/hypernode-platform/tools/improving-varnish-cache-hit.rate.md b/docs/hypernode-platform/tools/improving-varnish-cache-hit.rate.md
new file mode 100644
index 00000000..41ae7db6
--- /dev/null
+++ b/docs/hypernode-platform/tools/improving-varnish-cache-hit.rate.md
@@ -0,0 +1,135 @@
+---
+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.
+    title: Improving Varnish Cache Hit Rate on Hypernode
+---
+
+# Improving Varnish Cache Hit Rate
+
+An improved **Varnish hit rate** ensures that more pages are served directly from cache. This reduces backend resource usage on your Hypernode and allows your shop to handle more concurrent visitors without performance degradation.  
+A low hit ratio usually indicates a caching misconfiguration or cache invalidation happening too frequently.
+
+---
+
+## Understanding Cache Hit Rate
+
+- **HIT:** The response is served directly from Varnish cache  
+- **MISS:** The request is forwarded to the backend (for example, PHP/Magento)
+
+A consistently low hit rate means that:
+
+- Pages are bypassing Varnish  
+- Cache entries are being purged too often  
+- URLs are fragmented due to parameters or inconsistencies  
+
+---
+
+## Common Issue: Automatic Cache Busting
+
+If you notice that your cache is cleared at consistent times, this often points to an automated process that flushes the cache.
+
+### Typical causes
+
+- External integrations that frequently update stock or pricing  
+- Magento cron jobs triggering full cache purges  
+- Extensions that invalidate more cache than necessary  
+
+### What to do
+
+- Review all third-party integrations that update catalog or pricing data  
+- Inspect Magento cron jobs for full cache invalidation tasks  
+- Reduce the scope or frequency of full cache purges  
+- Prefer targeted purges (specific URLs or entities) instead of clearing the entire cache  
+
+---
+
+## Checking Cacheability and Hit/Miss Behavior
+
+When Varnish is frequently purged or bypassed, your hit rate will drop. You can analyze this behavior using the tools below.
+
+### Useful tools
+
+#### `varnishlog`
+View detailed logs of Varnish requests and responses. Look for recurring **MISS** patterns on URLs that should be cacheable.
+
+#### `varnishstat`
+Provides counters for cache hits, misses, and backend requests.
+
+#### Hypernode Insights (if available)
+Use hit/miss graphs to identify when cache invalidations occur and correlate them with deployments or cron activity.
+
+---
+
+## Checking Varnish Headers Using cURL
+
+You can verify whether a page is cached directly from your own terminal.
+
+```bash
+curl -I https://www.example.com/ \
+  | egrep 'Age:|Via:|X-Cache|X-Magento-Cache-Debug|Cache-Control'
+```
+
+### What to look for
+
+- **Age** header increasing → cached response  
+- **X-Cache: HIT** → served from Varnish  
+- **Cache-Control** headers that allow caching  
+- Absence of **Set-Cookie** for cacheable pages  
+
+---
+
+## Checking Cache Statistics on Your Hypernode
+
+### Snapshot of hits and misses
+
+Untested example (single run):
+
+```bash
+varnishstat -1 -f MAIN.cache_hit,MAIN.cache_miss,MAIN.backend_req
+```
+
+### Tested (live overview of cached URLs)
+
+```bash
+varnishncsa -F '%U%q %{Varnish:hitmiss}x' | grep hit
+```
+
+This helps identify which URLs are effectively cached and which are not.
+
+---
+
+## Handling Marketing and Tracking URL Parameters
+
+Marketing parameters such as `utm_source`, `utm_medium`, or `gclid` can dramatically increase the number of unique cache entries.  
+Each parameter variation creates a new cache object, lowering your overall hit rate.
+
+### Best practice
+
+Normalize URLs so that these parameters do not influence caching decisions.
+
+#### Examples of parameters to strip
+
+- `utm_*`  
+- `gclid`  
+- `fbclid`
+
+This normalization should happen before Varnish decides whether a request is cacheable.
+
+> **Tip:** The [`elgentos/magento2-varnish-extended`](https://github.com/elgentos/magento2-varnish-extended) extension improves handling of marketing parameters and enhances the default Magento 2 VCL.
+
+---
+
+## URL Normalization
+
+Different URL variations can fragment your cache and reduce efficiency.
+
+### Common normalization examples
+
+- **Trailing slashes**  
+  `/category` → `/category/`
+- **Lowercase query parameters**  
+  `?Color=Red` → `?color=red`
+- **Remove session IDs or irrelevant parameters**
+
+By normalizing URLs, similar requests map to the same cache object, reducing duplication and improving hit rates.
\ No newline at end of file

From 9eed62c8f0cad2f88cf224d1767889642cddfa07 Mon Sep 17 00:00:00 2001
From: Tim Veluwenkamp <TimVNL@users.noreply.github.com>
Date: Tue, 23 Dec 2025 09:45:44 +0100
Subject: [PATCH 02/10] readability improved for
 improving-varnish-cache-hit.rate

---
 .../tools/improving-varnish-cache-hit.rate.md       | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/docs/hypernode-platform/tools/improving-varnish-cache-hit.rate.md b/docs/hypernode-platform/tools/improving-varnish-cache-hit.rate.md
index 41ae7db6..eb7c2b8a 100644
--- a/docs/hypernode-platform/tools/improving-varnish-cache-hit.rate.md
+++ b/docs/hypernode-platform/tools/improving-varnish-cache-hit.rate.md
@@ -71,11 +71,10 @@ curl -I https://www.example.com/ \
 ```
 
 ### What to look for
-
-- **Age** header increasing → cached response  
-- **X-Cache: HIT** → served from Varnish  
-- **Cache-Control** headers that allow caching  
-- Absence of **Set-Cookie** for cacheable pages  
+- **Age** header increasing → cached response.
+- **X-Cache: HIT** → served from Varnish.
+- **Cache-Control** → verifies cacheability.
+- No **Set-Cookie** header → indicates a cacheable page.
 
 ---
 
@@ -83,7 +82,7 @@ curl -I https://www.example.com/ \
 
 ### Snapshot of hits and misses
 
-Untested example (single run):
+single run (untested):
 
 ```bash
 varnishstat -1 -f MAIN.cache_hit,MAIN.cache_miss,MAIN.backend_req
@@ -101,7 +100,7 @@ This helps identify which URLs are effectively cached and which are not.
 
 ## Handling Marketing and Tracking URL Parameters
 
-Marketing parameters such as `utm_source`, `utm_medium`, or `gclid` can dramatically increase the number of unique cache entries.  
+Marketing (query) parameters such as `utm_source`, `utm_medium`, or `gclid` can dramatically increase the number of unique cache entries.  
 Each parameter variation creates a new cache object, lowering your overall hit rate.
 
 ### Best practice

From fe9f5a69a14dc62c016b139230aa56970fee6ce5 Mon Sep 17 00:00:00 2001
From: Jonathan Visser <jonathan.visser@team.blue>
Date: Mon, 12 Jan 2026 13:56:09 +0100
Subject: [PATCH 03/10] Remove old documentation regarding hypernode-deploy v1

---
 ...r-application-using-hypernode-deploy-v1.md | 235 ------------------
 1 file changed, 235 deletions(-)
 delete mode 100644 docs/hypernode-platform/tools/how-to-deploy-your-application-using-hypernode-deploy-v1.md

diff --git a/docs/hypernode-platform/tools/how-to-deploy-your-application-using-hypernode-deploy-v1.md b/docs/hypernode-platform/tools/how-to-deploy-your-application-using-hypernode-deploy-v1.md
deleted file mode 100644
index 490f5525..00000000
--- a/docs/hypernode-platform/tools/how-to-deploy-your-application-using-hypernode-deploy-v1.md
+++ /dev/null
@@ -1,235 +0,0 @@
----
-myst:
-  html_meta:
-    description: 'This guide will walk you through the process of setting up a continues
-      integration and delivery/deployment pipeline for a Magento 2 shop. '
-    title: How to deploy your application using Hypernode Deploy?
-redirect_from:
-  - /en/support/solutions/articles/48001219280-how-to-deploy-your-application-using-hypernode-deploy-v1/
----
-
-<!-- source: https://support.hypernode.com/en/support/solutions/articles/48001219280-how-to-deploy-your-application-using-hypernode-deploy-v1/ -->
-
-# How to deploy your application using Hypernode Deploy v1
-
-## Introduction
-
-This tutorial will guide you through the process of setting up a continues integration and delivery/deployment pipeline for a Magento 2 shop, using Github as your CI-system. For simplicity reasons, we'll only focus on one environment: Staging.
-
-## Prerequisites
-
-Before starting, make sure you have the following requirements setup correctly:
-
-- (Access to) a Hypernode
-- A Github account
-
-Make sure to [create a new SSH key pair](../ssh/how-to-use-ssh-keys-on-hypernode.md) as a deployment key, and [add this to your Hypernode via the Control Panel](../../services/control-panel/how-to-add-keys-to-the-ssh-key-manager.md). We'll use this SSH key in the deployment process to upload your application to the Hypernode.
-
-## Configure your Deployment SSH key pair in Github
-
-Now that your deployment key is generated and added to your server, it's time to configure the deployment key pair in Github.
-
-Go to your Github repo and then to `Settings > Deploy keys`.
-
-![](_res/aPrFnC8q5cQvkXVPzglDGpc1jnKwDUq_Mg.png)
-
-Copy the private key from your deployment key pair, paste them as is (modifying the contents could result in "invalid key format" issues), and press `Add key.`
-
-`![](_res/jD7qiawwFbEs1VvdhmzqSTGmzuh-nu4NKw.png)`
-
-## Dump Magento configuration to configuration files
-
-For a successful pipeline it is important that the necessary configuration from the Magento Admin is exported to files, because we can't and do not want to have database dependencies / connections within a CI pipeline.
-
-Use the following command to dump the configuration to files:
-
-```bash
-bin/magento app:config:dump
-```
-
-Strip the configuration files so that 'app/etc/config.php' contains only the essential configuration. Add 'app/etc/config.php' to your Git repo history, but not 'app/etc/env.php' because this file only needs to live on the server.
-
-Read more about dumping Magento configuration in the [devdocs of Magento](https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cli/configuration-management/export-configuration).
-
-## Create Hypernode Deploy configuration file
-
-Now we added and configured the deploy key, it's time to setup the deployment configuration using "configuration as code". We just need a `deploy.php` file in the root of the project.
-
-The Hypernode Deploy configuration file ([here on Github](https://github.com/ByteInternet/hypernode-deploy-configuration/)) is a PHP file that contains a configuration object that will be used by the Hypernode Deploy Docker image (that we will later configure in the Github CI configuration) to perform configured CI/CD steps.
-
-Optional: to get code completion for your deploy configurations, add the Hypernode Deploy Configuration composer package as a development package to your project:
-
-```bash
-composer require hypernode/deploy-configuration --dev
-```
-
-You can either start from scratch with an empty `deploy.php` file, or use one the [starter templates](https://github.com/ByteInternet/hypernode-deploy-configuration/tree/master/templates) and continue from there.
-
-For this tutorial we'll use the [Magento 2 application template configuration](https://github.com/ByteInternet/hypernode-deploy-configuration/blob/master/src/ApplicationTemplate/Magento2.php). This template contains a default configuration for Magento 2 projects, which can be modified and extended to your own requirements.
-
-The configuration for just a staging environment could be as short as this:
-
-```php
-<?php
-namespace Hypernode\DeployConfiguration;
-
-$configuration = new ApplicationTemplate\Magento2(
- // Your GIT repository url
- 'git@github.org:myorg/myproject.git',
- // Frontend locales
- ['nl_NL'],
- // Backend locales
- ['nl_NL']
-);
-
-$stagingStage = $configuration->addStage('staging', 'staging.example.com');
-$stagingStage->addServer('example.hypernode.io');
-
-return $configuration;
-
-```
-
-Now we have to provide the files and folders that don't change per deployment and thus will be shared over multiple deployments.
-
-Common examples of shared files are configuration files such as `.env`, `env.php` and `config.php`. Often, those files are not under source control and might be generated / composed by the application or CI/CD system.
-
-The M2 starter template we're using already contains the following shared files configuration:
-
-```php
-$configuration->setSharedFiles([
-    'app/etc/env.php',
-    'pub/errors/local.xml'
-]);
-```
-
-Common examples of shared folders are: `media`, `uploads`, `var/import` and `var/log`. The M2 starter template already contains the following shared folder configuration:
-
-```php
-$configuration->setSharedFolders([
-    'var/log',
-    'var/session',
-    'var/report',
-    'pub/media'
-]);
-```
-
-Now it's time to add our build, deploy and after deploy commands.
-
-The M2 starter template contains the following default build commands:
-
-```php
-$configuration->addBuildCommand(new Command\Build\Composer());
-$configuration->addBuildCommand(new Command\Build\Magento2\SetupDiCompile());
-$configuration->addBuildCommand(new Command\Build\Magento2\SetupStaticContentDeploy($localesFrontend, 'frontend'));
-$configuration->addBuildCommand(new Command\Build\Magento2\SetupStaticContentDeploy($localesBackend, 'adminhtml'));
-```
-
-And the following deploy commands:
-
-```php
-$configuration->addDeployCommand(new Command\Deploy\Magento2\MaintenanceMode());
-$configuration->addDeployCommand(new Command\Deploy\Magento2\SetupUpgrade());
-$configuration->addDeployCommand(new Command\Deploy\Magento2\CacheFlush());
-```
-
-## Create Magento 2 configuration files
-
-For Magento 2 your first build will fail due to missing configuration. Login to the server and depending on your project file edit `app/etc/env.php` or `app/etc/local.xml`. You will find these files in `~/apps/<domain>/application/shared/`.
-
-## Create Github configuration file
-
-Now it's time to create your CI configuration file. You can either start from scratch or use the [Hypernode Deploy Github how-to page](../../hypernode-deploy/pipelines/github-actions.md).
-
-The CI configuration file needs to make use of the Hypernode Deploy image in order to run your CI/CD pipelines succesfully. We serve multiple flavors of the Hypernode Deploy image, one for every PHP + NodeJS version combination. See [our image repository](https://quay.io/repository/hypernode/deploy?tab=tags&tag=latest) for all supported flavors. As new PHP / Node versions come out, we'll bake more images to support those.
-
-Choose a version of the hypernode/deploy image that best reflects your application needs. Here's an example of a `.github/workflows/deploy.yml` file that uses the PHP 8.4 + Node 22 image and is configured with a configuration for the staging environment, containing a build step and deploy step to perform the deployment to the configured staging server. It uses the configuration provided in `deploy.php` to perform the steps.
-
-```yaml
-# This file would need to be placed in .github/workflows/deploy.yaml for example
-# In this example, the branches 'master' and 'staging' are used for the production and staging branch, respectively.
-
-name: Build and Deploy
-
-on:
- push:
- branches:
- - 'master'
- - 'staging'
-
-env:
- COMPOSER_CACHE_DIR: /tmp/composer-cache
-
-defaults:
- run:
- shell: bash
-
-jobs:
- build:
- runs-on: ubuntu-latest
- container: quay.io/hypernode/deploy:latest-php8.4-node20
- steps:
- - uses: actions/checkout@v2
- - uses: actions/cache@v2
-   with:
-     path: /tmp/composer-cache
-     key: ${{ runner.os }}-composer
- - uses: webfactory/ssh-agent@v0.5.4
-   with:
-     ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}
- - run: hypernode-deploy build -vvv
- - name: archive production artifacts
-   uses: actions/upload-artifact@v4
-   with:
-     name: deployment-build
-     path: build/build.tgz
-
- deploy_staging:
-   needs: build
-   runs-on: ubuntu-latest
-   container: quay.io/hypernode/deploy:latest-php8.4-node20
-   steps:
-   - uses: actions/checkout@v2
-   - name: download build artifact
-     uses: actions/download-artifact@v3
-     with:
-   - name: deployment-build
-     path: build/
-   - uses: webfactory/ssh-agent@v0.5.4
-     with:
-       ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}
-   - run: mkdir -p $HOME/.ssh
-   - name: deploy to staging
-     if: github.ref == 'refs/heads/staging'
-     run: hypernode-deploy deploy staging -vvv
-   - name: deploy to production
-     if: github.ref == 'refs/heads/master'
-     run: hypernode-deploy deploy production -vvv
-
-```
-
-## Optional: Test your Build and Deploy commands locally
-
-Now that we're done with the project configuration, we can test the configured Build and Deploy steps locally before committing and pushing to the remote Git repo. Because we don't have to wait for the Github pipeline result this will reduce the time of the feedback loop drastically. You'll need to have a Docker client setup in order to test your build and deployment locally.
-
-Run the `hypernode-deploy build` command locally. We assume that the private key of the earlier created deploy key is located at `~/.ssh/id_rsa_myproject_deploy`, and that is has access to the main Git repository, private packages and the SSH user. Keep in mind that the provided `SSH_PRIVATE_KEY` environment variable needs to be base64 encoded.
-
-```bash
-docker run -it --env SSH_PRIVATE_KEY="$(cat ~/.ssh/id_rsa_myproject_deploy | base64)" -v `pwd`:/build hypernode/deploy:php7.3-node13 hypernode-deploy build -vvv
-```
-
-Because all hypernode-deploy commands are implemented as Symfony Console commands, we can append the build command with a flag to determine the [verbosity level](https://symfony.com/doc/current/console/verbosity.html), like `-vvv` to display all messages. This will be useful to debug any errors.
-
-Just like the build command, we can also test the deploy command. For this example we first set the environment variables before using them in the command.
-
-```bash
-export SSH_PRIVATE_KEY=***
-export DEPLOY_COMPOSER_AUTH=***
-
-docker run -it -e SSH_PRIVATE_KEY -e DEPLOY_COMPOSER_AUTH -v `pwd`:/build hypernode/deploy hypernode-deploy deploy staging -vvv
-```
-
-## Commit and push project CI/CD configurations
-
-Now that all project configuration is done and we verified that both our build and deploy commands run locally as expected, it's time to commit and push both the Hypernode Deploy configuration (`deploy.php`) and CI configuration (`github-pipelines.yml`) to the remote Git repository.
-
-After that's done, Github will automatically trigger the pipeline as configured. The only accepted outcome is a pipeline that completely succeeds!

From 5590c0952736c0e16ad1d919750ea4b6df2bf1d9 Mon Sep 17 00:00:00 2001
From: Tim Veluwenkamp <TimVNL@users.noreply.github.com>
Date: Thu, 26 Feb 2026 11:25:58 +0100
Subject: [PATCH 04/10] Added varnish hitrate docs

---
 .../tools/improving-varnish-cache-hit-rate.md | 207 ++++++++++++++++++
 .../tools/improving-varnish-cache-hit.rate.md | 134 ------------
 2 files changed, 207 insertions(+), 134 deletions(-)
 create mode 100644 docs/hypernode-platform/tools/improving-varnish-cache-hit-rate.md
 delete mode 100644 docs/hypernode-platform/tools/improving-varnish-cache-hit.rate.md

diff --git a/docs/hypernode-platform/tools/improving-varnish-cache-hit-rate.md b/docs/hypernode-platform/tools/improving-varnish-cache-hit-rate.md
new file mode 100644
index 00000000..9ed519bc
--- /dev/null
+++ b/docs/hypernode-platform/tools/improving-varnish-cache-hit-rate.md
@@ -0,0 +1,207 @@
+---
+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.
+    title: Improving Varnish Cache Hit Rate on Hypernode
+---
+
+# Improving Your Varnish Cache Hit Rate
+
+A higher Varnish cache hit rate means more pages are served directly from cache.
+This reduces backend resource usage on your Hypernode, improves page load speed, and helps your shop handle more concurrent visitors without performance degradation.
+
+A low hit rate often indicates that cache isn’t being reused effectively, typically caused by misconfiguration, frequent invalidation, or too much variation in URLs.
+
+This guide takes you step-by-step from verifying that your cache is active to diagnosing and improving your hit ratio.
+
+## Before You Begin
+
+Typical cache hit rates:
+- **Below 10%** → Cache is barely reused  
+- **30–70%** → Improvement possible (depends on shop type)  
+- **Above 80%** → Generally healthy  
+
+Keep in mind:
+- Staging environments typically have low hit rates  
+- B2B webshops often have lower hit rates due to personalization  
+
+
+# Step 1 — Verify Varnish Is Enabled
+
+Ensure Varnish is properly enabled on your Hypernode and configured in your
+application (e.g. Magento 2).
+
+For Magento 2, verify:
+- Varnish is selected as the caching application
+- The correct VCL is generated and loaded
+- Full Page Cache (FPC) is enabled
+
+For a complete guide on how to configure Varnish in Magento 2 see: 
+https://docs.hypernode.com/ecommerce-applications/magento-2/how-to-configure-varnish-for-magento-2-x.html#how-to-configure-varnish-for-magento-2-x
+
+```{tip}
+Tip: The [elgentos/magento2-varnish-extended](https://github.com/elgentos/magento2-varnish-extended) extension improves Magento’s
+default VCL configuration and marketing parameter handling.
+```
+
+# Step 2 — Check if Pages Are Being Cached
+
+Use `curl` to inspect response headers:
+
+```console
+curl -I https://yourdomain.com
+```
+
+Look for:
+- `X-Cache: HIT` → Served from Varnish
+- `X-Cache: MISS` → Served from backend
+- `Age` → How long the object has been cached
+- `X-Magento-*` headers → Useful Magento cache debug info only visible when developer mode is enabled.
+
+If most responses return `MISS`, caching is not being reused effectively.
+
+You can also inspect these headers in your browser via:
+Developer Tools → Network tab → Select request → Response Headers
+
+---
+
+# Step 3 — Measure Your Cache Hit Rate
+
+Run:
+
+```console
+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
+
+A high miss count relative to hits indicates room for improvement.
+
+For live monitoring:
+
+```console
+varnishstat
+```
+
+---
+
+# Step 4 — Common Causes of Low Hit Rates
+
+## 1. Pages Bypassing Varnish
+
+Some pages are intentionally not cached:
+- Checkout
+- Customer account pages
+- Requests containing `Set-Cookie` headers
+
+This is expected behavior.
+
+## 2. Frequent Cache Invalidations
+
+If cache clears happen frequently, reuse becomes impossible.
+
+Common causes:
+- Stock or pricing integrations
+- Magento cron jobs performing full cache purges
+- Extensions invalidating excessive cache entries
+
+Best practice:
+Perform targeted purges (specific URLs or cache tags) instead of full cache
+flushes.
+
+---
+
+## 3. Marketing & Tracking Parameters
+
+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
+
+These generate separate cache objects unless normalized.
+
+Solution:
+
+Strip non-essential tracking parameters in VCL.
+
+```{tip}
+The [elgentos/magento2-varnish-extended](https://github.com/elgentos/magento2-varnish-extended) module improves this behavior.
+```
+---
+
+## 4. URL Normalization Issues
+
+Different URL formats fragment your cache.
+
+Examples:
+- `/category` vs `/category/`
+- `?Color=Red` vs `?color=red`
+- Unsorted query parameters
+- Session IDs in URLs
+
+Normalize URLs to ensure identical content maps to a single cache object.
+
+---
+
+## 5. Non-Cacheable Magento Blocks
+
+In Magento, a single block marked as non-cacheable can disable Full Page Cache
+for the entire page.
+
+Search for non-cacheable blocks:
+
+```console
+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
+
+Even one unnecessary non-cacheable block can severely impact hit rate.
+
+# Optional — Enable Magento Developer Mode for Debugging
+
+Developer mode provides more detailed error output:
+```console
+magerun2 deploy:mode:set developer
+```
+
+Or: 
+```console
+php bin/magento deploy:mode:set developer
+```
+
+# Debugging Tools
+
+## varnishlog
+Inspect detailed request handling:
+```bash
+varnishlog
+```
+Look for recurring MISS patterns on pages that should be cacheable.
+
+## varnishncsa
+Show hit/miss per URL:
+```bash
+varnishncsa -F '%U%q %{Varnish:hitmiss}x'
+```
+Filter for hits:
+```bash
+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
\ No newline at end of file
diff --git a/docs/hypernode-platform/tools/improving-varnish-cache-hit.rate.md b/docs/hypernode-platform/tools/improving-varnish-cache-hit.rate.md
deleted file mode 100644
index eb7c2b8a..00000000
--- a/docs/hypernode-platform/tools/improving-varnish-cache-hit.rate.md
+++ /dev/null
@@ -1,134 +0,0 @@
----
-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.
-    title: Improving Varnish Cache Hit Rate on Hypernode
----
-
-# Improving Varnish Cache Hit Rate
-
-An improved **Varnish hit rate** ensures that more pages are served directly from cache. This reduces backend resource usage on your Hypernode and allows your shop to handle more concurrent visitors without performance degradation.  
-A low hit ratio usually indicates a caching misconfiguration or cache invalidation happening too frequently.
-
----
-
-## Understanding Cache Hit Rate
-
-- **HIT:** The response is served directly from Varnish cache  
-- **MISS:** The request is forwarded to the backend (for example, PHP/Magento)
-
-A consistently low hit rate means that:
-
-- Pages are bypassing Varnish  
-- Cache entries are being purged too often  
-- URLs are fragmented due to parameters or inconsistencies  
-
----
-
-## Common Issue: Automatic Cache Busting
-
-If you notice that your cache is cleared at consistent times, this often points to an automated process that flushes the cache.
-
-### Typical causes
-
-- External integrations that frequently update stock or pricing  
-- Magento cron jobs triggering full cache purges  
-- Extensions that invalidate more cache than necessary  
-
-### What to do
-
-- Review all third-party integrations that update catalog or pricing data  
-- Inspect Magento cron jobs for full cache invalidation tasks  
-- Reduce the scope or frequency of full cache purges  
-- Prefer targeted purges (specific URLs or entities) instead of clearing the entire cache  
-
----
-
-## Checking Cacheability and Hit/Miss Behavior
-
-When Varnish is frequently purged or bypassed, your hit rate will drop. You can analyze this behavior using the tools below.
-
-### Useful tools
-
-#### `varnishlog`
-View detailed logs of Varnish requests and responses. Look for recurring **MISS** patterns on URLs that should be cacheable.
-
-#### `varnishstat`
-Provides counters for cache hits, misses, and backend requests.
-
-#### Hypernode Insights (if available)
-Use hit/miss graphs to identify when cache invalidations occur and correlate them with deployments or cron activity.
-
----
-
-## Checking Varnish Headers Using cURL
-
-You can verify whether a page is cached directly from your own terminal.
-
-```bash
-curl -I https://www.example.com/ \
-  | egrep 'Age:|Via:|X-Cache|X-Magento-Cache-Debug|Cache-Control'
-```
-
-### What to look for
-- **Age** header increasing → cached response.
-- **X-Cache: HIT** → served from Varnish.
-- **Cache-Control** → verifies cacheability.
-- No **Set-Cookie** header → indicates a cacheable page.
-
----
-
-## Checking Cache Statistics on Your Hypernode
-
-### Snapshot of hits and misses
-
-single run (untested):
-
-```bash
-varnishstat -1 -f MAIN.cache_hit,MAIN.cache_miss,MAIN.backend_req
-```
-
-### Tested (live overview of cached URLs)
-
-```bash
-varnishncsa -F '%U%q %{Varnish:hitmiss}x' | grep hit
-```
-
-This helps identify which URLs are effectively cached and which are not.
-
----
-
-## Handling Marketing and Tracking URL Parameters
-
-Marketing (query) parameters such as `utm_source`, `utm_medium`, or `gclid` can dramatically increase the number of unique cache entries.  
-Each parameter variation creates a new cache object, lowering your overall hit rate.
-
-### Best practice
-
-Normalize URLs so that these parameters do not influence caching decisions.
-
-#### Examples of parameters to strip
-
-- `utm_*`  
-- `gclid`  
-- `fbclid`
-
-This normalization should happen before Varnish decides whether a request is cacheable.
-
-> **Tip:** The [`elgentos/magento2-varnish-extended`](https://github.com/elgentos/magento2-varnish-extended) extension improves handling of marketing parameters and enhances the default Magento 2 VCL.
-
----
-
-## URL Normalization
-
-Different URL variations can fragment your cache and reduce efficiency.
-
-### Common normalization examples
-
-- **Trailing slashes**  
-  `/category` → `/category/`
-- **Lowercase query parameters**  
-  `?Color=Red` → `?color=red`
-- **Remove session IDs or irrelevant parameters**
-
-By normalizing URLs, similar requests map to the same cache object, reducing duplication and improving hit rates.
\ No newline at end of file

From a5c49dc7f06cf9132951ed89960e26d278c41e3c Mon Sep 17 00:00:00 2001
From: Tim Veluwenkamp <TimVNL@users.noreply.github.com>
Date: Thu, 26 Feb 2026 11:41:26 +0100
Subject: [PATCH 05/10] Improved readability and links in varnish-hitrate-docs

---
 .../tools/improving-varnish-cache-hit-rate.md | 19 ++++---------------
 1 file changed, 4 insertions(+), 15 deletions(-)

diff --git a/docs/hypernode-platform/tools/improving-varnish-cache-hit-rate.md b/docs/hypernode-platform/tools/improving-varnish-cache-hit-rate.md
index 9ed519bc..6a2ce992 100644
--- a/docs/hypernode-platform/tools/improving-varnish-cache-hit-rate.md
+++ b/docs/hypernode-platform/tools/improving-varnish-cache-hit-rate.md
@@ -28,20 +28,19 @@ Keep in mind:
 
 # Step 1 — Verify Varnish Is Enabled
 
-Ensure Varnish is properly enabled on your Hypernode and configured in your
+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  
 - Varnish is selected as the caching application
 - The correct VCL is generated and loaded
 - Full Page Cache (FPC) is enabled
 
-For a complete guide on how to configure Varnish in Magento 2 see: 
-https://docs.hypernode.com/ecommerce-applications/magento-2/how-to-configure-varnish-for-magento-2-x.html#how-to-configure-varnish-for-magento-2-x
+For a step-by-step guide on activating and configuring Varnish in Magento 2, please refer to our [documentation here](https://docs.hypernode.com/ecommerce-applications/magento-2/how-to-configure-varnish-for-magento-2-x.html#how-to-configure-varnish-for-magento-2-x)
 
 ```{tip}
-Tip: The [elgentos/magento2-varnish-extended](https://github.com/elgentos/magento2-varnish-extended) extension improves Magento’s
-default VCL configuration and marketing parameter handling.
+Tip: The [elgentos/magento2-varnish-extended](https://github.com/elgentos/magento2-varnish-extended) extension improves Magento’s default VCL configuration and marketing parameter handling.
 ```
 
 # Step 2 — Check if Pages Are Being Cached
@@ -63,8 +62,6 @@ If most responses return `MISS`, caching is not being reused effectively.
 You can also inspect these headers in your browser via:
 Developer Tools → Network tab → Select request → Response Headers
 
----
-
 # Step 3 — Measure Your Cache Hit Rate
 
 Run:
@@ -85,8 +82,6 @@ For live monitoring:
 varnishstat
 ```
 
----
-
 # Step 4 — Common Causes of Low Hit Rates
 
 ## 1. Pages Bypassing Varnish
@@ -111,8 +106,6 @@ Best practice:
 Perform targeted purges (specific URLs or cache tags) instead of full cache
 flushes.
 
----
-
 ## 3. Marketing & Tracking Parameters
 
 Tracking parameters create separate cache entries for identical content.
@@ -130,13 +123,11 @@ Example problem:
 These generate separate cache objects unless normalized.
 
 Solution:
-
 Strip non-essential tracking parameters in VCL.
 
 ```{tip}
 The [elgentos/magento2-varnish-extended](https://github.com/elgentos/magento2-varnish-extended) module improves this behavior.
 ```
----
 
 ## 4. URL Normalization Issues
 
@@ -150,8 +141,6 @@ Examples:
 
 Normalize URLs to ensure identical content maps to a single cache object.
 
----
-
 ## 5. Non-Cacheable Magento Blocks
 
 In Magento, a single block marked as non-cacheable can disable Full Page Cache

From 8682f6ae034502a18b1d20809b4a2370ec2d559a Mon Sep 17 00:00:00 2001
From: Tim Veluwenkamp <TimVNL@users.noreply.github.com>
Date: Thu, 26 Feb 2026 19:23:01 +0100
Subject: [PATCH 06/10] feedback based improvements to varnish-hitrate-docs

---
 .../tools/improving-varnish-cache-hit-rate.md | 30 ++++++++++++++-----
 1 file changed, 22 insertions(+), 8 deletions(-)

diff --git a/docs/hypernode-platform/tools/improving-varnish-cache-hit-rate.md b/docs/hypernode-platform/tools/improving-varnish-cache-hit-rate.md
index 6a2ce992..e9ee4077 100644
--- a/docs/hypernode-platform/tools/improving-varnish-cache-hit-rate.md
+++ b/docs/hypernode-platform/tools/improving-varnish-cache-hit-rate.md
@@ -7,8 +7,8 @@ myst:
 
 # Improving Your Varnish Cache Hit Rate
 
-A higher Varnish cache hit rate means more pages are served directly from cache.
-This reduces backend resource usage on your Hypernode, improves page load speed, and helps your shop handle more concurrent visitors without performance degradation.
+A higher Varnish cache hit rate means more requests are served directly from cache.
+This reduces resource usage on your Hypernode, improves page load speed, and helps your shop handle more concurrent visitors without performance degradation.
 
 A low hit rate often indicates that cache isn’t being reused effectively, typically caused by misconfiguration, frequent invalidation, or too much variation in URLs.
 
@@ -51,13 +51,21 @@ Use `curl` to inspect response headers:
 curl -I https://yourdomain.com
 ```
 
-Look for:
-- `X-Cache: HIT` → Served from Varnish
-- `X-Cache: MISS` → Served from backend
-- `Age` → How long the object has been cached
-- `X-Magento-*` headers → Useful Magento cache debug info only visible when developer mode is enabled.
+Review the following headers:
+
+- **`Set-Cookie`**  
+  If `PHPSESSID` is present, Varnish will not cache the response.
+
+- **`Cache-Control`**  
+  Should **not** contain `private`, `no-store`, or `no-cache`.
+
+- **`Age`**  
+  Indicates how long (in seconds) the object has been cached.
 
-If most responses return `MISS`, caching is not being reused effectively.
+- **`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.
 
 You can also inspect these headers in your browser via:
 Developer Tools → Network tab → Select request → Response Headers
@@ -82,6 +90,12 @@ For live monitoring:
 varnishstat
 ```
 
+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.
+- `X-Magento-*` headers → Provides Magento cache/debug information (visible in developer mode).
+
 # Step 4 — Common Causes of Low Hit Rates
 
 ## 1. Pages Bypassing Varnish

From db1b4d7df497b8351833ea5ec4ba523651ec130d Mon Sep 17 00:00:00 2001
From: Tim Veluwenkamp <TimVNL@users.noreply.github.com>
Date: Wed, 4 Mar 2026 09:50:06 +0100
Subject: [PATCH 07/10] Moved varnish-hit-rate docs to tools/varnish +
 improvements based on internal Feedback

---
 ...mproving-varnish-hit-rate-on-hypernode.md} | 93 ++++++++++++-------
 1 file changed, 61 insertions(+), 32 deletions(-)
 rename docs/hypernode-platform/{tools/improving-varnish-cache-hit-rate.md => varnish/improving-varnish-hit-rate-on-hypernode.md} (66%)

diff --git a/docs/hypernode-platform/tools/improving-varnish-cache-hit-rate.md b/docs/hypernode-platform/varnish/improving-varnish-hit-rate-on-hypernode.md
similarity index 66%
rename from docs/hypernode-platform/tools/improving-varnish-cache-hit-rate.md
rename to docs/hypernode-platform/varnish/improving-varnish-hit-rate-on-hypernode.md
index e9ee4077..f2edea74 100644
--- a/docs/hypernode-platform/tools/improving-varnish-cache-hit-rate.md
+++ b/docs/hypernode-platform/varnish/improving-varnish-hit-rate-on-hypernode.md
@@ -7,10 +7,10 @@ myst:
 
 # Improving Your Varnish Cache Hit Rate
 
-A higher Varnish cache hit rate means more requests are served directly from cache.
+A higher Varnish cache hit rate means more requests are served directly from the cache.
 This reduces resource usage on your Hypernode, improves page load speed, and helps your shop handle more concurrent visitors without performance degradation.
 
-A low hit rate often indicates that cache isn’t being reused effectively, typically caused by misconfiguration, frequent invalidation, or too much variation in URLs.
+A low hit rate often indicates that cache is not being reused effectively, typically caused by misconfiguration, frequent invalidation, or too much variation in URLs.
 
 This guide takes you step-by-step from verifying that your cache is active to diagnosing and improving your hit ratio.
 
@@ -18,21 +18,35 @@ This guide takes you step-by-step from verifying that your cache is active to di
 
 Typical cache hit rates:
 - **Below 10%** → Cache is barely reused  
-- **30–70%** → Improvement possible (depends on shop type)  
-- **Above 80%** → Generally healthy  
+- **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  
+- 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.
 
-# Step 1 — Verify Varnish Is Enabled
+## When a Low Hit Rate Is Expected
+
+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  
+
+Investigate further only if traffic is stable, the cache is warmed up, and the hit rate remains consistently low.
+
+## Step 1 — Verify Varnish Is Enabled
 
 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
@@ -43,9 +57,17 @@ For a step-by-step guide on activating and configuring Varnish in Magento 2, ple
 Tip: The [elgentos/magento2-varnish-extended](https://github.com/elgentos/magento2-varnish-extended) extension improves Magento’s default VCL configuration and marketing parameter handling.
 ```
 
-# Step 2 — Check if Pages Are Being Cached
+## 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 
+varnishncsa -F '%U%q %{Varnish:hitmiss}x'
+```
+Look for:
+- `hit` → Served from Varnish
+- `miss` → Served from backend
 
-Use `curl` to inspect response headers:
+Alternatively, you can use `curl` to inspect response headers:
 
 ```console
 curl -I https://yourdomain.com
@@ -54,7 +76,7 @@ curl -I https://yourdomain.com
 Review the following headers:
 
 - **`Set-Cookie`**  
-  If `PHPSESSID` is present, Varnish will not cache the response.
+  If a Set-Cookie header (such as PHPSESSID) is present, Varnish will typically not cache the response.
 
 - **`Cache-Control`**  
   Should **not** contain `private`, `no-store`, or `no-cache`.
@@ -70,7 +92,7 @@ If most responses return `MISS` (for example in `X-Magento-Cache-Debug` or simil
 You can also inspect these headers in your browser via:
 Developer Tools → Network tab → Select request → Response Headers
 
-# Step 3 — Measure Your Cache Hit Rate
+## Step 3 — Measure Your Cache Hit Rate
 
 Run:
 
@@ -84,10 +106,10 @@ This shows:
 
 A high miss count relative to hits indicates room for improvement.
 
-For live monitoring:
+For live monitoring of which requests are hitting Varnish, use:
 
 ```console
-varnishstat
+varnishlog
 ```
 
 Look for:
@@ -96,9 +118,11 @@ Look for:
 - `Age` → Indicates how long (in seconds) the object has been cached.
 - `X-Magento-*` headers → Provides Magento cache/debug information (visible in developer mode).
 
-# Step 4 — Common Causes of Low Hit Rates
+Alternatively, reuse the varnishncsa command from Step 2 for live hit/miss monitoring.
+
+## Step 4 — Common Causes of Low Hit Rates
 
-## 1. Pages Bypassing Varnish
+### 1. Pages Bypassing Varnish
 
 Some pages are intentionally not cached:
 - Checkout
@@ -107,9 +131,9 @@ Some pages are intentionally not cached:
 
 This is expected behavior.
 
-## 2. Frequent Cache Invalidations
+### 2. Frequent Cache Invalidations
 
-If cache clears happen frequently, reuse becomes impossible.
+If cache clears happen frequently, cache reuse becomes nearly impossible.
 
 Common causes:
 - Stock or pricing integrations
@@ -120,7 +144,7 @@ Best practice:
 Perform targeted purges (specific URLs or cache tags) instead of full cache
 flushes.
 
-## 3. Marketing & Tracking Parameters
+### 3. Marketing & Tracking Parameters
 
 Tracking parameters create separate cache entries for identical content.
 
@@ -134,7 +158,7 @@ Example problem:
 - /product-x
 - /product-x?utm_source=google
 
-These generate separate cache objects unless normalized.
+These generate separate cache objects unless the URLs are normalized.
 
 Solution:
 Strip non-essential tracking parameters in VCL.
@@ -143,7 +167,7 @@ Strip non-essential tracking parameters in VCL.
 The [elgentos/magento2-varnish-extended](https://github.com/elgentos/magento2-varnish-extended) module improves this behavior.
 ```
 
-## 4. URL Normalization Issues
+### 4. URL Normalization Issues
 
 Different URL formats fragment your cache.
 
@@ -153,18 +177,18 @@ Examples:
 - Unsorted query parameters
 - Session IDs in URLs
 
-Normalize URLs to ensure identical content maps to a single cache object.
+Normalize URLs to ensure identical content maps to a single cache object in Varnish.
 
-## 5. Non-Cacheable Magento Blocks
+### 5. Non-Cacheable Magento Blocks
 
-In Magento, a single block marked as non-cacheable can disable Full Page Cache
-for the entire page.
+In Magento, a single block marked as non-cacheable can disable Full Page Cache (FPC) for the entire page.
 
 Search for non-cacheable blocks:
 
 ```console
 grep -R "cacheable=\"false\"" app/code vendor
 ```
+
 If found:
 - Verify the block truly needs to be dynamic
 - Remove cacheable="false" if unnecessary
@@ -172,38 +196,43 @@ If found:
 
 Even one unnecessary non-cacheable block can severely impact hit rate.
 
-# Optional — Enable Magento Developer Mode for Debugging
+## Optional — Enable Magento Developer Mode for Debugging
+
+Enable developer mode temporarily for debugging purposes:
 
-Developer mode provides more detailed error output:
 ```console
 magerun2 deploy:mode:set developer
 ```
 
 Or: 
+
 ```console
 php bin/magento deploy:mode:set developer
 ```
 
-# Debugging Tools
+## Debugging Tools
+
+### varnishlog
 
-## varnishlog
 Inspect detailed request handling:
-```bash
+```console
 varnishlog
 ```
 Look for recurring MISS patterns on pages that should be cacheable.
 
-## varnishncsa
+### varnishncsa
+
 Show hit/miss per URL:
-```bash
+```console
 varnishncsa -F '%U%q %{Varnish:hitmiss}x'
 ```
 Filter for hits:
-```bash
+```console
 varnishncsa -F '%U%q %{Varnish:hitmiss}x' | grep hit
 ```
 
-## Hypernode Insights (If Available)
+### Hypernode Insights (If Available)
+
 Use Hypernode Insights to:
 - Monitor hit/miss ratios
 - Detect purge spikes

From eb04b455b398c5e6334cf6598a7bf71255ec97c1 Mon Sep 17 00:00:00 2001
From: Jonathan Visser <jonathan.visser@team.blue>
Date: Mon, 9 Mar 2026 15:55:01 +0100
Subject: [PATCH 08/10] Add tideways_redis_keys_enabled setting to Tideways
 documentation

---
 .../performance/how-to-set-up-tideways.md              | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/docs/best-practices/performance/how-to-set-up-tideways.md b/docs/best-practices/performance/how-to-set-up-tideways.md
index e11dce53..2889a59c 100644
--- a/docs/best-practices/performance/how-to-set-up-tideways.md
+++ b/docs/best-practices/performance/how-to-set-up-tideways.md
@@ -45,6 +45,16 @@ You can assign an environment label (for example when this node is a staging ser
 hypernode-systemctl settings tideways_env_name staging
 ```
 
+#### Optional: Collect Keys for Redis Instrumentation
+
+Enable Redis key collection to see which keys are accessed by Redis operations in your traces. This provides more detailed insights when debugging Redis-related performance issues.
+
+```bash
+hypernode-systemctl settings tideways_redis_keys_enabled True
+```
+
+**Please note:** This setting can have privacy implications if your application uses personal identifiable information (such as email addresses or IP addresses) inside Redis keys. For more information, see the [Tideways documentation on Redis instrumentation](https://support.tideways.com/documentation/setup/configuration/advanced-instrumentation.html#collect-keys-for-redis-instrumentation).
+
 ### Activation through Control Panel
 
 It’s also possible to configure Tideways in the Control Panel.

From 84aff72d7f8465522875f18c99b833a67a0946ed Mon Sep 17 00:00:00 2001
From: Jonathan Visser <jonathan.visser@team.blue>
Date: Thu, 19 Mar 2026 12:59:20 +0100
Subject: [PATCH 09/10] Fix markdown formatting for
 improving-varnish-hit-rate-on-hypernode.md

---
 ...improving-varnish-hit-rate-on-hypernode.md | 60 +++++++++++++------
 1 file changed, 41 insertions(+), 19 deletions(-)

diff --git a/docs/hypernode-platform/varnish/improving-varnish-hit-rate-on-hypernode.md b/docs/hypernode-platform/varnish/improving-varnish-hit-rate-on-hypernode.md
index f2edea74..bca698e3 100644
--- a/docs/hypernode-platform/varnish/improving-varnish-hit-rate-on-hypernode.md
+++ b/docs/hypernode-platform/varnish/improving-varnish-hit-rate-on-hypernode.md
@@ -1,7 +1,9 @@
 ---
 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 +19,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 +36,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 +50,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 +65,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 +83,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 +109,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 +122,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 +135,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 +147,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 +161,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 +186,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 +205,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 +220,7 @@ Enable developer mode temporarily for debugging purposes:
 magerun2 deploy:mode:set developer
 ```
 
-Or: 
+Or:
 
 ```console
 php bin/magento deploy:mode:set developer
@@ -215,18 +231,23 @@ 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
 ```
@@ -234,6 +255,7 @@ 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
\ No newline at end of file
+- Correlate cache drops with deployments or cron jobs

From 81898f67a57c53a043dcbec8a24c141c08fe967b Mon Sep 17 00:00:00 2001
From: Jonathan <jonathanvis148@gmail.com>
Date: Thu, 19 Mar 2026 13:04:34 +0100
Subject: [PATCH 10/10] Update
 docs/hypernode-platform/varnish/improving-varnish-hit-rate-on-hypernode.md

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
---
 .../varnish/improving-varnish-hit-rate-on-hypernode.md      | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/hypernode-platform/varnish/improving-varnish-hit-rate-on-hypernode.md b/docs/hypernode-platform/varnish/improving-varnish-hit-rate-on-hypernode.md
index bca698e3..fd4dc1c6 100644
--- a/docs/hypernode-platform/varnish/improving-varnish-hit-rate-on-hypernode.md
+++ b/docs/hypernode-platform/varnish/improving-varnish-hit-rate-on-hypernode.md
@@ -1,9 +1,9 @@
 ---
 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
 ---