DEV Community: Jeremy Burgos

Field vs lab data: why most Core Web Vitals arguments are dataset confusion

Jeremy Burgos — Tue, 23 Jun 2026 10:30:00 +0000

TL;DR: If you cannot name which dataset you are looking at, you are arguing, not diagnosing. Field answers "are real users failing at scale." Lab answers "what mechanism caused it." Sequence: field to scope, lab to diagnose, field to validate.

The sequence that resolves most stuck performance debates:

field  -> confirm the problem exists and find its scope
lab    -> isolate a cause you can test
field  -> validate the fix against the evidence you started with

Core Web Vitals work falls apart when two people argue from two datasets. One looks at real-user field results, the other at a lab simulation. Both valid, both useful, answering different questions. Name which one, or you are not diagnosing.

What they measure, and the 75th percentile

LCP (good: 2.5s or less) is loading, INP (good: 200ms or less) is responsiveness, CLS (good: 0.1 or less) is visual stability. They are outcome metrics: they tell you what users experienced, not why. The detail that ends most "but it is fast for me" disagreements: pass/fail is the 75th percentile, not an average. A site can feel fast for many users and still fail, because the 75th percentile forces you to care about weaker devices and slower networks.

Field and lab are not interchangeable

Field data is aggregated real-user experience across devices and networks, including variance you cannot simulate: slow hardware, cellular latency, packet loss, cache states. It answers whether users are actually failing at scale. Lab data is controlled and repeatable, and gives you the traces field cannot: render-blocking resources, long tasks, layout shift events, waterfalls. It answers what mechanism is likely causing the outcome. They diverge because field is a distribution across sessions and lab is a snapshot under one config. Do not average them. Sequence them. If you claim what users experienced, trust field. If you claim why, trust lab traces.

An evidence standard that stays falsifiable

Map every claim to an artifact that would look different if the claim were false:

Claim: real users are failing        -> Search Console CWV trend at URL-group level
Claim: it is template-based          -> repeated failures across same-type URLs
Claim: LCP delayed by server/cache   -> lab traces: late doc response, delayed render start
Claim: INP failing, main-thread      -> DevTools recording: long tasks overlapping input
Claim: a release caused a regression -> timing correlation with deploy + change log

Do not trust a single Lighthouse run as proof of field improvement, desktop-only testing to explain mobile failures, or "it feels faster" as a pass condition.

Triage

Name the failing dataset in one sentence. If you cannot, gather minimum evidence first. Search Console gives field status by URL group; PageSpeed Insights gives lab diagnostics and some field context.
Confirm scope. Treat it as template-based until proven otherwise. Template scope means high-impact fixes; narrow scope points at conditional triggers.
Classify the dominant constraint: server/delivery, render path, main thread, layout stability, third-party, or change-driven.
Pick the smallest test that could prove you wrong. Field failing but lab fine means expand representativeness. LCP failing means confirm the element first. Regressed after deploy means investigate the change before optimizing.

What actually moves the field number

A faster render path for primary content, less main-thread contention, reserved space to stop layout shift, more consistent delivery so cache and routing produce less variance, and removing or conditioning third-party work. Lab scores can improve without any of that moving, if you optimized the test setup instead of the experience. Use lab to prove a bottleneck is gone, then validate with the same field evidence you began with.

Originally published at https://www.techseoexperts.com/performance-page-experience-diagnostics/core-web-vitals-diagnostics-field-vs-lab/

Architecting a Wazuh SIEM with active response: the four layers that matter

Jeremy Burgos — Tue, 16 Jun 2026 10:30:00 +0000

TL;DR: A Wazuh SIEM and XDR deployment built across four layers (manager and agents, active response, network monitoring, traffic filtering) to move an environment from reactive log review to automated detection and response. Sanitized rules and decoders are public, linked at the end.

The architecture, in the order the layers depend on each other:

Layer 1  Manager + agents      -> broad endpoint coverage, secure agent comms, central dashboard
Layer 2  Active response       -> auto-block/mitigate brute force and unauthorized access
Layer 3  Network monitoring    -> real-time log/network watch, correlation across signals
Layer 4  Traffic filtering     -> block known-bad IPs, domains, signatures; updated on intel

