Pre-launch foundation (7-14 days before)

Overview

This phase establishes the technical foundation for handling traffic spikes during your WooCommerce event. Working through these optimizations 7-14 days before launch gives you time to test changes, identify bottlenecks, and document baseline metrics. The goal is to maximize cache efficiency, minimize database overhead, and ensure all systems are properly configured before your high-traffic event.

Prerequisites

• Access requirements: WP-CLI access via SSH, WordPress admin credentials, DNS control panel access, staging environment access
• Time investment: 4-8 hours spread across several days (allow for testing between changes)
• Technical level: Mix of tasks; some require developer skills while others can be completed through WordPress admin

Success criteria

Phase 1 is complete when you have:

• Performance targets met:
  • Total autoloaded data under 1MB (ideally under 500KB)
  • Database queries under 50 per uncached page
  • Cache hit ratio above 90% on key pages
  • TTFB under 400ms for cached pages, under 700ms for uncached
• Completion indicators:
  • All critical optimizations tested on staging
  • Baseline metrics documented
  • Load testing completed with known capacity limits
  • Monitoring and alerting configured
• Documentation requirements:
  • Performance baselines recorded
  • Plugin disable/enable list created
  • Rollback procedures tested and documented
  • Emergency contacts confirmed

Phase 1 tasks

Each task includes key information to help with delegation, timelines, understanding the purpose of the task, and prioritization. We recommend you review this entire guide before planning your Phase 1.

1. Backend and database optimization

Clean up autoloaded data

[Developer] [30-60 min] [Improves every request, including cached pages] [Critical]

Why this matters: WordPress loads all autoloaded options into memory on every request, even for cached pages. Large autoloaded data (over 1MB) creates unnecessary overhead that can slow your site significantly during traffic spikes.

Implementation:

UI method:

1. Install WP Optimize plugin from WordPress Admin > Plugins > Add New
2. Navigate to Tools > WP Optimize > Database
3. Click on “Tables” tab and look for wp_options table information
4. Review autoload analysis section showing total size
5. Identify options over 100KB that can be cleaned
6. Take a database backup
7. Use a tool like Autoload Optimizer or manually edit the wp_options table in phpMyAdmin to adjust the identified autoload options

WP-CLI alternative:

# Check total autoload size

wp option list --autoload=on --format=total_bytes

# List largest autoloaded options

wp db query "

SELECT option_name, LENGTH(option_value) AS size_bytes

FROM $(wp db prefix)options

WHERE autoload = 'yes'

ORDER BY size_bytes DESC

LIMIT 20;

"

See our full guide to cleaning up autoloaded data here.

Success indicator: Total autoloaded data reduced below 1MB, verified through WP-CLI or plugin dashboard showing specific size reduction.

Remove unnecessary post revisions

[Developer] [5-10 min] [Reduces database size and query time] [Recommended]

Why this matters: Post revisions can contribute to bloated database size, slowing queries during high-traffic periods when every millisecond counts.

Implementation:

UI method:

1. Go to WordPress Admin > Plugins > Add New
2. Install and activate WP Optimize or Advanced Database Cleaner
3. Navigate to the database cleanup section
4. Select “Post Revisions” with “Keep revisions from last 30 days” option
5. Run the cleanup and note the space saved

WP-CLI alternative:

# Delete postmeta for old revisions to avoid leaving orphaned data

wp db query "

DELETE pm

FROM $(wp db prefix)postmeta pm

JOIN $(wp db prefix)posts p ON pm.post_id = p.ID

WHERE p.post_type = 'revision'

  AND p.post_date_gmt < DATE_SUB(UTC_TIMESTAMP(), INTERVAL 30 DAY);

"

# Then delete the revisions

wp db query "

DELETE FROM $(wp db prefix)posts

WHERE post_type = 'revision'

  AND post_date_gmt < DATE_SUB(UTC_TIMESTAMP(), INTERVAL 30 DAY);

"

Success indicator: Database size reduced, old revisions removed while preserving recent ones (verify through phpMyAdmin or database plugin).

Monitor slow queries

[Developer] [30-60 min] [Identifies database bottlenecks] [Critical]

Why this matters: Slow database queries compound under load; a query taking 100ms during normal traffic might take 500ms or timeout entirely during traffic spikes.

