內容簡介
Ultra Web Hosting Performance Toolkit 是一款專為 WordPress 設計的外掛，旨在優化網站性能與安全性。它能有效移除不必要的資源，提供即時的優化數據，並加強網站的安全防護，讓使用者輕鬆管理網站效能。
【主要功能】
• 移除不必要的腳本和樣式
• 提供即時優化數據和請求數量
• 強化登入安全，防止暴力破解
• 一鍵清除多個快取外掛的緩存
• 繪製訪客請求的路徑與環境評估
外掛標籤
開發者團隊
② 後台搜尋「Ultra Web Hosting Performance Toolkit」→ 直接安裝（推薦）
原文外掛簡介
Three things every WordPress site needs, and one screen that shows you all of them working.
WordPress loads roughly 90 KB of scripts and styles on every single page that most sites never use. Emoji detection. A jQuery compatibility shim for code written a decade ago. An icon font for visitors who will never see the admin. This plugin removes them, and then tells you exactly how many kilobytes and how many requests it saved. Not an estimate: the size of the real file on your server.
Speed. Twenty-one optimizations, each a plain toggle. The Optimizations tab opens with a running total of what your current settings have stripped from every page load, broken down by category, next to how much is still on the table. You never have to wonder whether a switch did anything.
Security. Brute-force login protection with a per-IP lockout and a log of who tried. Comment spam stopped by a honeypot, a signed speed trap and a link limiter. XML-RPC closed. The registration page closed. The theme and plugin file editors removed, so a stolen password no longer means arbitrary PHP on your server. Each one steps aside politely when a dedicated security plugin is already handling it.
One button that clears everything. LiteSpeed, AccelerateWP, WP Rocket, W3 Total Cache, WP Super Cache, WP Fastest Cache, Autoptimize, Elementor, Divi, Beaver Builder, Oxygen, GeneratePress, Brizy, OPcache, the object cache, your server’s reverse proxy and Cloudflare. One click, from the admin bar, wherever you are. It calls each plugin’s own flush routine rather than deleting its files behind its back, so it cooperates with your stack instead of fighting it. And if something fails, it says so and names it, rather than reporting a success that did not happen.
It tells you what you are actually running. The Environment tab draws the path a visitor’s request takes to reach your database, each hop lit or dimmed by what was detected, then grades your PHP version and handler, web server, reverse proxy, database, opcode and object caches, and the wp-config.php and .htaccess settings that matter. All read-only. The same checks appear in WordPress Site Health, where you already look.
No upsell, no account, no paid tier, and nothing phones home. The only external service the plugin ever contacts is Cloudflare, and only if you have deliberately set that up.
Every option is a plain toggle, and anything not marked below is generally safe to leave on.
Front-end optimizations
Remove query strings from static CSS/JS URLs so proxies and CDNs cache them more aggressively. Off by default, since stripping ?ver= can serve stale CSS/JS after an update on sites that rely on it for cache-busting. Leave it off if you run WooCommerce, where a stale cart or checkout script can break purchases silently.
Disable emoji scripts — browsers render emoji natively, so the detection script is dead weight.
Remove legacy head tags (RSD, Windows Live Writer, shortlink).
Hide the WordPress version generator tag from page source and feeds.
Disable embeds — removes the oEmbed discovery links, REST route, and wp-embed.js.
Remove jQuery Migrate — patches back methods jQuery 3 removed. Saves about 5 KB compressed and one request. Off by default, because if anything on the site still calls one of those methods this breaks it with only a console error to show for it. Leave jQuery Migrate loaded, open your browser console, and look for JQMIGRATE warnings first.
Dashicons for logged-in users only — skips the icon font for logged-out visitors, and steps aside automatically when a theme or plugin has declared a dependency on it.
Remove block editor CSS — drops the block library stylesheet and global styles from the front end. Off by default, and skipped automatically on block themes. Only suitable for classic themes that use no blocks.
Heartbeat API control — set the interval independently for the front end, dashboard, and post editor, or remove the heartbeat from public pages entirely. Blank leaves the WordPress default in place.
Disable pingbacks and self-pings — removes only the pingback.* XML-RPC methods and the X-Pingback header, closing a common DDoS amplification vector. Safe with Jetpack and the mobile app, which use the rest of XML-RPC.
Security and spam
Login protection — five failed attempts triggers a 15-minute per-IP lockout, with a lockout log on the settings page. Automatically steps aside when Wordfence, Solid Security, Sucuri, All-In-One WP Security, WP Cerber, Limit Login Attempts, LoginPress, Jetpack Protect, or Imunify Security is active, so there are no double lockouts.
Disable XML-RPC — returns 403 on xmlrpc.php to block brute-force amplification.
Comment spam protection — honeypot field, signed submit-speed trap, and link limiter. Comments with too many links are held for moderation rather than rejected, so a genuine comment is never lost.
Auto-close old comments — closes comments on posts older than 90 days, the favourite target of spam bots. Existing comments are preserved. Recommended, but off by default because it overrides your Settings > Discussion choice, so turn it on deliberately.
Block the registration page — closes wp-login.php?action=register and hides the Register link. Turning off “Anyone can register” stops accounts being created but still renders the form, and that URL is among the most probed on any WordPress site. Defers to the core setting: a site that allows registration is never blocked, however this is set.
Disable the file editors — removes the theme and plugin editors from the admin. Those editors let anyone with administrator access write PHP that runs on your server, which is the first thing an attacker reaches for after stealing a login.
One-click cache purge
Adds a Clear All Caches button to the admin bar that flushes, in one click: the WordPress object cache and transients, PHP OPcache, LiteSpeed Cache / AccelerateWP, WP Rocket, W3 Total Cache, WP Super Cache, WP Fastest Cache, Autoptimize, and Elementor / Divi / Beaver Builder / Oxygen / GeneratePress / Brizy generated CSS. Cloudflare purging and server-level cache purging are available as opt-in extras.
For each caching plugin the button calls that plugin’s own flush routine, so it works alongside your caching stack rather than fighting it. Anything not installed is skipped.
Database cleanup
Reports exactly how much cruft is in your database before removing any of it: post revisions, auto-drafts, trashed posts, spam and trashed comments, expired transients, orphaned post and comment metadata, and cached oEmbed markup. Counts are read live, nothing is pre-selected that is destructive, and deletion runs in bounded batches so a neglected site cannot time out the request. Removal goes through the WordPress APIs wherever they exist, so related rows are cleaned up by core rather than left behind.
Site Health integration
Adds five checks to Tools > Site Health: persistent object cache, PHP opcode cache, WP-Cron configuration, post revision accumulation, and visitor IP detection. The information appears where WordPress users already look for it.
WP-CLI
wp ultra-perf purge, `status`, `cleanup`, `lockouts`, `unlock`, `export`, and `import`. Cleanup supports `--dry-run` and `--items=`, and defaults to the non-destructive items only.
Server cache
A reverse proxy in front of WordPress can keep serving a page after every WordPress cache has been cleared, and PHP running as the site user cannot reach it. Two methods are offered: an HTTP purge request to the server itself, which is immediate where the host has configured a purge module, or a request written into the plugin’s own folder in the uploads directory for a privileged process on the server to collect, which works where the proxy cannot be addressed from the site at all.
Automatic is the default and the right choice for almost everyone. It tries the immediate method, quietly falls back to queuing if the server will not answer, remembers the answer so it stops asking, and reports a problem only when neither works. The settings page shows which methods your server has actually been shown to support.
Light and dark
The settings screen has a light and a dark theme, chosen per user from the switcher in the header, so two people administering the same site can each have their own. Light is the default, because WordPress has no admin dark mode and following the operating system would leave a dark panel inside a light admin. Auto is available for anyone who wants the system preference honoured.
Visitor IP detection
Login protection needs the real visitor address. Forwarding headers such as X-Forwarded-For and CF-Connecting-IP can be set by anyone, so they are only ever trusted on requests that genuinely arrived from a proxy.
Auto-detect handles this for you and is the default. It checks the connecting address against Cloudflare’s published ranges, then against loopback and private ranges, and falls back to the raw connection when neither matches. A header on a request that did not come from one of those ranges is ignored, so auto mode cannot be tricked by a spoofed header.
The settings page shows what the plugin sees on your own request: the address it resolved, which header it came from, and whether your current mode matches the evidence. A CDN other than Cloudflare needs Reverse proxy mode with its ranges listed.
Privacy
This plugin does not collect, store, or transmit any personal data about your visitors, and it contains no analytics or tracking of any kind.
Login protection stores the IP addresses of clients that trigger a lockout so an administrator can review and clear them. Entries are capped at the fifty most recent, and everything is removed when the plugin is deleted.
External services
This plugin contacts exactly one external service, and only if you switch it on:
Cloudflare API (api.cloudflare.com) — disabled by default. Contacted only if you enable Cloudflare purging on the settings page and supply an API token, and only when you click “Clear All Caches.” Two requests are involved: a zone lookup that sends your site’s hostname, and the purge itself. Your API token is sent as a credential with both. No visitor data, post content, or personal information is transmitted. The purge clears the entire zone, so take care if several sites share one Cloudflare zone. See the Cloudflare terms of service and privacy policy.
To work out whether an nginx reverse proxy sits in front of the site, the plugin sends a HEAD request to this server’s own address, as reported by the server itself, with your site’s Host header. It falls back to your home URL if the server does not report an address. Both go to your own server, no third party is involved, and the answer is cached for twenty-four hours. The server’s own address is tried first because a request to your public URL travels through your CDN, if you have one, and a CDN answers with its own headers, hiding the origin stack behind it.
Nothing else leaves your site. The WordPress version comparison on the dashboard reads the update data WordPress already keeps for its own update checks, rather than making a request of its own.
Host-specific behavior
The plugin writes nothing outside WordPress and makes no assumptions about your server’s filesystem.
A reverse proxy cache, such as nginx or Varnish sitting in front of WordPress, cannot be cleared by touching files: the paths belong to the host, are usually not writable by the site, and differ everywhere. Instead, Clear the Server Cache asks the proxy directly, using the same HTTP method Varnish and nginx purge modules have accepted for years. The request is addressed to your own server, with your site’s Host header, so it reaches the proxy running there rather than travelling out through a CDN. Nothing leaves the machine.
The setting does nothing until your host configures the proxy to accept it, and the plugin reports that rather than claiming success. For nginx with ngx_cache_purge, one location block is enough:
location ~ /purge(/.*) {
# The request originates on this machine, so allow the server's own
# address. Add 127.0.0.1 as well if your setup routes it that way.
allow 203.0.113.10;
deny all;
proxy_cache_purge my_cache_zone "$scheme$request_method$host$1";
}
The Environment tab shows the address the plugin will send from, so you can match the rule to it.
Where a proxy cannot be addressed from the site at all, the purge can instead be queued for the server to collect. Each purge writes a JSON record into wp-content/uploads/ultrawebhosting-performance-toolkit/ containing a timestamp, the site URL, its filesystem path and the layers already cleared. Nothing outside WordPress is touched, and the directory denies web access.
A privileged process on the server collects those records and clears what WordPress cannot reach itself. This is the approach to use where the proxy cache is owned by root and is deliberately not writable by the site, which is the normal arrangement on shared hosting. Records are pruned automatically, so a host that never collects them costs a site a few bytes and nothing else.
A minimal watcher, run from cron once a minute:
find /home/*/public_html/wp-content/uploads/ultrawebhosting-performance-toolkit \
-maxdepth 1 -type f -name 'purge-*.json' -mmin -15 |
while read -r trigger; do
user="${trigger#/home/}"; user="${user%%/*}"
[ "$(stat -c '%U' "$trigger")" = "$user" ] || continue # trigger must belong to the account
rm -f "$trigger"
your-purge-command "$user"
done
Check the ownership as shown. Without it, a writable uploads directory on one account could trigger work for another.
Hosts preferring their own mechanism can hook ultra_after_cache_purge instead:
add_action( 'ultra_after_cache_purge', function ( $cleared, $failed ) {
// Your host's own purge mechanism.
}, 10, 2 );
The plugin also reads a few well-known paths to work out which control panel it is running on, so its advice about scheduled tasks and object caching matches the reader’s host. Those are existence checks only; nothing is written.
Developer notes
Every threshold is adjustable with a standard filter:
`
// Comment spam protection
add_filter( ‘ultra_spam_max_links’, fn() => 2 );
add_filter( ‘ultra_spam_min_time’, fn() => 3 );
add_filter( ‘ultra_spam_close_after_days’, fn() => 90 );
// Login protection
add_filter( ‘ultra_login_max_attempts’, fn() => 5 );
add_filter( ‘ultra_login_lockout_duration’, fn() => 15 * MINUTE_IN_SECONDS );
add_filter( ‘ultra_login_tracking_window’, fn() => 30 * MINUTE_IN_SECONDS );
// Heartbeat intervals in seconds; a front-end value of 0 disables it
add_filter( ‘ultra_heartbeat_frontend_interval’, fn() => 0 );
add_filter( ‘ultra_heartbeat_admin_interval’, fn() => 120 );
add_filter( ‘ultra_heartbeat_editor_interval’, fn() => 30 );
// Trusted proxy ranges used for visitor IP detection
add_filter( ‘ultra_trusted_proxies’, function( $ranges, $mode ) { return $ranges; }, 10, 2 );
// Whether a full opcache_reset() is allowed when per-file invalidation is unavailable
add_filter( ‘ultra_purge_opcache_reset’, ‘__return_false’ );
// Rows removed per pass by the database cleanup
add_filter( ‘ultra_cleanup_batch_size’, fn() => 500 );
// Warm the origin before purging the CDN, so the edge cannot cache a 404
// for an asset that is about to be regenerated
add_filter( ‘ultra_warm_origin_before_cdn_purge’, ‘__return_true’ );
// Minimum gap between login lockout alert emails
add_filter( ‘ultra_lockout_email_cooldown’, fn() => HOUR_IN_SECONDS …