Before this deployment, the environment looked like most: fragmented visibility, log review that depended on someone actually doing it, and no automated response for the threats that show up constantly, brute force, unauthorized access, malicious traffic. That means you find out late and every response starts cold. The goal was not to install a platform. It was to build a monitoring and response layer that acts on its own.

Layer 1: manager, agents, and the dashboard

The foundation is the Wazuh manager with agents deployed across endpoints for broad coverage, a dashboard centralizing alerting and rule management, and secure communication between manager and agents so the monitoring data itself cannot be tampered with in transit. Get this layer wrong and everything above it is built on unreliable signal.

Layer 2: active response, and where it earns its keep

Active response rules target higher-risk behavior, brute force, unauthorized access, and are designed to block or mitigate automatically. The part that separates a useful deployment from a noisy one is the refinement: the rules get tested and tuned to stay reliable while keeping false positives down. Active response that fires on legitimate activity gets ignored within a week, which is worse than no automation at all, because now nobody trusts the alerts either.

Layer 3: network and log monitoring

Real-time monitoring of system logs and network activity watches for the patterns that matter: unusual logins, unexpected outbound connections, privilege escalations. Existing monitoring signals are integrated so the system can correlate across sources instead of treating each in isolation. Correlation is where you catch the things a single log never shows you.

Layer 4: traffic filtering

Custom filtering rules detect and block unwanted patterns, known malicious IPs, suspicious domains, harmful signatures, and they get updated as threat intelligence evolves so the deployment stays current instead of going stale. Static filtering rules are a snapshot of last quarter's threats.

What changed

The environment moved from reactive to structured. Detection improved through real-time visibility into logs, traffic, and endpoint activity. Mitigation got faster because active response shrinks the window between a threat appearing and something being done about it. Network control tightened through filtering. And it integrated without disrupting operations, which is the part that makes it sustainable rather than a one-time project that decays.

The full deployment, with a video walkthrough of the actual setup and configuration, is at https://www.jeremyburgos.com/projects/wazuh-siem-and-xdr-deployment/. Sanitized detection rules and decoders are public at https://github.com/Jeremy-Burgos/wazuh-detection-engineering.

Originally published at https://www.jeremyburgos.com/projects/wazuh-siem-and-xdr-deployment/

Architecting isolated workspaces with Kasm: hardened, egress-controlled, disposable

Jeremy Burgos — Tue, 09 Jun 2026 10:30:00 +0000

TL;DR: A hardened Kasm Workspace deployment where every research session runs in an isolated, egress-controlled, throwaway container. Four layers (server hardening, VPN egress, instances and tools, monitoring), built so sensitive workloads never weaken the host.

The architecture:

Layer 1  Server hardening   -> locked-down base, secure headers, minimal mgmt surface
Layer 2  Egress VPN         -> all instance traffic through encrypted tunnels, no raw outbound
Layer 3  Instances + tools  -> AlmaLinux / Parrot / Ubuntu, Brave, SpiderFoot, Forensic OSINT
Layer 4  Monitoring         -> logging, access controls, periodic security review

Most people do their riskiest browsing in their most valuable environment, the same browser logged into client accounts, email, and banking. This deployment exists to separate the two: a controlled environment that can handle research, OSINT, and testing without weakening the machine or network underneath it. The design had to clear four bars at once, isolation, controlled egress, multi-OS support, and monitoring, which a standard server setup does not.

Layer 1: server hardening

The server is hardened from the ground up, with secure header controls and a locked-down management interface, so the environment can be administered without exposing extra attack surface. This is the base everything else sits on.

Layer 2: egress VPN

Instance traffic is routed through encrypted VPN tunnels rather than direct, unmanaged outbound paths, with authentication and encryption tightened so access and data flows stay protected. The containers are aligned to use secure outbound routing consistently, so nothing leaks out a side door.

Layer 3: instances and tools

Multiple operating systems, AlmaLinux, Parrot OS, Ubuntu, plus cloud browsers, Brave, Firefox, Chromium, with research tools including SpiderFoot and Forensic OSINT integrated for investigative work. Each session is its own container, so the work is sandboxed and disposable.

