BerqWP - WordPress Plugin

A Practical Guide to Configuring BerqWP for Faster WordPress Performance

BerqWP is best viewed not as just another "speed up your site" toggle, but as a WordPress optimization system where page caching, CSS and JavaScript delivery, images, link preloading, and testing mode all need to work together. In this guide, we will walk through how to prepare your site, choose an optimization method, enable caching safely, verify the results, and avoid breaking dynamic pages.

This article is written for site owners, webmasters, and developers who want to deploy the plugin without guesswork. It starts with preparation and initial checks, then moves into detailed setup, a separate workflow for stores or sites with dynamic pages, troubleshooting, and a comparison with similar solutions.

One key point before you begin: you cannot evaluate WordPress performance by looking at a single PageSpeed Insights score alone. You need to check whether the cached page is actually being served, whether styles are still intact, whether the cart still works, whether above-the-fold content loads correctly, and whether optimization is creating unnecessary versions of the same page with different URL parameters.

What This Performance Plugin Is Good For

BerqWP's main purpose is to reduce the time required to generate and load WordPress pages. It does this through full HTML page caching, CSS and JavaScript optimization, lazy loading for images and embedded blocks, LCP image preloading, font handling, and additional cloud features through BerqWP Cloud.

On its official site and in the WordPress directory, the plugin is positioned as an automated Core Web Vitals tool. That does not mean every site will instantly become perfect. In practice, results depend on the theme, page builder, hosting, the number of third-party scripts, ad blocks, analytics, cookie consent forms, and whether the site includes dynamic content.

Common Use Cases

• A content site or blog where most pages can be safely served from static cache.
• A business site built with a page builder, where LCP, lazy loading for maps, video, and heavy sections matter.
• A WooCommerce store, as long as the cart, checkout, and account pages are excluded carefully.
• An agency site portfolio where you need a fast baseline optimization layer without manually tuning every CSS file.
• A site with a global audience, if you plan to use cloud delivery and Cloudflare Edge Cache.

BerqWP is especially useful when the site owner does not want to piece together a separate cache plugin, image optimizer, lazy load plugin, and critical CSS tool. But because it affects so many parts of the stack, you should not install it on top of several active optimization tools and assume they will sort things out on their own.

When a Different Approach Makes More Sense

The plugin may not be a good fit for a site where almost every page is personalized per user, depends on complex cookies, changes heavily through Ajax, or is assembled by a third-party application. In those cases, full HTML caching can lead to incorrect interface states: an outdated cart, someone else's recommendation, the wrong price, a hidden form, or stale content blocks.

If your hosting environment already provides managed server-side caching, such as LiteSpeed, Varnish, or a provider-specific cache layer, the first step is to determine whether one of the layers can be disabled. The official BerqWP documentation explicitly states that the plugin should be the only caching service for the public-facing part of the site. This is not a formality: two cache layers can clear at different times and create errors that are difficult to reproduce.

What to Check Before Installation

Preparation matters more than installation itself. BerqWP changes how pages and assets are delivered, so before enabling the plugin you should capture the site's baseline state. That gives you a clear way to see what actually improved and what got worse after optimization.

Minimum Technical Checklist

• Check your PHP version: the official guide requires PHP 7.4 or higher.
• Create a backup of your files and database using your hosting tools or a trusted backup plugin.
• Disable, or at least temporarily deactivate, other caching and front-end optimization plugins.
• Ask your hosting provider whether a separate front-end cache is enabled and cannot be cleared from WordPress.
• Save baseline PageSpeed Insights, GTmetrix, or WebPageTest results for the homepage, a typical post, a product page, and the checkout page if WooCommerce is installed.
• Open the site in a private window and manually test the menu, forms, search, sliders, filters, cart, and account area.

A practical starting point: test BerqWP on a staging copy of the site first, or use Sandbox Mode. If you do not have a staging copy, enable settings gradually and check not only the speed score but also normal visitor actions.

Which Pages Should Not Be Treated as Regular Cache Pages

