Coder Legion - Recent posts tagged performancebudget

Font Subsetting for Web Performance: 4 Tools to Reduce Font File Size and Improve LCP

Tue, 02 Jun 2026 10:47:00 +0000

In web development, every millisecond on the critical path matters. Typography is part of your visual identity, yet a single self-hosted family can add hundreds of kilobytes before the browser paints the hero line clients actually see. That cost often shows up as slower First Contentful Paint (FCP) and a worse Largest Contentful Paint (LCP) when the LCP element is a headline set in a custom face.

Font subsetting is the practical fix: ship only the characters (glyphs) each page or component needs instead of entire typefaces built for every language and symbol you will never render.

What font subsetting is

A typical desktop font file contains thousands of glyphs: Latin extended, Cyrillic, ligatures, numerals, punctuation, and symbols you may never use on a marketing site. When you @font-face that file or pull it from a CDN, the browser still has to download and parse the whole package unless you split it.

Subsetting creates a smaller font file that includes a defined subset of Unicode code points. Examples:

A display font used only on one H1 might need fewer than 40 characters.
A Latin-only blog body font does not need CJK tables on every article.
UI labels in English can omit unused weights and scripts.

The browser downloads less data, spends less time decoding, and can apply the face sooner. You keep the look; you drop the dead weight.

When font subsetting improves web font performance and LCP

Subsetting pays off fastest in these cases:

Situation	Why subsetting helps
Display or hero typography	Few unique characters, high visual impact, often on the LCP text node
Single-language sites	Remove unused scripts and diacritic ranges you do not publish
Icon or logo fonts misused as full fonts	Replace with SVG where possible; subset if you must keep a font icon set
Multiple weights loaded globally	Subset per weight, or load weights only on routes that need them

It is lower priority when you already use a system font stack for body copy and only load one small variable font with modern compression. Still measure: “small” on disk is not always small on a slow mobile connection.

Pair subsetting with loading discipline: font-display: swap or optional, preload only the file that blocks the hero, and avoid loading six weights site-wide because the brand guide lists them. Our image optimisation strategies for better LCP guide covers the image side of the same paint problem; fonts are the other half of many hero templates.

Font subsetting example: hero display copy without the full font file

Imagine a campaign landing page with one H1 in a distinctive display face: “Summer sale ends Sunday”. The full commercial font might be 180 KB of WOFF2 per weight. The string uses letters, a space, and basic punctuation: perhaps 28 glyphs.

Subsetting to those glyphs (plus a few extras you reserve for CMS edits, such as 0123456789 and -%) might produce a file under 15 KB. Same aesthetics on the title; far less work for the network and font loader on first visit.

Always keep a slightly wider subset than the literal string if editors can change copy without redeploying. A common pattern is “characters used on site” plus a safety buffer of numerals and common punctuation, or a per-locale subset file.

Four tools for font subsetting

You do not need to hand-edit binary tables for most projects. These four tools cover the usual workflows.

Google Fonts

Google Fonts hosts families with many axes and scripts. When you embed through the Google Fonts CSS API, you can limit what Google serves:

Use the text= parameter to request only the characters in a string (useful for fixed hero copy).
Choose only the weights and styles you need in the embed code generator.
Prefer display=swap (or optional where appropriate) so text stays visible while the file loads.

Self-hosting a Google Font download is also valid: download the family, subset locally, and serve WOFF2 from your own CDN for stricter cache control.

Font Squirrel Webfont Generator

Font Squirrel’s Webfont Generator is the familiar upload-and-convert workflow. Upload your source (check your licence allows web embedding), choose “Expert” mode, and define custom subsets: Unicode ranges, specific glyphs, or language presets. It outputs WOFF2/WOFF kits with a starter @font-face block.

Good for agency teams without a font toolchain in CI: one-off subsets for a client launch, then store the outputs in the repo or asset pipeline.

Everything Fonts Subsetter

Everything Fonts Subsetter accepts uploaded TTF/OTF/WOFF files and builds a reduced file from the characters you paste or select. Useful when you already know the exact glyph list from a design export or when you are trimming an existing self-hosted file after an audit.

FontForge

FontForge is desktop software for creating and editing fonts. Use it when you need precise control: merge subsets, remove tables, or build a custom subset for a product name baked into a brand face. The learning curve is steeper than a web generator, but it is the right tool when the font is yours to modify or when legal subsetting must be documented for the client.

How to implement font subsets (`@font-face`, `unicode-range`, `font-display`)

After you have a smaller file, wire it so the browser does not download the old full font by mistake.

@font-face {
  font-family: "Brand Display";
  src: url("/fonts/brand-display-hero-subset.woff2") format("woff2");
  font-weight: 700;
  font-style: normal;
  font-display: swap;
  unicode-range: U+0020-007F;
}

unicode-range tells the browser to skip downloading this file for characters outside the range. You can split one family into multiple files (Latin hero, Latin body, numerals-only) so each page loads only what it needs.

For variable fonts, subsetting is trickier but still worthwhile on high-traffic templates. Test on real devices: some older browsers handle unicode-range plus variable fonts differently than a static WOFF2 subset.

Document subsets in your client handover: which file applies to which template, and how to regenerate when marketing changes the hero string.

Reduce font file size: less data per page view

Subsetting is a technical optimisation first. Smaller font files mean less data over the wire per page view. On a site with 50 000 monthly sessions and a 150 KB font removed from the critical path, you avoid gigabytes of transfer over a year without changing the design.

That matters for:

Mobile users on metered or weak connections
CDN and origin egress costs at scale
Battery and CPU spent decoding fonts that never render

We avoid treating that as vague “eco” marketing. The measurable claim is simpler: you sent fewer bytes for the same page. If sustainability reporting matters to your client, subsetting is one line item next to image compression and script audits.

How to verify LCP and FCP after font subsetting

Subsetting is not done when the file size looks smaller in Finder. Verify in the browser and in your monitoring rhythm.

Network panel: Confirm the subset WOFF2 is requested (not the legacy full file). Check transfer size and that the request sits early enough for the hero.
PageSpeed Insights or Lighthouse: Compare FCP and LCP before and after on the same URL and throttling profile. Lab scores move for many reasons; keep one change per deploy when you are proving cause.
Filmstrip or trace: Ensure the hero text does not flash invisible for long periods. If font-display: swap causes a large layout shift when the custom face arrives, fix CLS separately (reserved space, fallback metrics).
Production monitoring: If you run automated PageSpeed monitoring, add the template to a performance budget so a future CMS or plugin change does not reintroduce the full font on every page.

Agencies maintaining many sites benefit from the same loop as images: fix the asset, prove it in lab, then watch scheduled tests so the regression does not return quietly on the next theme update.

Pick one high-traffic URL where the LCP node is text in a custom font. List the characters that can appear in that block (or export copy from the CMS). Generate a subset with Font Squirrel or Everything Fonts, deploy with font-display: swap, and re-run PSI. If LCP improves, roll the same pattern to other display templates and document the glyph list for the client.

Common font subsetting mistakes

Subsetting too aggressively so editors cannot type an em dash or an accented character without tofu squares.
Loading both subset and full font because an old enqueue line was left in WordPress or the tag manager.
Subsetting body fonts but still loading five weights on pages that use one weight.
Ignoring licensing; not every foundry permits subsetting or self-hosting. Read the EULA before Font Squirrel or FontForge exports go to production.
Skipping fallbacks; use a similar system stack in font-family so text stays readable if the subset fails to load.

Typography should not be the reason a fast layout scores poorly on paint metrics. Subsetting keeps the brand face while respecting the budget the network actually has.

Create a free account to track LCP and FCP across client sites with scheduled PageSpeed tests and performance budgets.

FAQ

Does font subsetting affect SEO?

Not directly. Search engines care about experience signals and crawlability. Faster paint and stable layout support the page experience story; subsetting is one input, not a ranking lever on its own.

Can I subset Google Fonts without self-hosting?

Yes, partially. The CSS API text= and family/axis parameters reduce what Google sends. For maximum control and caching, download and self-host a subset you generated.

Will subsetting break translations?

It can if you subset for English only and later add a Greek or Japanese locale. Plan per-locale subset files or a wider subset for multilingual templates.

WOFF2 only, or still ship WOFF?

For modern browsers in 2026, WOFF2 alone is usually enough. Keep WOFF only if you must support legacy clients named in the client’s browser support policy.

How does subsetting compare to using a system font stack?

System fonts add zero webfont bytes. Subsetting is the middle path when brand guidelines require a custom face but you refuse to ship an entire foundry file on every route.

Should I subset icon fonts?

Prefer SVG icons. If you remain on an icon font, subset to the icons in use or migrate to inline SVG to remove font decoding from the critical path entirely.

Specd : Five Features. Full Stop.

Fri, 01 May 2026 12:20:31 +0000

Most teams do not need another PRD template. They need a hard stop. Vague scope does not become expensive because nobody wrote documentation. It becomes expensive because nobody is willing to say what will not be built.

Scope creep rarely announces itself as scope creep. It shows up as a reasonable sentence.

"Can we also add invites?" "Should we include analytics?" "What about an admin dashboard?" "If we are already building this, we might as well add billing, export, and notifications."

None of those ideas are obviously wrong. That is why they are dangerous. Bad ideas are easy to reject. Good-but-not-now ideas are what turn a clear V1 into a slow, expensive project that never reaches the market.

The buyer does not want a PRD generator

A product manager with stakeholder pressure is not waking up thinking, "I need a document generator." An agency owner watching a fixed-fee project expand is not looking for prettier requirements. A technical lead staring at a vague handoff is not asking for more words.

They want the bleeding to stop.

They want the request turned into a boundary. They want a defensible answer to "why is this not in V1?" They want engineering to build from a decision, not from a conversation that can be renegotiated every week.

V1 gets five features. Everything else is a future decision.

Five is not magic. Five is useful because it forces tradeoffs early,
while the cost of changing your mind is still measured in minutes
instead of engineering weeks.

A five-feature cap changes the planning conversation. Without a cap, the team asks, "What else should this product do?" With a cap, the team asks, "What are the five things this product must do to prove the business case?"

Why five features works

That second question is harder. It is also the question that protects budget.

Five features is enough to define a real workflow. It is not enough to hide indecision inside a backlog. That tension is the point. If a feature cannot survive the top-five cut, it probably does not belong in the first build.

The goal is not to make the product smaller forever. The goal is to make V1 clear enough to ship, measure, and learn from before the roadmap eats the project.

Performance Monitoring for EdTech: What to Measure Across Enrolment, Learning, and Checkout

Tue, 28 Apr 2026 20:08:46 +0000

EdTech teams often inherit a monitoring setup built for generic SaaS dashboards, not learning workflows. That mismatch causes two problems: you miss issues that hurt students, and you spend hours chasing alerts that do not affect outcomes.

In education products, performance has to serve three groups at once: learners, educators, and administrators. Each group uses different pages, on different devices, at different times. A home page score can look healthy while quiz submission pages fail on school networks. A checkout flow can be fast while live-class pages feel sticky when students open chat and polls.

This post breaks performance monitoring for EdTech into practical parts: what to measure, where to measure it, and how to build an alerting policy that helps your team act quickly.

If you are new to the metrics themselves, start with What Are Core Web Vitals? A Practical Guide for 2026 and LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It. This guide assumes you know the basics and want an EdTech-specific operating model.

Why EdTech needs a different monitoring approach

Most EdTech products mix content, interaction, media, and transactions in one platform. That creates a wider performance surface than many B2B apps.

Typical patterns include:

Public marketing pages for course discovery and trust building.
Logged-in learner dashboards with heavy personalisation.
Interactive lesson pages with video, chat, quizzes, and progress tracking.
Assignment upload and grading workflows with file processing.
Payment and enrolment flows for courses, subscriptions, or certifications.

Each area has different failure modes. Slow image loading on a brochure page is not the same issue as delayed quiz feedback in a timed assessment. If you treat both as one blended score, you lose the signal that helps prioritisation.

EdTech also has sharp traffic peaks around class start times, assignment deadlines, and exam periods. These predictable surges stress front-end rendering, backend APIs, and third-party services at the same time. Monitoring has to reflect those windows instead of daily averages only.

Map metrics to the learner journey

A useful EdTech monitoring plan starts with journey stages, not tools.

1) Discovery and enrolment

This stage includes landing pages, course catalogues, search/filter pages, course detail pages, and signup or checkout.

Speed here is not a cosmetic KPI. In the Google-commissioned Deloitte and 55 study, a 0.1 second performance improvement across key speed metrics was linked to stronger funnel progression and conversion outcomes across large consumer journeys (web.dev summary). EdTech funnels differ from retail, but the operational lesson is the same: small delays at step transitions compound into measurable business loss.

What usually matters most:

LCP on landing, catalogue, and course detail pages.
INP for search filters, date pickers, and plan selection.
CLS in pricing sections, promo banners, and checkout forms.
Conversion step timing for account creation and payment completion.

If course imagery and promo embeds are heavy, LCP often degrades first. If payment pages load multiple scripts, INP and CLS often degrade during form interaction.

2) First learning session

The first minutes after signup decide activation for many education products.

Key surfaces:

Onboarding checklist.
First lesson page.
Video player load and first playable frame.
First quiz or exercise interaction.

Useful signals:

Time to first meaningful lesson interaction.
INP on first quiz answer and submit actions.
Error rate for lesson-content API calls.
Video startup delay and buffering events.

This stage is where technical performance and product activation overlap directly.

3) Ongoing study and assessment

Returning learners use calendar views, progress dashboards, lesson modules, discussion threads, and assignment forms.

Watch for:

INP on high-frequency actions (next lesson, mark complete, submit answer).
API latency percentiles for progress save and assessment endpoints.
Front-end error rates tied to specific lesson templates.
Long-task frequency during interactive sessions.

A page can load fast and still feel broken if each click takes 400-600ms to respond. INP and interaction-level traces reveal this faster than load metrics alone.

4) Educator and admin workflows

In many EdTech products, instructors and admins perform heavy actions:

Uploading content packs.
Bulk enrolment.
Grade export.
Attendance sync.
Reporting dashboard filters.

These screens are operationally critical. If they slow down, support tickets rise and delivery teams lose trust in the platform. Include role-based dashboards and admin actions in your monitoring scope, even if public pages are the top SEO focus.

Core metrics for EdTech teams

Core Web Vitals remain the baseline, but EdTech needs a wider set around interactions and reliability.

Core Web Vitals

LCP: loading quality for first content and lesson entry points.
INP: responsiveness for quiz, navigation, discussion, and form actions.
CLS: visual stability for pages with embeds, dynamic modules, and notices.

Use separate thresholds by template. A marketing home page and a lesson player page should not share one budget by default.

Supporting technical metrics

API latency at p50, p95, and p99 for key learning actions.
Front-end JavaScript error rate by route.
Failed requests by endpoint group (content, progress, auth, payment).
Video startup time and rebuffer ratio where video is core.
Queue or processing time for assignment upload and grading jobs.

This set helps connect front-end symptoms to backend causes.

Outcome-linked product metrics

Pair technical monitoring with product outcomes:

Signup completion rate.
First lesson started rate.
Lesson completion rate.
Quiz submission success rate.
Payment completion rate.
Support tickets tagged with speed or loading issues.

When these are tracked side by side, performance work is easier to prioritise in roadmap discussions.

Device and network realities in education

EdTech audiences are often more mixed than other SaaS categories:

Students on older phones.
Shared household devices.
School-managed laptops with strict browser policies.
Variable Wi-Fi and mobile data conditions.

This is why desktop-only checks can create false confidence. Run both mobile and desktop, and set your default review lens to mobile where student traffic is high. Our guide on Mobile vs Desktop Core Web Vitals Monitoring: Why You Need Both covers this pattern in detail.

Global access data also supports this approach. UNESCO's GEM report notes that connectivity and device access remain uneven across education systems, and during pandemic-era remote learning at least 500 million students were not reached by remote provision (GEM 2023). If your monitoring assumes modern devices and stable broadband, you can miss the exact populations most likely to struggle.

In addition, test representative geographies if your platform serves multiple regions. International cohorts can face latency patterns that a single-region test misses.

Synthetic monitoring, field data, and in-app telemetry

For EdTech operations, each source answers a different question:

Synthetic tests: "Did this route regress after deploy?"
Field data: "What are learners and educators actually experiencing?"
In-app telemetry: "Which user action failed, and at which step?"

Synthetic monitoring gives repeatability across your key URLs and user journeys. It is excellent for regressions, budget checks, and release confidence.

Field data (for example via CrUX where coverage exists) adds real-user outcomes but can be delayed and sparse on low-traffic routes.

In-app telemetry gives event-level visibility for core actions like submit quiz, upload assignment, or complete checkout.

The strongest setup combines all three:

Scheduled synthetic checks for route coverage and trend history.
Field signals for user reality and long-term quality.
Product instrumentation for action-level failures and drop-offs.

Alerting policy that avoids fatigue

A common EdTech issue is alert fatigue during release weeks. Teams receive many warnings and ignore most of them.

Use a tiered policy:

Tier 1: learner-critical alerts (immediate)

Trigger immediately for:

Large INP regression on lesson or quiz pages.
Elevated error rate on progress save or submission endpoints.
Checkout failures above baseline.
Major LCP degradation on login and first lesson routes.

These alerts should page the owning team during core operating hours.

Tier 2: quality drift alerts (daily review)

Trigger for:

Smaller but persistent LCP or CLS drift.
Elevated third-party script cost on discovery pages.
Slow admin report routes outside incident thresholds.

Route these to a daily triage queue rather than instant paging.

Tier 3: planning signals (weekly)

Track trends like:

Device class degradation over time.
Seasonal spikes around exam windows.
Performance budget breaches by template over 2-4 weeks.

Use these for sprint planning and technical debt prioritisation.

Cooldowns and deduplication matter as much as thresholds. One incident should not create twenty notifications across channels.

Third-party dependencies in learning platforms

EdTech products often depend on many external services:

Analytics and product analytics.
Video and interactive media.
Classroom engagement widgets.
Proctoring or identity checks.
Payment processors.
Support chat.

Each script can add latency or thread blocking. During audits, measure not only total page load but script-level contribution on critical routes.

A practical process:

Inventory third-party scripts by route group.
Run before/after synthetic tests when adding a vendor.
Set per-route budgets for third-party weight and request count.
Review quarterly and remove low-value scripts.

For many teams, this single discipline creates immediate gains on learning and checkout pages.

A practical 30-day rollout plan

If your current setup is ad hoc, use a phased rollout:

Week 1: define route groups and success metrics

List your top learner, educator, and admin routes.
Tag routes by journey stage (discovery, first session, ongoing study, admin).
Agree on critical outcomes to protect (activation, completion, checkout).

This route-first discipline prevents "dashboard theatre". The same UNESCO GEM evidence base reports substantial underuse of paid education software licences in practice, including US data showing high non-use rates across procured tools (GEM 2023 chapter). Monitoring tied to real, high-frequency workflows protects you from buying observability that teams rarely use when it matters.

Week 2: instrument baseline monitoring

Configure scheduled synthetic tests for each route group.
Record baseline LCP, INP, CLS, error rate, and API latency.
Confirm dashboards are segmented by role and device.

Week 3: add alert tiers and ownership

Define Tier 1/2/3 thresholds.
Assign route owners and on-call expectations.
Configure cooldowns to reduce noise.

Week 4: connect performance to product review

Add a weekly performance review to product and engineering rituals.
Include outcome metrics in the same dashboard or report.
Prioritise top regressions by learner impact and business effect.

This plan is small enough to run without a full platform overhaul.

Where Apogee Watcher fits for EdTech teams

Apogee Watcher helps teams monitor multiple routes and sites on a schedule, with historical trends and threshold alerts. That is useful when you manage several programme sites, white-label properties, or many route templates across one learning platform.

For teams supporting education clients, it also reduces manual reporting overhead. Instead of collecting one-off snapshots, you get trend visibility and a repeatable view of route health.

If you are currently in a manual workflow, compare your existing process with Automated vs Manual PageSpeed Testing: A Time and Cost Comparison. For setup guidance, use How to Set Up Automated PageSpeed Monitoring for Multiple Sites.

FAQ

What should EdTech teams monitor first?

Start with a small set of learner-critical routes: login, first lesson, one quiz page, and checkout or enrolment. Track LCP, INP, CLS, error rate, and API latency for those routes before expanding coverage.

Is Core Web Vitals enough for education products?

Core Web Vitals are necessary but not sufficient. Add interaction and reliability metrics such as request failures, endpoint latency, and action success rates for submissions and payments.

How often should we run synthetic tests?

For learner-critical routes, daily is a practical default. During high-risk periods such as launch week or exam season, increase frequency on key pages. For lower-risk admin pages, weekly can be enough.

How do we avoid alert fatigue?

Use tiered thresholds, cooldown windows, and clear ownership. Page only on learner-critical incidents. Move smaller drifts into daily or weekly review workflows.

Can agencies use the same framework for multiple education clients?

Yes. Keep a shared monitoring blueprint, then customise route lists and thresholds per client. Standard process with client-specific budgets is usually easier to scale than fully custom monitoring from scratch.

Summary

Performance monitoring for EdTech works best when it mirrors real learning journeys, not generic page groups. Monitor discovery, first session, ongoing study, and admin operations as separate surfaces. Pair Core Web Vitals with interaction and reliability signals, then connect those signals to activation, completion, and checkout outcomes.

Teams that do this well usually share three habits: route-based budgets, tiered alerting, and weekly review tied to product decisions. Start small, make ownership clear, and expand once your team trusts the signal.

Monthly Performance Review Template for Agency Teams

Tue, 28 Apr 2026 11:32:25 +0000

Most agency teams do not struggle with data. They struggle with rhythm.

You already have scores, alerts, and test history. The friction starts when the month ends and you need to answer four questions quickly:

What improved?
What regressed?
What matters for the client right now?
Who is doing what next?

This template gives you a repeatable monthly review in 30-45 minutes per client—built for multi-site teams where consistency beats perfect slides.

If you need setup guidance before review cadence, use How to Set Up Automated PageSpeed Monitoring for Multiple Sites. If you need a client-facing deliverable, pair this with Client-Ready Core Web Vitals Report Outline.

What we mean by a monthly performance review

Many “monthly performance review” templates are built for HR one-to-ones. This one is for website performance: Core Web Vitals, regressions, and the work your team ships—so clients who pay for speed and stability get a steady rhythm instead of one-off updates when something breaks.

You need: a clear agenda, a small set of metrics you can defend, copy that works in a client email, and three actions with owners—not “we will keep an eye on it”. The script below is that meeting. Run it internally first; the next section covers the client conversation.

Use this template as a meeting script

The structure below works as:

an internal monthly review meeting
a client-facing performance call
a handover note between technical and account teams

Copy this into your docs tool and reuse it every month.

// Monthly Performance Review — [CLIENT / SITE]
// Period: [YYYY-MM]
// Meeting date: [DATE]
// Owner: [NAME]
// Participants: [NAMES]

1) Snapshot
- Overall status: [Healthy / Needs attention / Critical]
- Portfolio summary:
  - Sites monitored: [N]
  - Pages monitored: [N]
  - Tests run this month: [N]
  - Alerts triggered: [N]
  - Alerts resolved: [N]

2) Metric trend review (mobile + desktop)
- LCP: [value] (last month: [value], delta: [value])
- INP: [value] (last month: [value], delta: [value])
- CLS: [value] (last month: [value], delta: [value])
- Performance score: [value] (last month: [value], delta: [value])
- Comment: [What changed and why]

3) Biggest wins this month
- Win #1: [change made] -> [metric impact] -> [business impact]
- Win #2: [change made] -> [metric impact] -> [business impact]

4) Regressions and risks
- Regression #1: [page / template]
  - Detected: [date]
  - Suspected cause: [release, script, image, third-party, etc.]
  - Current impact: [SEO / UX / conversion]
  - Severity: [High / Medium / Low]
- Regression #2: [...]

5) Top 3 actions for next month
- Action 1: [task]
  - Owner: [name]
  - Due: [date]
  - Success metric: [target]
- Action 2: [...]
- Action 3: [...]

6) Decisions and dependencies
- Client decisions needed: [yes/no + details]
- Cross-team dependencies: [dev, content, design, hosting]
- Blockers: [list]

7) Client communication summary
- What we will tell the client this month (3 bullets max)
- Confidence level: [High / Medium / Low]
- Escalation needed: [yes/no]

Internal review first, then the client

Do not skip the internal pass. Half-explained metrics on a client call usually mean the team argues about interpretation in front of them—or nobody agreed what “green” meant before you dialled in.

Run sections 1–6 with tech plus account or delivery (15–20 minutes). Align on severity, strip noise, agree what you can say externally. Then use section 7 plus one executive line for the client call or email (20–30 minutes; account-only is fine for low-touch clients). Clients rarely need every alert ID—they need proof you are in control and a clear ask when their content, scripts, or hosting blocks progress.

On maintenance and monitoring retainers, this meeting is often the clearest proof of value. Still complete section 3 (wins). Stability after a heavy release month is a win worth naming.

Why this format works for agencies

It forces one pass from raw metrics to accountable actions.

Many reviews fail because teams stay in reporting mode: charts and discussion, then no owner. This template keeps one output in view: actions with names and deadlines. Keep budget targets visible in the room. If thresholds are still loose, set them with Performance Budget Thresholds Template before the next cycle.

A practical scoring model for monthly status

Use a simple status system so everyone speaks the same language:

Healthy: no high-severity regressions open; core templates stay within agreed thresholds
Needs attention: one or more key templates out of threshold, but impact is contained
Critical: high-impact regressions on revenue or lead pages, unresolved for multiple runs

Keep the labels simple. The goal is faster decisions, not a perfect classification scheme.

What to prepare before the meeting

Keep prep under 20 minutes per client:

Pull this month versus last month metric deltas
Export or copy the top alert events and resolution notes
Select the 2-3 most important pages (homepage, pricing, lead form, key product template)
Draft the three client-facing bullets in advance

Technical lead: confirm URLs, mobile and desktop, and budgets still match what you monitor. One line of suspected cause per regression; realistic effort for the top three actions.

Account or delivery lead: what the client already saw in tickets or Slack; promises in writing; whether section 7 reads like a service update, not a post-mortem.

If prep runs long, use the same export, comparison window, and three priority URLs every month.

After the meeting: outputs that close the loop