Layer 4: monitoring and review

Stricter access controls reduce exposure, and logging plus periodic security review keep the environment stable and trustworthy over time, rather than relying on the initial configuration holding forever.

What it changes about the work

The obvious win is privacy: research traffic moves through encrypted tunnels and a closed session leaves nothing behind. The less obvious win is cleaner observation. The moment your research environment is disposable and isolated, you stop confusing your own logged-in, ad-profiled browser with a neutral instrument, and you see closer to what a fresh visitor or a crawler sees. The discipline underneath it, separate sensitive work from disposable work, treat environments as ephemeral, assume new things are untrusted, carries well beyond research.

Honest tradeoff: this is not a five-minute setup. It runs on real infrastructure (a hardened DigitalOcean server in this case) and took deliberate work across hardening, VPN, instances, and monitoring. If you do not run your own infrastructure, a clean browser profile with no extensions and no signed-in accounts, on a separate device or VM, gets you a meaningful share of the benefit for far less effort.

The full build, with a video walkthrough of the setup and configuration, is at https://www.jeremyburgos.com/projects/secure-kasm-workspace-deployment/.

Originally published at https://www.jeremyburgos.com/projects/secure-kasm-workspace-deployment/

Four HTTP security headers every WordPress site should set

Jeremy Burgos — Tue, 02 Jun 2026 10:30:00 +0000

TL;DR: Four response headers, a few minutes of work, most of the header-level security gap closed. Exact values below, plus a one-line curl to check any site.

Run this against your own site first:

curl -I -s https://yoursite.com | grep -i -E 'strict-transport|x-content|x-frame|referrer'

Whatever does not come back is your to-do list. These four headers are public on every request and contain nothing sensitive, so you can check mine, I can check yours, and neither of us has to log into anything. Here is what each one is and the value I actually run in production.

Strict-Transport-Security

strict-transport-security: max-age=31536000; includeSubDomains; preload

Tells the browser to use HTTPS for your domain, full stop, for the max-age window. Once a browser has seen it, typing http:// does nothing; the browser refuses to send the insecure request. max-age=31536000 is one year. includeSubDomains pushes the rule to every subdomain, closing the gap where an attacker targets some forgotten staging host. preload is the part people skip, and it matters: without it, the very first request before the browser has ever seen your header can still go out over HTTP, and that first request is the attack window. Preloaded domains skip it because the browser ships already knowing your domain is HTTPS-only. Submit once at hstspreload.org, it is free, and inclusion rides the Chromium release train so it takes a few weeks.

X-Content-Type-Options

x-content-type-options: nosniff

Browsers used to guess at content types when the server was vague, which is exploitable. nosniff tells the browser to trust the declared Content-Type and stop guessing. There is no other value and nothing to tune. If your production site is missing this, you can fix it before you finish this article.

X-Frame-Options

x-frame-options: SAMEORIGIN

Your clickjacking defense. It stops someone loading your real, logged-in site in an invisible iframe and floating their own buttons over it. SAMEORIGIN allows only your own pages to frame your site. DENY blocks all framing including yours, which is wrong if your WordPress setup uses internal iframes (Elementor previews, some widgets). The modern successor is CSP's frame-ancestors; run both during the transition, X-Frame-Options for older clients, CSP for the rest.

Referrer-Policy

referrer-policy: strict-origin-when-cross-origin

Controls what your site leaks about users when they click away. strict-origin-when-cross-origin sends the full URL on same-origin requests so your analytics still work, only the origin on cross-origin HTTPS so you are not leaking that someone was on /account/billing, and nothing on cross-origin HTTP. Set it explicitly so you are not at the mercy of whatever default the next browser release ships.

Verifying

The curl above is the fastest check; all four lines should come back. In a browser, DevTools, Network tab, click the document request, read Response Headers. For a letter grade, securityheaders.com scores you against a known rubric. One quirk: these four alone land a B, and you reach A only once you add Content-Security-Policy.

These four are the floor. The next layer is Permissions-Policy and CSP in report-only mode. But if you only ever do these four, you have closed most of the gap, in minutes.

Originally published at https://www.webstackdefense.com/security-headers-production-websites/