Implementation:

UI method:

1. Install Query Monitor plugin from WordPress Admin > Plugins
2. Activate and visit your key pages: homepage, shop, product, cart, checkout
3. Click the Query Monitor item in the admin bar
4. Navigate to “Queries by Component” to identify slow plugins
5. Look for queries over 100ms or duplicate queries

Success indicator: All critical pages profiled with slow queries documented, no single query exceeding 100ms on key pages.

2. WooCommerce-specific optimizations

Verify HPOS compatibility

[Store Owner] [10-15 min] [Prevents order processing failures] [Critical]

Why this matters: High-Performance Order Storage (HPOS) significantly improves order processing speed during high traffic, but incompatible extensions can cause order failures or data loss.

Implementation:

UI method:

1. Navigate to WooCommerce > Settings > Advanced > Features
2. Check if “High-Performance Order Storage” is enabled
3. If not enabled, click “Check compatibility” to scan your extensions
4. Review the compatibility report for any critical payment or shipping plugins
5. For incompatible plugins, check for updates or contact the developer
6. Enable HPOS if all critical extensions are compatible

Success indicator: HPOS enabled with all payment gateways and critical extensions showing as compatible in the status report.

Disable cart fragments on non-essential pages

[Developer] [30-60 min] [Reduces PHP load by up to 30-50%] [Critical]

Why this matters: Cart fragments create uncached AJAX requests on every page load, consuming PHP workers that should be serving customers. This single optimization can reduce server load by up to 30-50% during traffic spikes.

Implementation:

UI method:

1. Install Code Snippets plugin from WordPress Admin > Plugins
2. Go to Snippets > Add New
3. Add the code snippet below
4. Set to run on frontend only and activate

// Disable Woo cart fragments when it's safe to do so

function disable_wc_cart_fragments_safely() {

    if ( is_admin() || wp_doing_ajax() || is_customize_preview() ) {

        return;

    }

    // If a mini-cart is present, keep fragments to avoid breaking it.

    $mini_cart_widget_active = is_active_widget( false, false, 'woocommerce_widget_cart', true ); // Classic widget

    $mini_cart_block_present = function_exists( 'has_block' ) && has_block( 'woocommerce/mini-cart' ); // Block theme

    if ( $mini_cart_widget_active || $mini_cart_block_present ) {

        return;

    }

    // Keep fragments on key commerce screens, or when there are items in cart.

    $cart_maybe_has_items = ! empty( $_COOKIE['woocommerce_items_in_cart'] ); // Cheap check

    if ( is_cart() || is_checkout() || $cart_maybe_has_items ) {

        return;

    }

    // Dequeue/deregister late to beat most themes; still before print.

    if ( wp_script_is( 'wc-cart-fragments', 'enqueued' ) ) {

        wp_dequeue_script( 'wc-cart-fragments' );

        wp_deregister_script( 'wc-cart-fragments' );

    }

}

add_action( 'wp_enqueue_scripts', 'disable_wc_cart_fragments_safely', 200 );

Success indicator: Browser DevTools Network tab shows no admin-ajax.php?action=woocommerce_get_refreshed_fragments requests on homepage, category, or product pages.

Test payment gateway webhooks

[Store Owner] [30-60 min] [Prevents lost sales from payment failures] [Critical]

Why this matters: Payment webhook failures during high traffic directly translate to lost revenue and require manual order reconciliation.

Implementation:

UI method:

1. Go to WooCommerce > Settings > Payments
2. For each active gateway, enter settings and enable test/sandbox mode
3. Note webhook URLs for each gateway (usually in advanced settings)
4. Place test orders using each payment method
5. Verify order status updates correctly after payment
6. Check WooCommerce > Status > Logs for any webhook errors

Success indicator: All payment methods process test transactions successfully with webhooks confirmed working, no errors in payment logs.

3. Caching and coverage

Verify cache coverage on key pages

[Anyone] [5-10 min] [Ensures maximum traffic serves from Edge Cache] [Critical]

Why this matters: Cached pages serve instantly from Pressable’s Edge Cache without touching PHP workers. A properly cached homepage can handle virtually unlimited traffic.

Implementation:

UI method:

1. Open Browser Developer Tools (F12), go to Network tab
2. Visit homepage, refresh once, then check first request’s Response Headers
3. Look for x-ac: HIT (if you see MISS, refresh again)
4. Repeat for: main shop page, top 3 category pages, top 5 product pages
5. Document which pages show consistent HIT vs MISS

WP-CLI alternative:

# Check cache status for key pages

curl -I https://yoursite.com/ | grep x-ac

curl -I https://yoursite.com/shop/ | grep x-ac

curl -I https://yoursite.com/product/bestseller/ | grep x-ac

Success indicator: All key pages show x-ac: HIT header after second visit, documented list of cached vs uncached pages.

Pre-warm cache after changes

[Anyone] [10-15 min] [Prevents slow first visits] [Recommended]

Why this matters: After cache purges, your first visitors experience slow page loads while cache rebuilds, potentially losing customers during critical event moments.

Implementation:

UI method:

1. Create a bookmarks folder called “Cache Pre-warm”
2. Add bookmarks for: homepage, main shop, all category pages, top 20 products
3. After any cache purge, right-click folder –> “Open All Bookmarks”
4. Let all tabs load completely before closing
5. Verify cache hits using Developer Tools on a few pages

Success indicator: All critical pages visited and showing x-ac: HIT in headers when checked.

Pressable platform note: Pressable provides Edge Cache at the CDN level and platform-managed cache files. Third-party caching plugins cannot control platform cache and often conflict with our built-in systems. Caching plugins should be disabled during high-traffic events.

4. Infrastructure and risk controls

Audit and disable non-essential plugins

[Store Owner] [30-60 min] [Reduces PHP load] [Critical]

Why this matters: Each active plugin consumes resources on every request; disabling non-essential plugins can free up more capacity for serving customers.

Implementation:

UI method:

1. Go to WordPress Admin > Plugins > Installed Plugins
2. Take a screenshot or export list of currently active plugins
3. Identify plugins safe to disable during your event:
   • Backup plugins (backup manually before event)
   • Social media auto-posters
   • Marketing automation (temporarily)
   • Development/debugging tools
   • SEO plugins (if not affecting structure)
4. Deactivate identified plugins
5. Test complete purchase flow after deactivation

Success indicator: Non-essential plugins disabled, complete test order successful, documented list of disabled plugins for post-event reactivation.

Configure uptime monitoring

[Anyone] [10-15 min] [Provides external alerts before customers complain] [Critical]

Why this matters: External monitoring alerts you to issues immediately, often before customers notice problems, allowing rapid response.

Implementation:

UI method:

1. Sign up for UptimeRobot (free) or enable Jetpack Monitor
2. Add monitors for:
   • Homepage (check every 5 minutes)
   • Shop page (check every 5 minutes)
   • A bestselling product page
   • Checkout page (keyword monitoring, not transaction)
3. Configure alerts: email + SMS for downtime over 5 minutes
4. Add team members to alerts
5. Test alerts by temporarily blocking your monitoring tool’s IP in Pressable

Success indicator: Test alerts received by team, monitoring dashboard shows all green, response times baseline documented.

Load test on staging environment

[Developer] [2-4 hrs] [Identifies breaking points] [Critical]

Why this matters: Load testing reveals your actual capacity limits and bottlenecks before customers experience them, preventing event-day surprises.

Implementation:

NOTE: Because some load testing tools use a small range of IP addresses, our firewall may identify the test as a DDoS attack or other malicious traffic pattern. You may need to contact Pressable support to arrange for a time window during which standard rate-limiting can be loosened on your staging site. Normal visitors come from a wider range of IP addresses and should not trigger similar limiting.

UI method using Loader.io:

1. Sign up at loader.io and verify your staging domain
2. Create test: “Maintain load” test type
3. Configure: 50 users/minute for 5 minutes, then increase gradually
4. Target URLs: homepage, category page, product page
5. Run test and note when response times exceed 2 seconds
6. Document maximum sustainable traffic level

Advanced alternative using k6:

// Save as loadtest.js and run with: k6 run loadtest.js

import http from 'k6/http';

import { check, sleep } from 'k6';