Tasks — three actions with owner and due date in your PM tool, not only in notes.
Client touchpoint — short email with section 7 bullets plus a dashboard or PDF link, or a call with the same content; depth should match the contract.
Threshold sanity — if the same template stays “Needs attention”, fix the budget, fix the page, or reset expectations in writing.

Optional: one line in your internal monthly business review—“Performance: [status] — top risk: [X]”—so web performance stays visible next to SEO and content.

Common mistakes this template avoids

1) Mixing diagnosis with decision-making

You can spend an hour debating why a metric moved and still leave without a plan. Keep root-cause deep dives separate when needed. The monthly review should end with owned actions.

2) Reporting averages only

Averaged scores hide broken high-value pages. Always include at least one section on key templates and business-critical URLs.

3) No link between performance and client impact

Clients do not buy "better Lighthouse numbers". They buy risk reduction, stability, and fewer surprises. Translate each major change into likely impact on user experience and search visibility.

4) Too many priorities

If every item is urgent, nothing is urgent. Keep the next-month action list to three items max.

Suggested monthly cadence

Week 1: run the review and lock actions. Weeks 2–3: ship fixes. Week 4: verify and draft next month’s notes. Busy sites can add weekly tactical checks; still hold one monthly reset.

If you are still deciding what to monitor, start with Core Web Vitals Monitoring Checklist for Agencies. If the same pages fail every month, read The Complete Guide to Performance Budgets for Web Teams and reset thresholds.

FAQ

How long should a monthly performance review meeting take?
30-45 minutes per client is enough if prep is done and the agenda is fixed. Longer meetings usually mean unclear ownership or too much ad-hoc debugging inside the call.

Who should attend from the agency side?
At minimum: one technical owner and one account owner. Technical owners explain causes and options; account owners align recommendations with client priorities and communication.

Is this the same as an HR performance review template?
No. This article is for website performance and delivery reviews with clients or internal delivery teams. It does not cover employee appraisals or performance improvement plans.

Should we include every monitored page in the review?
No. Review trends portfolio-wide, then focus discussion on business-critical templates and the highest-impact regressions.

What if nothing significant changed this month?
That is still a useful outcome. Record stability, confirm thresholds are still appropriate, and document one preventive action for next month.

How is this different from a client report template?
This template is for decision meetings. A client report is a polished output for stakeholders. Use this review first, then summarise outcomes in a client-ready report format.

What should I put in the calendar invite?
Title: “Monthly web performance review — [Client] — [Month YYYY]”. Body: link to the dashboard or report, four-bullet agenda (snapshot, trends, regressions, three actions), attendees.

Can we run this monthly review for a single site?
Yes—set section 1 counts to one site; the rest of the script stays the same.

Same agenda every month and every action owned—that is how monitoring reads as a service. Sign up for scheduled PageSpeed checks with less manual prep.

Third-Party Scripts and Performance: How to Identify and Fix the Worst Offenders

Mon, 27 Apr 2026 09:12:45 +0000

Most “performance projects” start with images and fonts. Fair enough. But the pages that still feel bad after a hero image is optimised, preloaded, and served from a CDN are often suffering from a different problem: third-party JavaScript. Tag managers, chat widgets, A/B tests, and social embeds do not have to be evil. Left unmanaged, they absolutely compete with your first paint, your LCP, and the interactions that INP measures. This guide is a practical way to name the worst offenders, decide what to cut or delay, and prove the win before the marketing team files a ticket because “the numbers look wrong”.

What “third party” really means in performance work

A third-party script is any JavaScript, iframe, or stylesheet you did not write that loads from another origin: analytics, ads, reviews, personalisation, consent platforms, and the tag manager that wires them together. Browsers do not care whether a script is “small business friendly”. They still parse it, sometimes execute it in the hot path, and every long task on the main thread delays input handling and the next paint.

Core Web Vitals are the clearest public scorecard, but the mechanism underneath is the same in smaller shops and enterprise:

LCP can move if a late-loading script or font pushes your hero, or if third-party work delays rendering.
INP gets worse when the main thread is busy; third-party long tasks and heavy event listeners sit in front of your own code.
Total Blocking Time (TBT) in lab tools like Lighthouse measures main-thread blocking after First Contentful Paint; it often correlates with poor INP in the field, but TBT is not a substitute for INP: it can miss slow interactions that happen after load (where a lot of third-party widgets do their work).

So the job is not “remove all third parties”. The job is to order them, time them, and measure so you are not optimising in the dark.

Step 1: Get a defensible list of what actually loads

You cannot fix what you cannot see. Start with a cold, hard inventory:

View source and search for and src=.** Note every external host. Do the same for link rel="preconnect" and import() chains if you use a modern bundler.
Open DevTools, Network, disable cache, hard reload. Sort by “Initiator” or group by “Domain” so you see which product pulled in which chain. A single GTM or Segment container often fans out to twenty requests.
Use your tag manager’s preview mode to log which tags fire on which page templates. A homepage does not have to carry the same load as a logged-in account area, but in practice one container often rules them all until someone audits it.

Read the Initiator column and the waterfall to see which script pulled in which chain. Use Group by options in the table header if you want rows collapsed by Domain (wording varies by Chrome version).

For clients, this inventory belongs in the same place as your design system: a short internal doc, not a one-off email. When a new pixel appears, you can ask “which tag added this?” and roll back a single change instead of re-running a mystery hunt every quarter.

Step 2: Use Lighthouse to rank third-party cost (not just bytes)

Lighthouse in Chrome (or the PageSpeed Insights “Diagnose performance issues” section) surfaces third-party impact in a dedicated audit (title: Reduce the impact of third-party code). It lists transfer size, CPU time, and main-thread blocking time by origin. Under the documented rules, Lighthouse fails this check when third-party code blocks the main thread for more than 250ms in total during the load it measures. Treat that as a first “who is expensive?” table before you dig into traces.

Depending on Lighthouse version, you may see the same idea under newer Performance insights (for example third-party coverage in Lighthouse 13’s insight model); the underlying job is unchanged: quantify cost per provider.

Pair it with:

“Reduce JavaScript execution time”, “Reduce the impact of third-party code” (above), and “Minimize main-thread work” where those audits appear (Lighthouse UI uses US spelling). The exact labels move between releases; the intent does not: find scripts that add long tasks and network overhead. For a walkthrough, see Identify slow third-party JavaScript.
A lab run on the slowest realistic conditions (mobile, throttled) so the ranking matches how your users experience the page, not a developer laptop on Wi-Fi.

The same audit appears in PageSpeed Insights under performance diagnostics; use it as your first sorted table of “who costs what” before DevTools deep dives.

Lab data is not field data, but for third-party work it is often more actionable: you can block a host in DevTools, reload, and see the same page without the tag.

Step 3: Use DevTools to find the moment a script hurts

Lighthouse points at winners and losers. DevTools shows when they run:

Performance panel: record a page load, then look for long yellow blocks (Scripting) and the Main flame chart. The Long Tasks API uses a 50ms threshold for a “long task”; tasks longer than that contribute to how “busy” the main thread feels. Heavy ads or frameworks often show 50–200ms+ slices.
Bottom-up / Call tree on the same recording, filtered by a third-party domain, tells you if time is in parse, compile, or your own app code after a third party schedules work.
Coverage tab: load a page, then record which portions of a third-party file actually run. A 400KB file that was fully downloaded but only 5% “used” is a candidate for lazy loading or removal, not a pat on the back for gzip.

Record a load (and, for INP, a real click or menu open). Long Scripting slices on the main thread are what make interactions feel delayed.

Coverage answers “did we even execute this?” High unused percentage means you may be shipping JS you never needed on that route.

If you are chasing INP, repeat the recording with a real interaction: open the menu, add to cart, open chat. The worst third-party work often appears after first load, when the widget initialises on scroll or on first click.

Step 4: Map findings to CWV and business impact

Not every big script is worth a fight. Sort candidates like this:

Question	If “yes”
Does it sit on the critical path before first meaningful paint?	Push it later or to a worker pattern (see below).
Does it add long main-thread work during typical interactions?	It is a prime INP target.
Is it on every page but only used on checkout?	Load it on checkout routes only.
Is it duplicated (same vendor, two tags)?	Merge at the source; duplicate pixels are a classic agency waste.
Does the marketing team need it for attribution this quarter?	Optimise the delivery first; removal is a product decision, not a dev-only one.

In multi-site and agency work, the same “standard” GTM install often ships to every property. A template fix in the container is cheaper than renegotiating a vendor contract, so fix the shared layer before you re-architect a single site.

Step 5: Fix patterns that work in production

Defer what you can. Non-critical script tags should not sit synchronously in . Your framework or CMS may be injecting them; override at the template level where possible. For scripts you truly need early, you are trading against LCP: keep the list as short as your analytics owner allows.

Load on interaction, not on paint. Chat widgets, non-critical A/B tools, and “nice to have” personalisation can wait until scroll, a tab click, or a 2–3 second idle timeout. requestIdleCallback is not supported everywhere, but a small setTimeout after load is still a step up from “block first paint”.

Facade heavy embeds where it makes sense for your content. A static placeholder that loads the real YouTube, map, or social widget on click (or on entering the viewport) cuts initial JavaScript and often improves LCP on content-heavy pages. See Efficiently load third-party JavaScript and implement facades in a way that does not break keyboard users or your consent flow.

Move work off the main thread for eligible scripts. Partytown and similar patterns run particular scripts in a web worker. They are not a free lunch (serialisation, compatibility), but for analytics and support scripts that can cooperate, they reduce main-thread contention. Fit them into your performance budget as an experiment, not a silent default, until you have tested INP and edge cases.

Server-side and edge tagging. If your use case is “send a conversion to ad platforms”, a server GTM on Cloud Run, or API-based server events, can remove a client tag entirely. The implementation cost is higher; the client-side win is real on interaction-heavy pages.

Govern the tag manager. One owner, naming conventions, a rule that new tags do not go live in “All Pages” without review, and a quarterly cull of unused tags will save more CPU than another round of webpack tweaks.

Step 6: Prove the change and set a floor so it sticks

Re-run the same Lighthouse and DevTools profile after the change. Keep a one-page before/after note: third-party main-thread ms, LCP, INP (if you have field data in Search Console’s Core Web Vitals report or RUM), and a screenshot of the GTM version number. If someone re-imports a container without your fixes, you have an audit trail.

For portfolios, that proof is the difference between “we sped you up” and “we keep you fast when the next tag ships”. Tying the numbers to a monitoring or budget alert means a regression is an email, not a surprise in a QBR. Apogee Watcher is built for that loop: schedule PageSpeed runs, set budgets per site or template, and get alerts when lab metrics drift. We do not replace your tag manager; we give you a steady signal that the work you just shipped (or the tag someone added at 5 p.m. Friday) is still within the thresholds you and the client agreed.

If you are still building a governance story for your team, the Core Web Vitals monitoring checklist for agencies is a good companion: it includes a third-party pass as part of ongoing ops, not a one-off launch audit.

FAQ

Are third-party scripts the main cause of bad Core Web Vitals?

Not always, but they are a common cause of high INP and TBT, and they keep turning up in audits for LCP and CLS when they shift layout or delay rendering. TBT in the lab and INP in the field are related but not the same (post-load interactions matter for INP). Your own images and font strategy still matter. Treat third parties as a parallel track you measure with the same rigour as first-party code.

Should I use only field data to prioritise?

Field data (CrUX, RUM) tells you who suffers in the real world. Lab data and DevTools help you attribute that pain to a specific script before you change contracts or tags. Use both. For more on the split, read PageSpeed Insights vs automated monitoring: when manual checks are not enough and Understanding INP: the newest Core Web Vital.

What is the fastest win?

In our experience, the fastest win is cutting duplicate tags and loading chat and secondary widgets after load or on interaction, before you touch your core bundle. The slowest is migrating to full server-side tagging, which pays off for large programmes but is not a Friday afternoon change.

Will delaying analytics break reporting?

It can change “session” definitions if you delay too aggressively or if your vendor counts page views before a delayed tag fires. Align with whoever owns the data model. Often you can still send one lightweight pageview early and load heavier remarketing and enrichment after idle.

How do I explain this to a non-technical stakeholder?

Framed the right way, it is a cost conversation: every script has a time cost on the user’s device. The table from Lighthouse, plus one before/after number for LCP or INP, is usually enough to get approval for a staged rollout.

Image Optimisation Strategies for Better LCP Scores

Sat, 25 Apr 2026 06:55:16 +0000

On many marketing and product pages, Largest Contentful Paint (LCP) is not abstract. It is a hero photograph, a product shot, or a full-width banner. The metric tracks when that largest visible element finishes rendering; if the element is an image, your optimisation work is mostly bytes, dimensions, and discovery order—not another round of “general speed tips”.

This guide assumes you already know what LCP measures. If you need the full picture first, read What Are Core Web Vitals? A Practical Guide for 2026 and LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It. Here we go deep on image-specific strategies that move LCP toward the “good” band (≤ 2.5 seconds in the field), and how to pair them with performance budgets so improvements stick.

Start by identifying the real LCP element

You cannot optimise “the page” in the abstract. LCP is tied to one element in the viewport. In PageSpeed Insights or Lighthouse, open the diagnostics and note which node is reported as LCP—often an , sometimes a text block or a background.

If the tool points at an image:

Confirm the URL you are actually serving (CDN vs origin, srcset winner, and any CMS transforms).
Check the file size after compression. A 2.5 MB hero on a 360 px wide phone viewport is a sizing problem first, not a format problem.
Trace load order: is something else blocking discovery (late CSS, client-rendered markup, or a lazy attribute on the hero)?

Skipping this step is how teams ship a perfect WebP pipeline and still fail LCP because the LCP element was a different image—or text—than they assumed.

Pick modern formats and tune quality deliberately

AVIF usually beats WebP on file size at comparable visual quality; WebP still beats most JPEG for photos. The practical approach for 2026:

Serve AVIF with WebP or JPEG fallbacks using or rely on your CDN’s automatic format negotiation if you trust its tests.
Avoid shipping a single giant JPEG “because it works everywhere” unless you have measured that the conversion pipeline genuinely cannot run yet.
For illustrations with flat colour, SVG or optimised PNG can win; for large photographic heroes, raster formats dominate.

Quality settings are not universal. A quality of 75 in one encoder is not the same as 75 in another. Pick a default (for example AVIF at a sensible quantiser, WebP at 75–80), then visually compare at real display widths. Automated tools help, but a human glance at banding on skies and skin tones still catches regressions.

When you change format, re-measure LCP on the same URL. Lab scores can move for reasons unrelated to user-perceived quality, so keep before/after filmstrips or screenshots for stakeholders.

Match dimensions to rendered size, not to the asset library

LCP often fails because the browser decodes a 4000 px image into a 400 px slot. Responsive design does not mean “one huge master file for all breakpoints”.

Export or generate variants at the maximum CSS width they will occupy, per breakpoint, with a small margin for DPR (device pixel ratio). A 2× retina asset should be roughly 2× the CSS pixels, not 5× “for safety”.
Strip metadata you do not need; it is wasted bytes on every request.
If your CMS offers “automatic resizing”, verify the actual output dimensions in Network, not the checkbox in the admin UI.

If you only do one thing after reading this section: open DevTools → Network, click the LCP image, and compare Intrinsic size (natural width/height) to Rendered size. If the intrinsic side is many times larger than rendered, fix that before touching anything else.

Use `srcset` and `sizes` so the browser picks a sane file

Giving the browser a range of widths beats a single src for almost all content images.

srcset lists candidate widths or descriptors (480w, 800w, …).
sizes tells the browser how wide the image will be in the layout at different viewport widths, so it can pick the right candidate before downloading the wrong one.

Common mistakes:

sizes="100vw" on an image that is only half the layout width—so the browser pulls an unnecessarily large file.
Omitting sizes when using w descriptors, which can lead to poor selections.
Using loading="lazy" on an image that is above the fold and is your LCP element. The browser may defer work you needed immediately.

For a full-width hero, sizes="100vw" is often correct. For a card grid, describe the column width at each breakpoint. MDN’s documentation on responsive images is worth bookmarking for copy-paste patterns you can adapt.

Loading order: preload, priority, and lazy boundaries

Preload the LCP image when you know the URL early in the document:

Use this when the hero URL is stable and not swapped by heavy client-side logic. If the URL only appears after JavaScript runs, preload may fire too late—fix when the URL is known, not only how it is loaded.

fetchpriority="high" on the LCP nudges the browser to fetch that image sooner relative to other images. Use it sparingly (setting high on more than one or two images is usually not helpful) and pair it with not marking that same image as lazy.

Lazy loading belongs on below-the-fold images. For anything in the first screen, omit loading="lazy" or you risk delaying the very resource that defines LCP.

Decoding: decoding="async" can help keep the main thread responsive; test on low-end hardware if you are borderline on LCP.

CSS background images and LCP

Background images set in CSS are not elements. They are still eligible for LCP, but the browser can’t reliably discover the underlying image URL until after CSS is parsed—so you can end up with extra LCP resource load delay. You also lose straightforward alt semantics for critical content.

If your hero is purely decorative, a background can be fine—but you still pay the same byte and timing costs. If the hero carries meaning (product, banner text is not enough), prefer semantic or so preload and priority hints map cleanly to the resource.

When you must keep a background, preload it explicitly (e.g. link rel="preload" with fetchpriority="high" or a matching Link header) so it starts fetching early, and make sure the CSS/JS that reveals it doesn’t block rendering.

Third-party CDNs and transforms

Image CDNs that resize, reformat, and cache at the edge can shrink time-to-bytes dramatically. When you adopt one:

Lock URL parameters (width, quality, format) so marketing edits in the CMS do not silently generate new uncached variants.
Watch cache hit ratios after deploys; a “small” config change can bust effective caching.
Align transforms with your srcset strategy—duplicating the same logical image under twenty unbounded parameter combinations is a recipe for cache fragmentation.

CMS uploads and the “full size” trap

Many CMS/theme setups default new uploads to full resolution and then display them small. The HTML still references a massive file unless your theme registers proper image sizes and the markup uses them.

If you inherit a WordPress or similar build, check: (1) registered image sizes for hero slots, (2) whether the template uses wp_get_attachment_image with a named size or blindly outputs the original, (3) whether page builders inject full URLs into inline styles. One corrected template often beats dozens of hand-compressed assets nobody uses.

Verify in the lab, then confirm in the field

After changes:

Run PageSpeed Insights (or Lighthouse) on mobile and note LCP and the LCP element breakdown (TTFB, resource load delay, duration, render delay).
Compare field data (CrUX) where available—lab wins do not always match real users on slow networks.
If you use automated monitoring, add or check budgets for LCP on key templates so regressions surface when someone ships a new hero asset.

For a before/after story, WebPageTest filmstrips or Lighthouse’s View Trace help show whether you shortened resource load duration or merely shifted work. If TTFB or render delay still dominates, image tweaks alone will not get you to green.

Document one baseline number (median LCP or Lighthouse LCP) per template so the next redesign has a reference point.

Tie optimisation to budgets and ownership

Image work is easy to undo: a new campaign drops a 4 MB PNG into the hero and nobody notices until Search Console complains. Add a simple budget per template: maximum dimensions, maximum encoded kilobytes, and allowed formats. Our Performance Budget Thresholds Template is a starting point if you do not have internal standards yet.

Assign who approves hero assets in the CMS—often a designer uploads once and the performance contract is forgotten. A short checklist in the handover doc beats a post-launch fire drill.

What to do next

Identify the LCP element on your top templates.
Resize and re-encode; wire srcset/sizes correctly.
Remove lazy loading from above-the-fold heroes; add preload or fetchpriority where appropriate.
Re-test in the lab and watch field metrics after release.

Small, measurable steps beat a sweeping “image audit” that never ships.

FAQ

Is the hero image always the LCP element?

No. LCP is the largest visible element in the viewport; it can be a headline block, a video poster, or another image. Always confirm in your tooling before optimising the wrong asset.

WebP or AVIF first?

Prefer AVIF with a WebP or JPEG fallback for broad support, or use CDN negotiation if you have verified behaviour across browsers you care about.

Does lazy loading hurt LCP?

Lazy-loading your actual LCP element can delay LCP. In practice, omit loading="lazy" for the first-screen hero (and for any image the diagnostics report as LCP).

Do I need a CDN to pass LCP?

Not always, but a CDN often cuts latency and improves repeat visits. If TTFB or download time dominates your LCP breakdown, origin geography and caching deserve attention alongside image bytes.

Product Spotlight: Performance Budgets and Email Alerts in Apogee Watcher

Tue, 21 Apr 2026 21:12:58 +0000

A performance budget on paper is only a policy. In production it needs two things: thresholds your tests actually enforce, and notifications people will read without muting the sender. This product spotlight walks through how Apogee Watcher connects performance budgets to email alerts so regressions show up in your inbox as structured digests tied to each scheduled run.

If you are new to the vocabulary, our Core Web Vitals monitoring checklist for agencies covers the operational habits around budgets; here we focus on what the product does with those numbers after each PageSpeed Insights-backed test completes.

Why budgets and alerts belong together

Teams adopt budgets for different reasons. Some need a line in the sand before a release train ships. Others need evidence for a client retainer (“we agreed LCP stays inside this band”). Without automated checks, those thresholds become a PDF you filed once. With scheduled lab tests, the same thresholds can answer a simpler question: did this week’s deploy move any URL outside the band we care about?

Alerts are the other half. If every breach generated a separate message per URL and per metric, a single bad deploy on a large site would bury your team in mail before anyone opened a dashboard. Apogee Watcher sends one digest email per site per budget-check run when the alert channel is email. The digest lists up to ten pages with the worst scores first, plus totals for how many pages breached budgets and how violations break down by metric. That design follows the same instinct as a good incident summary: enough detail to triage, not enough to replace your issue tracker.

What “a budget” means inside Watcher

Budgets in Apogee Watcher are site-level and strategy-specific. For each monitored site you configure separate rows for mobile and desktop lab strategies. That matters because retail and content sites often diverge sharply by breakpoint: a template can pass mobile LCP while desktop TBT balloons after a script change.

Each active budget stores thresholds the product compares against stored lab results from scheduled runs. You can set caps and floors across the metrics PageSpeed Insights exposes in our results model, including the following:

Performance score (minimum acceptable Lighthouse-style score)
Largest Contentful Paint (LCP) as a time budget
Interaction to Next Paint (INP) where the API supplies it
Cumulative Layout Shift (CLS)
First Contentful Paint (FCP)
Total Blocking Time (TBT)
Speed Index

Not every team enables every field. A content marketing site might care most about LCP and CLS; an app-heavy property might weight INP and TBT more heavily. The performance budget thresholds template post includes starter numbers you can copy before you tune per client.

When you add a site, the product creates default budget rows for both strategies so you are not starting from an empty configuration. You still choose which numbers reflect your contract or internal standard, and you can deactivate a strategy’s budget if you only monitor one form factor for a given property.

From a scheduled test to an alert row

The loop is intentionally boring, which is what you want from monitoring infrastructure:

Scheduled tests run on the cadence allowed by your plan (hourly, daily, weekly, and so on). Each run produces fresh lab metrics per page and strategy.
Budget evaluation compares those metrics to the active budget for the same site and strategy. When a value is worse than the threshold (for example LCP above your maximum seconds, or performance score below your minimum), the system records an alert with the metric name, the threshold you set, and the value observed.
Resolution happens automatically when a later test shows the metric back inside the budget. Resolved alerts stop contributing to “open” noise; you keep history for auditing without treating old breaches as current fires.

That pipeline sits on top of the same automated PageSpeed monitoring setup this blog has covered before: organisations, sites, pages, and scheduled tests. Budgets do not replace discovery or URL hygiene; they judge the URLs you already chose to measure.

Email digests: what actually arrives

When new violations exist after a run and your budget’s alert channel is set to email, Apogee Watcher sends the budget-violation digest to each active organisation admin. The mail is scoped per site, not per page. Inside one digest you will typically see:

Summary counts for how many pages had violations and how many individual metric breaches occurred, plus a breakdown by metric type so you can tell whether the deploy mainly hurt LCP or spread pain across several signals.
Detailed rows for up to ten pages, prioritised so the weakest performance scores surface first, then by URL when scores tie. If more than ten pages failed, the email tells you that you are viewing the first ten of a larger set, while the totals still reflect the full picture.

Digest timing aligns with your scheduled test frequency for that site. The footer of the email states that it was generated from the automated schedule, which keeps expectations aligned: this is not a real-time push from your CDN; it is the post-run account of what the lab saw after the last completed sweep.

Recipients are organisation admins because alert routing is tied to account responsibility. If you need a wider broadcast inside a client team, forward the digest or pull the same numbers into your stand-up doc. For Slack-first teams, the product’s data model reserves other alert channels for when those integrations ship end to end; today’s reliable path for delivery is email.

Cooldowns and why they exist

A page that fails a budget on Monday will often fail again on Tuesday until someone ships a fix. Without guardrails you would receive a fresh digest with the same headline every day. Apogee Watcher applies cooldown logic keyed to page, strategy, and time since the last alert for that combination. The goal is simple: signal when something newly breaks or re-breaks, not to ping you on every run while the underlying issue is unchanged.

Cooldowns interact with your schedule. A site on a daily cadence still gets timely reminders; a weekly site batches more change into each run. If you tighten budgets after a major refactor, expect a burst of legitimate new violations while the system learns what “normal” looks like under the new line. That is working as intended.

How this fits next to policy and people

Budgets answer what crossed a line. People still answer who fixes it and how it gets prioritised. Many teams pair Watcher with a lightweight policy doc so on-call knows which breaches page the SEO lead versus the platform team. Our Slack alert policy template for web performance teams is written for Slack-shaped workflows, but the same sections (ownership, severity, quiet hours) translate directly to email-first teams: paste the digest link into the ticket, attach the URL list, and move on.

If you sell performance work to clients, budgets also give you a defensible story: you are not arguing from a one-off Lighthouse screenshot taken on someone’s laptop; you are pointing to thresholds you agreed in writing and time-stamped breaches after scheduled runs. That pairs naturally with the prospecting angle in From monitoring to pipeline, even though this spotlight stays on product mechanics rather than sales motion.

Getting started in a few concrete steps

Add or select a site and confirm your page list covers the templates you care about. Use automatic page discovery if the inventory has drifted.
Open budgets for that site and set mobile and desktop thresholds to match your standard or the client contract. Start from the template post if you do not want to guess at seconds and milliseconds.
Choose email as the alert channel on each active budget row your plan allows, and verify admin membership on the organisation so the right inboxes receive digests.
Let at least one scheduled run complete after deploy. If nothing breaches, you will not get mail, which is also useful signal.

