Using PixelYourSite on Pressable

Last modified: July 3, 2026

Ask Your Favorite AI

Copy the link to a markdown format of this article for ChatGPT, Claude, Gemini, or your favorite AI.

PixelYourSite, including both the free and Pro versions, can work on Pressable. Some configurations, though, interfere with caching and generate heavy uncached traffic. The two most common issues are:

  • Frontend requests becoming uncacheable because PixelYourSite starts a PHP session and sets a PHPSESSID cookie
  • High admin-ajax.php activity from features such as pys_get_pbid, pys_api_event, and some GDPR-related AJAX behavior

Either of those can make a site feel much slower than expected, even when Pressable’s caching is available and configured correctly. This article explains why, how to recognize it, and what to change.

How PixelYourSite Affects Performance on Pressable

Pressable uses multiple caching layers: Batcache for full-page caching and Edge Cache for serving cached pages and static assets from edge locations. Both work best when anonymous visitors can be served from cache. If a plugin sets server-side cookies or makes responses dynamic on every page load, caching gets bypassed.

With PixelYourSite, the two issues we see most often are session_start() setting a PHPSESSID session cookie on every page load, and AJAX activity through pys_get_pbid, pys_api_event, and GDPR-related requests. Left unaddressed, these can break caching entirely and put significant load on admin-ajax.php.

Common Symptoms

You may be dealing with a PixelYourSite performance issue if you notice:

  • High Time to First Byte (TTFB) for logged-out visitors
  • Cache headers showing repeated MISS or BYPASS
  • A site that only feels fast after a few page loads
  • Heavy admin-ajax.php activity in browser developer tools, logs, or performance tooling
  • Slowdowns that started after enabling or reconfiguring PixelYourSite features related to sessions, consent, or tracking identifiers

The pattern makes sense once you know how Pressable’s caching works: normal anonymous page views can be cached, but every admin-ajax.php request is uncached and consumes a PHP worker.

The Main Problem Patterns

When PixelYourSite starts a PHP session for anonymous frontend visitors, WordPress sends a PHPSESSID cookie with the response. On Pressable, that prevents Batcache and Edge Cache from storing and serving the page normally, so pages rebuild dynamically far more often than they should.

2. High admin-ajax.php Usage

Some PixelYourSite setups generate a lot of AJAX traffic. The actions we see most often are pys_get_pbid, pys_api_event, and GDPR consent requests. Since admin-ajax.php is uncached and every request uses a PHP worker, high volume here degrades performance even if page caching is otherwise working. On sites where this issue is present, PixelYourSite’s AJAX call count tends to dwarf every other plugin on the site.

How to Identify Whether PixelYourSite Is the Culprit

Using Browser Developer Tools

Start with these checks:

  • Inspect response headers for frontend pages and look for Set-Cookie, especially PHPSESSID
  • Check whether Edge Cache is showing MISS or BYPASS repeatedly for anonymous traffic
  • Open the Network tab and filter for admin-ajax to see if the page is firing repeated background requests
  • Compare behavior in a logged-out private window versus a logged-in session

Broken Versus Working Cache Headers

When PixelYourSite is starting a PHP session and caching is broken, a curl -I or browser header inspection will typically show:

set-cookie: PHPSESSID=...; path=/
cache-control: no-store, no-cache, must-revalidate
pragma: no-cache

After disabling PHP sessions in PixelYourSite and purging cache, the same page should show:

cache-control: max-age=300, must-revalidate
x-nananana: Batcache-Set
x-ac: ... HIT

PHPSESSID in the response headers alongside no-store / no-cache cache-control directives is a reliable sign that something (PixelYourSite or another plugin) is starting PHP sessions on the frontend.

Using a Staging Clone to Confirm the Issue

Before touching a live site, consider creating a staging copy with PixelYourSite deactivated and comparing cache behavior between the two. In practice, deactivating PixelYourSite on the staging copy has immediately restored normal caching and produced the expected cache hit headers. If the staging site shows clean hits and production doesn’t, PixelYourSite is almost certainly involved.

SSH Diagnostic

Using SSH access, you can find which plugins are calling session_start() (the PHP function that creates the PHPSESSID cookie) by running this from the site root:

grep -Ril "session_start(" wp-content/plugins

Not every result is necessarily active in production; some will be in vendor libraries or unused code paths. But any PixelYourSite files in the output confirm the mechanism is there.

First Priority: Stop PixelYourSite From Breaking Anonymous Page Caching

If your site is slow for logged-out visitors and PixelYourSite is active, the first thing to check is whether the plugin is starting PHP sessions. PixelYourSite has a built-in setting for this (available since version 9.5.3):

  1. From the plugin’s main settings page, go to Global Settings.
  2. Find the Disable PHP Sessions toggle and enable it.
  3. Save the settings, then purge all cache from the MyPressable Control Panel or with the Pressable Cache Management Plugin.
  4. Retest from a logged-out private browsing window.

Performance may dip briefly while cache rebuilds after the first purge.

Second Priority: Reduce Unnecessary PixelYourSite AJAX Traffic

If caching is working but the site still underperforms, check whether PixelYourSite is generating a large number of admin-ajax.php requests. Filtering your server logs is a good way to do this.

If you’re managing GDPR consent through a separate tool and don’t need PixelYourSite’s built-in GDPR AJAX behavior, disabling it can meaningfully reduce the load. PixelYourSite exposes a WordPress filter for this:

add_filter( 'pys_gdpr_ajax_enabled', '__return_false' );

Add that to a must-use plugin, a code snippet plugin, or your theme’s functions.php.

Third Priority: Verify That Cache Is Actually Being Used

After adjusting PixelYourSite’s settings, verify cache behavior from a logged-out session. On Pressable, the x-ac response header indicates Edge Cache status; the Edge Cache documentation explains what HIT, MISS, and BYPASS mean.

Continued misses or bypasses on anonymous requests usually point to another cookie or plugin conflict.

A Note on Custom Mitigations for Technical Users

For agency-managed or developer-supported sites, it’s sometimes possible to write a small must-use plugin that strips the session cookie for anonymous visitors before it reaches the cache layer. We’ve seen this work as a fast, reversible way to restore caching without waiting on plugin configuration changes. Pressable may be able to share a sample starting point, but any custom code is the site owner’s or developer’s responsibility to maintain.

That said, it’s a patch rather than a fix. The session is still being started; it’s just being hidden from the cache. Fixing PixelYourSite’s settings is the cleaner path.

If you’re using PixelYourSite on Pressable and performance is poor:

  1. Confirm whether anonymous frontend traffic is cacheable
  2. Check for PHPSESSID or other unexpected cookies on frontend responses
  3. Enable PixelYourSite’s Disable PHP Sessions toggle in Global Settings
  4. Reduce unnecessary AJAX features, especially consent- or identifier-related AJAX behavior
  5. Purge cache and retest from a logged-out browser session
  6. If the issue remains, move on to plugin conflict testing or deeper admin-ajax.php analysis

Cache is almost always the first thing wrong; AJAX load tends to be the secondary issue once caching is restored.