Pages whose content depends on the current user require special attention. The cart, checkout, account area, search results, booking forms, protected sections, filtered pages, and any URL with one-time tokens should not be blindly collapsed into a single static version for every visitor.

The official exclusions documentation specifically mentions pages with user-specific dynamic content, including the WooCommerce cart and checkout. Even if the plugin already includes built-in logic for common scenarios, you still need to test your actual mix of store, subscription, booking, or account-related plugins after installation.

Installation and the First Post-Activation Check

Installation is standard for WordPress, but there is one important detail: before activation, it is best to remove competing optimization tools. In the WordPress plugin directory, the plugin appears as BerqWP, while some technical links use the slug searchpro. That is normal and does not mean you found a different product.

Installation Steps

1. Open the WordPress admin panel and go to Plugins - Add New Plugin.
2. Search for BerqWP, install the plugin, and click Activate.
3. Open the BerqWP section or BerqWP > Dashboard.
4. Choose an optimization method: for a cautious rollout, it usually makes sense to start with Local if you want a free, self-contained mode running on your own server.
5. Save the settings, clear your browser cache or open a private window, then visit the homepage and a few internal pages.

Do not judge the result by the very first page load after activation. The cache still needs to be built, and optimization may start only after the first visit or through a warm-up queue. To verify it properly, open the page as a guest, then refresh it once more. If the second request is faster and diagnostics show signs of caching, the base layer is working.

How to Tell Whether the Cache Is Being Created

In the BerqWP admin panel, check the number of cached pages or the optimization status. In the browser, it is also useful to open developer tools, go to the Network tab, refresh the page, and inspect the response headers. In the Apache documentation, the developer mentions server-level cache delivery and indicators such as the X-served: server header, but the exact header set can vary depending on the mode, hosting environment, and plugin version.

How to validate the result: test a public page in a private window, without URL parameters and while logged out of WordPress. A logged-in administrator often sees a different version of the page than a regular visitor.

Local vs Cloud: How to Choose the Right Optimization Method

One of BerqWP's key features is the split between Local Optimization and BerqWP Cloud. These are not just two pricing tiers. They use different page-processing logic, depend on outside infrastructure to different degrees, and offer different capabilities.

Local Optimization

In the official article on Local Optimization, the developer describes this method as a free mode that runs on your server through PHP and does not require a license or account. It includes full page caching, lazy loading for images and embedded blocks, LCP image preloading, automatic image dimensions, URL preloading, prerendering on link hover, and font optimization.

Local is a good choice for a cautious start: fewer external dependencies, a clearer responsibility boundary, and an easier story to explain to a client. On Apache, the plugin can automatically add rules to .htaccess so cached pages are served before PHP runs. On Nginx, comparable server-level cache delivery may require manual rules, so you need to check both the documentation and your hosting capabilities.

BerqWP Cloud

According to the developer's description, Cloud mode uses Photon Engine and cloud infrastructure for heavier tasks: critical CSS generation, WebP, Fluid Images with AVIF/WebP or original format delivery, CDN support, JavaScript execution settings, and Web Vitals analytics. The WordPress directory also states that Cloud receives the page URL and plugin settings, then optimizes the page in an external layer and stores the result as cache.

Cloud is worth considering if you need cloud delivery, automated image processing, and less strain on weak hosting. But this mode adds a dependency on an external service and a license. That is not inherently a problem for a commercial website, but it does require clear validation: service availability, hosting security rules, no blocked requests, and proper cache invalidation after updates.

Your Settings Map After Installation

BerqWP promises automated optimization, but that does not mean the administrator has nothing to review. After installation, go through the settings as if they were a risk map: what affects HTML caching, what affects CSS/JS delivery, what affects images, and what should only be enabled after a visual check.

Optimization Method and CSS/JS Mode

The BerqWP mode documentation makes one important point clear: Standard, Smart, Blaze, and Turbo specifically affect how CSS and JavaScript are loaded. That makes troubleshooting easier. If a slider disappears, a menu stops opening, or a form stops working after switching to a more aggressive mode, the root cause is usually not HTML caching itself but delayed or asynchronous asset loading.

