Performance Degradation
Use this guide to troubleshoot performance degradation in Pressidium EDGE.
Performance degradation means your site was performing acceptably before, but has become slower over time or after a specific change. This is different from a site that has always been slow. Use this guide to compare current performance with earlier behavior, identify what changed, and decide which area needs deeper investigation.
When to use
Use this guide when:
- Site performance has declined over time
- Load times are increasing compared with earlier results
- Server response time is higher than before
- Cache hit rate has dropped
- Error rate has increased
- Traffic has grown and performance has become less stable
- A recent plugin, theme, cache, DNS, firewall, or origin change appears to have affected performance
- Performance is worse during specific hours, campaigns, or traffic spikes
If the site is simply slow and you do not know whether this is a new issue, start with Site Loading Slowly.
Symptoms
Common signs of performance degradation include:
- Gradual slowdown: Pages become slower over days, weeks, or months.
- Increased load times: Important pages take longer to load than before.
- Higher server response time: Requests take longer to be generated by the origin.
- Lower cache hit rate: Fewer eligible requests are served from cache.
- More cache misses or bypasses: Requests that were previously cached now reach the origin more often.
- Increased error rate: More requests return
4xxor5xxresponses. - Traffic-related instability: Performance becomes worse during traffic spikes or campaigns.
- Path-specific slowdown: A small number of URLs, endpoints, or WordPress paths have a large performance impact.
- Frontend metric decline: Core Web Vitals, TTFB, LCP, CLS, FCP, or TBT have worsened compared with previous audits.
Common causes
Traffic growth
Issue: Traffic increased and the site now receives more requests than before.
This can increase origin load, expose uncached dynamic paths, reduce perceived performance, or increase the impact of slow pages.
What to check:
- Request volume over time
- Traffic spikes
- Campaign or launch dates
- Bot, crawler, or suspicious traffic
- High-volume URLs
- Top IPs, countries, and referrers
- Changes in pageview and static asset request volume
- Whether more requests are reaching the origin instead of being served from cache
What to do:
- Review traffic patterns in Traffic Analytics.
- Identify URLs with the highest request volume.
- Check whether high-traffic pages are cacheable.
- Review cache behavior for top paths.
- Investigate suspicious or abnormal traffic before blocking it.
- Consider plan or infrastructure changes if legitimate traffic has grown beyond the current setup.
Cache behavior changed
Issue: More traffic is bypassing cache or missing cache than before.
A lower cache hit rate can increase origin load and make pages slower, especially on high-traffic public pages.
What to check:
- Cache hit rate
- Cacheable hit rate
- Increase in cache misses
- Increase in cache bypasses
- Top URLs by cache status
- Recent cache purges
- New cache exclusions
- Cookie-based cache bypass
- Logged-in, cart, checkout, account, LMS, membership, search, or dynamic paths
- Plugins or origin headers that prevent caching
What to do:
- Review cache status in Cache Analytics.
- Compare the same time range before and after the slowdown.
- Identify high-traffic URLs with unexpected misses or bypasses.
- Review cache exclusions and custom rules.
- Check whether WordPress plugins are setting no-cache headers or cookies.
- Purge affected cache only when stale or incorrect content is involved.
See Cache Not Working for cache-specific troubleshooting.
Origin response time increased
Issue: The origin or WordPress application takes longer to generate responses.
This is common when more uncached requests reach WordPress, database queries become slower, plugins add processing overhead, or traffic increases.
What to check:
- Server response time trend
- Total request time trend
- High-impact paths
- Frequent
POST, AJAX, REST API, admin, search, cart, checkout, LMS, or membership requests - Slow dynamic pages
- Recent plugin or theme changes
- Recent WordPress, WooCommerce, LMS, or membership changes
- Database-heavy pages
- External API calls that block page generation
What to do:
- Use Performance Analytics to find paths with high impact.
- Compare server response time before and after the slowdown.
- Check whether slow paths are public pages, dynamic endpoints, or admin/API requests.
- Review plugins, custom code, queries, and external calls related to the affected paths.
- Optimize or cache expensive requests where safe.
- Contact Support if the origin remains slow and the cause is unclear.
Resource accumulation
Issue: The WordPress site has accumulated data, plugins, media, revisions, logs, transients, or unused features that add overhead.
Possible causes:
- Too many active plugins
- Heavy plugins or page builders
- Database bloat
- Expired transients or large option values
- Large media library
- Unused themes or plugins
- Excessive logs or temporary files
- Old optimization or cache layers
- Slow scheduled tasks or cron jobs
What to do:
- Review active plugins and remove unnecessary ones.
- Disable unused theme and plugin features.
- Clean up database data only after taking a backup.
- Remove unused media and large temporary files where safe.
- Review scheduled tasks and background processes.
- Avoid direct database changes unless you understand the impact or have developer support.
Configuration drift
Issue: Performance changed because configuration changed over time.
Configuration drift can happen after plugin updates, theme changes, cache changes, DNS changes, firewall rules, redirect updates, origin changes, or optimization setting changes.
What to check:
- Recent Dashboard changes
- Cache and cache exclusion changes
- WordPress plugin or theme updates
- New plugins
- Performance plugin settings
- Image optimization settings
- Redirect changes
- DNS or SSL changes
- Origin hostname or IP changes
- Firewall, WAF, or bot protection changes
- Deployment history
What to do:
- Identify what changed before the degradation started.
- Compare the current setup with the last known good configuration.
- Revert one suspected change at a time where safe.
- Test after each change.
- Document the result before making further changes.
External services or third-party scripts
Issue: External services slow down page rendering or client-side loading.
Possible causes:
- Analytics scripts
- Ads
- Tracking pixels
- Chat widgets
- Payment gateways
- CRM forms
- External fonts
- Social embeds
- External APIs
- Third-party JavaScript added by plugins or tag managers
What to check:
- Browser waterfall
- Third-party request timing
- JavaScript errors
- Render-blocking scripts
- Slow API responses
- Changes in tag manager containers
- New marketing, analytics, or advertising scripts
What to do:
- Remove unused third-party scripts.
- Defer or delay non-critical scripts where safe.
- Load third-party scripts only on pages that need them.
- Cache external API responses when appropriate.
- Add timeouts or fallbacks for external API calls.
- Test before and after each change.
Frontend asset growth
Issue: Page weight, image size, JavaScript, CSS, fonts, or layout behavior has worsened.
What to check:
- Page weight
- Number of requests
- Large images
- Render-blocking CSS or JavaScript
- Layout shifts
- Web font loading
- New page builder sections
- New tracking or marketing scripts
- Mobile vs desktop audit differences
What to do:
- Run a Site Audit for affected pages.
- Compare current audit results with earlier results.
- Review Core Web Vitals and loading metrics.
- Optimize large images and unused assets.
- Remove unnecessary third-party scripts.
- Test mobile and desktop separately.
See Site Audit Screen for page-level performance audits.
Diagnostic steps
Step 1: Define the degradation
Start by clarifying what changed.
Check:
- When performance started to decline
- Whether the issue is constant or intermittent
- Whether it affects all pages or specific URLs
- Whether it affects all users or specific regions, devices, browsers, or networks
- Whether it affects frontend load time, server response time, cache behavior, or errors
- Whether the issue started after a known change
Write down the suspected start date and time. This makes analytics comparison more useful.
Step 2: Compare performance over time
Use the same time ranges when comparing performance.
In the Pressidium Dashboard:
- Open the site.
- Go to Performance -> Performance Analytics.
- Compare the current period with a previous equivalent period.
- Review request volume, total request time, and server response time.
- Identify hours where response timing increased.
- Open the high-impact paths for the affected period.
Look for:
- Higher average server response time
- Higher average total request time
- Request spikes
- Slow hours
- High-impact paths
- Increase in dynamic request methods such as
POST - A small number of paths responsible for a large part of the slowdown
See The Performance Analytics screen for request volume, response timing, and high-impact path analysis.
Step 3: Review cache behavior
In the Pressidium Dashboard:
- Open the site.
- Go to Performance -> Cache Analytics.
- Compare the current cache hit rate and cacheable hit rate with earlier periods.
- Review the cache status breakdown.
- Check whether hits decreased, misses increased, or bypasses increased.
- Review top URLs by cache status.
Look for:
- Sudden drop in cache hit rate
- Increase in cache misses
- Increase in bypassed requests
- High-traffic URLs that should be cacheable but are not
- Dynamic WordPress paths generating more traffic than expected
- Recent cache purges or exclusion changes
See Cache Analytics screen for cache hit rate, cacheable hit rate, hits, misses, bypasses, and top URLs.
Step 4: Review traffic patterns
In the Pressidium Dashboard:
- Open the site.
- Go to Traffic -> Traffic Analytics.
- Review total requests and response breakdown.
- Check top URLs by request volume.
- Review top countries, IPs, and referrers.
- Compare traffic before and after the degradation started.
Look for:
- Traffic spikes
- Unexpected countries or referrers
- Repeated requests from specific IP addresses
- More static asset requests than expected
- More
404, redirect, or error responses than usual - High-volume URLs that do not match normal user behavior
See Traffic Analytics screen for traffic volume, top URLs, request sources, geographic distribution, referrers, and response patterns.
Step 5: Identify recent changes
Review changes made before the degradation started.
Check:
- Plugin updates
- Theme updates
- WordPress updates
- WooCommerce, LMS, membership, or form plugin changes
- New page builder content
- New tracking scripts or tag manager changes
- Cache setting changes
- Cache exclusion changes
- Image optimization changes
- Redirect changes
- DNS or origin changes
- Firewall or WAF changes
- Traffic campaigns
- Content imports or migrations
Change history is often the fastest way to find the cause.
Step 6: Analyze affected paths
Use analytics to identify which paths matter most.
Focus on:
- Paths with high request count and high average response time
- Paths that became slower after a change
- Paths that bypass cache unexpectedly
- Dynamic paths such as checkout, account, search,
wp-admin,admin-ajax.php, REST API, LMS, membership, and form endpoints - Paths returning unexpected errors or redirects
- Static assets with unusually high request volume or slow delivery
Avoid optimizing low-traffic paths first unless they are business-critical.
Step 7: Review resource usage and application behavior
EDGE analytics can identify where to investigate, but application-level issues may require WordPress, database, or origin review.
Check:
- PHP errors
- Slow database queries
- Plugin logs
- WooCommerce or LMS background jobs
- Scheduled tasks
- Long-running imports or exports
- Form spam
- Search traffic
- Admin AJAX activity
- REST API activity
- Cron behavior
- External API delays
If you do not have access to resource-level data, collect the affected paths and timestamps before contacting Support.
Step 8: Run page-level audits
Run audits for the pages most affected by the degradation.
Check:
- Homepage
- High-traffic landing pages
- Product pages
- Checkout or conversion pages
- LMS or membership pages
- Important forms
- Recently changed pages
Compare:
- TTFB
- LCP
- FCP
- TBT
- CLS
- Page weight
- Number of requests
- Desktop vs mobile results
See Site Audit Screen for running and comparing page-level audits.
Solutions
Optimize for traffic growth
- Review traffic patterns: Use Traffic Analytics to identify spikes, top URLs, top IPs, top countries, and referrers.
- Separate legitimate and suspicious traffic: Do not block traffic based only on volume. Review URLs, user behavior, and security context first.
- Optimize high-traffic pages: Prioritize pages with high request volume and high response time.
- Improve cache coverage: Make sure public, anonymous pages are cacheable where safe.
- Reduce dynamic load: Review uncached dynamic paths and optimize the ones with the highest impact.
- Review plan or resource fit: If legitimate traffic has grown significantly, discuss scaling options with Pressidium.
Improve cache behavior
- Review Cache Analytics.
- Identify high-traffic misses and bypasses.
- Check cache exclusions.
- Review cookies, query strings, redirects, and dynamic paths.
- Check whether plugins are setting no-cache headers.
- Purge only affected URLs where needed.
- Retest as a logged-out visitor.
- Compare cache hit rate after changes.
See Cache Not Working for detailed cache troubleshooting.
Reduce slow origin responses
- Use Performance Analytics to find high-impact slow paths.
- Identify whether affected paths are public pages, dynamic endpoints, or admin/API requests.
- Review plugins, theme code, custom queries, and external services used by those paths.
- Reduce unnecessary plugins or plugin features.
- Optimize database-heavy pages.
- Cache safe public content.
- Avoid caching private, user-specific, cart, checkout, account, or logged-in content.
- Contact Support if server response time remains consistently high.
Clean up accumulated resources
- Review active plugins and remove unused ones.
- Remove unused themes.
- Review large media files and unused uploads.
- Clean expired transients and temporary data using safe WordPress tools.
- Review logs, imports, exports, and temporary files.
- Review scheduled tasks and background jobs.
- Take a backup before database cleanup.
- Avoid direct database cleanup unless performed by a qualified developer or Support.
Fix configuration drift
- Identify the last known good configuration.
- List changes made since then.
- Prioritize changes that affect cache, redirects, origin routing, plugins, themes, scripts, or security.
- Revert one suspected change at a time where safe.
- Test after each change.
- Keep notes on what changed and what improved.
- Restore the intended configuration once the cause is confirmed.
Address external factors
- Identify third-party services loaded on affected pages.
- Review browser waterfall timing.
- Remove unused third-party scripts.
- Defer or delay non-critical scripts where safe.
- Load scripts only where needed.
- Cache external API responses where appropriate.
- Add sensible timeouts and fallbacks for external API calls.
- Contact the third-party provider if their service is slow or unreliable.
Improve frontend performance
- Run a Site Audit for affected pages.
- Review TTFB, LCP, FCP, TBT, CLS, page weight, and requests.
- Optimize large images.
- Review render-blocking CSS and JavaScript.
- Remove unused scripts and styles.
- Review font loading.
- Review layout shifts caused by images, embeds, ads, or dynamic content.
- Test mobile and desktop separately.
- Rerun the audit after changes.
Performance monitoring
Regular monitoring
Review performance regularly, especially after site changes.
Use:
- Performance Analytics: Review request volume, response timing, high-impact paths, and server response time.
- Cache Analytics: Review cache hit rate, cacheable hit rate, hits, misses, bypasses, and top URLs.
- Traffic Analytics: Review traffic spikes, top URLs, countries, IPs, referrers, and response patterns.
- Site Audits: Review page-level metrics and compare audits over time.
- Browser testing: Check key pages from a real browser, including mobile and desktop.
Review performance after:
- Plugin updates
- Theme updates
- WordPress updates
- Deployments
- Cache rule changes
- DNS changes
- Campaign launches
- Traffic spikes
- Major content changes
- New third-party scripts
Establish performance baselines
Create a baseline before making major changes.
Track:
- Average server response time
- Average total request time
- Request volume
- Cache hit rate
- Cacheable hit rate
- Top high-impact paths
- Error rate
- Top requested URLs
- TTFB
- LCP
- FCP
- TBT
- CLS
- Page weight
- Number of requests
Use the same page, device type, time range, and test conditions when comparing before-and-after results.
Prevention
Best practices
- Monitor performance continuously.
- Review analytics after major changes.
- Keep a record of plugin, theme, cache, DNS, origin, and firewall changes.
- Test important pages after deployments.
- Keep cache exclusions narrow and intentional.
- Do not cache private or user-specific pages.
- Review traffic spikes after campaigns.
- Audit more than the homepage.
- Optimize high-impact pages first.
- Review third-party scripts regularly.
- Keep WordPress plugins and themes lean.
- Take backups before major cleanup or database work.
Regular maintenance
- Review active plugins and remove unused ones.
- Review slow or high-impact paths regularly.
- Review cache exclusions and bypasses.
- Purge cache intentionally, not repeatedly.
- Review large images and media-heavy pages.
- Check for broken URLs and unnecessary redirects.
- Review scheduled tasks and background jobs.
- Clean temporary data using safe WordPress tools.
- Review traffic and cache analytics after campaigns.
- Re-run audits for key pages after major changes.
Troubleshooting checklist
- [ ] Defined when the degradation started
- [ ] Compared current performance with a previous equivalent period
- [ ] Reviewed Performance Analytics
- [ ] Reviewed Cache Analytics
- [ ] Reviewed Traffic Analytics
- [ ] Checked cache hit rate and cacheable hit rate
- [ ] Checked for increased cache misses or bypasses
- [ ] Identified high-impact paths
- [ ] Reviewed top URLs and traffic spikes
- [ ] Checked for increased errors, redirects, or
404responses - [ ] Reviewed recent plugin, theme, WordPress, cache, DNS, firewall, origin, or deployment changes
- [ ] Reviewed third-party scripts and external services
- [ ] Checked whether affected pages are cacheable
- [ ] Reviewed dynamic WordPress paths such as checkout, account, LMS, membership, AJAX, REST API, or search
- [ ] Ran Site Audits for affected pages
- [ ] Compared mobile and desktop results
- [ ] Tested improvements after each change
- [ ] Collected screenshots, exports, timestamps, and affected paths for Support
When to contact Support
Contact Pressidium Support when:
- Performance degradation persists after troubleshooting
- Server response time remains consistently high
- A path shows an unexpected increase in traffic or response time
- Cache hit rate dropped and you cannot identify why
- A high-impact path appears to be slow without a clear cause
- Performance issues affect production users
- You see unusual traffic spikes, error spikes, or suspicious request patterns
- You need help interpreting exported analytics data
- You need advanced diagnostics
When contacting Support, include:
- Site name
- Affected domain
- Affected environment
- When the degradation started
- Whether the issue is constant or intermittent
- Affected URLs or paths
- Selected reporting time range
- Relevant hours or timestamps with timezone
- Performance Analytics screenshots or exports
- Cache Analytics screenshots or exports
- Traffic Analytics screenshots or exports
- Site Audit results, if available
- Recent plugin, theme, WordPress, DNS, cache, firewall, origin, or deployment changes
- Any third-party services involved
- Steps already taken
Where to go next
- Review The Performance Analytics screen to investigate request volume, response timing, and high-impact paths.
- Review Cache Analytics screen to inspect cache hit rate, cacheable hit rate, hits, misses, bypasses, and top URLs.
- Review Traffic Analytics screen to investigate traffic spikes, top URLs, countries, IPs, referrers, and response patterns.
- Review Site Audit Screen to run page-level audits and compare key performance metrics.
- Review Site Loading Slowly if the site is slow and the cause is not yet clear.
- Review Cache Not Working if cache hit rate dropped or requests are bypassing cache unexpectedly.
- Review Images Not Loading if images are slow, stale, broken, or affected by optimization settings.
- Open a Support Request if performance degradation continues after completing the checks in this guide.
Was this article helpful?