Skip to content
  • Quick Ref
  • Contact
  • About
wpcanyon.com

wpcanyon.com

Category: Speed & Security

Reduce TTFB on cheap hosting (object cache & OPcache)

Posted on August 19, 2025 By Admin No Comments on Reduce TTFB on cheap hosting (object cache & OPcache)

Reduce TTFB on Cheap Hosting (Object Cache & OPcache)

Time To First Byte (TTFB) is a critical performance metric for WordPress sites. On cheap hosting, slow TTFB can frustrate visitors and harm SEO. The good news: you can significantly reduce TTFB by enabling OPcache and object caching, cleaning up your database, and using a CDN. This guide walks you through practical steps to speed up your WordPress site without expensive hosting upgrades.

Quick Fix

  1. Enable PHP OPcache on your server.
  2. Activate an object caching plugin like Redis or Memcached.
  3. Clean up your WordPress database to remove overhead.
  4. Integrate a CDN to serve static assets closer to users.

Why This Happens

Cheap hosting often uses shared resources and limited server configurations, resulting in slower PHP execution and database queries. Without caching, every page load triggers PHP scripts and database calls from scratch, increasing TTFB. OPcache stores precompiled PHP bytecode in memory, reducing script load times. Object caching stores database query results in memory, cutting down repeated queries. Cleaning the database removes bloat that slows queries. A CDN reduces latency by serving assets from edge servers near visitors.

Step-by-step

1. Enable OPcache

OPcache is a PHP extension that caches compiled script bytecode. Many cheap hosts support it but may not enable it by default.

  1. Check if OPcache is enabled by creating a phpinfo.php file in your WordPress root with this content:
    <?php
    phpinfo();
    ?>
  2. Access yourdomain.com/phpinfo.php and search for “OPcache”. If enabled, you’ll see its configuration.
  3. If not enabled, enable it via your hosting control panel or by adding this to your php.ini or .user.ini file:
    opcache.enable=1
    opcache.memory_consumption=128
    opcache.interned_strings_buffer=8
    opcache.max_accelerated_files=4000
    opcache.revalidate_freq=60
    opcache.fast_shutdown=1
  4. Restart PHP or your web server if possible.

2. Enable Object Cache

Object caching stores database query results in memory, reducing repeated queries and lowering TTFB.

  1. Check if your host supports Redis or Memcached. You can ask support or check documentation.
  2. Install a WordPress plugin for object caching, for example:
    • Redis: Redis Object Cache plugin
    • Memcached: Memcached Redux or W3 Total Cache
  3. Configure the plugin to connect to your Redis or Memcached server. Usually, this is 127.0.0.1 and default ports.
  4. Verify caching is active via the plugin’s status page.

3. Clean Up Your Database

A bloated database slows queries, increasing TTFB. Cleaning removes overhead, spam, revisions, and transient options.

  1. Backup your database before making changes.
  2. Install a plugin like WP-Optimize or Advanced Database Cleaner.
  3. Run database optimization:
    • Remove post revisions
    • Delete spam and trashed comments
    • Clear expired transients
    • Optimize database tables
  4. Schedule regular cleanups to maintain performance.

4. Use a CDN

A Content Delivery Network (CDN) reduces latency by serving static files (images, CSS, JS) from servers closer to visitors.

  1. Choose a CDN provider (Cloudflare, BunnyCDN, StackPath, etc.).
  2. Create an account and configure your domain.
  3. Change your DNS nameservers to point to the CDN (if using Cloudflare) or configure your CDN to pull from your origin server.
  4. Install a plugin like Cloudflare or CDN Enabler to integrate the CDN with WordPress.
  5. Verify static assets load from the CDN URL.

Works on

Environment Notes
Apache Supports OPcache and object cache; .htaccess may be used for CDN rewrites.
Nginx Fully compatible with OPcache and object cache; CDN integration via proxy or DNS.
LiteSpeed Supports OPcache and object cache; LiteSpeed Cache plugin can help.
cPanel Enable OPcache via MultiPHP INI Editor; Redis/Memcached often available.
Plesk Enable OPcache via PHP settings; Redis/Memcached extensions can be installed.

FAQ