For the first rollout, Standard or Smart is a sensible choice, especially on a complex site. Turbo may produce a higher test score, but it should also be the first thing you roll back if interactivity breaks. After changing the mode, clear the cache and test the page as a guest.

Sandbox Mode for Safe Previewing

Sandbox Mode is designed to let you inspect the optimized version without affecting real visitors. According to the official instructions, the mode is enabled from the BerqWP panel, and the optimized version is opened by adding ?berqwp to the page URL. That is useful when you want to compare the original and optimized versions before applying the settings publicly.

Do not confuse Sandbox Mode with a full staging site. It helps you see the effect of optimization, but it does not replace backups or test every server-specific behavior. The Apache documentation also notes that .htaccess rules are temporarily removed in Sandbox Mode, so server-level cache delivery should be tested only after the mode is turned off.

Images, WebP, and Fluid Images

In Local mode, image optimization mainly revolves around lazy loading, image dimensions, and LCP preloading. Cloud offers a broader feature set, including WebP/AVIF and Fluid Images. If the site already uses a separate image service, check first to make sure the transformations are not being duplicated. Double optimization can sometimes create extra redirects, broken srcset, or lower image quality instead of improving performance.

If the plugin previously generated WebP files and you are changing your image strategy, do not delete those files blindly on a live site. An older official article about removing WebP files is marked as outdated, so any bulk image cleanup is best done only after a backup and a review of the current documentation.

Cloudflare Edge Cache and External CDN

BerqWP claims support for Cloudflare Edge Cache and cloud delivery. That can significantly reduce response times for visitors in different regions, but it also adds another cache layer. After connecting Cloudflare, verify not only speed but also how cache invalidation works when you update a page, product, menu, or template. If you still see an old page version after publishing changes, the problem may be in one of the external layers rather than in WordPress itself.

Page Cache, Exclusions, and URL Parameters

The most common mistake when configuring any cache plugin is assuming everything should be cached. In reality, a good cache layer needs to do more than store pages - it also needs to know when to bypass caching because the data must stay fresh or personalized.

Page Exclusions

In the BerqWP documentation, the exclusions section is located under BerqWP - Cache Management, and the field is called Page Exclusions. This is where you add page URLs that should never be cached. For WooCommerce, the first pages to verify are the cart, checkout, and account pages. On a subscription-based site, that list should also include login, profile, payment, cancellation, and protected content pages.

If you use a custom URL for a private account area, do not assume the plugin will understand your business logic automatically. Add the exclusion manually, clear the cache, open the page in a private window, and verify that different users are not receiving the same personalized HTML.

Ignore URL Parameters

URL parameters can destroy cache efficiency. If your ad platform appends utm_source, fbclid, gclid, or similar parameters, the cache may treat the same page as many different URLs. The official BerqWP article states that common marketing parameters are already excluded by default, and custom ones can be added to Ignore URL Parameters.

This setting requires care. Marketing parameters are usually safe to ignore because they do not change page content. But product filters, sorting, language, currency, or personal token parameters must not be ignored if they affect what the visitor actually sees.

How to Test Exclusions Properly

1. Open the page while logged out of WordPress and perform an action that changes its state: add a product, log in, or apply a filter.
2. Open the same URL in another private window and make sure the personalized data does not carry over.
3. Clear the cache for that specific page using Purge this page if you changed only one page.
4. Use the full Flush cache option only after broader changes to the theme, templates, or optimization mode.

Practical Example: Rolling It Out on a WooCommerce Site

Now let us look at a scenario with more risk than a standard blog: a WooCommerce store with a homepage, category page, product page, cart, and checkout. The goal is to speed up public pages without caching customer-specific states.

Goal

Create fast cache delivery for the homepage, category page, and product page, while keeping the cart, checkout, and account area dynamic. After setup, customers should always see an up-to-date cart, and the administrator should understand how to roll back questionable settings.

Preparation