When you are ready to stress-test the workflow, temporarily lower a threshold on a staging URL you control, run a test, and confirm the digest lists the expected metric. Roll the threshold back once you have validated routing.

Create a free account to configure budgets, scheduled PageSpeed tests, and email digests without wiring the PageSpeed Insights API yourself.

FAQ

Do I need separate budgets for mobile and desktop?

You should set both if you care about both experiences. Lab scores often diverge because assets, layout, and third-party behaviour differ by viewport. Empty or inactive strategies simply skip evaluation for that form factor.

Will I get one email per failing page?

No. Email notifications are digests: one message per site per run (for the email channel), with detailed rows for up to ten pages and summary totals for the full set of violations.

Who receives the digest?

Active organisation admins on the account. Viewer or manager roles do not automatically receive budget mail; adjust membership if someone else should be in that admin list.

What if I only want alerts on production, not staging?

Keep staging on its own site record with stricter or looser budgets, or pause budgets on environments you do not want to page yourself about. The product evaluates whatever URLs you attach to that site.

Does Apogee Watcher replace my status page or incident tool?

No. It tells you that lab metrics crossed thresholds you set after scheduled PageSpeed runs. You still route that signal through your normal engineering and client communication channels.

Are Slack notifications available?

Additional channels are part of the roadmap. Today, rely on email digests for delivery; check current plan details in the app for which channels your tier exposes.

How to Set Up Performance Budgets in CI/CD Pipelines

Sun, 19 Apr 2026 23:55:33 +0000

A performance budget in production is a line you refuse to cross. In CI it is the same line, enforced before a merge or deploy lands. Done well, the pipeline fails fast when a change regresses Core Web Vitals proxies, bundle weight, or your own custom thresholds, so you fix it in the branch instead of shipping first.

This guide assumes you already know why budgets matter. For the full conceptual frame and metric tables, read The Complete Guide to Performance Budgets for Web Teams. Here we focus on wiring budgets into CI/CD: tools, config shapes, and operational pitfalls.

What “performance budget in CI” usually means

In pipelines, teams typically enforce lab metrics (Lighthouse scores and timings such as LCP, CLS, INP where available, TBT, and so on) against numeric ceilings or floors; resource budgets (caps on JS, CSS, image bytes, request counts, or third-party weight); or custom checks (synthetic steps that call your own scripts or APIs after a build).

Lighthouse CI is the common open path for lab metrics because it runs Lighthouse in a controlled environment, stores results, and supports assertions against budgets. Pair it with bundle analysers or size limits when regressions come from dependency drift rather than layout alone.

CI budgets are not a substitute for field data or scheduled monitoring across many URLs. They gate the build you are about to ship. Products such as Apogee Watcher focus on ongoing lab schedules, portfolios, and alerts; see How to Set Up Automated PageSpeed Monitoring for Multiple Sites for that workflow.

Before you write YAML: pick URLs and environments

CI runs should be deterministic enough to trust. Preview URLs from Netlify, Vercel, Cloudflare Pages, or internal preview hosts work if the pipeline waits until the deploy is reachable. Local static servers (serve, http-server) suit static sites; SPAs often need the production build and a correct BASE_URL. Auth walls break Lighthouse unless you script login or use a dedicated test route.

Document which URLs represent home, a heavy template, and checkout or app shell if those differ. One URL with a loose budget hides regressions on another; at minimum, list primary templates in lighthouserc or equivalent.

Path 1: Lighthouse CI (LHCI)

Install

Add Lighthouse CI to the repo (dev dependency is typical):

npm install --save-dev @lhci/cli

Minimal `lighthouserc` (assertions + collect)

LHCI reads configuration from lighthouserc.js or lighthouserc.json. Example JSON shape:

{
  "ci": {
    "collect": {
      "url": [
        "https://your-preview.example.com/",
        "https://your-preview.example.com/pricing"
      ],
      "numberOfRuns": 3
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", { "minScore": 0.9 }],
        "largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
        "cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }],
        "total-blocking-time": ["warn", { "maxNumericValue": 300 }]
      }
    },
    "upload": {
      "target": "temporary-public-storage"
    }
  }
}

Notes:

numberOfRuns: multiple runs reduce noise; three is a common starting point.
Assertion keys map to Lighthouse audit IDs; align numeric budgets with your performance budget template and team policy.
upload.target: temporary-public-storage is fine for getting started; teams often move to LHCI server or skip upload in pure gate mode.

Wire the CI job

Invoke LHCI after the app is built and the target URL responds. Typical flow:

Install dependencies.
Build the site (if needed).
Deploy to preview or start a static server in the background.
Wait until the test URLs return HTTP 200.
Run lhci autorun (or lhci collect then lhci assert).

If you use GitHub Actions, a dedicated job with timeout-minutes and a health-check step avoids flaky “site not ready” failures. A minimal pattern is to probe the preview URL before lhci autorun, for example with curl -fsS --retry 5 --retry-delay 5 --retry-connrefused "$PREVIEW_URL". --retry-connrefused matters because a deploy that is not listening yet often returns “connection refused”, which plain curl retries do not treat as transient by default. Store the same base URL in a CI variable and pass it into lighthouserc or environment overrides your setup supports, so you do not duplicate hostnames in three places.

Resource limits: `budgetsFile` vs assertions

Lighthouse CI can assert against a budget.json-style file via assert.budgetsFile (path relative to the working directory). In the upstream configuration model, that budgetsFile mode is an alternative to filling assert.assertions with audit IDs; it is not mixed with other assert options in the same way. Check the Lighthouse CI configuration reference for the exact rules your CLI version supports.

If you want lab metrics (LCP, CLS, and so on) and transfer or request budgets in one assertions block, use Lighthouse CI’s resource-summary assertions (for example resource-summary:script:size, resource-summary:third-party:count) alongside the audit keys. Sizes there use bytes in assertion options; the standalone budget.json format often documents kilobytes, so keep units straight when you copy numbers between files.

Whether you use a checked-in budget file or assertion rows, treat the file like any other policy: generate from your design system pipeline or review diffs in PRs so “max JS kilobytes” does not drift silently.

Path 2: GitHub Actions sketch

Below is a pattern, not a drop-in for every stack: replace build commands, Node version, and URL discovery with your own.

name: Lighthouse CI
on:
  pull_request:
    branches: [main, develop]

jobs:
  lhci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      # Example: wait for preview deploy via your provider’s CLI or API, then:
      - run: npx @lhci/cli autorun
        # Optional: set LHCI_GITHUB_APP_TOKEN if you use the Lighthouse CI GitHub App
        # so upload can post PR status checks. Not required for a local pass/fail gate.
        # env:
        #   LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

Many teams split build and LHCI across workflows so preview deploy completes first; use workflow_run or provider webhooks if needed. The critical invariant is that Lighthouse runs against the same artifact users will get, not a half-built tree.

On GitLab CI, CircleCI, or Buildkite the same steps apply: install Node, build, wait for URLs, then run npx @lhci/cli autorun (or your package script). Cache node_modules between runs when your runner allows it; cold installs dominate wall time on small changes.

Resource budgets alongside Lighthouse

Lab metrics can pass while JavaScript weight creeps up on every sprint. Add at least one of: bundle size limits (bundlesize, size-limit, or webpack’s performance hints), or dependency reviews in the PR template so someone notices a multi-megabyte new dependency.

Treat resource budgets as complementary to LCP and CLS gates. A slow-LCP fix might add twenty kilobytes and still help users; a green Lighthouse run with a nine-hundred-kilobyte main bundle remains fragile.

Flakiness and false positives

CI environments are colder than a developer laptop. Variance in LCP and CLS is normal: mitigate with multiple runs, pinned Chrome, and stable network throttling settings in LHCI. Third-party ads or A/B scripts can differ run to run; block known domains in a test profile or point at a clean route. A cold CDN edge on the first request after deploy can skew timings; an optional warmup GET before LHCI helps.

If the main branch is red every other day, teams stop trusting the job. Prefer warnings on noisy metrics and errors on stable ones until baselines settle.

How this pairs with product-side budgets and alerts

CI answers whether this change broke your thresholds on the URLs you chose. Scheduled monitoring answers whether you are still inside budget next week across the pages you track in production.

If you already use performance budgets and email alerts in Apogee Watcher, treat CI as the pre-merge gate and Watcher as the continuous check on real site inventories. Same vocabulary, different phase of the lifecycle.

Apogee Watcher and CI: agency API (in active development)

You do not need a vendor API to get value from Watcher next to LHCI. Many teams keep Lighthouse CI (or Lighthouse CLI) in the pipeline for fast feedback on the preview URL, and keep budgets, schedules, and digests in Apogee Watcher so production-facing URLs and client reporting stay in one product. Align the numbers: copy thresholds from your performance budget template into both LHCI assertions and Watcher site budgets so “green in CI” and “green in monitoring” mean the same thing.

Apogee Watcher is building a plan-gated customer HTTP API (under /api/v1) aimed at agency workflows. It is in active development: behaviour, routes, and reference documentation will firm up as releases land. Eligible plans will expose the capabilities below; exact rollout timing will follow release notes.

For agency users, the API will be supporting:

Check test results: read latest (and historical) PageSpeed outcomes for monitored pages without opening the dashboard.
Trigger a new test: request a fresh run after a deploy so CI or a script can wait on Watcher instead of calling the Google PageSpeed API key from your own workers.
Retrieve aggregated reports: pull summary or roll-up reporting suitable for client packs or internal gates.
Retrieve historical trends: chart-friendly series so pipelines or internal tools can compare this build against last week, not only the last run.

Why that matters next to LHCI: once those endpoints are live, a pipeline will be able to trigger a test, poll until results land, then fail if metrics breach the same budgets you set in the app. Quota and retries will stay on Watcher’s side, and the failing run will remain tied to stored results and trends for client conversations, not only a line in your CI log.

Until the public reference and stable endpoints are published, keep using LHCI for branch gates and the Watcher UI for schedules and alerts. Follow the Product & Brand category on the blog for product news and API-related updates, and check plan details for API access when you are ready to wire automation. If you are interested in early beta tester access to the agency API, contact us.

Checklist: ship a credible CI budget

[ ] Listed representative URLs (not only /).
[ ] Chose numeric thresholds aligned with your complete guide or client contract.
[ ] Set numberOfRuns ≥ 2 for stability.
[ ] Documented preview URL or static server startup in the workflow.
[ ] Added at least one resource or bundle guard for JS/CSS creep.
[ ] Separated error vs warn assertions to reduce alert fatigue.

FAQ

Is Lighthouse CI the only option?

No. Some teams wrap plain Lighthouse CLI, use Playwright traces, or rely on vendor-specific speed tools in CI. LHCI is widely documented and gives assertions + history-friendly uploads out of the box.

Should performance CI block every PR?

Often yes for main, with optional paths for docs-only changes. Use path filters so markdown edits do not run full LHCI unless you want them to.

Can I enforce budgets without a preview deploy?

Yes for static sites: build, serve locally in CI, and point LHCI at localhost. Dynamic server-rendered apps may need a test server with seed data.

Does this replace RUM or Search Console field data?

No. Lab CI validates the candidate build; field metrics validate real users. Both belong in a mature performance program.

What if our budgets are stricter than Lighthouse in CI can reliably hit?

Loosen CI thresholds slightly below production targets, or scope strict checks to stable audits (CLS, bundle size) and use warnings for high-variance metrics until your environment is stable.

Can I trigger Apogee Watcher tests from CI with an API?

That workflow is in active development. The customer API will support checking test results, triggering new tests, retrieving aggregated reports, and retrieving historical trends from automation for agency users on eligible plans (subject to published docs and plan limits). It is not a stable, copy-paste integration yet. For today’s deploy gates, use LHCI or Lighthouse in CI; keep Watcher for scheduled runs, budgets, and alerts. When the reference documentation and endpoints are public, they will be the supported way to align CI with dashboard budgets without putting a PageSpeed API key in your pipeline.

How to Set Up Automated PageSpeed Monitoring for Multiple Sites

Fri, 10 Apr 2026 21:02:07 +0000

The Problem: Manual Testing Doesn't Scale

You manage 10 client sites. Each has 5 key pages. You want to test both mobile and desktop. That's 100 tests — every time you want a snapshot of your portfolio's performance.

Running those tests manually in PageSpeed Insights takes about 2 minutes each. That's over 3 hours of tab-switching, waiting, and copy-pasting numbers into a spreadsheet. And by the time you finish the last site, the first site's results are already hours old.

This is why automated monitoring exists. Set it up once, and every test runs itself.

What Automated PageSpeed Monitoring Should Do

Before choosing a tool or approach, define what you need:

Must-Have Features

Scheduled testing — Tests run automatically at configured intervals (daily, hourly, etc.)
Multiple sites — Manage all your sites from one place
Mobile and desktop — Test both strategies for every page
Historical data — Store results over time for trend analysis
Alerting — Get notified when performance degrades below a threshold
No manual intervention — Once configured, it runs without you

Nice-to-Have Features