Q: How do I know if OPcache is working?
A: Use a phpinfo() page or a plugin like Query Monitor to check if OPcache is enabled and caching scripts.
Q: Can I enable object caching without Redis or Memcached?
A: Yes, but it’s less efficient. Some plugins offer file-based caching, but memory-based caches like Redis/Memcached are faster.
Q: Will enabling OPcache and object cache fix all performance issues?
A: They significantly reduce TTFB but don’t replace good hosting or optimized themes/plugins. Combine with database cleanup and CDN for best results.
Q: Is it safe to clean my database with plugins?
A: Yes, if you backup first. Use reputable plugins and avoid deleting data you might need.
Q: Does using a CDN increase my hosting costs?
A: Most CDNs have free tiers or low-cost plans. They
…
Speed & Security

Block bad bots in .htaccess (copy/paste)

Posted on August 19, 2025 By Admin No Comments on Block bad bots in .htaccess (copy/paste)

Block Bad Bots in .htaccess (Copy/Paste)

If your WordPress site is suffering from unwanted traffic caused by bad bots—such as scrapers, spammers, or malicious crawlers—you can block them efficiently using your .htaccess file. This quick fix not only denies access to known bad bots but also rate limits requests to reduce server load and improve site security.

Quick Fix: Deny Bad Bots & Rate Limit in .htaccess

  1. Open your WordPress root directory and locate the .htaccess file.
  2. Backup the .htaccess file before making changes.
  3. Copy and paste the following code at the top of your .htaccess file:
# Block Bad Bots by User-Agent
SetEnvIfNoCase User-Agent "AhrefsBot" bad_bot
SetEnvIfNoCase User-Agent "SemrushBot" bad_bot
SetEnvIfNoCase User-Agent "MJ12bot" bad_bot
SetEnvIfNoCase User-Agent "DotBot" bad_bot
SetEnvIfNoCase User-Agent "BLEXBot" bad_bot
SetEnvIfNoCase User-Agent "YandexBot" bad_bot

Order Allow,Deny
Allow from all
Deny from env=bad_bot

# Rate limiting: Limit excessive requests per IP

  SetEnvIf Remote_Addr "^.*$" RATE_LIMIT
  
    SetOutputFilter RATE_LIMIT
    SetEnv rate-limit 400
  


# Alternative rate limiting using mod_reqtimeout (Apache 2.2.15+)

  RequestReadTimeout header=20-40,minrate=500

  1. Save the file and upload it back to your server if editing locally.
  2. Test your site to ensure it loads correctly and bad bots are blocked.

Why This Happens

Bad bots can cause multiple issues for WordPress sites:

  • Server overload: Excessive requests from bots can consume bandwidth and CPU, slowing down your site.
  • Security risks: Some bots scan for vulnerabilities or attempt brute force attacks.
  • SEO damage: Scrapers can steal your content, harming your search engine rankings.

Blocking bad bots at the .htaccess level prevents them from reaching your WordPress application, reducing resource usage and improving overall site performance and security.

Step-by-Step: How to Block Bad Bots in .htaccess

  1. Access your WordPress root directory: Use FTP, SFTP, or your hosting control panel’s file manager to navigate to the folder where WordPress is installed. This folder contains the wp-config.php and .htaccess files.
  2. Backup your current .htaccess file: Before making any changes, download a copy of your existing .htaccess file to your local machine. This ensures you can restore it if something goes wrong.
  3. Edit the .htaccess file: Open the .htaccess file in a plain text editor.
  4. Add bad bot blocking rules: Insert the following code at the very top of the file, before any WordPress rules:
# Block Bad Bots by User-Agent
SetEnvIfNoCase User-Agent "AhrefsBot" bad_bot
SetEnvIfNoCase User-Agent "SemrushBot" bad_bot
SetEnvIfNoCase User-Agent "MJ12bot" bad_bot
SetEnvIfNoCase User-Agent "DotBot" bad_bot
SetEnvIfNoCase User-Agent "BLEXBot" bad_bot
SetEnvIfNoCase User-Agent "YandexBot" bad_bot

Order Allow,Deny
Allow from all
Deny from env=bad_bot

This code uses SetEnvIfNoCase to detect bad bots by their user-agent strings and denies them access.

  1. Add rate limiting rules: To prevent excessive requests from any IP address, add the following code below the bot blocking rules:
# Rate limiting: Limit excessive requests per IP

  SetEnvIf Remote_Addr "^.*$" RATE_LIMIT
  
    SetOutputFilter RATE_LIMIT
    SetEnv rate-limit 400
  


# Alternative rate limiting using mod_reqtimeout (Apache 2.2.15+)

  RequestReadTimeout header=20-40,minrate=500

This limits the bandwidth and request rate to protect your server from overload.

  1. Save and upload the file: If editing locally, upload the modified .htaccess file back to your server, overwriting the existing one.
  2. Test your website: Visit your site in a browser to ensure it loads normally. Use online tools or command line to simulate bad bot user-agents and confirm they are blocked.

Testing Your Bad Bot Blocking

  • Browser test: Your site should load normally for regular browsers.
  • Command line test: Use curl to simulate a bad bot user-agent:
curl -A "AhrefsBot" -I https://yourdomain.com/

The response should be 403 Forbidden or similar, indicating the bot is blocked.

  • Check server logs: Review your Apache error or access logs to verify that requests from bad bots are denied.

Works On

Server Software Notes
Apache Fully supported; requires mod_setenvif, mod_authz_host, and optionally mod_ratelimit or mod_reqtimeout
Nginx Does not use .htaccess; configure in server block instead
LiteSpeed Supports .htaccess rules similar to Apache
cPanel / Ples
…
Speed & Security

Serve WebP in WordPress without breaking Safari

Posted on August 19, 2025 By Admin No Comments on Serve WebP in WordPress without breaking Safari

Serve WebP in WordPress without breaking Safari

Serving WebP images in WordPress improves site speed and reduces bandwidth, but Safari’s limited WebP support can cause images to break or not display properly. The quick fix is to serve WebP images only when the browser supports them, using Accept headers and fallback images for Safari and other incompatible browsers.

Quick Fix: Serve WebP with Accept Headers and Fallbacks

  1. Detect if the browser supports WebP using the Accept HTTP header.
  2. Serve WebP images only if supported.
  3. Provide fallback JPEG/PNG images for browsers like Safari that don’t fully support WebP.
  4. Use server-level rules (Apache .htaccess or Nginx config) to automate this detection and fallback.
  5. Alternatively, use a WordPress plugin that handles WebP fallback automatically.

Why This Happens

WebP is a modern image format that offers superior compression. Most browsers support it, but Safari added partial WebP support only in recent versions, and some features like transparency or animation may still cause issues. When a WebP image is served directly to Safari without fallback, the image may not render, resulting in broken images on your site.

WordPress by default does not serve WebP images or handle browser compatibility. Without proper server-side detection and fallback, Safari users will see broken images if only WebP versions are served.

Step-by-step: Serve WebP with Fallbacks Using Server Configuration

1. Apache (.htaccess) Configuration

Add the following rules to your WordPress root .htaccess file to serve WebP images only to browsers that support them and fallback to JPEG/PNG otherwise:

# Serve WebP images if browser supports them

  RewriteEngine On

  # Check if browser accepts WebP images
  RewriteCond %{HTTP_ACCEPT} image/webp

  # Check if WebP version of the requested image exists
  RewriteCond %{REQUEST_FILENAME}.webp -f

  # Serve WebP image instead
  RewriteRule ^(.+).(jpe?g|png)$ $1.$2.webp [T=image/webp,E=accept:1]


# Add correct MIME type for WebP

  AddType image/webp .webp

Explanation: This checks if the browser sends Accept: image/webp header and if a WebP version of the requested image exists. If yes, it serves the WebP image instead of JPEG/PNG.

2. Nginx Configuration

Add the following snippet inside your server block to serve WebP images with fallback:

location ~* ^(.+).(jpg|jpeg|png)$ {
    set $webp "";
    if ($http_accept ~* "image/webp") {
        set $webp ".webp";
    }

    # Check if WebP file exists
    if (-f $request_filename$webp) {
        rewrite ^(.+).(jpg|jpeg|png)$ $1.$2.webp break;
    }

    # Serve original if no WebP
    try_files $uri =404;
}

# Add MIME type for WebP
types {
    image/webp webp;
}

Explanation: This configuration checks the Accept header for WebP support and rewrites image requests to WebP versions if they exist. Otherwise, it serves the original JPEG/PNG.