• Create a test product with a simple price and availability.
• Write down the cart, checkout, and account page URLs.
• Disable any other page cache or server-side optimizer if it overlaps with BerqWP.
• Capture baseline performance measurements for the homepage, category page, and product page.

Setup Steps

1. Enable BerqWP and choose Local Optimization for the first pass.
2. Select Standard or Smart if the theme relies heavily on JavaScript. On a simpler theme, you can test Blaze, but clear the cache after each mode change.
3. Turn on Sandbox Mode and open the homepage with the ?berqwp parameter. Check the menu, header, above-the-fold area, and buttons.
4. Go to Cache Management and confirm that the cart, checkout, and account URLs are excluded or detected automatically. If the site uses non-standard paths, add them manually.
5. Open a product page in a private window, add the product to the cart, proceed to checkout, and verify that the quantity and total are correct.
6. If everything works, turn off Sandbox Mode, clear the cache, and repeat the test without ?berqwp.

Expected Result and One Important Nuance

Public pages should load faster on repeat requests, while dynamic pages should remain fully live. If adding a product works only when you are logged in but breaks for guests, the first thing to do is roll back the CSS/JS mode to a less aggressive setting and recheck your cache exclusions. If the issue disappears, then the problem was not WooCommerce itself but script delivery or static HTML.

Short takeaway: for a store, the main success criterion is not the highest PageSpeed score, but the balance between fast product pages and a fully working cart, checkout, coupons, payments, and account area.

How to Verify the Result: Speed, Cache, and Visual Stability

Validation should happen in three layers. First comes the technical layer: is the cache being created, and is the page being served correctly to guests? Second is the visual layer: has the layout broken, have images disappeared, are fonts still loading properly? Third is the user layer: can visitors still complete the actions that matter?

What to Look at in Speed Tests

PageSpeed Insights is useful, but it should not be your only benchmark. Watch LCP, CLS, INP, server response time, and the list of resources blocking above-the-fold rendering. If the score improves but the first screen flickers in a real browser, the menu opens with a delay, or a form stops submitting, that setup should not be considered successful.

Do not test only the homepage. A typical WordPress test set includes the homepage, a post, a category page, a product page, a form page, and a page with a map or video. Each of them may have a different LCP element and a different script set.

How to Check HTML Cache

• Open the page in a private window and refresh it twice.
• Check the Network tab in developer tools and compare the response time of the first document.
• Make sure the URL does not include parameters that are supposed to bypass cache.
• Log out of the admin panel, because logged-in users often bypass cache.
• If Cloudflare or another CDN is enabled, inspect the external cache headers as well.

Visual Review After Every Change

After changing the optimization mode, do a quick tour of the site: top navigation, mobile menu, slider, cookie popup, contact form, search, product filters, gallery, map, video, and page builder blocks. These are the elements most likely to depend on JavaScript execution order.

If you spot an issue, do not change five settings at once. Roll back the last change, clear the cache, and repeat the test. That approach is less exciting than "trying everything," but it is the only reliable way to identify the real cause.

Common Problems and Fixes

Below are the issues most commonly associated with caching and resource optimization, and some of them are mentioned directly in the official BerqWP documentation or community discussions. Use this section as a diagnostic map, not as a reason to start editing code immediately.

Cache not detected message

Symptom: the plugin panel shows a message saying the cache was not detected. Possible cause: another page cache is active, the hosting platform is adding its own cache layer, or there is a duplicate define( 'WP_CACHE', true ); line in wp-config.php. The official documentation recommends leaving BerqWP as the only caching service for the public side of the site.

What to do: disable the other cache plugin, check your hosting control panel, then deactivate and reactivate BerqWP. Do not manually remove system files unless you have a backup and know exactly what created them.

The site looks broken after enabling Turbo or Blaze

Symptom: styles are missing, the menu no longer opens, or the slider or form stops working. Cause: the optimization modes change how CSS and JavaScript are delivered. The documentation states that Standard, Smart, Blaze, and Turbo differ specifically in their CSS/JS loading methods.

