Astral 360 WSA — Website Accelerator

Optimization and developer tools

Using browser developer tools to identify cookies and URIs to exclude from cache.

Good WSA configuration depends on your knowledge of your site's actual behavior: which cookies does it use to identify users? Which URLs need real-time content? This page guides you through using browser developer tools to retrieve this information.

💡 The tutorial uses Google Chrome for captures and shortcuts, but Firefox and Edge have similar tools accessible via the same keyboard shortcuts.

1. Prepare the developer tool

The developer tool will help you throughout the tutorial to get information ordinarily inaccessible on your site. Before starting, go to your site and open the tool.

1.1 Open the tool

In Google Chrome, you have two options:

  • Press Ctrl + Shift + I (Windows / Linux) or Cmd + Option + I (Mac) on your keyboard.
  • Or click the 3 dots in the top right, go to More tools, and click Developer tools.

1.2 Disable browser cache

Once the tool is open, go to the Network tab and check the Disable cache box.

This box prevents the browser from keeping a local copy of the page, which would skew the analysis. You want to see what really happens between your browser and the server, without local optimizations that would mask the diagnosis.

⚠️ Don't forget that the Disable cache box only works when the developer tool is open. As soon as you close it, the browser cache resumes.

2. Cookies

Cookies are ubiquitous when browsing the web. They are text information saved in your browser to help identify you in various situations when navigating the web. They have a lifetime ranging from a few minutes to a few months.

One example of their use is to identify a logged-in user.

2.2 Why cookies matter for cache

Considering it's the cookie that keeps authentication active, if the user loses their cookie, they'll automatically be logged out.

Hence the importance of not caching everything on your site. A page with an important cookie in the cache could cause:

  • Session sharing between different users — one person could see another's shopping cart.
  • Login prevention — by placing an empty cookie in the buffer memory, the website will always think a visitor has never entered their login information.

2.3 Verify cookies on your site

Now that you have a better idea of cookie usage on the web, let's look at the cookies your site uses:

  1. Go to the homepage of your site.
  2. Open the developer tool (F12).
  3. Make sure you're in the Network tab.
  4. Click the Doc subtab (filter to see only HTML documents).
  5. Refresh the page (Ctrl + R).

In most cases, there should be only one line in the list. In cases where multiple lines appear, choose the line named for the page you're currently on.

2.4 Read the cookies list

When you click the line, a page appears on the right. On this page, go to the Cookies tab.

You'll find a list of cookies currently used by your site. Note them and classify them into two categories:

"Base" category

Cookies always present on your site that should not cause problems with page caching. Typical examples:

  • _ga, _gid — Google Analytics (statistical tracking only).
  • cookielawinfo-* — GDPR consent.
  • wp_woocommerce_session_* — Empty WooCommerce session.

These cookies don't identify a logged-in user or contain private data — the cache can ignore their presence.

"Important" category

Cookies that identify a user or contain user data. Navigate to pages that in your opinion would require adding new cookies:

  • Login page — log in, then observe new cookies appear.
  • Shopping cart — add a product, see new cookies.
  • Web form — fill out and submit, see new cookies.
  • Member area — navigate your logged-in account.

Note these new cookies in the "Important" category, because under no circumstances should pages containing these cookies be cached to guarantee proper site functioning.

Typical examples:

  • wordpress_logged_in_* — Logged-in WordPress session.
  • PHPSESSID — Generic PHP session.
  • woocommerce_cart_hash — Active WooCommerce cart.
  • customer_* — E-commerce customer session cookies.

2.5 Add cookies to WSA

The cookies collected in the "Important" category should be placed in the cookie list not to cache:

  • Simple mode: these exclusions are automatically managed by the profiles — the Online store profile already knows WooCommerce / PrestaShop / Magento cookies.
  • Advanced mode: open a domain's editor, go to the Dynamic tab, in the Cookie bypass list section, add each cookie name one by one with the + button.

💡 The trailing * wildcard is supported. For example, wordpress_logged_in_* matches all cookies whose name starts with wordpress_logged_in_ (useful because WordPress adds a unique hash to the name).

3. URIs

3.1 What's a URI?

A URI (Uniform Resource Identifier) is the part of your website's link representing a page, after the domain name.

For a WordPress-built site, the admin page with the domain will be mysite.com/wp-login.php. The URI to consider is then /wp-login.php — we keep only what follows the domain.

3.2 Which URIs to exclude from cache

When talking about adding cache on a site, there are surely some pages where it's preferable to cache nothing. Among these pages, here are some examples where it's preferable to abstain from adding cache:

Page type WordPress examples WooCommerce / e-commerce examples
Administration /wp-admin, /wp-login.php /admin, /dashboard
Dynamic form /contact (sometimes) /checkout, /cart
Member area /account, /profile /my-account, /customer/*
Content preview /?p=preview /preview

However, it's up to you to judge the usefulness of not caching a page. For example, on a blog, a /contact page that simply displays a static form can perfectly well be cached — only the form processing (POST submission) should not be, and that one is never cached anyway (WSA only caches GET requests).

3.3 How to note a page's URI

To note a page's address, simply go there and look after the domain name's slash:

Full URL in browser URI to note
https://example.com/wp-login.php /wp-login.php
https://shop.example.com/cart/ /cart/
https://blog.example.com/?p=preview&id=42 /?p=preview
https://site.com/admin/dashboard/users /admin/dashboard/users

📝 If you have several subfolders, you can simply bypass the parent folder: /admin covers all paths starting with /admin/. No need to enumerate each subpage.

3.4 Add URIs to WSA

Collected pages should be added in the URI list not to cache:

  • Simple mode: these exclusions are automatically managed by the profiles.
  • Advanced mode: open a domain's editor, go to the Dynamic tab, in the URI bypass list section, add each URI one by one with the + button.

📝 Important: only place what follows the domain. For example, for the page https://example.com/wp-login.php, keep only /wp-login.php.

4. Verify the cache works (WSA 2.2 new)

Once your cookies and URIs are configured, verify the cache acts as expected:

4.1 Enable cache status header

WSA can send an X-Nginx-Cache-Status header on every response, telling you in real time what's happening:

  • Simple mode: enabled by default, nothing to do.
  • Advanced mode: Basic tab → Show cache status header toggle on On.

4.2 Read the header in DevTools

  1. Developer tool → Network tab.
  2. Refresh your site's page.
  3. Click the first line (the HTML page itself).
  4. In the right pane, go to Headers → Response Headers section.
  5. Look for X-Nginx-Cache-Status.

4.3 Interpret the value

Value Meaning Action
HIT Served from cache. Perfect! None.
MISS First visit, page now cached. Refresh a 2nd time → should go HIT.
BYPASS Cache deliberately bypassed (cookie, excluded URI, Cache-Control). Verify it's intentional. If not, see 4.4.
EXPIRED Stale entry, fresh fetched. Normal after TTL expired.
REVALIDATED Re-validated with Apache (304). Normal.

4.4 If you always see BYPASS

Typical causes:

  • A cookie is set on every page: your app sends a Set-Cookie on every visit. Check the Cookies tab in Network to identify which one.
  • The URL matches an exclusion URI: check your URI bypass lists in WSA.
  • The app sends Cache-Control: no-cache: visible in Headers tab → Response Headers. Enable Bypass Cache-Control in WSA to ignore this directive.

4.5 Compare HIT vs MISS to measure the gain

In the Network tab, the Time column displays each request's duration:

  • Without cache (MISS): typically 200-1000 ms.
  • With cache (HIT): typically 5-50 ms.

The ratio is your measured gain. A typical WordPress site goes from 600 ms (MISS) to 15 ms (HIT) — 40× faster.

5. Bot protection (WSA 2.2 new)

WSA 2.2 advanced mode now includes 8 categories of unwanted bot protection. You can check in server logs which bots visit your site:

5.1 See bots blocked by WSA

The WHM dashboard displays a Top Offenders with the 10 most-blocked User-Agents over the last 24 hours.

cPanel customer side: open advanced mode, in the Bot Protection tab, each category is in Server default mode by default. If you see unexpected bots in your Apache log, you can:

  1. Force a category to Blocked on your domain.
  2. Add the specific User-Agent to this category's list.

5.2 Identify a bot in your logs

# See most frequent User-Agents on your site
cd /home/<user>/access-logs
sort *.log | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn | head -20

User-Agents appearing at the top of the list without matching a real browser (Chrome, Firefox, Safari, mobiles) are your candidates for blocking.

6. Verify served compression format

WSA automatically enables Gzip compression and, if installed by your host, Brotli. To verify which is served to your browser:

  1. Network → click the HTML page.
  2. Headers → Response Headers → Content-Encoding.
Value Compression
br Brotli (ideal, ~20% smaller than gzip).
gzip Gzip (standard, broad compatibility).
(absent) No compression (file already compressed, or config error).

7. Verify HTTP/3 works (WSA 2.2 new)

If your host has enabled HTTP/3 on the server:

  1. Network → click any line.
  2. Headers → Response Headers → look for Alt-Svc.

If you see Alt-Svc: h3=":443"; ma=86400, h2=":443"; ma=86400, your server announces HTTP/3.

To verify your browser uses it:

  1. Reload the page once (so Chrome catches the Alt-Svc announcement).
  2. Reload again.
  3. The Protocol column in Network should display h3 instead of h2 or http/1.1.

💡 If the Protocol column isn't visible, right-click the Network column headers and enable Protocol.

A complete workflow to configure WSA on a new site using developer tools:

  1. Install WSA in simple mode with the most appropriate profile (Daily for a blog, Store for a shop, etc.).
  2. Navigate your site in all its important zones:
    • Homepage
    • Product / article page
    • Login / signup page
    • Cart / checkout (if applicable)
    • Contact / form page
  3. Inventory cookies appearing at each step (e-commerce sites generate new cookies over the interaction).
  4. Verify X-Nginx-Cache-Status on public pages (should be HIT) and logged-in pages (should be BYPASS).
  5. If a logged-in page returns HIT, it's a leak risk — switch to advanced mode and add the missing cookie to the bypass list.
  6. Measure response times on 5-10 pages to confirm the gain.

9. Further reading