Automated page discovery — The tool finds pages to monitor from your sitemap
Performance budgets — Set thresholds per site and get alerted on violations
Client-ready reports — Generate PDFs or summaries for clients
Team access — Multiple team members with role-based permissions
API access — Pull data programmatically for custom dashboards
White-label branding — Reports and dashboards with your agency branding

Approach 1: DIY with Open-Source Tools

If you have the technical chops and want full control, you can build automated monitoring with open-source tools.

Using Lighthouse CI

Lighthouse CI runs Lighthouse tests in a CI/CD pipeline and stores results over time.

Setup:

Install Lighthouse CI:

npm install -g @lhci/cli

Create a lighthouserc.json configuration:

{

  "ci": {
"collect": {
  "url": [
    "https://client1.com/",
    "https://client1.com/pricing",
    "https://client2.com/",
    "https://client2.com/products"
  ],
  "numberOfRuns": 3,
  "settings": {
    "preset": "desktop"
  }
},
"assert": {
  "assertions": {
    "categories:performance": ["error", {"minScore": 0.9}],
    "largest-contentful-paint": ["warn", {"maxNumericValue": 2500}],
    "cumulative-layout-shift": ["warn", {"maxNumericValue": 0.1}]
  }
},
"upload": {
  "target": "lhci",
  "serverBaseUrl": "https://your-lhci-server.com"
}

}
}

Set up a LHCI server for storing and viewing results:

npm install -g @lhci/server

lhci server --storage.storageMethod=sql --storage.sqlDatabasePath=./lhci.db

Schedule runs with cron:

# Run daily at 7 AM

0 7   * cd /path/to/config && lhci autorun

Pros: Free, fully customisable, integrates with CI/CD pipelines.
Cons: Requires server setup and maintenance, no built-in alerting, no multi-tenant management, no client-facing reports, limited mobile testing (emulated only).

Using Google PageSpeed Insights API Directly

For teams comfortable with scripting, you can call the PSI API directly:

# Basic API call

curl "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://example.com&strategy=mobile&key=YOUR_API_KEY"

Build a monitoring script:

import requests

import json

from datetime import datetime
SITES = [
{"name": "Client 1", "urls": ["https://client1.com/", "https://client1.com/pricing"]},
{"name": "Client 2", "urls": ["https://client2.com/", "https://client2.com/products"]},

]

API_KEY = "your-api-key"
STRATEGIES = ["mobile", "desktop"]

def run_test(url, strategy):

endpoint = "https://www.googleapis.com/pagespeedonline/v5/runPagespeed"
params = {"url": url, "strategy": strategy, "key": API_KEY}
response = requests.get(endpoint, params=params)
data = response.json()
# API response structure: lighthouseResult contains categories and audits
# See https://developers.google.com/speed/docs/insights/v5/reference/pagespeedapi/runpagespeed
lh = data.get("lighthouseResult", {})
cats = lh.get("categories", {})
audits = lh.get("audits", {})
return {
    "url": url,
    "strategy": strategy,
    "score": (cats.get("performance", {}).get("score") or 0) * 100,
    "lcp": audits.get("largest-contentful-paint", {}).get("numericValue", 0),
    "cls": audits.get("cumulative-layout-shift", {}).get("numericValue", 0),
    "tbt": audits.get("total-blocking-time", {}).get("numericValue", 0),
    "tested_at": datetime.now().isoformat()
}

Run tests

for site in SITES:

for url in site["urls"]:
    for strategy in STRATEGIES:
        result = run_test(url, strategy)
        print(f"{site['name']} | {url} | {strategy} | Score: {result['score']}")
        # Store result in database, CSV, or send to Slack

Pros: Maximum flexibility, use any language, store data anywhere.
Cons: You build and maintain everything — alerting, storage, reporting, UI, error handling, quota management, scheduling. Significant development and maintenance effort.

API quota note: Google's PageSpeed Insights API allows 25,000 requests per day on the free tier. Each URL + strategy (mobile/desktop) counts as one request. For 25 clients × 5 pages × 2 strategies × 30 days, that's 7,500 requests/month — well within quota. Scale up carefully; request a quota increase if you need more.

Approach 2: Purpose-Built Monitoring Platforms

For most teams, a purpose-built platform is the better choice. You get all the features without the maintenance burden.

What to Look for in a Platform

Feature	Why It Matters
Multi-site management	One dashboard for all clients
Automated page discovery	Don't manually enter every URL
Scheduled testing	Tests run without manual intervention
Performance budgets	Set thresholds and get alerted on violations
Alerting (email, Slack)	Know immediately when something breaks
Historical data	Track trends over weeks and months
Reporting	Generate client-ready reports
Team access	Multiple users with appropriate permissions
API access	Integrate with your existing tools

Platform Comparison Factors

When evaluating platforms, consider:

Pricing model — Per site? Per test? Flat rate? How does cost scale with your growth?
Test accuracy — Does it use Google's actual PageSpeed Insights API or its own analysis?
Mobile testing — Real device testing or emulated? (Emulated is standard; real device testing is rare and expensive)
Data retention — How long are historical results stored?
Alert flexibility — Can you set custom thresholds? Multiple channels? Cooldowns?
Report customisation — Can you brand reports with your agency logo?

Approach 3: Hybrid (Recommended for Growing Agencies)

The most effective setup combines a monitoring platform with CI/CD integration:

In Production: Monitoring Platform

Use a platform like Apogee Watcher for ongoing production monitoring:

Daily automated tests on all client sites
Performance budgets per site with alert notifications
Historical trend tracking
Monthly client reports

In Development: Lighthouse CI

Use Lighthouse CI in your deployment pipeline:

Run performance tests on every PR or deployment
Block deploys that regress performance below budget
Catch issues before they reach production

The Workflow

Development:

  PR opened → Lighthouse CI runs → Budget check passes → PR approved
Production:

  Deploy → Monitoring platform detects change → Tests run →

  Results compared against budgets →

  If regression: Alert fired → Team investigates → Fix deployed
Ongoing:

  Daily tests run automatically → Results stored →

  Monthly report generated → Sent to client

