Speed Smoke Test

Smoke test vs real performance audit

Slow pages hurt conversion and feel like downtime during traffic peaks. But not every “speed test” measures the same thing. This tool runs a server-side HTTP fetch and reports TTFB and total download time for the initial response — from one location, when you click.

Free, no signup. Not Lighthouse, not WebPageTest filmstrip, not Core Web Vitals (LCP, INP, CLS). Honest labeling matters so you do not optimize the wrong metric.

Definitions

• TTFB (Time To First Byte): Wait until first byte of response body/header stream arrives — backend + network.
• Total time: Complete download of the HTML response our fetch receives — not all page assets.

Worked example 1 — deploy regression

Worked example 2 — good TTFB, bad user experience

Worked example 3 — partial outage framing

When TTFB is high — common causes

• Cold application workers or JIT warmup after scale-out.
• Expensive database queries on uncached paths.
• CDN cache miss forcing origin round trip.
• TLS handshake + geographic distance (single-region check reflects our path).
• WAF or bot management inspection latency.

When NOT to use this tool

• Frontend asset optimization audits — use Lighthouse.
• Global user experience — need RUM across regions and devices.
• Load testing — single request only.
• SPAs where HTML shell is empty — TTFB misleading vs API waterfalls.

Core Web Vitals reminder

Google’s LCP, INP, and CLS measure real user experience in Chrome — unrelated to this server fetch. Use PageSpeed Insights or RUM for SEO and conversion work; use this smoke test for origin reachability speed.

Baseline and alert on delta

Record TTFB after each deploy. Alert internally when >2× baseline for 15 minutes — degradation incident even if HTTP 200.

Deep dive: performance as revenue lever

Ecommerce studies often cite conversion drop per second of delay — use your own analytics, not industry averages, when tying TTFB to money. If 500 ms slower TTFB correlates with 2% lower conversion on checkout, multiply by session volume for a degradation cost model alongside full downtime.

Mobile networks inflate TTFB for real users vs this datacenter fetch — another reason not to equate smoke test numbers with RUM. Still useful for “did we deploy a regression?” comparisons second-over-second.

Measurement methodology (what we actually time)

Our API performs a server-side HTTP client request: DNS resolve, TCP connect, TLS handshake (for HTTPS), send request, wait for response headers (TTFB), then read the response body until complete (total time). No browser layout, no JavaScript, no parallel asset loads. That is intentional — origin server path diagnosis, not user-perceived page load.

Compare TTFB before and after CDN changes: if TTFB drops but user complaints continue, problem is likely front-end bundle size or third-party scripts — outside this tool’s scope. If both TTFB and total spike together, suspect origin saturation or database contention.

Log smoke test results in deploy tickets. A table of TTFB over last ten releases catches gradual regressions that no single threshold alert would flag.

Degradation cost linkage (methodology)

Slow is not binary down, but revenue impact can be modeled. If baseline conversion is 3.2% and a 500 ms TTFB increase correlates with 0.4 percentage-point drop (from your analytics, not industry averages), at 10,000 sessions/hour and $85 average order value: lost orders ≈ 10,000 × 0.004 × 0.032 × $85 ≈ $1,088/hour during degradation. Log smoke test TTFB in incident tickets; pair with Downtime Cost using reduced conversion input when HTTP status stays 200.

Common mistakes interpreting smoke-test speed

• Equating good TTFB with good Lighthouse score. 5 MB JavaScript bundle still kills LCP.
• Single test after cold deploy. First request includes JIT warmup — compare second run or use monitoring trends.
• Testing CDN-cached homepage only. Origin may be slow while edge is fast — add cache-bypass query param in monitoring, not always here.
• Ignoring HTTP 200 with 8s TTFB. Technically up; customers abandon — treat as incident.
• Using this for global SLA. One datacenter path ≠ user in São Paulo on 4G.
• Optimizing TTFB while database N+1 queries grow. Smoke test may not hit the slow query path.

Worked example — deploy regression quantified

Honest limits

Server-side fetch of initial HTML response only. No JavaScript execution, no subresource waterfall, no Core Web Vitals, no filmstrip, no multi-run averaging. Single geographic vantage. Use for origin-path regression detection after deploys — not product-wide performance strategy.

CDN cache effects on smoke tests

Cached responses return low TTFB from edge — good for customers, misleading for origin diagnosis. If you suspect origin regression, compare homepage (often cached) against uncached path such as dynamic account page or API-adjacent HTML route. Monitoring tools use cache-bypass headers; this smoke test reflects whatever the URL returns on default fetch — note cache status in incident notes when interpreting results.

During flash sales, TTFB may rise from origin load while CDN still serves static assets quickly. Pair this tool with error rate dashboards — latency without errors may still cap conversion when checkout API is the bottleneck, not HTML TTFB.

Building an internal TTFB baseline table

After each production deploy, record smoke test TTFB for three URLs in deploy ticket: homepage, login, checkout. Rolling 10-deploy median becomes your regression detector. Alert informally when new deploy exceeds 2× median — even at HTTP 200. Example: median 140 ms, deploy reads 410 ms → investigate before customers notice; at 890 ms → consider rollback per runbook threshold.

Partial outage vs full outage framing

HTTP 200 with TTFB 4,200 ms for 90 minutes may not trigger availability alerts but still violates user expectations. Internal severity: SEV3 degradation minimum. Estimate cost: 90 min at reduced conversion using calculator assumptions — often 15–40% of full hard-down cost depending on funnel. Document in post-mortem as latency incident, not “no incident because site was up.”

Third-party script impact (outside this tool)

Analytics, chat widgets, and ad tags load after HTML — they do not appear in TTFB or total HTML download here. If smoke test looks healthy but Lighthouse shows poor LCP, audit third-party weight separately. During incidents, temporarily disabling non-essential scripts is a valid mitigation even when origin TTFB is normal.

Synthetic monitoring graduation path

Teams often start with manual smoke tests post-deploy, then automate the same URLs every 5 minutes from one region, then add multi-region probes with alert routing. This page remains useful for ad-hoc checks from security-review laptops that cannot run CI scripts — same math, human-triggered.

Status page during slow-not-down incidents

When TTFB doubles but HTTP 200 persists, consider Status Page “degraded performance” if user impact is confirmed — honesty beats silent green. Pair with support macro linking status URL.

Related tools

Availability Checker · REST API Checker · Downtime Cost · Free Tools.