3. WordPress Plugin vs Custom Code

  • Plugins: Plugins like WebP Express or Imagify automate WebP generation and fallback handling without manual server config. They are ideal if you prefer a no-code solution.
  • Custom Code: Using server-level rules is more lightweight and efficient but requires access to server config and some technical knowledge.

Choose plugins if you want easy setup and automatic WebP conversion. Choose server config if you want full control and minimal overhead.

Works on

Server Compatibility
Apache Yes, via .htaccess rules
Nginx Yes, via server block config
LiteSpeed Compatible with Apache rules
cPanel / Plesk Yes, supports editing .htaccess or Nginx config

FAQ

  • Q: Does Safari support WebP now?
    A: Safari supports WebP starting from version 14, but some features like transparency or animation may still have issues. Providing fallbacks ensures compatibility.
  • Q: Can I serve WebP images without server config?
    A: You can use WordPress plugins that handle WebP conversion and fallback automatically without server config.
  • Q: Will this method affect SEO?
    A: No. Serving WebP with proper fallbacks improves page speed and user experience, which can positively impact SEO.
  • Q: What if my server doesn’t support .htaccess?
    A: Use Nginx configuration or a plugin to handle WebP serving and fallback.
  • Q: How do I generate WebP images?
    A: Use image optimization plugins like Imagify, ShortPixel, or WebP Express, or generate WebP images manually and upload them alongside originals.
…
Speed & Security

BunnyCDN + Cloudflare: should you double‑up and how to do it

Posted on August 19, 2025 By Admin No Comments on BunnyCDN + Cloudflare: should you double‑up and how to do it

BunnyCDN + Cloudflare: Should You Double‑Up and How to Do It

Using BunnyCDN and Cloudflare together can supercharge your WordPress site’s speed and security. But is it necessary to stack these two CDNs, and if so, how do you configure them correctly without causing conflicts? This guide explains when combining BunnyCDN and Cloudflare makes sense and provides a clear, step-by-step setup to get you started.

Quick Fix: How to Use BunnyCDN and Cloudflare Together on WordPress

  1. Set up Cloudflare as your DNS and primary CDN with your domain pointing to your origin server.
  2. Create a Pull Zone in BunnyCDN targeting your Cloudflare URL or origin server.
  3. Configure BunnyCDN as a secondary CDN by rewriting static asset URLs to BunnyCDN URLs in WordPress.
  4. Adjust cache settings on both BunnyCDN and Cloudflare to avoid cache conflicts.
  5. Test your site to ensure assets load correctly and caching behaves as expected.

Why This Happens: Understanding the Need for BunnyCDN and Cloudflare Together

Cloudflare is a popular CDN and security provider that offers global caching, DDoS protection, and SSL termination. BunnyCDN is a fast, affordable CDN focused on delivering static assets with low latency. Using both together can:

  • Improve global performance: Cloudflare caches your entire site at the edge, while BunnyCDN can serve static assets from a highly optimized network.
  • Enhance security: Cloudflare protects your origin from attacks and bots.
  • Optimize costs: BunnyCDN’s pay-as-you-go pricing for bandwidth can reduce costs for heavy static asset delivery.

However, stacking two CDNs can cause caching conflicts, increased complexity, and potential delays if not configured properly. This is why a clear architecture and cache strategy is essential.

Architecture Options: How to Combine BunnyCDN and Cloudflare

There are two common architectures when combining BunnyCDN and Cloudflare:

Architecture Description Pros Cons
Cloudflare as Primary CDN + BunnyCDN as Secondary CDN Cloudflare proxies all traffic, BunnyCDN serves static assets (images, CSS, JS) via rewritten URLs. Best security, flexible static asset delivery, easy to control cache separately. Requires URL rewriting and cache rule management.
BunnyCDN as Primary CDN + Cloudflare as DNS + Security BunnyCDN pulls from origin; Cloudflare handles DNS and security but does not proxy content. Simpler CDN setup, Cloudflare security benefits. Less caching at Cloudflare edge, possible slower dynamic content.

The most common and recommended setup is Cloudflare as primary CDN with BunnyCDN serving static assets separately.