This hybrid approach catches issues at two points: before they ship (CI) and after they ship (production monitoring). If something slips through CI (which can happen — lab tests don't catch everything), production monitoring is your safety net.

Step-by-Step Setup Guide

Regardless of which approach you choose, follow these steps:

Step 1: Inventory Your Sites

Create a spreadsheet of all sites you need to monitor:

Client,Domain,Key Pages,Strategy,Priority

Client A,clienta.com,"/, /pricing, /contact",Both,High

Client B,clientb.com,"/, /products, /checkout",Both,High

Client C,clientc.com,"/, /blog, /about",Both,Medium

Step 2: Define Performance Budgets

Set budgets for each site type. For an introduction to what is Core Web Vitals (LCP, INP, CLS), see our practical guide. Use the templates from our Performance Budget Thresholds Template and The Complete Guide to Performance Budgets as a starting point:

E-commerce: LCP ≤ 2.0s, INP ≤ 150ms, CLS ≤ 0.05
Content sites: LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.10
Landing pages: LCP ≤ 2.0s, INP ≤ 150ms, CLS ≤ 0.05

Step 3: Configure Your Monitoring Tool

In your chosen platform:

Add each site with its domain
Run page discovery to find all monitorable pages (or add key pages manually)
Set performance budgets per site and strategy (mobile/desktop)
Configure alerts — Choose channels (email, Slack) and recipients
Set the test schedule — Daily is standard; twice daily for high-priority sites

Step 4: Establish Your Review Routine

Automated monitoring doesn't mean zero human attention. Establish a rhythm:

Daily: Glance at alerts. If none fired, you're good.
Weekly: Review the dashboard for trends. Are any sites gradually degrading?
Monthly: Generate client reports. Review budget compliance. Adjust budgets if needed.

Step 5: Integrate with Your Workflow

Connect monitoring to your team's existing workflow:

Slack integration: Performance alerts appear alongside other team notifications
Ticketing: Create tickets automatically when alerts fire (via webhooks)
Reporting: Schedule client reports to auto-generate and send

Step 6: Onboard Your Team

Everyone who might respond to alerts needs to know:

What the metrics mean
What the budgets are
How to investigate a regression
How to run a manual test when needed
Where to find historical data

Common Pitfalls

1. Monitoring Too Many Pages

Start with key pages (homepage, landing pages, conversion pages). Add more over time. Monitoring 500 pages on day one creates noise without value.

2. Setting Alerts Too Aggressively

Performance scores fluctuate naturally. A score of 89 on one test and 91 on the next doesn't mean anything changed. Use cooldowns (e.g. 8–24 hours between alerts for the same page) and only alert on sustained or significant changes. Consider alerting only when a metric is over budget for 2+ consecutive tests.

3. Not Monitoring Mobile

Desktop scores are usually better than mobile. If you only monitor desktop, you're seeing an optimistic picture. Always monitor both strategies.

4. Forgetting to Review

Automated tests are only useful if someone looks at the results. Automated alerts are only useful if someone responds. Build the review habit into your weekly routine.

5. Not Adjusting Over Time

As sites evolve (new features, new content, redesigns), your monitoring setup needs to evolve too. Add new pages, adjust budgets, update alert recipients.

What You Get When It's in Place

Once automated monitoring is running, you get:

One place for all sites — No more tab-switching or separate spreadsheets; every client's results live in one dashboard.
History and trends — Stored results over time so you can see whether a site is improving or degrading.
Alerts that fire when it matters — Not every tiny fluctuation; thresholds and cooldowns mean you're notified when metrics cross the line.
No maintenance burden — No cron jobs to debug, no API keys to rotate, no scripts that break after a platform update. The tool runs the tests; you review and act.

That's the benefit of a purpose-built platform versus DIY: you spend time on performance decisions, not on keeping the monitoring system alive.

The End Result

When automated monitoring is set up correctly, your daily effort looks like this:

Check Slack — Any alerts overnight? If not, everything's fine.
If alert fired — Click the link in the alert, review the data, investigate, fix or create a ticket.
Done. — Total time: 5-15 minutes.

Compare that to 3+ hours of manual PageSpeed testing. Automated monitoring doesn't just save time — it fundamentally changes your relationship with performance from reactive to proactive.

What you can achieve: You can have scheduled monitoring across all your sites, with alerts and history, without running scripts or maintaining pipelines yourself. One dashboard, clear budgets, and client-ready reporting when you need it — so performance stays visible without becoming a second job.

FAQ

What's the difference between Lighthouse CI and a monitoring platform?Lighthouse CI runs in your CI/CD pipeline — it catches regressions before they ship. A monitoring platform (like Apogee Watcher) runs tests on production on a schedule — it catches issues after they ship. Use both: CI for pre-deploy gates, monitoring for ongoing production visibility.

How many pages should I monitor per site?Start with 5–10 key pages: homepage, top landing pages, conversion pages. Add more over time. Monitoring 500 pages on day one creates noise without value. Quality of coverage beats quantity.

Does automated monitoring require a sitemap?Many tools can discover pages from a sitemap automatically. If the client has no sitemap, add key URLs manually. Most platforms support both sitemap discovery and manual URL entry.

What's the cost of building vs buying automated monitoring?Building from scratch (API calls, storage, alerting, UI, multi-tenant management) takes months. Ongoing maintenance adds up. Purpose-built platforms cost $50–200/month and eliminate that burden. For most teams, buying is the better ROI.

Apogee Watcher automates PageSpeed monitoring for agencies managing multiple sites. Automated discovery, daily testing, performance budgets, alerts, and client-ready reports — all from one dashboard. Join the waitlist for early access.

Slack Alert Policy Template for Web Performance Teams

Wed, 08 Apr 2026 09:51:34 +0000

The Problem: Alerts Without a Policy Are Chaos

You've got performance alerts, but nobody knows when to treat one as critical versus "review when you can." You either drown in notifications and start ignoring them, or you set thresholds so high that real issues slip through. Without a policy, your team doesn't know when to drop everything, when to acknowledge in the next standup, or how to avoid re-alerting on the same issue every hour.

The solution: An alert policy. It defines:

What triggers an alert
When the alert fires (thresholds and conditions)
Where the alert goes (channels, recipients)
How the team responds (severity levels, SLAs, escalation)

This template gives you a complete policy you can adopt, adapt, and paste into your team's Slack workspace or documentation. For background on what is Core Web Vitals (LCP, INP, CLS), see our practical guide; for performance budget thresholds and severity criteria, see The Complete Guide to Performance Budgets and our Performance Budget Thresholds Template.

The Alert Policy Template

Section 1: Alert Channels

Define where alerts are routed based on severity.

// Alert Channel Configuration
perf-alerts-critical
  Purpose:     P1 and P2 alerts only

  Who watches:  On-call engineer, tech lead

  Expectation:  Respond within 30 minutes during business hours

  Muted:        Never
perf-alerts
  Purpose:     All performance alerts (P1-P4)

  Who watches:  Full engineering team

  Expectation:  Review during next standup

  Muted:        Allowed outside business hours
client-[name]-alerts (per-client channels, optional)
  Purpose:     Client-specific performance alerts

  Who watches:  Account manager, assigned developer

  Expectation:  Review same business day

  Muted:        Allowed outside business hours
Email (fallback)

  Purpose:     Backup delivery for all P1 alerts

  Recipients:  Emails are not allowed, Emails are not allowed

  Expectation:  Ensures delivery if Slack is down

Section 2: Severity Levels

Define four severity levels based on metric deviation from budget. The "Poor" thresholds below match Google's Core Web Vitals definitions (LCP > 4s, INP > 500ms, CLS > 0.25).

// Severity Levels
P1 — CRITICAL

  Condition:   Any Core Web Vital in "Poor" range OR Performance Score < 50

  Thresholds:
- LCP > 4.0 seconds
- INP > 500 milliseconds
- CLS > 0.25
- Performance Score < 50

Channel: #perf-alerts-critical + email fallback
Response: Acknowledge within 30 minutes. Begin investigation immediately.
Escalation: If unacknowledged after 1 hour → notify tech lead directly
Cooldown: 4 hours (don't re-alert for same page/metric within 4 hours)

P2 — WARNING
Condition: Any Core Web Vital exceeds budget by > 20% but not in "Poor" range
Thresholds:

- LCP > 3.0 seconds (budget: 2.5s, 20% over)
- INP > 240 milliseconds (budget: 200ms, 20% over)
- CLS > 0.12 (budget: 0.1, 20% over)
- Performance Score < 75

Channel: #perf-alerts-critical
Response: Investigate within 4 hours during business hours.
Escalation: If unresolved after 24 hours → escalate to P1
Cooldown: 8 hours

P3 — NOTICE
Condition: Any Core Web Vital exceeds budget but by < 20%
Thresholds:

- LCP 2.5 – 3.0 seconds
- INP 200 – 240 milliseconds
- CLS 0.10 – 0.12
- Performance Score 75 – 89

Channel: #perf-alerts
Response: Review in next standup. Create ticket if persistent.
Escalation: If still over budget after 3 consecutive tests → escalate to P2
Cooldown: 24 hours

P4 — INFO
Condition: Score improved significantly OR metric returned to budget after violation
Thresholds:

- Performance Score improved by > 10 points
- Previously violated metric now within budget

Channel: #perf-alerts
Response: No action required. For awareness only.
Cooldown: None (fire once per event)

Section 3: What to Include in Each Alert

Define the content of each alert message so the team can triage quickly.

// Alert Message Template
[SEVERITY] Performance Alert — [SITE] — [PAGE]
Metric:        [METRIC_NAME]

Current Value: [ACTUAL_VALUE]

Budget:        [BUDGET_VALUE]

Strategy:      [MOBILE / DESKTOP]

Deviation:     [PERCENTAGE OVER BUDGET]
Page URL:      [FULL_URL]

Test Time:     [TIMESTAMP]

Dashboard:     [LINK_TO_MONITORING_DASHBOARD]
Previous Test: [PREVIOUS_VALUE] at [PREVIOUS_TIMESTAMP]

Trend:         [IMPROVING / DEGRADING / STABLE]

Example P2 Alert:

[P2] Performance Alert — acme.com — Homepage
Metric:        LCP (Largest Contentful Paint)

Current Value: 3,200 ms

Budget:        2,500 ms

Strategy:      Mobile

Deviation:     28% over budget
Page URL:      https://acme.com/

Test Time:     2026-02-12 07:00 UTC

Dashboard:     https://app.apogeewatcher.com/sites/acme/results
Previous Test: 2,400 ms at 2026-02-11 07:00 UTC

Trend:         DEGRADING (↑ 800ms in 24 hours)

Section 4: Response Procedures

Define what happens after an alert fires.

// Response Procedure
Step 1: ACKNOWLEDGE

React to the Slack message to signal you're looking (e.g. add a reaction)
If P1: reply in thread confirming you're investigating

Step 2: TRIAGE

Open the monitoring dashboard link from the alert
Check if the issue is on multiple pages or isolated to one
Check if the issue is on mobile only, desktop only, or both
Check the trend: is this a sudden drop or gradual degradation?

Step 3: IDENTIFY CAUSE

Recent deployment? Check git log for changes in the last 24 hours
New third-party script? Check the page source for new external resources
Server issue? Check TTFB and server response times
Image/media change? Check if the LCP element changed
CDN issue? Check CDN provider status page

Step 4: FIX OR ESCALATE

If the fix is straightforward (e.g., revert a deployment, remove a script):
Fix it, then re-run a manual test to verify


If the fix requires investigation:
Create a ticket with the alert details
Set priority based on severity level
Assign to the appropriate developer



Step 5: VERIFY

After fixing, run a PageSpeed test to confirm the metric is back within budget
Reply in the alert thread with the resolution
React to the alert to signal resolution (e.g. checkmark reaction)

Step 6: POST-MORTEM (P1 only)

For P1 incidents lasting > 2 hours:
Write a brief post-mortem (what happened, why, how it was fixed)
Identify preventive measures
Share in #perf-alerts for team awareness

Section 5: Cooldown and De-Duplication Rules

Prevent alert fatigue with smart cooldown rules. PagerDuty's guide to reducing alert noise covers similar principles: rate limits, deduplication, severity-based routing, and suppression during maintenance. The rules below follow the same approach.

// Cooldown Rules



Rule 1: Per-Page Cooldown

  After an alert fires for a specific page + metric + strategy,

  do not fire again for the same combination within the cooldown period.
  P1: 4 hours

  P2: 8 hours

  P3: 24 hours
Rule 2: Escalation Override

  If a metric worsens during the cooldown period (e.g., P3 → P2 threshold),

  fire a new alert at the higher severity regardless of cooldown.
Rule 3: Resolution Resets Cooldown

  When a metric returns to within budget, the cooldown resets.

  If it exceeds budget again, a new alert fires immediately.
Rule 4: Maintenance Windows

  During scheduled maintenance or deployments:

Suppress P3 and P4 alerts for 2 hours
P1 and P2 alerts are NEVER suppressed
Use Slack's /mute-perf-alerts command (if configured) or

temporarily disable non-critical alerts in the monitoring tool

Section 6: Scheduled Reporting (Non-Alert)

In addition to reactive alerts, set up proactive scheduled messages.

// Scheduled Reports

Daily Digest (posted to #perf-alerts at 9:00 AM)

  Content:
- Number of tests run in the last 24 hours
- Number of budget violations detected
- Top 3 worst-performing pages (by score)
- Any new alerts that fired overnight

Weekly Summary (posted to #perf-alerts every Monday at 9:00 AM)
Content:

- Week-over-week score trends for all monitored sites
- Pages that improved vs degraded
- Open alerts that haven't been resolved
- API usage summary

Monthly Report (posted to #perf-alerts first Monday of each month)
Content:

- Link to the full monthly performance report
- Top wins and regressions
- Budget compliance percentage per client
- Recommendations for the coming month

Quick Start: Minimal Policy

If you're not ready for the full policy, start with this:

One channel — #perf-alerts for all alerts
Two severity levels — Critical (score < 50 or any CWV in "Poor" range) and Notice (everything else)
Cooldown — 8 hours minimum between alerts for the same page/metric
Response — Acknowledge Critical within 4 hours; review Notice in next standup

Expand to the full policy as your team and client count grow.

Customisation Guide

For Small Teams (1-3 People)

Simplify to two channels:

#perf-alerts for all alerts
Email fallback for P1 only

Reduce severity levels to P1 (Critical) and P3 (Notice). Skip P2 and P4.

For Large Agencies (10+ Clients)

Add per-client channels (#client-acme-alerts) and route alerts based on client assignment. Use a rotation for on-call acknowledgment. Consider integrating with PagerDuty or Opsgenie for P1 escalation.

For In-House Teams

Replace "client" language with "product" or "team." Route alerts to the team that owns the page or feature. Add deployment-triggered alerts (test automatically after every deploy).

Implementation Checklist

[ ] Create Slack channels (#perf-alerts-critical, #perf-alerts)
[ ] Configure monitoring tool to send alerts to the appropriate channels
[ ] Set up severity thresholds per the template above
[ ] Configure cooldown periods
[ ] Document the response procedure in your team wiki
[ ] Brief the team on the new alert policy
[ ] Run a test alert to verify routing works
[ ] Schedule a 2-week review to adjust thresholds based on alert volume

FAQ

What's the difference between P1, P2, P3, and P4 severity levels?P1 is critical: any Core Web Vital in "Poor" range or Performance Score below 50. P2 is warning: metrics exceed budget by more than 20%. P3 is notice: metrics exceed budget but by less than 20%. P4 is informational: score improved or a previously violated metric returned to budget.

How do I prevent alert fatigue?Use cooldowns so the same page/metric doesn't alert repeatedly within a short window. Start with 8–24 hour cooldowns. Escalate only when metrics worsen or persist. Consider alerting only after 2+ consecutive tests over budget to filter natural fluctuation. PagerDuty's reduce-noise guide applies the same logic to incident management: deduplication, severity-based routing, and suppression during maintenance.

Should every team member get every alert?No. Route P1 and P2 to a small critical channel (on-call engineer, tech lead). Route all alerts to a general channel for visibility. Use per-client channels for agencies so the right account manager sees the right alerts.

Can I integrate performance alerts with PagerDuty or Opsgenie?Yes. Many monitoring tools support webhooks. Configure a webhook to fire on P1 alerts and point it at your incident management service. PagerDuty and Opsgenie accept incoming webhooks for alert creation.

How often should I review and adjust alert thresholds?Plan a review every 2–4 weeks for the first few months. If you're getting too many P2 or P3 alerts, thresholds may be too tight (or you have real regressions to fix). If you rarely see alerts, thresholds may be too loose. Use the scheduled digest to spot patterns before changing numbers.

Should I use different thresholds for mobile vs desktop?Yes, if you test both. Mobile typically performs worse (slower networks, weaker devices). Many teams set the same budget for both but expect more mobile alerts; others set a slightly looser mobile budget (e.g. LCP 3.0s mobile vs 2.5s desktop). Document your choice in the policy so the team knows what to expect.

What you can achieve: Your team has one policy — who gets which alerts, how to respond, and how to avoid fatigue. You can add Slack (or email) alerts without chaos: everyone knows when to act and when to review later.

Apogee Watcher supports email alerts today, with Slack and webhook delivery coming soon. Set configurable thresholds, cooldowns, and per-site budgets. Join the waitlist to be the first to set up automated performance alerts for your team.

Performance Budget Thresholds Template

Wed, 01 Apr 2026 11:36:01 +0000

The Problem: No Clear Definition of "Good"

Without concrete thresholds, you can't set performance budgets, explain pass/fail to clients, or know when to alert. "LCP should be good" isn't enough — you need numbers. This template gives you those numbers: ready-to-use thresholds by site type (e-commerce, agency client sites, content, SaaS, landing pages) so you can define "good" once and enforce it everywhere.

Benefits: One place for all your budget values, client-ready language, and clear escalation (warning vs critical).
What you get: Set budgets per site, get alerted only when it matters, and report to clients with confidence.

Your Ready-to-Use Performance Budget Template

Copy the thresholds below into a Google Sheet, CSV, or your monitoring tool. No theory — just the numbers, organised by site type and strategy.

If you want the "why" behind these numbers, read our Complete Guide to Performance Budgets first.

The Template

Universal Thresholds (Google's "Good" Baselines)

These are the starting points for any site. For an introduction to what is Core Web Vitals, see our practical guide; the numbers below follow Google's documented thresholds. Adjust based on your baseline: If your current scores are far from these targets, use them as stretch goals and set interim budgets at your current values. Tighten as you improve.

Note: For LCP, INP, FCP, TBT, Speed Index — lower is better. "Poor" = exceed the max. For Performance Score and CLS — higher is better (Score) / lower is better (CLS).

Budget Template by Site Type

E-Commerce

Agency Client Sites (Default)

Content / Blog Sites

SaaS / Web Applications

Landing Pages / Marketing Sites

How to Use This Template

Step 1: Choose Your Site Type

Pick the template that matches your site (or start with the "Agency Client Sites" default if you're not sure).

Step 2: Copy Into Your Tool

Google Sheets / CSV:Copy the CSV data above into a spreadsheet. Add columns for:

Current Mobile Score — Your latest test result
Current Desktop Score — Your latest test result
Status — Within Budget / Over Budget / Critical

Monitoring tool (like Apogee Watcher):Enter the Mobile Budget and Desktop Budget values as your performance budget thresholds per site.

Lighthouse CI config:Translate thresholds into your lighthouserc.json:

{
  "ci": {
    "assert": {
      "assertions": {
        "largest-contentful-paint": ["error", {"maxNumericValue": 2500}],
        "cumulative-layout-shift": ["error", {"maxNumericValue": 0.1}],
        "total-blocking-time": ["error", {"maxNumericValue": 200}],
        "first-contentful-paint": ["warn", {"maxNumericValue": 1800}],
        "categories:performance": ["error", {"minScore": 0.9}]
      }
    }
  }
}

Step 3: Baseline Your Sites

Run PageSpeed Insights on your key pages. Fill in the "Current" columns. Anything marked "Over Budget" is an immediate action item.

Step 4: Set Up Alerts

Configure your monitoring tool to alert you when any metric exceeds its budget. Without alerts, this template is just a document. With alerts, it's a safety net.

Multi-Client Tracking Spreadsheet

For agencies managing multiple clients, use this structure:

Color-code the Status column: green for OK, red for OVER. Review weekly.

Budget Escalation Levels

Not all budget violations are equal. Use escalation levels to prioritise response:

Adjusting Budgets Over Time

Budgets aren't permanent. Review quarterly:

Tighten when:

Your team consistently meets budgets with room to spare
Competitors are faster and you're losing rankings
Client expectations increase

Loosen when:

New required functionality legitimately impacts performance (e.g., adding a complex interactive feature)
A temporary campaign requires heavier scripts (set an expiration date for the loosened budget)

Never loosen because:

"We can't fix it right now" — that's a prioritisation issue, not a budget issue
"The score fluctuates" — that's normal variance, not a reason to move the goalposts

FAQ

Can I customise these thresholds for my specific site?Yes. The template provides baseline values. Adjust based on your current scores, site type, and competitive benchmarks. E-commerce and landing pages often need stricter LCP and CLS budgets; content sites can use the standard thresholds.

What's the difference between the "Agency Client Sites" and "E-Commerce" templates?Agency Client Sites use Google's standard "Good" thresholds as a default. E-Commerce is stricter — lower LCP (2s vs 2.5s), tighter INP (150ms vs 200ms), and stricter CLS (0.05 vs 0.1) because conversion-critical pages need to feel instant.

How do I use this template with a monitoring tool?Copy the budget values into your tool's configuration. Most tools let you set thresholds per metric, per site, and per strategy (mobile/desktop). Once set, the tool will run tests against these budgets and alert you when thresholds are exceeded.

Should I track all metrics or just LCP, INP, and CLS?LCP, INP, and CLS are the Core Web Vitals — track them first. FCP, TBT, and Speed Index add useful context. Performance Score is a useful composite. Start with CWV + Score; add others if you need deeper visibility.

What you can achieve: Every site can have clear pass/fail thresholds, alerts that fire only when metrics cross the line, and reports clients understand. Use this template so performance budgets stop being guesswork and start being something you can set, enforce, and show.

Managing performance budgets across multiple sites is easier with automation. Apogee Watcher lets you set budgets per site, get alerted when thresholds are exceeded, and track trends over time. Join the waitlist for early access.

The Complete Guide to Performance Budgets for Web Teams

Thu, 26 Mar 2026 09:37:25 +0000

What Is a Performance Budget?

A performance budget is a set of limits on metrics that affect user experience. It's a threshold you agree not to exceed. When a metric crosses the budget, it triggers a review, an alert, or a rollback — just like a financial budget triggers action when you overspend. For the metrics behind these budgets, see What Are Core Web Vitals?. for copy-paste thresholds by site type, see our performance budget template; for setup steps, see our automated monitoring resources.

Performance budgets aren't aspirational goals. They're hard constraints. The difference matters: a goal is something you aim for; a budget is something you enforce.

Why Performance Budgets Work

Without budgets, performance degrades gradually. It's the "boiling frog" problem: no single change makes the site noticeably slower, but over months of new features, additional scripts, and growing page weight, performance erodes until someone finally notices — usually a client, a user, or Google.

Performance budgets prevent this by making degradation visible and actionable the moment it happens.

Benefits of Performance Budgets

Prevent gradual degradation — Every change is checked against the
budget
Create accountability — The team knows what "too slow" means, concretely
Enable automation — Budgets can trigger alerts, block deploys, or flag regressions
Simplify decision-making — "Does this change break the budget?" is a yes/no question
Improve client communication — "Your site is within budget" is clear and reassuring

Types of Performance Budgets

Metric-Based Budgets (Recommended)

Set limits on Core Web Vitals and related metrics:

Metric-based budgets are the most practical because they directly correspond to what Google measures and what users experience.

Resource-Based Budgets

Set limits on the resources that make up a page:

Resource-based budgets are useful during development but less directly tied to user experience. A page can be over the resource budget but still perform well (or vice versa).

Quantity-Based Budgets

Set limits on the number of resources:

Quantity budgets are easy to enforce but can be gamed (bundling everything into one massive file passes the "number of files" budget but creates other problems).

Which Type Should You Use?

Start with metric-based budgets. They're the most meaningful because they measure what users actually experience. Add resource-based budgets as guardrails for development. Use quantity-based budgets sparingly — they're useful for specific constraints (like limiting third-party script count) but shouldn't be your primary tool.

How to Set Performance Budgets

Step 1: Baseline Your Current Performance

Before setting budgets, you need to know where you stand. Run PageSpeed Insights on your key pages (homepage, landing pages, conversion pages) for both mobile and desktop.

Record the current values:

// Example Baseline

Page: Homepage (mobile)
LCP: 3.1 seconds
INP: 280 milliseconds
CLS: 0.08
FCP: 2.1 seconds
TBT: 340 milliseconds
Speed Index: 4.2 seconds
Score: 68

Step 2: Set Budgets Based on Thresholds, Not Current Scores

Don't set your budget at your current score. Set it at the "Good" threshold defined by Google. If your current score is below that threshold, your budget becomes your improvement target.

// Budget Configuration

Page: Homepage (mobile)
LCP Budget: ≤ 2.5s (current: 3.1s — OVER BUDGET)
INP Budget: ≤ 200ms (current: 280ms — OVER BUDGET)
CLS Budget: ≤ 0.1 (current: 0.08 — WITHIN BUDGET)
FCP Budget: ≤ 1.8s (current: 2.1s — OVER BUDGET)
TBT Budget: ≤ 200ms (current: 340ms — OVER BUDGET)
Score Budget: ≥ 90 (current: 68 — OVER BUDGET)

Step 3: Prioritize Which Budgets to Enforce

You probably can't fix everything at once. Prioritize:

LCP — Biggest impact on perceived speed and SEO
CLS — Often the easiest to fix (HTML/CSS changes)
INP — Usually requires JS refactoring, which takes longer
Overall Score — Composite metric that improves as individual metrics improve

Step 4: Enforce Budgets Through Automation

Budgets only work if they're enforced. Options for enforcement:

Monitoring alerts (recommended for most teams):
Set up automated PageSpeed tests that run daily
Configure alerts when any metric exceeds its budget
Review and fix regressions within a defined SLA (e.g., 48 hours)
CI/CD integration (for teams with mature deployment pipelines):
Run Lighthouse in CI and fail the build if budgets are exceeded
Block deploys that regress performance metrics
Require performance review for changes that approach budget limits
Manual review (minimum viable approach):
Run monthly PageSpeed audits
Review results against budgets
Create tickets for budget violations

Step 5: Review and Adjust Quarterly

Performance budgets shouldn't be set once and forgotten. Review them quarterly:

Tighten budgets when your team consistently meets them (set stretch goals)
Adjust budgets when requirements change (e.g., new functionality that legitimately impacts performance)
Add budgets for new pages or new metrics
Remove budgets that aren't actionable or useful

Performance Budgets for Different Site Types

E-Commerce Sites

Content / Blog Sites

SaaS / Web Applications

Agency Client Sites (Default Template)

Common Mistakes with Performance Budgets

Setting Budgets Too Loose
If your budget is "LCP ≤ 5 seconds", you've set a budget that won't catch real problems. Start at Google's "Good" thresholds. If that's too aggressive for your current state, set a temporary budget at your baseline and work towards "Good".
Not Monitoring Both Strategies
Mobile and desktop performance are different. A page might be within budget on desktop but over budget on mobile. Always set and monitor budgets for both strategies.
Only Monitoring the Homepage
The homepage is usually the fastest page because it gets the most attention. Monitor landing pages, product pages, blog posts — the pages that actually drive traffic and conversions.
Setting Budgets and Forgetting Them
Budgets without enforcement are just numbers in a document. Connect them to alerts and make someone responsible for responding when budgets are exceeded.
Treating Budgets as Permanent
As your site evolves, budgets should evolve too. New functionality might justify adjusting a budget. Successful optimisation should lead to tighter budgets. When to temporarily loosen a budget: During a known incident (e.g. CDN outage, migration) or a planned heavy deployment, you can temporarily relax a budget to avoid alert fatigue. Document the reason and set an expiration date (e.g. "Loosen LCP budget to 3.5s until migration completes on March 15"). Revert to normal as soon as the situation is resolved.
Alerting on Natural Variance
Lighthouse scores can fluctuate ±5 points between runs due to network conditions, server load, and test variability. Don't alert on a single test that's 1–2 points below budget. Use cooldowns (e.g. alert only if the metric is over budget for 2+ consecutive tests) or set alert thresholds slightly looser than your budget (e.g. alert at LCP > 2.8s when budget is 2.5s).
Implementing Performance Budgets

Option 1: Monitoring Platform (Easiest)

Use a tool like Apogee Watcher that supports:

Setting metric-based budgets per site and strategy
Automated daily testing against budgets
Alert notifications when budgets are exceeded
Historical tracking to see budget compliance over time

Option 2: Lighthouse CI

For teams with CI/CD pipelines:

Option 3: Spreadsheet Tracking (Manual)

If you're just starting out, even a spreadsheet works. Track scores weekly, colour-code cells (green = within budget, red = over budget), and review during team standups.

Key Takeaway

Performance budgets turn vague performance goals into concrete, enforceable constraints. They prevent gradual degradation, create accountability, and give your team a clear definition of "fast enough."

Start with metric-based budgets at Google's "Good" thresholds. Enforce them through automated monitoring and alerts. Review and tighten quarterly. That's it.

FAQ

What's the difference between a performance budget and a performance goal?
A goal is aspirational ("we'd like to be fast"); a budget is a hard constraint ("we will not exceed 2.5s LCP"). Budgets trigger action when exceeded; goals don't. Budgets enable automation (alerts, CI gates); goals are subjective.

Should I set different budgets for mobile vs desktop?
Yes. Mobile typically lags desktop due to slower networks and devices. Use separate mobile and desktop budgets — for example, LCP ≤ 2.5s mobile and ≤ 2.0s desktop. Many monitoring tools let you configure per-strategy thresholds.

How do I choose thresholds for a site that's currently slow?
Start with your current baseline as the initial budget. That prevents further degradation. Then set stretch goals (Google's "Good" thresholds) and tighten the budget as you fix issues. Don't set an unrealistic budget you'll immediately violate.

Can performance budgets block deployments?
Yes. Lighthouse CI and similar tools can fail CI/CD when budgets are exceeded. For monitoring platforms, budgets typically trigger alerts instead of blocking. Choose alerts for flexibility; use CI gates when you want zero tolerance for regressions.

Want to set and enforce performance budgets across all your sites? Apogee Watcher makes budget management part of automated monitoring. Join the waitlist for early access.

Coder Legion - Recent posts tagged performancebudget

Font Subsetting for Web Performance: 4 Tools to Reduce Font File Size and Improve LCP

What font subsetting is

When font subsetting improves web font performance and LCP

Font subsetting example: hero display copy without the full font file

Four tools for font subsetting

Google Fonts

Font Squirrel Webfont Generator

Everything Fonts Subsetter

FontForge

How to implement font subsets (@font-face, unicode-range, font-display)

Reduce font file size: less data per page view

How to verify LCP and FCP after font subsetting

Common font subsetting mistakes

FAQ

Specd : Five Features. Full Stop.

The buyer does not want a PRD generator

Why five features works

Performance Monitoring for EdTech: What to Measure Across Enrolment, Learning, and Checkout

Why EdTech needs a different monitoring approach

Map metrics to the learner journey

1) Discovery and enrolment

2) First learning session

3) Ongoing study and assessment

4) Educator and admin workflows

Core metrics for EdTech teams

Core Web Vitals

Supporting technical metrics

Outcome-linked product metrics

Device and network realities in education

Synthetic monitoring, field data, and in-app telemetry

Alerting policy that avoids fatigue

Tier 1: learner-critical alerts (immediate)

Tier 2: quality drift alerts (daily review)

Tier 3: planning signals (weekly)

Third-party dependencies in learning platforms

A practical 30-day rollout plan

Week 1: define route groups and success metrics

Week 2: instrument baseline monitoring

Week 3: add alert tiers and ownership

Week 4: connect performance to product review

Where Apogee Watcher fits for EdTech teams

FAQ

Summary

Monthly Performance Review Template for Agency Teams

What we mean by a monthly performance review

Use this template as a meeting script

Internal review first, then the client

Why this format works for agencies

A practical scoring model for monthly status

What to prepare before the meeting

After the meeting: outputs that close the loop

Common mistakes this template avoids

1) Mixing diagnosis with decision-making

2) Reporting averages only

3) No link between performance and client impact

4) Too many priorities

Suggested monthly cadence

FAQ

Third-Party Scripts and Performance: How to Identify and Fix the Worst Offenders

What “third party” really means in performance work

Step 1: Get a defensible list of what actually loads

Step 2: Use Lighthouse to rank third-party cost (not just bytes)

Step 3: Use DevTools to find the moment a script hurts

Step 4: Map findings to CWV and business impact

Step 5: Fix patterns that work in production

Step 6: Prove the change and set a floor so it sticks

FAQ

Image Optimisation Strategies for Better LCP Scores

Start by identifying the real LCP element

Pick modern formats and tune quality deliberately

Match dimensions to rendered size, not to the asset library

Use srcset and sizes so the browser picks a sane file

Loading order: preload, priority, and lazy boundaries

CSS background images and LCP

Third-party CDNs and transforms

CMS uploads and the “full size” trap

Verify in the lab, then confirm in the field

Tie optimisation to budgets and ownership

What to do next

How to implement font subsets (`@font-face`, `unicode-range`, `font-display`)

Use `srcset` and `sizes` so the browser picks a sane file

Minimal `lighthouserc` (assertions + collect)

Resource limits: `budgetsFile` vs assertions