export let options = {

  stages: [

    { duration: '2m', target: 50 },  // Ramp up

    { duration: '5m', target: 50 },  // Stay at 50 users

    { duration: '2m', target: 100 }, // Spike test

    { duration: '2m', target: 0 },   // Ramp down

  ],

};

export default function() {

  let res = http.get('https://your-staging-site.com/');

  check(res, {

    'status is 200': (r) => r.status === 200,

    'response time < 2000ms': (r) => r.timings.duration < 2000,

  });

  sleep(1);

}

Success indicator: Maximum concurrent users identified, breaking point documented, response time thresholds established for monitoring.

PHP worker limits: Pressable sites have fixed PHP worker limits (5 workers on Signature plans, 10 on Premium plans) with burst capacity up to 110 workers. Each worker has 512MB RAM on a dedicated core. Optimizing for cache hits and reducing uncached requests is crucial for managing worker load.

5. Critical platform configurations

Test email deliverability

[Developer] [30-60 min] [Ensures order confirmations reach customers] [Critical]

Why this matters: Failed order confirmation emails lead to support tickets and chargebacks. Pressable limits sites using the default transactional mailer to 200 emails/hour, which can be exceeded during flash sales.

Implementation:

UI method:

1. Install an SMTP plugin (WP Mail SMTP, Post SMTP, or FluentSMTP)
2. Configure with your email service
3. Set up SPF record in DNS (ex. v=spf1 include:[your-smtp-provider] ~all)
4. Add DKIM records provided by your SMTP service
5. Test configuration: WooCommerce > Settings > Emails > Send test email
6. Set up email logging to monitor delivery rates

Success indicator: Test emails delivered successfully, SPF/DKIM records verified via mail-tester.com, SMTP provider dashboard shows successful authentication.

See our guide on email deliverability troubleshooting and SMTP plugins here.

Note: Pressable’s 200 emails/hour limit requires SMTP configuration for high-volume events. See our SMTP setup guide for detailed instructions.

Configure webhook rate limiting

[Developer] [15-30 min] [Prevents webhook overload] [Recommended]

Why this matters: Payment gateways can flood your site with webhook requests during high-traffic periods, consuming PHP workers needed for customers.

Implementation:

UI method:

1. Check each payment gateway’s webhook settings:
   • PayPal: Set IPN retry interval to maximum
   • Stripe: Configure webhook endpoint rate limiting
   • Square: Review webhook delivery settings
2. Document webhook URLs and rate limits for each provider
3. Bookmark payment provider status pages:
   • status.stripe.com
   • www.paypal-status.com
   • status.squareup.com
4. Consider implementing webhook queue plugin if available

Success indicator: Webhook rate limits documented, provider status pages bookmarked, webhook URLs added to monitoring.

Coordinate third-party CDN settings

[Developer] [15-30 min] [Prevents cache conflicts] [Advanced]

Why this matters: If using Cloudflare or another CDN in front of Pressable, misconfigurations can cause cache conflicts or bypass Pressable’s optimizations.

Implementation:

For Cloudflare users:

1. Create Page Rules to exclude dynamic paths:
   • *yoursite.com/cart/* – Cache Level: Bypass
   • *yoursite.com/checkout/* – Cache Level: Bypass
   • *yoursite.com/my-account/* – Cache Level: Bypass
2. Set browser cache TTL to respect existing headers
3. Disable Rocket Loader for WooCommerce pages
4. Configure cache purge coordination with Pressable
5. Document cache purge procedure for both layers

Success indicator: CDN rules configured to respect Pressable caching, no double-caching of dynamic content, unified purge procedure documented.

Verify staging environment hygiene

[Anyone] [5-10 min] [Prevents analytics pollution] [Recommended]

Why this matters: Staging site indexing can pollute analytics data and create duplicate content issues during critical validation testing.

Implementation:

UI method:

1. On staging site, go to Settings > Reading
2. Ensure “Search engine visibility” is checked (discourage search engines)
3. Install “Bulk Noindex & NoFollow Toolkit” plugin if additional protection needed
4. Verify Google Analytics/Tag Manager is disabled or using test property
5. Check that email sending is restricted to test addresses

Success indicator: Staging site returns “noindex” meta tag, analytics shows no staging traffic, test emails confined to safe addresses.

Establish mobile performance baseline

[Store Owner] [30-60 min] [Critical for conversion rates] [Critical]

Why this matters: Mobile users often account for 60-70% of flash sale traffic, and mobile conversion rates drop significantly with slow performance.

Implementation:

UI method:

1. Use Google PageSpeed Insights mobile tab for baseline scores:
   • Homepage
   • Product page
   • Cart page
   • Checkout page
2. Test critical paths on actual mobile devices:
   • Product search and filtering
   • Add to cart interaction
   • Checkout form completion
   • Payment method selection
3. Document specific issues found:
   • Buttons too small or close together
   • Forms difficult to complete
   • Images not optimized for mobile
   • Text too small to read
4. Use Chrome DevTools Device Mode to test checkout on various screen sizes

Success indicator: Mobile PageSpeed scores documented (aim for 50+ on key pages), checkout flow tested on 3+ device sizes, accessibility issues identified and logged.

Reduce DNS TTL values

[Anyone] [5-10 min] [Enables quick DNS changes if needed] [Recommended]

Why this matters: Low TTL values allow rapid DNS changes for traffic redirection or failover during emergencies, critical for disaster recovery.

Implementation:

UI method:

1. Log into your DNS provider (Cloudflare, GoDaddy, etc.)
2. Find DNS settings for your domain
3. Locate TTL field for A record and CNAME records
4. Change from 3600 (1 hour) to 300 (5 minutes)
5. Save and document the change for reversal post-event

Success indicator: DNS TTL values set to 300 seconds, propagation verified via whatsmydns.net.

Create fresh backup

[Anyone] [5-10 min] [Provides rollback safety] [Critical]

Why this matters: A fresh backup immediately before implementing optimizations ensures you can quickly restore if any changes cause issues.

Implementation:

UI method:

1. Log into Pressable Control Panel
2. Navigate to your site > Manage Data
3. Click “Create Backup” for on-demand backup
4. Document backup location and restoration time (typically 5-10 minutes)
5. Test restoration procedure on staging if not previously done

See our guide to manual backups here.

WP-CLI alternative:

wp db export backup-phase1-$(date +%Y%m%d-%H%M%S).sql

Success indicator: Backup created and location documented, restoration procedure tested with time estimate recorded.

Phase 1 outputs

Before proceeding to Phase 2, document these critical metrics and procedures:

Performance baselines to record

• Total autoloaded data size: _____ KB
• Homepage TTFB (cached): _____ ms
• Cart page TTFB (uncached): _____ ms
• Checkout page TTFB (uncached): _____ ms
• Database total size: _____ MB
• Largest database tables: _____
• Average queries per page (homepage/product/cart/checkout): _____
• Cache hit ratio for key pages: _____%
• Mobile PageSpeed scores (homepage/product/checkout): _____

Load testing results to document

• Maximum concurrent users before degradation: _____
• Response time at 50% capacity: _____ ms
• Response time at 80% capacity: _____ ms
• Breaking point (errors occur): _____ concurrent users
• Bottlenecks identified: _____
• PHP worker pressure indicators noted: _____

Operational procedures to prepare

• Plugin disable list with reactivation order
• Rollback checklist with specific commands
• Emergency contacts with availability windows
• Cache purge procedures for each layer (Pressable, CDN if applicable)
• Webhook URLs and rate limits for each payment provider
• Monitoring dashboard links and login credentials

Success criteria checklist

• Autoload under 1MB
• HPOS enabled and compatible
• Cart fragments disabled on non-essential pages
• All payment gateways tested
• Cache coverage verified (>90% hit rate)
• Email deliverability configured
• Monitoring active and tested
• Load testing completed
• Mobile performance baselined
• DNS TTL reduced
• Fresh backups created

Next steps

With Phase 1 complete, you have:

1. Optimized foundation: Database cleaned, autoload minimized, queries optimized
2. WooCommerce tuning: Cart fragments controlled, HPOS enabled, payments tested
3. Cache strategy: Coverage verified, pre-warming documented, platform configured
4. Risk controls: Monitoring active, backups fresh, rollback procedures ready
5. Capacity knowledge: Load limits identified, bottlenecks documented, baselines recorded

Proceed to Phase 2 (1-2 days before) for final validation and testing, ensuring all optimizations are working correctly in production.