# Caching > Source: https://www.allsweb.com/sixpanel/docs/caching > Markdown for agents: https://www.allsweb.com/sixpanel/docs/caching.md > Publisher: AllsWeb (www.allsweb.com) Part of: SixPanel documentation **What this page is for:** make a website faster with the caches that fit it — **Varnish** in front of it, a **Memcached** of its own, **Redis** (WordPress's object cache, or your app's own use), the **WordPress page cache** — and compress everything the server sends with **Brotli**. Each one is optional: nothing is installed and nothing runs until you turn it on. Open the website, then **Caching** in its menu. The server's side of each — installing it, its memory, the websites using it — is **Software**. **You need** - The owner's login to change anything here. A temporary login can read the page and press **Purge cache**; the read-only demo shows it but changes nothing. - Memcached, Varnish and Brotli installed from **Software** before a website can use them. Each card there says what it needs (memory, disk) before you press **Install**. **The rule that does not move:** a cache only ever keeps what the app allows. A visitor who is signed in, has a cart, or carries a cookie the app reads always reaches the app, and so do the admin, the sign-in page, the cart, the checkout and anything the app marks as private. --- ## Which cache for which website | Website | Varnish | Memcached | Redis | Page cache | |---|---|---|---|---| | WordPress | yes (pages) | for plugins that use it | yes — the object cache | yes (nginx), never with Varnish | | PHP | yes | yes (PHP extension) | yes (and sessions) | — | | Node.js, Create with AI | yes | yes (`MEMCACHED_SOCKET`) | yes (`REDIS_URL` …) | — | | Python, Java | yes | yes (`MEMCACHED_SOCKET`) | yes (`REDIS_URL` …) | — | | Reverse proxy | yes | — | — | — | | Static | — (nginx already serves the files from disk) | — | — | — | Brotli is for the whole server: every website and every shop. A **static** website's Caching page has its recommendation, **Purge cache** and compression: nginx already serves its files from disk and tells browsers to keep them, so it has nothing else to add. ## Recommended for this website The first card on the Caching page works out which of these fit **this** website, and whether each one works, every time the page opens (**Measure again** asks once more). For Varnish, the WordPress page cache, Memcached, Redis and compression — and a static website's browser cache — one row says what it is for, whether it is **on** here, whether it **works**, a verdict (**Recommended**, **Optional**, **Not needed** or **In use**), why, and the memory it would use. **What it reads.** The kind of website, and what the website's own files say it uses — names only, never a value: for WordPress an object cache in `wp-content/object-cache.php` and the caching plugins in `wp-content/plugins`; for PHP and Laravel the cache, session and queue drivers of its `.env` (`CACHE_STORE`, `CACHE_DRIVER`, `SESSION_DRIVER`, `QUEUE_CONNECTION` — nothing else in that file is read into the page); for Node.js and Create with AI a Redis or Memcached client in `package.json`; for Python `requirements.txt` and `pyproject.toml`; for Java `pom.xml` and `build.gradle`. Files are read from the live version only, and never through a link. **What it measures, on this server, just now.** The website's home page is asked twice the way a visitor who is not signed in asks: the `X-Cache` of the second answer says whether Varnish or the page cache kept it, `Content-Encoding` whether it was compressed (and with what), `Cache-Control` and a `Set-Cookie` whether a cache may keep it at all. Its Redis is sent `PING`; its Memcached's own counters give how many lookups were found in it. A website with no certificate yet, a parked one, or one whose home page answers an error or sends visitors elsewhere is not measured, and the card says which. **The verdicts it never gives.** Varnish is never recommended for a page that sets a cookie or says `private`, `no-store` or `no-cache` — it would keep nothing and only add a step, and a signed-in page must never be kept. A reverse proxy is offered Varnish only when its upstream says its answers may be kept (`Cache-Control: max-age`); a WordPress website is offered the page cache first (it uses no memory) and Varnish only as the alternative. Another plugin's object cache is never replaced. Nothing a kind cannot have is offered. **Apply** does it where the panel can do it safely, and asks first, saying the memory it uses: Redis is added (as on the Database page), Brotli is switched on for the server, the WordPress page cache is ticked; for Varnish, Memcached and the object cache it presses the card's own button below, with that card's question. Where it cannot — an app has to be told to use Redis — **How to connect it** gives the exact steps: for Laravel the lines for its `.env` (`REDIS_HOST` is the socket, `REDIS_PORT=0`, `CACHE_STORE=redis`; Laravel 10 and older read `CACHE_DRIVER`), and `php artisan config:clear` when the app has cached its configuration. ## Varnish Varnish keeps the pages a visitor gets **without signing in** in memory and answers the next visitor from there — the app is not asked at all. On the website's **Caching** page press **Turn Varnish on**. What happens, in order: - **nginx keeps the certificate.** Visitors still reach the website's own nginx on HTTPS, with its Web Rules and the Cloudflare-only lock as before. nginx hands each request to Varnish, which listens on **this server only** (`127.0.0.1:6081`) — never on the internet. - **If Varnish stops, nothing goes offline.** nginx then serves the website directly, as it did without Varnish, only not cached. The panel starts Varnish again by itself within a few minutes (up to 3 times a day); **Software → Varnish → Start / repair** does it at once. - **What is kept:** pages (status 200) and "not found" answers (404 — a minute at most, unless the app says otherwise). Never a redirect, an error, a file over 10 MB, an answer that sets a cookie or says `private`, `no-store` or `no-cache`, and never anything for a request with a cookie the app reads, a password (`Authorization`), or a method other than GET and HEAD. WordPress's admin, sign-in, REST API, cart, checkout and account pages, and WooCommerce's own requests, always reach PHP. Advertising tags (`?utm_source=…`, `?gclid=…`) are answered from the plain page's copy. - **How long:** the app's own `Cache-Control` decides. A page that says nothing about caching is kept for the website's own time — **1800 seconds (30 minutes) for WordPress**, **0 (not at all) for every other kind** until you set one in the **Keep a page … for** field. Nothing is kept longer than a day. - **Every answer says what happened**, in its `X-Cache` header: `HIT` (from Varnish), `MISS` (fetched and kept), `PASS` (not kept, by the rules above). - **WordPress: never together with the page cache.** Turning Varnish on turns the WordPress page cache off; ticking the page cache in **Settings** turns Varnish off. Both pages say so. - **A staging site is never served through Varnish** — it is tested exactly as its own server block serves it. **Its memory** is set on **Software → Varnish**: 5 % of the server's memory by default (64 MB to 1 GB), and up to a quarter of it if you choose. A change restarts Varnish, which starts empty. Varnish runs only while at least one website uses it. **Turn Varnish off** puts nginx back in front of the website alone and empties what Varnish kept for it. A WordPress website can then turn its page cache back on in **Settings**. A Varnish somebody installed on the server by hand is never taken over: install it from **Software** after stopping your own (`systemctl disable --now varnish`). ## Purge cache **Purge cache** (on the Caching page) empties every cache the website has: Varnish, the WordPress page cache, and Cloudflare's copy of its addresses. You rarely need it — every **deploy** and **rollback** does the same, and a WordPress website behind Varnish is emptied the moment a post or a page changes. **Software → Varnish → Empty everything** empties Varnish for every website at once. Varnish takes no `PURGE` or `BAN` request over HTTP: a visitor reaches it from this server's own nginx, so no address could tell the panel's request from anyone else's — only the panel empties it (a plugin that sends `PURGE` gets 405). ## Memcached A website can have a **Memcached of its own** — for a PHP app, a Laravel app (`CACHE_STORE=memcached`), a WordPress plugin that uses Memcached (W3 Total Cache, LiteSpeed Cache …), or a Node.js, Python or Java app. On the Caching page choose its **memory** (64 MB to start; from 16 MB up to an eighth of the server's memory, 1 GB at most) and press **Add Memcached**. What the panel makes: - **An instance that only this website can open.** It runs as the website's own account, on a unix socket in a folder only that account can enter (`/run/memcached-site-/memcached.sock`). There is no network port at all: no other website on the server, and nothing on the internet, can read or write it. (Memcached has no password, which is why the shared instance its package brings — `127.0.0.1:11211`, open to every account — is never switched on.) - **The PHP extension** (`memcached`) is turned on for this website's PHP only; the other websites' and shops' PHP do not change. It needs `msgpack` and `igbinary` loaded before it, so the ones the server's PHP does not load for everyone are turned on for the website too, and loaded first. - **The connection details** on the card: the socket and the lines to paste. A Node.js app finds it in its environment as `MEMCACHED_SOCKET` (restart the app after adding it). It is a **cache**: nothing in it is kept on disk, and it starts empty after a restart of the server, a memory change, or **Start Memcached**. What does not fit is dropped, oldest first. **Empty it** removes everything in it now (an app that keeps its sign-ins in Memcached signs everyone out). **Remove Memcached** takes the instance away; an app written to need it shows errors until it is added again. The PHP extension stays on for the website. If it stops, the panel starts it again by itself within a few minutes (up to 3 times a day); **Start Memcached** does it at once. A website that is being moved has it stopped on purpose. ## Redis for WordPress, Node.js, Python and Java Every website that runs code of its own can have a **Redis of its own** now (it is added on its **Database** page, with its memory and its own password, exactly as for a PHP website). What it is used for depends on the kind: - **WordPress — the object cache.** On the Caching page press **Keep the object cache in Redis**. SixPanel installs the **Redis Object Cache** plugin (unless it is already there), writes the four lines it needs into `wp-config.php` (the socket, the password and a key prefix — the password never leaves the server), switches it on through WP-CLI as the website's own account, and checks that WordPress says **Connected**. It is offered, never forced. If another plugin's object cache is already in place (`wp-content/object-cache.php`), SixPanel does not replace it: turn that plugin's object cache off first. **Take the object cache out of Redis** removes what SixPanel added (the plugin too, when SixPanel installed it). - **Node.js, Create with AI, Python and Java** — the app's environment carries `REDIS_SOCKET`, `REDIS_PASSWORD` and `REDIS_URL`. Restart the app after adding Redis. When its password is changed (**Change password** on the Database page), a running Node.js app is given the new one and restarted. A WordPress website keeps its sign-ins in its own cookies and tables, so **Sessions in Redis** stays a choice of a plain PHP website (its PHP page). ## Brotli **Brotli** makes pages, scripts and stylesheets smaller than gzip. Install it from **Server → Software**: it comes from the distribution's own nginx modules, and Install turns it on. nginx then uses Brotli for every browser that asks for it (and for Cloudflare towards this server), and gzip for the others. It is part of nginx itself: nothing new runs. Every change is tested with `nginx -t` before nginx reloads. A website behind Varnish is sent the gzip copy Varnish keeps in memory, so no page is compressed again on each visit. If the module ever goes away (its package removed, or an nginx update it was not rebuilt for), the panel switches Brotli off at its next start, so nginx can always reload, and **Health** says so; gzip carries on meanwhile. ## PageSpeed There is no PageSpeed module. Google's `ngx_pagespeed` and `mod_pagespeed` are retired upstream, build against no current nginx, and have no build for ARM servers. Varnish (pages from memory) and Brotli (smaller files) are the server-side part of what it did; image and script optimisation belongs in the website itself or at Cloudflare. ## What a temporary login can do Read the Caching page and press **Purge cache**. Turning Varnish on or off, adding, sizing, starting, emptying or removing Memcached, the object cache, and everything on Software are the owner's. ## How to check it worked - The **Recommended for this website** card: each row that is on says **Works** or **Not working**, with what was measured. Press **Measure again** after a change. - Varnish: `curl -sI https:/// | grep -i x-cache` twice — the second answer says `HIT` for a page that may be kept. A page that should be kept and says `PASS` carries a cookie or a `Cache-Control` that forbids it; the app decides. - Memcached: the card shows **Running**, the memory used and how many lookups were found in it. - **Server → Health** has a row for each: **Websites' Memcached**, **Varnish**, **Brotli compression**. ## If it went wrong - **A signed-in page shows to a visitor who is not signed in** — that page reached Varnish without the cookie that marks the visitor, or the app sent it without `private`/`no-cache`. Press **Purge cache**, then set the page's `Cache-Control` in the app (or set **Keep a page … for** to 0, which keeps only what the app explicitly allows). - **Varnish is not running** — nothing is down (nginx serves the websites directly). Press **Start / repair** on Software → Varnish; the job's log says what it found. Over SSH, `journalctl -u varnish` is Varnish's own log. - **Memcached does not start** — press **Start Memcached**; the panel tries again by itself. Over SSH, `journalctl -u sixpanel-memcached@` is its own log. - **The object cache will not turn on** — the job's log says why: another plugin's object cache is in place, WordPress is not installed yet, or the website has no Redis.