What to do: switch to a less aggressive mode, clear the cache, and test the page in a private window. If the problem disappears, keep the stable mode and do not chase extra points. On a complex theme, a stable Smart setup can be better than a flashy but fragile Turbo result.

Cache creation is too slow or the warm-up process is not progressing

Symptom: new pages stay uncached for too long, the queue does not move, and repeat measurements are inconsistent. Possible causes: weak hosting, blocked external requests in Cloud mode, a WP-Cron conflict, too many pages, or a temporary queue error.

What to check: open the page as a guest, review the status in BerqWP, inspect the PHP error log, and look for messages from your hosting provider. If Cloud is enabled, make sure the firewall is not blocking service requests. WordPress.org discussions have included complaints about slow warm-up behavior, so on larger sites it is best to test a limited set of key pages first.

Checkout or the account area shows incorrect data

Symptom: the cart does not update, the order total is wrong, or the account area shows stale data. Cause: a dynamic page received static cache or an important script was delayed.

What to do: add the URL to Page Exclusions, clear the cache, and test both as a guest and as a logged-in user. If you use custom WooCommerce pages or a third-party checkout plugin, do not rely only on automatic detection.

Images are served in the wrong format or fail to load

Symptom: some images disappear, WebP/AVIF is not delivered consistently, or srcset is broken. Cause: a conflict between multiple image optimizers, the CDN, lazy loading, or old files left over after switching modes.

What to do: temporarily disable the third-party image optimizer, clear both BerqWP and CDN cache, then inspect the image HTML and network requests. Do not delete all generated WebP files without a backup and a review of the current documentation.

Visitors still see the old page after changes are published

Symptom: everything is updated in the admin area, but the public site still shows the old text or template. Cause: one of the cache layers was not cleared: BerqWP, CDN, Cloudflare, hosting cache, or the browser.

What to do: use Purge this page for a single page, and use Flush cache for theme changes or global template updates. If an external CDN is connected, purge it by URL or fully if needed, but do not run a full purge on a large site every time without a reason.

Safe Enhancements for Developers

Most sites can get by with the plugin settings alone. Add code only when you have custom logic that BerqWP cannot detect automatically: a custom account area, a protected section, non-standard content imports, custom post types, or multilingual URL structures.

Below is an example of a safe direction: excluding a protected section from cache based on part of the URL. Add code like this through a child theme or the Code Snippets plugin. Do not modify WordPress core, BerqWP files, or the parent theme.

add_filter( 'berqwp_exclude_slug_match', function ( $exclude_items ) {
    $exclude_items[] = '/members/';
    $exclude_items[] = '/account/private/';
    return $exclude_items;
} );

After adding the snippet, clear the cache, open the protected page as both a guest and a logged-in user, and verify that it is not being served like a normal cached public page. Rolling back is simple: disable the snippet, clear the cache, and test again.

Limitation: cache filters run on public requests, so you should not perform heavy database queries, remote HTTP calls, or complex checks inside them. The condition needs to stay fast and predictable.

For bulk content imports, the official Cache API includes actions and filters for controlling cache invalidation. But these recipes are best implemented by a developer who understands when the full cache should be cleared and when clearing a single page is enough. On a large site, flushing everything after every minor change can create a long re-optimization queue.

Is It Worth Moving Forward with Testing?

BerqWP looks like a strong option for sites that need a fast start with page caching, resource optimization, and a clear Local/Cloud workflow. Its main value is automation, but that is also its biggest risk area: automated optimization affects HTML, CSS, JavaScript, images, and external cache layers, so it should be introduced step by step.

If you run a standard blog, a business site, or a store with well-defined exclusions, the plugin is worth testing on a staging copy or through Sandbox Mode. If the site is fully dynamic, built around complex user states, or already relies on managed server-side caching, map out the conflicts first and decide which cache layer should be the primary one.

After reading this guide, the most sensible next step is to go to the download block, download BerqWP, install it on a test copy of the site, and work through the checks covered above: guest-side caching, dynamic pages, CSS/JS modes, images, and cache invalidation after updates.