Block Weight Inspector vs Perfbase

Block Weight Inspector adds a sidebar panel in the block editor that maps blocks in the current post/page to the CSS and JS assets they register. It estimates local asset sizes, highlights top offenders, and exports a JSON report. It can also generate a suggested conditional-loading snippet to help you dequeue assets when a block is not present. It also adds a Tools -> Block Weight Inspector screen for auditing existing posts without opening the editor. Note: The inspector preserves block comment delimiters when analyzing content so parse_blocks() remains accurate after sanitization. Key features: Block -> asset mapping using registered block metadata. Estimated size for local assets. Top offenders summary and full asset list. JSON export for sharing or auditing. Suggested conditional-loading rules (review before use).

Perfbase profiles WordPress applications and sends performance traces to the Perfbase APM platform. It captures request lifecycle timing, WordPress context, selected metadata, and trace data through the native Perfbase PHP extension and the shared Perfbase PHP SDK. This plugin is a Software-as-a-Service integration. It requires a Perfbase account, a Perfbase API key, and the native ext-perfbase PHP extension. The plugin does not submit traces until profiling is enabled and an API key is configured. The plugin can profile: Standard HTTP requests. Admin requests when enabled. AJAX requests. WordPress cron runs. WP-CLI commands when enabled. WordPress, theme, plugin, REST, and WooCommerce context when available. For privacy and cardinality control, request URLs are stored without query strings. Important WordPress query parameters are stored separately where useful. External Services This plugin connects to the Perfbase APM platform, an external application performance monitoring service, when profiling is enabled. Service name: Perfbase APM platform and the configured Perfbase ingest API endpoint. The default endpoint is https://ingress.perfbase.cloud. Service policies: Perfbase Privacy Policy and Perfbase Terms. When data is sent: trace data is sent only after a Perfbase API key is configured, profiling is enabled, the request passes the configured sampling rate, include/exclude filters, user-agent exclusions, request-type toggles, and HTTP status-code rules. For HTTP, AJAX, cron, and WP-CLI lifecycles, submission normally happens at the end of the lifecycle or during shutdown. The plugin does not submit profiling traces while profiling is disabled or while no API key is configured. Perfbase can send: Native trace payloads: function call trees, function names, source file paths and line numbers, timing, CPU, memory, host resource metrics, call context, and runtime error or exception context. System/resource data: host operating system, kernel, hostname, CPU architecture, CPU details, disk capacity details, memory usage, CPU usage, disk I/O, and network I/O samples. Process-list tracking when enabled: capped process snapshots with process ID, executable basename, OS user, CPU usage, memory usage, and process runtime. Command-line arguments are not included in process snapshots. Additional native trace metadata: normalized SQL query text and query type, database DSN/host/database/username/port metadata, MongoDB or Elasticsearch query/filter payload summaries, Redis or Memcached keys and fields, HTTP URL or URI metadata that may include query strings depending on the PHP API or HTTP library used, HTTP method/status/timing/byte-count metadata, file paths and file operation metadata, mail recipient and subject metadata, shell/process command strings, AWS operation names, OPcache and JIT statistics, PHP error or exception samples, compiled file paths, magic method counts, and truncated function argument values if argument capture is separately configured. WordPress request metadata: action name, HTTP method, request URL without query string, HTTP status code, user IP address, user agent, logged-in user ID when available, hostname, environment, application version, PHP version, WordPress version, and Perfbase plugin version. WordPress context metadata: AJAX action, REST route, admin page, post/page identifiers, post type/status, taxonomy context, template and theme information, conditional page type flags, plugin lifecycle context, and WooCommerce page, cart, product, or order context when available. Operational summaries: memory usage, database query count and timing summaries when available, and sanitized outbound HTTP request metadata when HTTP tracking is enabled. Perfbase does not collect: Source code. Request bodies, full POST payloads ($_POST), arbitrary form fields, or uploaded file contents. Cookie values ($_COOKIE) or PHP session data ($_SESSION). Authorization header values. Passwords, API keys, nonces, or session IDs from WordPress request, cookie, or session data. Command-line arguments for process-list snapshots. Feature flags control the extra native trace metadata listed under “Perfbase can send”, including outbound HTTP URLs or URIs with query strings for some HTTP libraries and truncated function argument values if argument capture is separately configured. Administrators should review enabled Perfbase extension feature flags before profiling sensitive workloads. Extension installer and CDN: the plugin runtime does not call cdn.perfbase.com. The optional extension installer and manual extension binary downloads use https://cdn.perfbase.com only when a server administrator downloads or runs those installation assets. Privacy This plugin connects to Perfbase’s external service when profiling is enabled. It sends profiling trace data and request metadata to the configured Perfbase API endpoint. Data submission requires explicit configuration of a Perfbase API key and the Enable Profiling setting. The plugin does not submit traces while profiling is disabled or while no API key is configured. Administrators should review their site’s privacy policy and disclose their use of Perfbase where appropriate.