Step-by-Step: Setting Up BunnyCDN and Cloudflare Together on WordPress

  1. Configure Cloudflare for Your Domain
    1. Sign up or log in to Cloudflare.
    2. Add your domain and update your nameservers to Cloudflare’s.
    3. Enable proxy (orange cloud) for your domain in DNS settings.
    4. Configure SSL (Full or Full Strict) and security settings.
    5. Enable caching and performance features as needed.
    
  2. Create a BunnyCDN Pull Zone
    1. Log in to BunnyCDN dashboard.
    2. Go to 'Pull Zones' and create a new zone.
    3. Set the origin URL to your Cloudflare proxied domain (e.g., https://www.yoursite.com).
    4. Choose the closest storage region.
    5. Save the Pull Zone and note the BunnyCDN URL (e.g., yourzone.b-cdn.net).
    
  3. Rewrite Static Asset URLs in WordPress

    Use a plugin or code snippet to rewrite URLs for images, CSS, and JS to BunnyCDN URLs.

    <?php
    function replace_static_urls_with_bunnycdn($content) {
        $bunnycdn_url = 'https://yourzone.b-cdn.net';
        $site_url = get_site_url();
        $content = str_replace($site_url . '/wp-content/uploads', $bunnycdn_url . '/wp-content/uploads', $content);
        $content = str_replace($site_url . '/wp-includes', $bunnycdn_url . '/wp-includes', $content);
        $content = str_replace($site_url . '/wp-content/themes', $bunnycdn_url . '/wp-content/themes', $content);
        return $content;
    }
    add_filter('the_content', 'replace_static_urls_with_bunnycdn');
    add_filter('style_loader_src', function($src) use ($bunnycdn_url, $site_url) {
        return str_replace($site_url, $bunnycdn_url, $src);
    });
    add_filter('script_loader_src', function($src) use ($bunnycdn_url, $site_url) {
        return str_replace($site_url, $bunnycdn_url, $src);
    });
    ?>
    

    Alternatively, use plugins like CDN Enabler to rewrite URLs easily.

  4. Configure Cache Settings on Cloudflare and BunnyCDN
    • On Cloudflare, set caching level to “Standard” or “Aggressive” but exclude static assets served by BunnyCDN if possible.
    • On BunnyCDN, set appropriate cache expiration headers (e.g., 1 week for images, CSS, JS).
    • Use page rules in Cloudflare to bypass cache for dynamic content or admin pages.
  5. Test Your Setup
    1. Clear all caches (WordPress, BunnyCDN, Cloudflare).
    2. Load your site and inspect asset URLs to confirm they use BunnyCDN URLs.
    3. Use browser dev tools to check response headers for caching.
    4. Verify SSL works correctly and site loads fast globally.
    

Cache Rules: Best Practices for BunnyCDN and Cloudflare

  • Cloudflare: Use page rules to bypass cache on wp-admin, login pages, and dynamic endpoints.
  • BunnyCDN: Cache static assets aggressively with long TTL
…
Speed & Security

WP Rocket best settings on LiteSpeed servers (or use LSCache?)

Posted on August 19, 2025 By Admin No Comments on WP Rocket best settings on LiteSpeed servers (or use LSCache?)

WP Rocket Best Settings on LiteSpeed Servers (or Use LSCache?)

If you are running a WordPress site on a LiteSpeed server, you might wonder whether to use WP Rocket or LiteSpeed’s native LSCache plugin for optimal performance. Both plugins offer powerful caching and optimization features, but choosing the right one and configuring it correctly can significantly impact your site speed and resource usage.

This guide explains the best WP Rocket settings for LiteSpeed servers, compares WP Rocket with LSCache, and provides a settings checklist and benchmarks to help you decide which solution fits your needs.

Quick Fix: Best WP Rocket Settings on LiteSpeed Servers

  1. Enable WP Rocket’s caching but disable the “Minify CSS/JS” and “Combine CSS/JS” options to avoid conflicts with LiteSpeed server-level optimizations.
  2. Turn off WP Rocket’s lazy loading if LSCache is also active, or use only one plugin to avoid duplicate lazy loading.
  3. Disable WP Rocket’s database optimization if you use LSCache’s database cleaner.
  4. Use WP Rocket’s CDN integration if you have a CDN configured, but avoid overlapping CDN features with LSCache.
  5. Enable “Optimize CSS delivery” but test thoroughly as LiteSpeed may already optimize CSS loading.
  6. Exclude critical LSCache files from WP Rocket optimization to prevent conflicts.

When to Prefer WP Rocket vs LSCache

Use Case WP Rocket LSCache
Server Type Works on any server (Apache, Nginx, LiteSpeed) Only works on LiteSpeed servers
Ease of Use User-friendly UI, beginner-friendly More technical, requires LiteSpeed server
Performance Excellent caching and optimization Better integration with LiteSpeed server, faster cache delivery
Features Advanced minification, CDN, database cleanup, lazy load Server-level caching, ESI, HTTP/3 push, image optimization
Cost Premium plugin with subscription Free with LiteSpeed server

Summary: If you run a LiteSpeed server and want the best performance with server-level caching, LSCache is generally the preferred choice. However, if you want a simpler interface or use multiple server types, WP Rocket is a solid option with proper configuration.

Settings Checklist for WP Rocket on LiteSpeed Servers

  • Caching: Enable page caching but disable minify and combine CSS/JS.
  • File Optimization: Disable minify/combine CSS and JS to avoid conflicts.
  • Media: Enable lazy loading only if LSCache lazy loading is off.
  • Preload: Enable sitemap-based preload for faster cache warming.
  • Database: Disable database cleanup if LSCache database cleaner is active.
  • CDN: Configure CDN URL if applicable, avoid duplicate CDN features.
  • Advanced Rules: Exclude LSCache plugin files and cache folders from WP Rocket optimization.
  • Heartbeat Control: Use WP Rocket’s heartbeat control to reduce server load.

Benchmarks: WP Rocket vs LSCache on LiteSpeed Servers

Multiple independent tests show that LSCache outperforms WP Rocket on LiteSpeed servers in raw speed and server resource usage due to its server-level integration. Here are typical results from a WordPress site on a LiteSpeed server:

Metric WP Rocket LSCache
Page Load Time (Desktop) 1.2 seconds 0.8 seconds
Time to First Byte (TTFB) 250 ms 120 ms
CPU Usage (Peak) Moderate Low
Memory Usage Higher Lower

While WP Rocket is very effective, LSCache’s server-level caching and HTTP/3 push features give it an edge on LiteSpeed servers.

Why This Happens

WP Rocket is a PHP-level caching and optimization plugin designed to work across all server types. It generates cached HTML files and optimizes assets via PHP processes.

LSCache, on the other hand, integrates directly with the LiteSpeed web server, allowing it to serve cached pages faster without invoking PHP. It also supports advanced features like Edge Side Includes (ESI), HTTP/3 push, and image optimization at the server level.

This deep integration means LSCache can deliver faster response times and use fewer server resources compared to WP Rocket on LiteSpeed servers.

Step-by-Step: Configure WP Rocket on LiteSpeed Servers

  1. Install and activate WP Rocket from your WordPress dashboard.
  2. Go to Settings > WP Rocket > Cache and enable caching for mobile and logged-in users if needed.
  3. Navigate to Settings > WP Rocket > File Optimization and disable the following options:
    • Minify CSS files
    • Combine CSS files
    • Minify JavaScript files
    • Combine JavaScript files
  4. Under Media, enable lazy loading only if LSCache lazy loading is disabled or LSCache is not installed.
  5. Go to Preload and enable sitemap-based preloading by entering your sitemap URL.
  6. In Database, disable automatic cleanup if you use LSCache’s database cleaner.
  7. Under CDN, enter your CDN
…
Speed & Security

Posts pagination

Previous 1 2

Recent Posts

  • Top WordPress Themes for Blogs in 2025
  • WordPress Admin Panel Trick: Adding ID Field to the Posts Listing
  • Solution previous_posts_link and next_posts_link Not Working
  • Show Top Commentators in WordPress Without a Plugin
  • How to Style Admin Comments in WordPress

Recent Comments

    Archives

    • August 2025

    Categories

    • Admin & Blocks
    • Admin & UI
    • Automation
    • Automation & Plugins
    • Comments
    • Comparisons
    • Database & Revisions
    • Developer Snippets
    • Fixes & Errors
    • Media & Thumbnails
    • Queries & Pagination
    • Security
    • Speed & Security
    • Tips & Tricks
    • WooCommerce How‑tos
    • WordPress Snippets
    • WordPress Themes
    • Terms & Conditions
    • Affiliate Disclosure

    Copyright © 2025 wpcanyon.com.

    Powered by PressBook WordPress theme