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
PHPSESSIDcookie - High
admin-ajax.phpactivity from features such aspys_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
MISSorBYPASS - A site that only feels fast after a few page loads
- Heavy
admin-ajax.phpactivity 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
1. PHP Sessions and the PHPSESSID Cookie
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
Pressable disables Batcache and Edge Cache for logged-in administrator sessions. Testing while logged into WP Admin will show bypassed cache behavior that has nothing to do with what anonymous visitors see. Always verify cache behavior from a logged-out private window.
Using Browser Developer Tools
Start with these checks:
- Inspect response headers for frontend pages and look for
Set-Cookie, especiallyPHPSESSID - Check whether Edge Cache is showing
MISSorBYPASSrepeatedly for anonymous traffic - Open the Network tab and filter for
admin-ajaxto 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.
Recommended Settings and Corrective Actions
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):
- From the plugin’s main settings page, go to Global Settings.
- Find the Disable PHP Sessions toggle and enable it.
- Save the settings, then purge all cache from the MyPressable Control Panel or with the Pressable Cache Management Plugin.
- Retest from a logged-out private browsing window.
PixelYourSite’s own documentation marks this toggle as off by default, only for use when troubleshooting session or caching conflicts. That’s exactly the situation here, so enable it. Doing so may reduce accuracy for some session-based attribution data (landing page, traffic source, UTMs), so test the tracking impact before committing to the change permanently.
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.
This is a code-level change, best suited to developer-managed sites. See PixelYourSite’s documentation on consent filters for full details: https://www.pixelyoursite.com/docs/consent-filters-hooks
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.
Recommended Troubleshooting Order
If you’re using PixelYourSite on Pressable and performance is poor:
- Confirm whether anonymous frontend traffic is cacheable
- Check for
PHPSESSIDor other unexpected cookies on frontend responses - Enable PixelYourSite’s Disable PHP Sessions toggle in Global Settings
- Reduce unnecessary AJAX features, especially consent- or identifier-related AJAX behavior
- Purge cache and retest from a logged-out browser session
- If the issue remains, move on to plugin conflict testing or deeper
admin-ajax.phpanalysis
Cache is almost always the first thing wrong; AJAX load tends to be the secondary issue once caching is restored.
Related Pressable Resources
- Edge Cache
- Caching Types Available in Pressable
- Tips for Troubleshooting Website Performance Issues
- Understanding and Troubleshooting admin-ajax.php in WordPress
- The Pressable Cache Management Plugin
- How to Flush WordPress Site Cache and Purge Edge Cache (CDN)
- How to Test for Plugin and Theme Conflicts