Coder Legion - Recent posts tagged web-performance

Top No-Code Form Builders to Capture Leads on Blogging Sites

Tue, 13 Oct 2026 15:04:13 +0000

A blog can attract readers through search engines, social media, and referrals without generating a single business inquiry. The problem is not always a lack of traffic. Visitors need a clear way to subscribe to a newsletter, request a service, download a resource, or contact the publisher.

No-code form builders solve this problem by allowing bloggers to create lead capture forms without writing code. Depending on the platform, these tools can collect email addresses, organize customer inquiries, connect submissions to marketing software, and send notifications when someone completes a form.

The right tool depends on how a blog operates. A WordPress publisher may prefer a form plugin that works inside the dashboard, while a blogger using Ghost, Webflow, or another website platform may benefit from an embeddable form service. Businesses that need a customer relationship management system (CRM) may also want a builder that sends contact information directly into their sales database.

Here are seven no-code form builders worth considering for lead generation on blogging websites.

HubSpot Forms: Best for Managing Leads in a CRM
HubSpot Forms is a strong option for bloggers who want to do more than collect email addresses. Its form builder connects lead capture with contact management, allowing submitted information to enter HubSpot's CRM.

The platform provides a drag-and-drop editor and templates for use cases such as newsletter subscriptions, ebook downloads, event registrations, and other lead generation activities. HubSpot also supports standalone forms and forms published on websites. Official HubSpot documentation explains these capabilities.

For a blog that publishes marketing guides, business tutorials, or industry research, this integration can simplify the process of turning readers into contacts. A visitor who requests a downloadable guide can become a recorded contact rather than an entry that remains isolated in a form builder.

HubSpot also offers follow-up capabilities, including automated emails and lead nurturing features. The availability of specific automation and personalization functions depends on the subscription and product features involved.

Best use cases: Business blogs, marketing publications, consultancy websites, and publishers that want to build a contact database.

Main advantage: Form submissions can feed directly into HubSpot's CRM, reducing the need to transfer contact information manually.

What to consider: HubSpot's wider marketing features may be unnecessary for a small blog that only needs a basic newsletter signup. Review the available plan limits and the requirements of any automation you intend to use before committing.

WPForms: Best for WordPress Blogs
WPForms is a WordPress form plugin designed for users who want to create forms through a visual editor. It supports contact forms, lead generation forms, and other data collection use cases without requiring users to build the forms from scratch.

Its Lead Forms addon allows a form to present questions one at a time, using page breaks to divide the submission process into smaller steps. WPForms also documents features such as conditional logic, spam protection, entry management, notifications, and integrations with email marketing services. See the official WPForms Lead Forms documentation.

For bloggers, the main benefit is the ability to manage forms within the WordPress environment. A publisher can create a newsletter signup form, add a contact form to a service page, or collect inquiries from readers interested in a product recommendation.

Consider a blog about personal finance that publishes a guide to budgeting. The publisher could place a form on the page offering a downloadable budget planner in exchange for an email address. The form becomes a direct route from the article to the publisher's mailing list, provided the necessary email marketing integration and subscription settings are configured.

WPForms is particularly relevant to bloggers who want control over form placement and submission management without maintaining a separate form-building account for every basic website form.

Best use cases: WordPress blogs, affiliate websites, professional blogs, and publishers that collect reader inquiries.

Main advantage: The plugin works within WordPress and provides a visual form-building process.

What to consider: Some lead generation features and integrations depend on the relevant addon or paid plan. Confirm which license includes the functions you need before purchasing.

Tally: Best for Bloggers Seeking a Generous Free Plan
Tally is an online form builder that offers a free plan with unlimited forms and submissions, subject to its fair-use guidelines. Its listed features include conditional logic, file uploads, payment collection, custom thank-you pages, email notifications, and integrations with services such as Google Sheets, Notion, Airtable, Zapier, and Make. Tally's official pricing page lists its current free-plan offering.

One of Tally's useful features for bloggers is its website embedding support. Publishers can embed forms directly into web pages, display them in popups, or use full-page embeds. Tally documents these options in its official embedding guide.

This makes the service suitable for bloggers who do not want to install a dedicated WordPress plugin or maintain a complex marketing platform. A publisher can build a reader survey, a newsletter interest form, or a request form for a free resource and then place it within a relevant article.

For example, a travel blogger could embed a form in a destination guide and ask readers to subscribe for future itinerary recommendations. A technology blogger could collect questions from readers who want a follow-up tutorial on a specific topic.

Tally can also connect form submissions to external tools, helping publishers organize responses and route information to other applications. Its integration options are useful when a blog's email marketing or customer management system sits outside the form builder.

Best use cases: New bloggers, independent publishers, niche websites, and creators who want to test lead capture before paying for a dedicated service.

Main advantage: The free plan includes unlimited forms and submissions, subject to fair-use guidelines.

What to consider: Some advanced features, including removing Tally branding, require a paid plan. Check the current plan details if branding control is important to your website.

Typeform: Best for Interactive Lead Capture
Typeform is designed for forms that present questions in an interactive format. Rather than relying exclusively on a conventional list of fields, publishers can build a guided question-and-answer experience.

This approach can be useful when a blogger needs more information than a name and email address. A marketing blog, for example, could ask visitors about their business size, main challenge, and preferred service before requesting contact details.

Typeform supports website embedding in several formats, including standard, full-page, popup, slider, popover, and side-tab presentations. Its official embedding documentation explains the available options.

The platform also provides integrations with other applications. Its documentation identifies services such as Mailchimp and Airtable among the integrations available on the Free plan, although the number of responses and other restrictions depend on the selected subscription. See Typeform's plan guidance.

For a blog that sells consulting services or publishes specialized industry advice, interactive forms can help qualify inquiries before a conversation begins. The publisher can use answers to identify the type of assistance a visitor wants and direct the submission to the appropriate follow-up process.

However, more questions do not automatically produce better leads. Every additional field creates another task for the visitor. Use conditional logic where available and ask only for information that serves a clear purpose.

Best use cases: Consulting blogs, business publications, niche expert websites, and publishers that need more detailed reader information.

Main advantage: Interactive forms and multiple embedding options provide flexibility in how visitors submit information.

What to consider: Typeform limits responses according to the selected plan. Its free offering is intended for limited use, so check the current response allowance before placing a form on a high-traffic blog.

Jotform: Best for Blogs That Need Versatile Forms
Jotform is a general-purpose online form builder with a visual editor, form templates, integrations, and several publishing options. It is suitable for bloggers who need to collect more than newsletter subscriptions.

A publisher might use Jotform to collect guest post proposals, organize event registrations, receive reader feedback, or gather inquiries from prospective clients. Its range of form fields also supports more detailed submissions than a basic email signup.

Jotform supports embedding through methods including JavaScript and iframe code. It also provides publishing options for website platforms and content management systems, including WordPress, Wix, Squarespace, Ghost, and Blogger. The appropriate option depends on the website and the form's requirements. Jotform's official embedding guide explains the available methods.

The JavaScript embed can reflect changes made in the form builder without requiring the publisher to replace the original embed code. Jotform's documentation also describes iframe embedding as an alternative when a site experiences conflicts with other scripts.

This flexibility can be helpful for bloggers who operate several websites or publish through different platforms. Instead of building a separate form from scratch for every use case, they can create forms for specific tasks and publish them where needed.

Jotform offers a Starter plan, along with paid tiers that increase available limits. Its free plan includes standard features but applies restrictions to usage, and forms include Jotform branding until the user upgrades. Consult the official Jotform pricing page for the current limits.

Best use cases: Multi-purpose blogs, event-focused publications, professional service websites, and publishers collecting detailed inquiries.

Main advantage: Multiple embed methods and a broad range of form-building features.

What to consider: Review submission limits, storage allowances, branding restrictions, and the features available under the plan you intend to use.

Formidable Forms: Best for Advanced WordPress Lead Forms
Formidable Forms is another WordPress form plugin, with features that extend beyond basic contact forms. Its official feature listings include conditional logic, multi-page forms, file uploads, payment forms, surveys, and tools for displaying submitted information on a website. See the Formidable Forms WordPress plugin listing.

For bloggers, these capabilities are useful when a form needs to collect structured information. A business blog might collect project requirements from prospective clients, while a property publication could use forms to gather detailed inquiries from readers.

The plugin also supports integrations with email marketing services. Its paid plans list additional integrations, automation capabilities, and tools for more advanced form-based applications. Available features depend on the license selected.

A practical example is a website that publishes tutorials for freelancers. The publisher could build a project inquiry form with fields for service type, budget range, deadline, and contact information. Conditional logic could display relevant questions based on the service selected, where the selected plan supports that functionality.

Formidable Forms is worth considering when the blog needs to do more with submissions than simply forward an email notification. Its data display features can also support websites that need to publish or organize information collected through forms.

Best use cases: WordPress business blogs, professional directories, service providers, and websites with complex data collection requirements.

Main advantage: Advanced form logic and options for working with submitted information.

What to consider: Its broader feature set may be unnecessary for a blog that only needs a simple newsletter signup. Check the current license details for integrations and advanced features before buying.

Mailchimp Embedded Signup Forms: Best for Growing an Email Newsletter
Mailchimp is worth considering for bloggers whose primary goal is to build an email subscriber list. Its embedded signup forms allow publishers to collect email addresses directly on their websites and send subscriber information to a selected Mailchimp audience.

The platform lets users customize form fields, adjust field order, add help text, and generate embed code for their websites. Mailchimp documents support for embedding signup forms on platforms including WordPress, Blogger, and Weebly. Read Mailchimp's official embedded signup form guide.

This makes Mailchimp useful for blogs that publish recurring content and want a direct channel for reaching readers. A food blogger, for example, could place a subscription form below recipes and invite visitors to receive future recipe updates. A technology publisher could collect subscribers interested in software tutorials or product comparisons.

Mailchimp also provides options for tracking where subscribers joined an audience. Publishers can use separate forms or tags to identify signups from different website pages, helping them understand which content attracts subscribers. Some tracking configurations require additional setup. See Mailchimp's documentation on identifying signup locations.

There is one important limitation. Mailchimp's documentation notes that embedded form code may need to be replaced after changes are made to the form. Publishers should also test the form on their live website to verify that submissions and confirmation messages work correctly.

Best use cases: Newsletter-focused blogs, food websites, lifestyle publishers, and content creators who want to build an email audience.

Main advantage: Signup forms connect directly to a Mailchimp audience, keeping subscriber collection close to the email marketing process.

What to consider: Some customization requires editing code, and available marketing features depend on the selected plan. Review the current subscription terms before choosing Mailchimp.

How to Choose the Right No-Code Form Builder for Your Blog
Before installing a plugin or embedding a third-party form, identify the exact information you need to collect and what should happen after a visitor submits it.

Define the lead you want to capture
A newsletter subscriber is different from a prospective client. Newsletter forms often need only an email address and, where appropriate, a first name. A service inquiry may require additional information to determine whether the request is relevant.

Do not collect personal information without a clear reason. Shorter forms are generally easier to complete, and unnecessary questions can discourage submissions.

Check compatibility with your publishing platform
WordPress users can consider WPForms and Formidable Forms. Bloggers using other platforms can evaluate embeddable options such as Tally, Typeform, and Jotform.

Before publishing, verify that your website editor permits the required embed method. Test the form on the live page, not only inside the builder's preview.

Confirm where submissions will go
A form is useful only if someone can access and act on the information it collects. Determine whether submissions should remain in the form builder, enter a spreadsheet, join an email marketing list, or go into a CRM.

Verify that the necessary integration is available on your chosen plan. If the integration requires a paid subscription, include that expense in your decision.

Review usage limits and total cost
Free plans can be useful for testing a new lead generation strategy. However, limits on submissions, branding, integrations, and automation may become important as the blog grows.

Compare the features included in each plan rather than relying on a headline price. Check billing terms and renewal prices before purchasing.

Test the form on mobile devices
Readers may arrive through mobile search results or social media links. Check that the form fits the page, its fields are readable, and the submit button works correctly on smaller screens.

Also test the confirmation message, notification delivery, and any connected email marketing or CRM system. A successful submission should reach the intended destination.

Place forms where they serve the article
A form should relate to the content surrounding it. A recipe blog could offer a newsletter featuring new recipes, while a technology blog could invite readers to receive additional tutorials.

Relevant forms give visitors a clear reason to subscribe or make an inquiry. Avoid placing intrusive forms over the content before readers have had a reasonable opportunity to engage with the page.

Final Verdict
The best no-code form builder for a blogging website depends on its publishing platform, lead generation goals, budget, and follow-up requirements.

HubSpot Forms is a strong choice for publishers who want form submissions connected to a CRM. WPForms is a practical option for WordPress bloggers who need a visual form builder within their existing website. Tally is worth considering for creators seeking a free starting point with unlimited forms and submissions under its fair-use guidelines.

Typeform suits publishers who want interactive questionnaires, while Jotform offers versatile form creation and publishing options. Formidable Forms is better suited to WordPress websites that need advanced logic or more sophisticated ways to use submitted data.

Start with the simplest tool that meets your requirements. Build one form around a specific goal, connect it to the correct destination, test the entire submission process, and monitor the results. Upgrade only when a documented limitation prevents the blog from carrying out its lead generation strategy.

Fixing Zero-Click Technical Articles

Wed, 07 Oct 2026 18:04:14 +0000

Technical Context and Real Problem

In technical documentation, engineering blogs, and developer hubs, content teams routinely fall victim to the page-one zero-click paradox. An article achieves top-ten ranking positions in Google Search Console with strong impression volume, yet registers near-zero click-through rates. During an empirical audit of RayLabs across production technical articles, data revealed a sharp disconnect between ranking power and reader conversion.

Authors naturally write titles from a taxonomic, librarian perspective. However, a developer whose integrated development environment lost its connection does not search for abstract disconnection analysis. They search for the exact symptom observed on their physical device. When a command-line tool fails, developers copy-paste terminal output directly into search engines. Because standard meta titles omit literal error strings, users skip the snippet in favor of forum answers containing the exact phrase. Addressing this mismatch requires categorizing search queries into distinct developer intent archetypes and adjusting title architecture accordingly.

Architectural Decision and Trade-offs

To bridge the gap between search impressions and developer clicks, technical content creators can apply the developer intent title framework, which sorts queries into specific archetypes.

The Three Developer Search Archetypes

Literal Error String Intent: This is triggered by terminal exceptions, exit codes, daemon crashes, or compiler diagnostics. The query pattern relies on exact string matching, such as error codes or missing device notifications. The title architecture should place the literal error string within the first thirty characters, followed by a colon and the pragmatic resolution.
Symptom or State Drift Intent: This is triggered by background process termination, battery optimization killing daemons, or silent socket drops. The query pattern uses active verb phrases describing unwanted degradation, such as processes keeping turning off or stopping after sleep. The title architecture mirrors the active verb phrase directly rather than converting it into a formal noun.
Operational Configuration Intent: This is triggered by setting defaults, switching profiles, passing command-line flags, or configuring local environments. The query pattern uses action verbs followed by configuration parameters, such as setting default models or overriding configuration paths. The title architecture leads with the tool name and an actionable imperative command. For a related implementation, see Mastering List To String Conversion In.

Title Mutation Risk Management

Modifying the title tag of a page that already ranks on page one carries inherent risks, as careless rewrites can strip away legacy keyword anchors and cause algorithmic volatility. To mitigate this risk, the primary entity noun must remain within the first thirty-five characters of the title. Creators should replace passive editorial descriptors with empirical high-impression queries mined directly from search console data. Furthermore, desktop and mobile display limits must remain between fifty and sixty characters to prevent truncation of intent keywords.

When editorial branding requires a clean literary title on the page canvas while search discovery demands literal error tokens, content teams can use the main title for on-page presentation and the meta title for search engines and schema markup.

Configuration Example

To update your HTML metadata and structured data to serve intent-driven titles without changing your visible on-page H1, configure your document header like this:

<head>
  <title>ADB Device Not Found / Not Detected? Fix USB Debugging Fast</title>
  <meta name="description" content="Fix ADB device not found errors quickly with proven USB debugging troubleshooting steps.">
  <script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "TechArticle",
    "headline": "ADB Device Not Found / Not Detected? Fix USB Debugging Fast",
    "description": "Fix ADB device not found errors quickly with proven USB debugging troubleshooting steps."
  }
  </script>
</head>

Reusable Takeaways

Mine Impressions with Zero Clicks: Query search console data for queries with high impressions and near-zero clicks to identify missing user vocabulary.
Prioritize Pain Verbs: Developers search with active symptom verbs rather than formal catalog nouns.
Front-Load Literal Errors: Place exact error strings and codes within the first thirty characters of the metadata title.
Enforce Character Limits: Keep metadata titles between fifty and sixty characters to ensure mobile and desktop readability without truncation.

Conclusion and Next Steps

Developers search with pain verbs and literal error messages rather than catalog nouns. By mining impressions with zero clicks in search console data and enforcing character boundaries, technical writers can capture targeted developer traffic reliably. Review your top-performing low-CTR pages, adjust their meta titles to reflect true search intent, and monitor performance shifts over a fourteen-day window.

Programmatic SEO Tag Density and Entity Hubs

Mon, 05 Oct 2026 06:04:07 +0000

Blogging platforms and content management systems historically popularized tag taxonomies by automatically generating a dedicated archive route for every tag applied to a post. While this appeared to expand the site indexable surface, in production environments it routinely causes severe technical SEO regressions. On RayLabs, an audit revealed 291 unique tags across 195 approved articles, but 201 tags or 69 percent were singletons attached to only a single post. Generating public landing pages for singletons creates low-value doorway pages that search engine crawlers classify as soft 404 or thin content, diluting overall site domain authority.

When a site maintains broad topical pillars such as android-mobile or developer-tools, creating redundant tag pages like android-mobile or developer-tools causes severe internal competition in search engine result pages, splitting backlinks and confusing search crawler intent. Furthermore, search engine bots spend valuable crawl budget fetching hundreds of near-identical single-article tag pages instead of indexing newly published, high-value technical guides. To solve these issues while capturing long-tail programmatic keyword benefits, RayLabs engineered a deterministic density threshold gate.

Implementing the Density Threshold Gate

The architecture relies on empirical density thresholds and strict routing rules to separate high-value entity hubs from thin content traps. Only tags associated with three or more approved canonical articles, or explicitly defined in a curated metadata registry, qualify to generate static HTML landing pages at the tags path. Singletons and low-density tags with fewer than three articles never generate static landing pages and are excluded from the XML sitemap. Instead of breaking or dead-ending, clicking a thin tag dynamically routes the user to a filtered catalog search query, providing excellent search UX without creating indexable crawler traps.

Before evaluating tag density, the taxonomy router checks the topic slug. Any tag matching a canonical pillar topic automatically resolves to the topics path. This enforces a single authoritative canonical source for core themes. Rather than relying on naive title-casing which mangles technical terms, the engine maintains an exact-brand dictionary for terms like CI/CD, Jetpack Compose, CameraX, WorkManager, Room Database, macOS, and SEO. For a related implementation, see Audit Macos System Data Before Deleting.

Structured Data and Internal Linking Mesh

Every qualified hub is enriched with human-crafted technical descriptions defining the engineering scope of the entity. Pages render valid schema collection page structured data with nested breadcrumb lists and item lists containing all tagged guides. In individual article headers, passive tag labels are transformed into semantic tokenized links pointing directly to the hub. Hubs feature a related sibling tags bar displaying co-occurring high-density tags, creating a tight topical mesh that circulates page rank and reduces bounce rates.

function evaluateTagRouting(tag, articleCount, isPillar) {
  if (isPillar) {
    return { route: `/topics/${tag}/`, type: 'canonical_pillar' };
  }
  if (articleCount >= 3) {
    return { route: `/tags/${tag}/`, type: 'static_hub' };
  }
  return { route: `/articles/?q=${tag}`, type: 'dynamic_fallback' };
}

Conclusion and Architectural Summary

Preventing search engine penalties from programmatic tags requires moving away from indiscriminate page generation. By enforcing strict minimum article density gates, redirecting overlapping terms to canonical pillars, and turning thin tags into dynamic search fallbacks, you protect crawl budget and maintain high editorial standards across large technical publishing platforms.

Building a Zero-Jank CSS Logo Marquee

Sun, 04 Oct 2026 00:11:39 +0000

Integrating community badges, open-source repositories, and syndicated profiles into static engineering sites often creates unexpected performance bottlenecks. Many teams pull in thirty-kilobyte carousel libraries or JavaScript animation engines just to display moving brand icons. These scripts execute continuously on the main thread, trigger Cumulative Layout Shift, and degrade mobile performance scores. Placing social proof directly below the hero header competes with primary calls-to-action, while brittle third-party API timeouts during static site generation frequently cause builds to fall back to hardcoded snapshots containing deleted or renamed repositories. For a related implementation, see Integrating Open Source Ai Tooling Ci.

To resolve these issues without compromising speed, accessibility, or build determinism, you can engineer a lightweight, CSS-only ambient syndication architecture. This approach replaces heavy scripts with a GPU-accelerated ticker, ensures strict compliance with reduced-motion preferences, and implements a deterministic fallback pipeline.

The Mathematics of Seamless CSS Marquees

Instead of relying on JavaScript animation loops that recalculate layout during frames, the marquee runs purely on hardware-accelerated transforms using transform: translateX(). Achieving a seamless infinite loop without visual popping requires careful item duplication. If your dataset contains $N$ platforms, repeating the array four times yields $4N$ items in the track. Translating the track container by calc(-50% - 1.75rem) means that exactly $2N$ items cycle before snapping invisibly back to the origin.

.marquee-container {
  overflow: hidden;
  width: 100%;
  mask-image: linear-gradient(to right, transparent 0%, black 7%, black 93%, transparent 100%);
}

.marquee-track {
  display: flex;
  width: max-content;
  animation: scroll-ticker 35s linear infinite;
}

.marquee-track:hover {
  animation-play-state: paused;
}

@keyframes scroll-ticker {
  0% {
    transform: translateX(0);
  }
  100% {
    transform: translateX(calc(-50% - 1.75rem));
  }
}

Rather than placing opaque pseudo-elements over the edges of the ticker, which can block pointer events and break on varied backgrounds, the code uses mask-image: linear-gradient(). This applies true alpha clipping at the container edges, allowing seamless fading while preserving full interactivity for underlying elements.

Accessibility and State Management

Static and moving components must remain usable across input modalities and user preferences. By default, marquee items appear in a muted monochrome state with reduced opacity to prevent visual distraction. Hovering or focusing an item pauses the animation track, slightly scales the target element, and restores its full brand identity. For a related implementation, see Prevent Private Urls Leaking Static Site.

To respect user vestibular motion preferences, a media query disables the animation entirely and falls back to a clean flex-wrap layout:

@media (prefers-reduced-motion: reduce) {
  .marquee-track {
    animation: none;
    flex-wrap: wrap;
    justify-content: center;
  }
}

Furthermore, all decorative elements are hidden from screen readers using aria-hidden="true", and interactive containers maintain touch targets of at least forty-four pixels.

Resilient Static Site Generation Ingestion

When fetching dynamic third-party data during static site generation, tight timeouts and unvalidated mock responses can corrupt your production output. If an API request times out and falls back to stale data containing deleted repositories, those ghost entities get permanently baked into your output HTML.

To prevent this, extend your fetch timeout boundary to at least thirty-five hundred milliseconds with proper authorization headers, and subject your fallback dataset to the same rigorous validation as your live API responses. Purge deprecated records regularly during build configuration updates.

Summary of Architectural Decisions

Replacing heavy JavaScript sliders with GPU-accelerated CSS transforms and robust static ingestion pipelines eliminates layout shifts while keeping your codebase maintainable. By relying on native browser layout compositing, proper alpha masking, and strict build-time validation, you can showcase community contributions reliably without sacrificing site performance.

Build a Lightweight CSS Marquee Without Damaging Web Vitals

Sat, 03 Oct 2026 05:14:58 +0000

Infinite tickers and scrolling marquees are a frequent requirement for showcasing partner logos, engineering badges, or featured announcements on modern marketing sites. Yet, many implementations rely on third-party JavaScript libraries or heavy animation wrappers that degrade performance. When a marquee is driven by JavaScript style updates on every frame, it blocks the main thread, inflates Total Blocking Time, and triggers costly layout recalculations. Developers need a way to create continuous visual movement that remains buttery smooth without sacrificing user experience or performance scores. For a related implementation, see App Updates Play Vs Managed Devices.

The Performance Cost of JavaScript Marquees

Traditional ticker scripts rely on requestAnimationFrame loops or timer intervals to mutate element positions on every tick. This approach forces the browser to recalculate styles and geometry during the layout phase for every active frame. On mobile devices or lower-powered hardware, this constant recalculation drops frame rates below sixty frames per second and elevates Total Blocking Time. Furthermore, dynamic DOM node insertion during script initialization can trigger sudden content jumps, ruining Cumulative Layout Shift metrics before the page fully settles. For a related implementation, see Memory Optimization Low Ram Devices.

The Double-Track Duplication Pattern

To achieve a seamless infinite loop without JavaScript calculations, you can structure the HTML with a parent container and two identical track children. Each track contains the exact same sequence of items. When the container width is set to fit the content of a single track, duplicating that track ensures that as the first set of items scrolls completely out of view, the second set seamlessly takes its place.

<div class="marquee-container">
  <div class="marquee-track">
    <div class="marquee-group">
      <span>Acme Corp</span>
      <span>Beta LLC</span>
      <span>Gamma Inc</span>
    </div>
    <div class="marquee-group" aria-hidden="true">
      <span>Acme Corp</span>
      <span>Beta LLC</span>
      <span>Gamma Inc</span>
    </div>
  </div>
</div>

Setting the second group with aria-hidden="true" ensures that screen readers do not read the duplicated items twice, preserving a clean accessibility tree.

GPU Compositing with 3D Transforms

Performance relies entirely on choosing the right CSS properties to animate. Animating layout properties like margin-left or left forces the browser to repeat layout and paint steps continuously. By contrast, using hardware-accelerated transforms shifts the workload entirely to the GPU compositor thread.

.marquee-container {
  overflow: hidden;
  width: 100%;
  display: flex;
}

.marquee-track {
  display: flex;
  width: max-content;
  animation: scroll-marquee 30s linear infinite;
}

.marquee-group {
  display: flex;
  gap: 2rem;
  justify-content: space-around;
  min-width: 100%;
}

@keyframes scroll-marquee {
  0% {
    transform: translate3d(0, 0, 0);
  }
  100% {
    transform: translate3d(-50%, 0, 0);
  }
}
}

Because the track contains two identical groups side by side, translating the entire track by negative fifty percent moves exactly one full group width before looping back to zero instantly and invisibly.

Zero CLS Containment

Layout shifts often occur when dynamic components load fonts or images after initial render. To prevent the marquee container from causing layout instability during hydration, enforce strict CSS containment. By applying explicit height constraints and sizing properties to the container, the browser reserves the exact layout box ahead of time.

.marquee-container {
  contain: layout size;
  height: 4rem;
}

This containment rule tells the optimization engine that the internal layout of the marquee does not affect outside document elements, eliminating unexpected reflows during load.

Polishing with CSS Edge Masks

Fading out the left and right edges of a scrolling marquee provides a polished visual finish without adding extra structural DOM nodes or overlapping gradient overlays. The mask-image property applies a linear alpha gradient directly to the element rendering surface.

.marquee-container {
  mask-image: linear-gradient(
    to right,
    transparent,
    black 15%,
    black 85%,
    transparent
  );
}

This composited mask ensures that items fade smoothly into view at the container boundaries, adapting cleanly to any background color or theme.

Accessibility and User Control

Continuous motion can cause discomfort for users with vestibular disorders. Providing clear ways to pause or disable the animation is both an ethical necessity and a requirement for strict accessibility compliance. You can pause movement on hover or keyboard focus, and completely disable it for users who prefer reduced motion.

.marquee-container:hover .marquee-track,
.marquee-container:focus-within .marquee-track {
  animation-play-state: paused;
}

@media (prefers-reduced-motion: reduce) {
  .marquee-track {
    animation: none;
    transform: none;
    overflow-x: auto;
  }
}

By adding these rules, users retain full control over their reading experience, and keyboard navigators can interact with the content inside the ticker without struggling against moving targets.

Conclusion

Implementing an infinite ticker no longer requires heavy JavaScript plugins or complex timer loops. By combining a double-track flexbox structure, GPU-accelerated transforms, CSS edge masks, and strict accessibility safeguards, you can deliver smooth visual motion that protects Core Web Vitals and runs efficiently across all devices.

Cloudflare and PSI Automation: Challenges, Allowlists & Monitoring

Fri, 18 Sep 2026 07:04:00 +0000

The same client URL opened in PageSpeed Insights from a laptop often completes. Put that URL on a schedule, call the PageSpeed Insights API from a monitoring stack, or re-run Lighthouse through a headless pipeline, and the document request returns a Cloudflare challenge, a 403, or an empty error shell. The score that ends up in the ticket is not a Core Web Vitals regression. It is a security edge deciding that automation is not a visitor worth serving HTML.

That contrast is the whole problem for agencies. Manual checks feel fine, so the account team trusts the green screenshot. Overnight automation red-flags the homepage, clients ask what broke, and engineering digs into LCP subparts on a page that never reached the real document. Cloudflare is doing its job. Monitoring is measuring the wrong response. What follows is how to tell those cases apart, which Cloudflare controls usually cause them, and how to allow legitimate PageSpeed Insights traffic without opening the site to every scraper on the internet.

For the wider network path (DNS, TLS, CDN cache), see Network Performance for Web Teams: DNS, TLS, HTTP, CDN, and Cache Rules. That guide covers where edge routing and cache hits change Time to First Byte before paint work begins. For why one-off PageSpeed Insights runs are a weak substitute for a schedule, see PageSpeed Insights vs Automated Monitoring: When Manual Checks Aren't Enough.

Why PageSpeed Insights works in a browser but fails under Cloudflare automation

PageSpeed Insights and Lighthouse need a full HTML document, then a rendered page, to compute lab metrics. An interactive browser session often looks enough like a human visitor for Cloudflare to pass the first request, especially if cookies from a prior challenge exist, JavaScript challenges can run, or the operator is on a residential network that is not already associated with bulk scraping. Scheduled and API-driven runs typically do not share that context. They arrive from data-centre ranges, use predictable automation User-Agents (including Chrome-Lighthouse strings), lack challenge cookies, and cannot complete managed challenges the way a person with a browser can.

Path	Typical Cloudflare outcome	What Lighthouse / PageSpeed Insights measures
Interactive browser PageSpeed Insights / DevTools	Often allowed after challenge or soft pass	Real HTML and assets (when allowed)
PageSpeed Insights API / scheduled headless	Challenge interstitial, 403, connection error	Challenge page, error document, or failed fetch
Monitoring tool from fixed egress IPs	Blocked until IP Access or Skip rule exists	Same failure modes until allowlisted

When the fetch fails, Google’s tooling often surfaces messages such as ERRORED_DOCUMENT_REQUEST or a generic connection failure. In Cloudflare Security Events you may see Bot Fight Mode, Super Bot Fight Mode, a WAF custom rule, rate limiting, or Under Attack Mode labelled against the same URL. Treating that as an LCP incident wastes a sprint; treat it as automation that never received the origin HTML.

Agencies also hit a quieter failure: the run “succeeds” but the lab screenshot shows a Cloudflare interstitial or a stripped challenge document. Scores look absurdly bad or oddly empty. Field data in PageSpeed Insights can still look normal when enough real users reach the site, which is another reason not to collapse lab and field into one narrative. For missing URL-level field metrics, see When PageSpeed Insights Shows No CLS or INP for Your URL. For when synthetic and real-user signals should disagree on purpose, see When to Use Synthetic vs Real User Monitoring for Performance.

Which Cloudflare controls block PageSpeed Insights and Lighthouse

Several Cloudflare products can interrupt PageSpeed Insights automation. They are not interchangeable, and some cannot be bypassed with the allowlist patterns people copy from blog posts. Matching the failed run to the right product saves a week of rewriting Largest Contentful Paint budgets on a document that never left the edge.

Bot Fight Mode (free)

Cloudflare documents that Bot Fight Mode challenges traffic matching known bot patterns and that you cannot bypass or skip it with WAF custom rules or Page Rules, because it does not run on the Ruleset Engine. If portfolio monitoring is blocked and Bot Fight Mode is on, Skip rules aimed at Chrome-Lighthouse will not save you. Cloudflare’s own guidance points teams toward Super Bot Fight Mode when they need exceptions, or toward IP Access rules that match the connecting IP before Bot Fight Mode evaluates the request.

Super Bot Fight Mode (Pro and above)

This product adds configurable actions and supports Skip actions in WAF custom rules. It is the practical path when you need to allow verified bots or monitoring User-Agents while still challenging other automated traffic. Misconfigured “Definitely automated” or “Likely automated” actions still catch Lighthouse and PageSpeed Insights traffic that Cloudflare does not classify as a verified bot.

Under Attack Mode

This mode raises friction for almost everyone. Community threads regularly report PageSpeed Insights failing with ERRORED_DOCUMENT_REQUEST while Under Attack Mode is enabled, even when a User-Agent allowlist appears to match in the logs. Temporary attack posture and continuous performance monitoring do not coexist cleanly unless verified bots (Known Bots) are explicitly skipped from remaining security checks. Under Attack Mode fits active incidents; it is a poor permanent monitoring configuration.

WAF custom rules and managed rules

Country blocks, ASN blocks, rate limits, and managed rule sets can 403 Google’s lab infrastructure or your monitoring egress. A rule that challenges “automated” traffic without an earlier Skip for known good bots will catch PageSpeed Insights. Order matters: exceptions for verified bots and monitoring IPs need to run before the block or challenge.

Rate limiting and Bot Management scores

Burst schedules across many URLs on one hostname can trip rate limits even when a single manual test works. Enterprise Bot Management customers can use score fields for finer thresholds; most agency clients on Free or Pro still need coarser Skip / IP Access patterns. When you investigate a Cloudflare block on PageSpeed Insights, open Security Events for the exact timestamp of the failed run, note the Service label, and match it to the product above before you rewrite Largest Contentful Paint budgets. Guessing “CDN is slow” from a challenged document wastes time that belongs in the security configuration, so screenshot the event for the client ticket so the zone admin sees the same evidence you used.

Origin versus edge: what a blocked lab run is actually measuring

A healthy synthetic run should measure the HTML and assets your visitors receive after Cloudflare’s edge has applied caching and routing, not a challenge interstitial and not a bypass that skips the edge entirely unless that bypass is intentional. Mixing those paths without labels is what makes weekly scores look volatile when nothing in the application changed. Three measurement modes show up in agency work:

Edge as users see it. Requests go through Cloudflare with the same security posture as public traffic, except for narrow exceptions for known good lab traffic. This is the default you want for scheduled PageSpeed Insights once allowlists are correct.
Challenge / block response. Automation measures Cloudflare’s security HTML or a failed document fetch. Lab metrics are invalid for Core Web Vitals decisions. Report the failure as a monitoring access issue, not as a performance regression.
Origin-direct bypass. Some teams point monitors at the origin hostname or an IP Access “grey cloud” path so tests always pass. That can prove origin PHP or application latency, but it is not the same as visitor experience through the CDN. Use it as a diagnostic split, labelled clearly, not as the only portfolio score.

In our experience, the worst client reports skip those labels. One week’s “green” run used a temporary Under Attack exception; the next week’s “red” run hit Bot Fight Mode again. The narrative looks like volatility. The cause is inconsistent access to the document.

Origin and edge stay honest the same way Cache-Control stays honest: name which hostname, which Cloudflare mode, and which allowlist were in effect for the run you are quoting. Pair that with fixed performance budgets so a challenge-induced score does not auto-open a “fix LCP” ticket. Budget templates live in Performance Budget Thresholds Template.

Allowlists that work: verified bots, IP Access, and Skip rules

There is no single checkbox labelled “allow PageSpeed Insights forever.” You assemble a small set of exceptions that match how Cloudflare classifies the traffic, then you verify with a scheduled re-run. The patterns below are the ones that usually hold up under Security Events review.

Prefer verified / known bots over User-Agent string matching alone

Cloudflare documents custom-rule patterns that allow search-engine and other verified bots using fields such as cf.client.bot (and Bot Management fields where available). User-Agent contains "Chrome-Lighthouse" rules are fragile: they are easy to spoof, easy to miss when Google changes strings, and insufficient under Under Attack Mode when the wrong Skip scope is selected. Known Bots / verified bot Skip rules for remaining WAF modules and Super Bot Fight Mode (where the plan supports them) are a stronger starting point, with monitoring-specific exceptions added only if Security Events still show blocks.

Use IP Access allow rules for known monitoring egress

If your PageSpeed Insights automation or third-party monitor exits from stable IP ranges, an IP Access allow that matches the connecting IP can prevent Bot Fight Mode from firing on those requests (Cloudflare notes Bot Fight Mode will not trigger when an IP Access rule matches first). Document the ranges with the vendor and rotate them when the vendor publishes changes. Allowlisting entire cloud regions is usually too broad for the risk you are trying to reduce.

Move from Bot Fight Mode to Super Bot Fight Mode when you need Skip

Free Bot Fight Mode cannot honour WAF Skip the way Super Bot Fight Mode can. Agencies stuck on Free with constant false positives on monitoring have a product constraint, not a missing regex. The realistic options are to disable Bot Fight Mode after the attack window, upgrade so Skip rules work, or accept that scheduled PageSpeed Insights on that zone will stay unreliable.

Scope Skip narrowly

A Skip that disables all remaining security for any bot-shaped request is a self-inflicted outage waiting to happen. Narrowing by hostname path if needed (public marketing URLs versus authenticated app), by verified-bot field, and by known monitoring IPs keeps the exception honest. Review Security Events after the change to confirm PageSpeed Insights is skipped for the right reason and that random scrapers are still challenged.

Confirm with the same automation that failed

A manual browser pass after a rule change proves little. Re-run the scheduled job or API call that produced the original error, and only then mark the incident closed. Scheduling discipline for portfolios is covered in PageSpeed Monitoring: How to Schedule Test Frequency and Priority Across Your Portfolio.

User-Agent myths, warm-up, retries, and what not to do

Spoofing Googlebot to “pass” Cloudflare from a monitoring host violates Google’s crawler guidelines, teaches the wrong security lesson, and still fails when Cloudflare verifies bots beyond the User-Agent string. If you need Googlebot behaviour, you are not debugging PageSpeed Insights automation; you are debugging crawl access. Turning security off globally to get a green Lighthouse score is the other common shortcut, and it trades one KPI for a real incident risk. Time-boxed Under Attack Mode, narrow Skips, and IP Access for monitors are safer than disabling Bot Fight Mode or WAF managed rules site-wide for a performance project.

User-Agent allowlists help on some plans and some products, but they are not complete. They do not override Bot Fight Mode. They do not always survive Under Attack Mode. They do nothing for rate limits keyed on IP.

Warm-up and retries have limits. A single warm-up request that solves a challenge in a full browser does not automatically mint cookies for a separate PageSpeed Insights API worker. Retrying a challenged URL every minute usually deepens rate-limit pain without producing a valid document, so retries fit transient network errors after allowlists are confirmed, not as a substitute for a Skip rule.

Runbooks stay clearer when “tool blocked” and “site slow” stay separate. Security Events and HTTP status come first; LCP subparts come after. If the document request never returned 200 HTML from the application, the performance playbook stops and a Cloudflare configuration ticket with the client’s zone admin is the right next step.

How agencies should report Cloudflare blocks in client monitoring

Clients rarely want a lecture on Ruleset Engine phases. They want to know whether the site is slow for users or whether the monitor was refused. A short script in the report usually covers it:

State the failure mode in plain language: “Scheduled PageSpeed Insights received a Cloudflare challenge / 403, so lab metrics are invalid for this run.”
Attach evidence: Security Events screenshot or rule name, HTTP status, and whether field data in PageSpeed Insights still looks normal.
Name the owner: client Cloudflare admin versus agency monitoring egress. Most allowlist changes require the zone owner.
Record the fix: verified-bot Skip, IP Access allow, Super Bot Fight Mode change, or temporary Under Attack Mode turned off after the incident.
Re-run on schedule and only then restore budget alerting for that URL.

Keep synthetic budgets armed for real regressions once access is restored. Muting an entire client because one zone had Bot Fight Mode misconfigured hides unrelated regressions; mute or annotate the affected URLs until the next clean run instead. That keeps Apogee Watcher-style portfolio schedules useful: continuous checks, early detection, clear reports, without pretending every red score is an LCP bug. If you run Apogee Watcher across many Cloudflare-fronted clients, recurring challenge failures belong on the onboarding checklist: confirm Bot Fight Mode posture, document whether Super Bot Fight Mode Skip is available, and store monitoring egress expectations with the client before you promise daily lab history.

FAQ

Why does PageSpeed Insights work manually but fail on a schedule behind Cloudflare?

Manual runs often complete challenges or arrive from networks Cloudflare treats more gently. Scheduled API and headless runs look like automation, lack challenge state, and hit Bot Fight Mode, WAF rules, or Under Attack Mode. Fix allowlists and product mode rather than only re-testing from a laptop.

Can a WAF custom rule Skip Bot Fight Mode for Chrome-Lighthouse?

No. Cloudflare documents that Bot Fight Mode cannot be bypassed with WAF custom rules or Page Rules. Super Bot Fight Mode with Skip, IP Access allows that match first, or disabling Bot Fight Mode when the attack window is over are the documented paths.

Should we allowlist by User-Agent or by verified bots?

Prefer verified / Known Bots fields and stable monitoring IPs. User-Agent matching is a weak secondary signal and is easy to get wrong under Under Attack Mode.

Is a green score through an origin bypass good enough for clients?

Only as a labelled diagnostic. Visitors still hit the Cloudflare edge. Report edge-path PageSpeed Insights once security exceptions are correct.

What if field data looks fine but lab keeps failing?

That pattern often means real users pass while automation is blocked, or that URL-level field metrics are missing for other reasons. Investigate Cloudflare events first, then reconcile lab versus field with your usual synthetic-versus-RUM rules.

When Cloudflare blocks PageSpeed Insights automation, the monitoring problem is access, not paint timing. Diagnose the product that challenged the request, apply the narrowest Skip or IP Access that still protects the zone, and re-run the same scheduled path before you rewrite performance budgets. If you want that loop across a multi-tenant portfolio without babysitting every PageSpeed Insights tab, start a free Apogee Watcher trial or run a quick check on a priority URL once Cloudflare allows the document through.

References

Bot Fight Mode (Cloudflare Docs)
Handle false positives from Bot Fight Mode or Super Bot Fight Mode (Cloudflare Docs)
<a href="https://developers.cloudflare.co

Cache-Control Headers for Web Performance: CDN and Browser Caching That Sticks

Thu, 17 Sep 2026 07:04:00 +0000

The CDN is enabled. The origin sends sensible browser caching headers. A lab run on the priority URL still shows a slow document Time to First Byte and repeat views that behave like cold loads. In our experience the gap is rarely “caching is off” as a single switch. It is a mismatch between what the origin allows, what the CDN dashboard overrides, and which layer the browser actually reuses on the next navigation. Cache-Control is the contract that ties those layers together. When the contract is vague or copied from a generic template, performance work does not stick past the next platform default or purge.

What follows is a content-type guide for teams who already understand DNS, TLS, and edge routing from Network Performance for Web Teams: DNS, TLS, HTTP, CDN, and Cache Rules. That piece explains where cache hits change TTFB on the request path. Here we focus on the header strings that make those hits legal, the CDN defaults that undo them, and how to prove the policy held after deploy with scheduled lab runs.

What Cache-Control changes on the path to first byte and repeat views

The Cache-Control response header holds directives that tell browsers and shared caches (CDNs, reverse proxies) whether they may store a response, how long it stays fresh, and whether they must revalidate before reuse. Freshness is measured from when the response was generated at the origin, adjusted by any Age header added by intermediaries. A directive on the HTML document can therefore change first-byte wait on a CDN miss, while directives on CSS, JavaScript, fonts, and images change how much work repeats on the second view without touching the document request at all.

The directives that matter most for web performance work are max-age (fresh lifetime in seconds), s-maxage (fresh lifetime for shared caches only), public and private (whether a shared cache may store the response), no-cache (store but revalidate before use), no-store (do not store), immutable (while fresh, skip revalidation on reload), must-revalidate, and extension directives such as stale-while-revalidate and stale-if-error. MDN documents each directive; RFC 9111 is the normative reference when you need to settle a dispute between engineering and the CDN vendor.

Treat every response as belonging to a content class before you copy a header string from a blog post. HTML entry points, fingerprinted static bundles, unversioned images, authenticated account pages, and public JSON APIs need different policies. The performance win comes from aligning the class, the origin header, the CDN rule, and your purge discipline so they still agree on the live hostname after release.

Browser cache versus CDN cache: two layers that need different directives

Browser caching headers govern the copy on the device. CDN cache rules govern the copy at the edge. They read the same Cache-Control line but apply different parts of it. s-maxage applies only to shared caches and overrides max-age for them when both are present. private keeps a response out of shared caches while still allowing a browser store. immutable affects reload behaviour for static assets in the browser. Confusing the two layers produces tickets that say “we purged the CDN but nothing changed,” because the team purged the edge while the browser still held an old document, or vice versa.

Layer	Who stores	Typical levers	Effect on cold TTFB	Effect on repeat views / LCP
Browser	Returning visitor	`max-age`, `immutable`, `no-cache` + validators	Small on first visit	Large when static assets skip full downloads
CDN (shared cache)	Any visitor hitting that PoP	`s-maxage`, `public`, origin cacheability, purge tags	Large on cache hit for HTML and assets	Smaller origin load; stable edge latency
Origin	Source of truth	App framework defaults, `CDN-Cache-Control` on some stacks	Defines miss cost	N/A until next request

A useful policy document names the content class, the origin header, the CDN behaviour when the header is absent, and who purges what on deploy. Without that table, agencies inherit “cache everything” dashboard templates that fight the application’s HTML strategy or strip ETag headers the framework relies on for cheap 304 Not Modified responses.

Cache-Control for fingerprinted CSS, JavaScript, fonts, and images

Static assets whose URLs change when content changes should be cached aggressively at both browser and CDN. The filename is the versioning mechanism. A stylesheet served as /assets/app.9f1c2d4e.css can safely carry a one-year freshness lifetime because the next deploy publishes /assets/app.b3e8a1f0.css and the HTML entry point references the new name.

Recommended pattern for hashed or fingerprinted files:

Cache-Control: public, max-age=31536000, immutable

The immutable directive, defined in RFC 8246, tells clients not to send conditional revalidation requests while the response is fresh. That matters on hard reloads: without immutable, browsers may still ask the server whether app.9f1c2d4e.css changed even though the URL encodes the revision. For performance-sensitive sites, those avoidable round trips show up as extra connection work before Largest Contentful Paint can use a cached font or script.

Do not put immutable on unversioned paths such as /styles/main.css or /logo.png unless your release process never overwrites the same URL. If the URL is stable, use a shorter max-age plus ETag or Last-Modified validators so updates propagate without waiting a year. Google’s guidance on efficient cache lifetimes aligns with the fingerprinted-file rule: long TTLs belong where the URL changes with the bytes.

After you set long TTLs at the origin, confirm the CDN is allowed to store those responses. Some platforms require public explicitly. Some honour a separate CDN-Cache-Control or vendor-specific override. Inspect Age, CF-Cache-Status, X-Cache, or the equivalent on a CSS or font request in production, not only on HTML.

Cache-Control for HTML documents agencies actually ship

HTML is the map to every other asset. If the browser or CDN serves stale HTML, it may point at old bundle names even when the new files already sit on the origin. Most delivery teams therefore want HTML to revalidate often while still allowing the CDN to absorb traffic for anonymous pages.

Common patterns:

Revalidate every use (good default for many marketing sites):

Cache-Control: no-cache
ETag: "build-20260910-abc123"

no-cache does not mean “do not cache.” It means the cache must validate with the origin before reuse. With a matching ETag, validation is a small 304 Not Modified instead of a full document download. That keeps HTML current without abandoning bandwidth savings.

Short browser freshness, longer edge TTL, background refresh:

Cache-Control: public, max-age=0, s-maxage=60, stale-while-revalidate=300, stale-if-error=600

Browsers treat the document as stale immediately and revalidate. The CDN may serve a fresh copy for sixty seconds and continue serving stale responses briefly while it revalidates in the background. This pattern can lower origin load during traffic spikes if your content model tolerates short edge staleness on public pages.

Personalised or authenticated HTML:

Cache-Control: private, no-store

or, when the response is user-specific but you still want browser revalidation without CDN storage:

Cache-Control: private, no-cache

Never mark personalised HTML public at the CDN unless you have deliberate edge logic that varies the cache key safely. Vary: Cookie without a tight vary set often collapses hit ratio to zero. Wrong HTML caching creates correctness incidents that outweigh any TTFB improvement.

When you deploy new HTML that references new asset hashes, purge or revalidate HTML at the CDN if your policy allows edge caching at all. Serving cached HTML that still points at removed bundles is a common post-release failure mode that looks like a performance regression in Lighthouse even though the new files are fast.

CDN defaults and dashboard rules that undo your header policy

Agencies often enable a CDN before origin headers are deliberate. Vendors ship attractive defaults: cache all static extensions for a month, “standard” caching for HTML, ignore certain origin headers, or respect only cache rules defined in the dashboard. Those defaults are a starting point, not a performance policy.

Defaults we see cause repeat TTFB and LCP pain:

Mistake	What breaks	What to check on the live URL
CDN caches HTML with a long TTL while origin says `no-cache`	Stale pages, wrong asset references after deploy	`CF-Cache-Status` / `X-Cache` on `/` and a template URL
Origin sends `Cache-Control: private` but team expects edge hits	Every request becomes an origin fetch	Response headers on document request
“Cache static file types” rule bypasses `immutable` fingerprint policy	Unnecessary revalidation or wrong TTL per extension	Headers on `.js`, `.css`, and font files
Blanket purge on every CMS save	Hit ratio collapses; TTFB spikes for a day	`Age` header trend across scheduled runs
`Vary: Cookie` on anonymous pages	Edge refuses to share entries	Cache key documentation from vendor
Flexible SSL or redirect loops at edge	TTFB rises before cache policy matters	Redirect count in waterfall (see post 62)

Dashboard rules should echo origin intent, not fight it. If the application sets CDN-Cache-Control or vendor-specific surrogate headers, document which header wins when both are present. After any CDN migration, re-audit the same priority URLs you used for the previous vendor. Rules do not transfer verbatim between Cloudflare, Fastly, Akamai, and CloudFront.

How Cache-Control headers show up in TTFB and LCP lab runs

Time to First Byte in PageSpeed Insights and Lighthouse reflects how long the navigation request waited for the first byte of the HTML response. When the CDN serves a fresh document from cache, TTFB often drops sharply compared with an origin miss. When HTML is private, no-store or bypasses the edge, TTFB still includes origin compute and PoP-to-origin latency even if static assets are well cached.

Largest Contentful Paint inherits that document delay and then adds how quickly the LCP resource itself arrives. A hero image with a long max-age at the CDN may paint fast on repeat views while the first view still waits on HTML generation. Conversely, perfect HTML caching cannot fix LCP if the LCP image lives at an unversioned URL with a five-minute TTL and the CDN misses every time.

Practical reading order in lab tools:

Document request: TTFB, cache status headers, redirect count.
LCP element request: cache hit or miss, protocol, priority hints.
Render-blocking CSS and font requests: are they fingerprinted with long TTLs or re-fetching each view?

Pair a cold run with a repeat view when your tool supports it. Cold exposes DNS, TLS, and first miss behaviour. Repeat exposes whether browser caching headers actually removed duplicate downloads. For operational thresholds on the same URLs, set performance budget thresholds that include TTFB and LCP, not only the Performance score.

Once first byte and paint are acceptable, the LCP work in A Quick Way to Fix LCP: Four Changes That Cut Time to Paint still matters. Cache-Control removes avoidable network round trips; it does not shrink an oversized hero file or late-discovered LCP candidate.

Verify Cache-Control on live URLs after every deploy

Header policy is only real on the public hostname users hit. Staging often lacks the CDN overlay or sends different headers from the production origin. After each deploy, cache rule edit, or CMS plugin that touches headers, verify the live response rather than assuming the dashboard screenshot still matches production.

Checklist we use on client sites:

Document URL: homepage plus one high-intent template (product, pricing, article).
Representative static asset: hashed JS or CSS referenced by that HTML.
LCP resource: image or video request from the same lab run.
Cache status: Age, vendor hit/miss header, and the full Cache-Control line.
Validators: ETag or Last-Modified present where you expect revalidation.
Compare to policy doc: content class, intended header, CDN rule, purge owner.

Export the header set into the ticket or client report so the next engineer does not re-discover the same miss. A single manual check catches the first mistake. It does not prove the CDN still hits next Thursday after a content editor triggers a purge storm.

Put priority URLs on scheduled PageSpeed monitoring with device splits that match the audience. Apogee Watcher stores lab payloads over time so you can see TTFB and LCP drift after edge changes without someone opening PageSpeed Insights from memory. That layers onto your CDN vendor; it does not replace header configuration or purge discipline. For why one-off lab runs are insufficient proof, see PageSpeed Insights vs Automated Monitoring: When Manual Checks Aren't Enough.

FAQ

What is the difference between no-cache and no-store?

no-cache allows storage but requires validation before reuse. Browsers and CDNs may keep a copy and often answer with 304 Not Modified when the ETag still matches. no-store forbids storing the response anywhere. Use no-cache for HTML that must stay current but can revalidate cheaply. Use no-store for sensitive account or payment flows where persistence is unacceptable.

When should we use immutable?

Use immutable only on fingerprinted static assets where the URL changes when the bytes change. Pair it with a long max-age, commonly 31536000 seconds. Do not use it on HTML or on unversioned files you overwrite in place.

Does max-age=0 disable caching?

No. It marks the response as immediately stale, which forces revalidation behaviour similar in practice to no-cache for many caches, but the directives are not identical in every intermediary. Be explicit: choose no-cache when you want validation semantics, or no-store when you want no persistence.

Why did TTFB improve in WebPageTest but not in PageSpeed Insights?

Tools use different locations, cache states, and throttling. A hit from one PoP near the test agent does not prove global behaviour. Align test location with audience geography and inspect cache headers on the document request in both tools before closing the ticket.

Should APIs use the same Cache-Control as HTML?

Public read-heavy JSON can use short browser max-age with longer s-maxage and stale-while-revalidate when responses are identical for all users. Authenticated or user-specific APIs usually need private or no-store. Treat each endpoint as its own content class.

We purged the CDN. Why do clients still see old CSS?

Purging the edge does not clear browser caches. If CSS URLs are not fingerprinted, visitors may keep an old file until max-age expires. Prefer hashed filenames for bundles and purge HTML if it still references retired names.

Put header policy on the same schedule as performance budgets

Pick one priority URL where TTFB or LCP still misses budget. Capture the live Cache-Control lines on HTML, the LCP asset, and one fingerprinted bundle. Fix the largest layer mismatch first: origin header, CDN rule, or purge process. Re-run lab from a region that matches traffic, then add th

Google Lighthouse Score Explained: How Scoring Works

Mon, 14 Sep 2026 19:47:44 +0000

A Google Lighthouse score is a lab Performance number from 0 to 100 for one controlled run. Scoring does not average raw milliseconds. Each metric is mapped through an HTTP Archive curve, then weighted into one score for a single URL and one device strategy.

Agencies usually meet that number as the green or amber circle in PageSpeed Insights. Clients treat it as "Google speed." It is neither a ranking factor by itself nor a field Core Web Vitals percentile. It is recorded under simulated conditions, then calculated with documented weights that change across Lighthouse majors.

TL;DR: Record lab metrics in a throttled run, convert each to a 0–100 metric score, apply Lighthouse 10 weights (TBT 30%, LCP and CLS 25% each, FCP and Speed Index 10% each), and report the blend as lab only. Keep CrUX and Search Console on a separate slide. Chrome’s Lighthouse performance scoring guide is the source of truth; what follows is the agency translation, including a worked example and FAQ.

What a Lighthouse Performance score actually is

The Performance score is a single 0–100 summary for one lab run of one URL under one device strategy (mobile or desktop). It is not a ranking factor by itself. It is not a rolling average of real visitors. Opportunities and Diagnostics in the report do not add points directly; they explain ways the underlying metrics might improve, which can raise the score indirectly when those metrics move.

Colour bands in the docs are simple: 0–49 poor (red), 50–89 needs improvement (orange), 90–100 good (green). A perfect 100 is unusually hard. Moving from 99 to 100 can need as much metric improvement as moving from 90 to 94. For client language, “good” means a lab run that cleared 90 under that profile, not that every user on every network had a green experience.

PageSpeed Insights uses Lighthouse for the lab block. When people say “the PageSpeed Insights score,” they usually mean that lab Performance category, sometimes while looking at a CrUX field panel on the same screen. Keep those two stories separate in every deck.

How Lighthouse records lab metrics in a controlled run

Recording comes first. Lighthouse (and PageSpeed Insights lab mode) loads the URL in a controlled environment: a chosen form factor, simulated network and CPU throttling for typical mobile profiles, and a single navigation. During that load it measures timings and layout behaviour. Common Performance metrics include First Contentful Paint (FCP), Speed Index (SI), Largest Contentful Paint (LCP), Total Blocking Time (TBT), and Cumulative Layout Shift (CLS). Diagnostics such as Time to First Byte (TTFB) may appear as supporting detail. None of those values are taken from real visitors in that run.

The lab profile matters. Mobile and desktop use different throttling and, since Lighthouse 6, different scoring curves so desktop is not scored on mobile HTTP Archive distributions. Running on a quiet office machine with extensions disabled still differs from a busy shared CI worker. Chrome documents common causes of score fluctuation: ads and A/B tests, routing changes, device power, extensions, antivirus. Treat a single paste as a sample from a distribution, not as the only possible score for that URL.

Scheduled monitoring reduces the “two screenshots, no baseline” problem. You still measure lab conditions, but you compare like with like over time. That is the operational gap we described in PageSpeed Insights versus automated monitoring.

How Lighthouse calculates the 0–100 Performance score

Calculation is a second step. Lighthouse does not average raw milliseconds into one number. For each metric it maps the recorded value onto a 0–100 metric score using a log-normal scoring curve calibrated from HTTP Archive site data. Those metric scores stay under the hood in the usual report UI. The visible Performance score is then a weighted average of the metric scores.

Chrome describes the curve control points clearly. The 25th percentile of HTTP Archive data for a metric maps to a metric score of 50. The 8th percentile maps to 90 (the “good” control point). Between roughly 0.50 and 0.92 the relationship is nearly linear; near 0.96 returns diminish and further metric gains buy less score. Exploring a metric in the Lighthouse scoring calculator is the fastest way to see how a raw LCP or TBT value becomes a metric score before weights apply.

Because the curves come from real-site distributions, “good” is relative to the web as captured in HTTP Archive, not to an arbitrary round number your client invented in a brand guideline. When Lighthouse major versions change weights or curves, historical scores need a footnote. Always cite the Lighthouse version your tool used when you compare quarters.

Lighthouse scoring weights (Lighthouse 10)

Chrome’s documented Lighthouse 10 weights for the Performance score are:

Metric	Weight
First Contentful Paint (FCP)	10%
Speed Index (SI)	10%
Largest Contentful Paint (LCP)	25%
Total Blocking Time (TBT)	30%
Cumulative Layout Shift (CLS)	25%

TBT carries the largest single weight. LCP and CLS share 25% each. FCP and Speed Index are lighter. Earlier majors differed; Lighthouse 8 still weighted Time to Interactive and used a different CLS weight. Verify the table for the version you ship in CI or see in PageSpeed Insights, and re-check the calculator when Google publishes a new major.

INP may appear in field tooling and in some report contexts, but the lab Performance blend documented for Lighthouse 10 emphasises TBT as the interactivity proxy inside the score. Do not tell a client that “INP is 30% of the Lighthouse score.” Point them at TBT for lab scoring and at field INP for CrUX and Search Console when samples exist. Metric definitions live in LCP, INP, and CLS explained; field interactivity detail is in our INP guide.

Worked example: from metric scores to a Performance number

Suppose a mobile lab run produces these metric scores (already mapped through the curves; not raw milliseconds): FCP 90, Speed Index 85, LCP 70, TBT 60, CLS 95. Apply the Lighthouse 10 weights:

FCP: 90 × 0.10 = 9.0
Speed Index: 85 × 0.10 = 8.5
LCP: 70 × 0.25 = 17.5
TBT: 60 × 0.30 = 18.0
CLS: 95 × 0.25 = 23.75

Sum ≈ 76.8, which rounds to a Performance score in the mid-70s (needs improvement). The same raw LCP in milliseconds can yield a different metric score when the curve or Lighthouse major changes, so always cite the version beside the number. Open the Lighthouse scoring calculator to poke individual levers before you promise a client that "ten points is one easy fix."

Lighthouse version footnote: Weights and curves above follow Chrome’s documented Lighthouse 10 Performance scoring. PageSpeed Insights and CI runners may ship a different major. When you compare quarters or tools, record the Lighthouse version (or PageSpeed Insights date) on the report. A five-point swing across a major upgrade can be scoring math, not a regression.

Why the Performance score is not the same as Core Web Vitals field data

Field Core Web Vitals come from real Chrome users in the Chrome User Experience Report (CrUX), with Search Console and the PageSpeed Insights field section as common surfaces. Lab Performance scores come from one synthetic navigation. Both can mention LCP and CLS; only the lab score folds in Speed Index and TBT with the weights above. Field INP has no twin inside that Lighthouse 10 weight table.

Question	Lab Performance score	Field Core Web Vitals (CrUX)
Who was measured?	Controlled lab profile	Real Chrome users (sample)
What number?	Weighted 0–100 from metric scores	Percentiles for LCP, INP, CLS (and related)
Interactivity in the blend?	TBT (lab)	INP (field)
Good enough for SEO field status?	No, not by itself	Search Console / CrUX when eligible
Useful after a deploy?	Yes, fast regression signal	Yes, after the rolling window catches up

Agencies need both clocks. Lab catches “we broke the template today.” Field answers “Chrome users over ~28 days still feel it.” We covered the field lag in Why your Core Web Vitals fix is not in CrUX yet and the synthetic versus RUM split in When to use synthetic versus real user monitoring. Missing field rows are a sampling problem, not proof the lab score is wrong; see When PageSpeed Insights shows no CLS or INP.

Mid-article check: run the URL you are arguing about

Before you debate a screenshot in Slack, run a free PageSpeed check on the same URL and strategy (mobile or desktop). Pair the lab Performance score with the metric breakdown, then keep the scoring calculator open so stakeholders see how LCP, TBT, and CLS drive the blend. Scheduled history in Apogee Watcher beats one heroic paste after a tag-manager change.

Why Lighthouse scores fluctuate between runs

Variability is normal. The same URL can move several points between back-to-back runs when ads, consent banners, third-party scripts, or CPU contention differ. Chrome’s variability documentation exists for a reason. For retainers, prefer medians or repeated scheduled runs over a single heroic screenshot. Agree the device strategy (mobile versus desktop) before you argue about a five-point swing.

CI and local DevTools can also disagree because of Lighthouse version, throttling presets, and whether the environment matches PageSpeed Insights. When you automate audits with coding agents or DevTools workflows, still treat the Performance number as lab math under a stated version. Our note on Lighthouse audits with AI agents covers the agency gap between one-off agent runs and portfolio schedules. Separate audits such as Baseline Features change Best Practices diagnostics without rewriting the Performance weight table; see Lighthouse’s Baseline Features audit.

How agencies should report Lighthouse scores to clients

Name the artefact: “Lighthouse / PageSpeed Insights lab Performance score,” not “Google’s speed ranking.”
State device and version: mobile or desktop, and Lighthouse major when known.
Show the drivers: LCP, TBT, and CLS usually explain most of the blend under current weights.
Separate field status: CrUX / Search Console on their own slide or paragraph.
Use trends: three or more scheduled runs beat one paste after a deploy.
Open the calculator when a stakeholder wants to know how many milliseconds buy the next ten points.
Avoid score chasing at 99–100 unless the contract truly requires vanity greens; spend engineering time on user-visible LCP and TBT first.

Budgets work better on metric thresholds than on a single Performance integer, because the integer hides which metric moved. Pair score trends with LCP and TBT budgets on money URLs so engineering knows what to fix. A five-point score drop that is all TBT is a different ticket from one that is all CLS.

Where Apogee Watcher stores Performance scores

Apogee Watcher schedules PageSpeed Insights tests across multi-tenant portfolios and stores the lab category scores and metric payloads from those runs for trends, budgets, and alerts. That history is lab data under Google’s PSI/Lighthouse pipeline. It is not a substitute for CrUX percentiles, and it does not claim to weight INP inside the Performance blend.

Use Watcher when you need the same URLs retested on a cadence after deploys, with mobile and desktop strategies and client-ready charts. Use CrUX and Search Console for field Core Web Vitals when samples exist. Use the scoring calculator when someone asks how the 0–100 number is built. Layer the tools; do not collapse them into one green circle in a slide.

Start a free trial to schedule PageSpeed tests and keep Performance score trends beside metric budgets. Or run a free PageSpeed check on a priority URL and open the Lighthouse scoring calculator beside the result.

FAQ

What is a Google Lighthouse score?

A Google Lighthouse score usually means the Performance category (0–100) from one lab audit, alongside Accessibility, Best Practices, and SEO category scores. The Performance number is the weighted blend covered here. It is not an average of real-user timings and not a Search Console field status.

How does Lighthouse scoring work?

Recording comes first: Lighthouse loads the URL under a fixed device and throttling profile and measures lab metrics (FCP, Speed Index, LCP, TBT, CLS under current docs). Calculation comes second: each metric maps to a 0–100 metric score via log-normal HTTP Archive curves, then those metric scores are weighted into the visible Performance number.

What is a good Lighthouse Performance score?

Chrome’s colour bands: 0–49 poor, 50–89 needs improvement, 90–100 good. "Good" means that lab run cleared 90 under that profile, not that every visitor on every network had a green experience. Chasing 99–100 is usually vanity; spend engineering time on user-visible LCP and TBT first.

How do lab Lighthouse scores differ from PageSpeed Insights and CrUX?

PageSpeed Insights shows a Lighthouse lab block and, when eligible, a CrUX field block on the same page. The lab circle is Lighthouse scoring. CrUX is aggregated Chrome field data (percentiles for LCP, INP, CLS), not the weighted 0–100 Performance blend. For when to lean on synthetic lab runs versus real-user monitoring, see when to use synthetic versus real user monitoring. Do not collapse "the PageSpeed Insights score," "Lighthouse," and "Core Web Vitals" into one sentence in a client deck.

Does Google use the Lighthouse Performance score as a ranking factor?

Google’s ranking systems use page experience signals tied to real-user Core Web Vitals concepts, not your lab Performance integer as a published ranking weight. Treat the score as an engineering and reporting aid. Use CrUX and Search Console for field status when data exists.

Why is Total Blocking Time in the score if INP is the Core Web Vital?

Lab runs need a synthetic interactivity signal during a single load. TBT fills that role inside the documented Lighthouse 10 Performance weights. INP is a field metric built from real interactions over a page life. Report both without merging them into one sentence.

Do Opportunities change the Performance score directly?

No. Only metric scores feed the weighted average. Opportunities and Diagnostics guide fixes that may improve those metrics on the next run.

Why did desktop scores change a lot after older Lighthouse versions?

Before Lighthouse 6, desktop runs could be scored against mobile-derived curves and look artificially strong. From v6 onward, desktop has its own scoring. Compare desktop history carefully across that boundary.

Can Apogee Watcher show how each metric score was weighted for a run?

Watcher stores the PageSpeed Insights / Lighthouse results from scheduled tests for trends and budgets. For interactive weight exploration, use Google’s scoring calculator and Chrome’s scoring documentation alongside your Watcher history.

References

Lighthouse performance scoring (Chrome for Developers)
Lighthouse scoring calculator (Chrome)
HTTP Archive (scoring curve source data)
Lighthouse variability (Lighthouse project)
<a href="https:

Late CLS vs Early CLS: How to Diagnose Layout Shift After Load

Mon, 14 Sep 2026 08:04:00 +0000

Late CLS is layout instability that happens after the page has already painted useful content: personalised modules, consent bars that collapse, infinite-scroll batches, client-side route changes, and embeds that activate on scroll. Early CLS is the classic load-time problem: images without dimensions, web fonts that swap metrics, and ad slots that expand when the network returns. Both count toward the same Cumulative Layout Shift score in the field, but they need different fixes and different lab reproduction steps.

If PageSpeed Insights or Lighthouse reports a calm CLS while CrUX or Search Console shows amber or red on the same URL, you are usually looking at cumulative layout shift after load, not a measurement bug. Lab runs emphasise the first few seconds of navigation. Real Chrome users keep scrolling, accept cookies, open menus, and trigger client-rendered updates that never appear in a default synthetic trace. Google’s own CLS guidance calls out that gap when you compare lab tooling with field data (Optimize Cumulative Layout Shift).

We covered the shared causes and fix order in CLS deep-dive: common causes and fixes for layout shift and the metric definitions in LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It. Below we split early versus late CLS, show how to fix cls after load without chasing load-only optimisations, and tie late shifts to INP when interaction and layout move in the same session.

Early CLS vs late CLS: what each phase measures

Cumulative Layout Shift aggregates unexpected movement of visible content during the page lifetime, grouped into session windows so bursts of instability score as one worst cluster rather than endless micro-penalties (Evolving the CLS metric). “Early” and “late” are operational labels we use on client tickets, not separate Google metrics. They help teams route work to the right owner.

Phase	Typical timing	Common culprits	First fix lever
Early CLS	First paint through LCP	Images and video without reserved size, font swap, hero ad slots, SSR/hydration mismatch	Intrinsic dimensions, `aspect-ratio`, font strategy, stable server HTML
Late CLS	After LCP, often after idle or interaction	Cookie and promo bars, infinite scroll, SPA route transitions, lazy embeds without wrappers, “new since visit” inserts	Reserved slots, overlay UI, route-level skeletons, facade patterns
Interaction-adjacent	During or right after tap/scroll	Menus, carousels, accordions, chat widgets, heavy click handlers that also insert DOM	Split INP work from layout work; reserve expanded state height

Early CLS is what most “how to fix CLS” guides optimise: size media, tame fonts, pin ad boxes. Late CLS is why those guides still leave field scores red. A template can pass lab CLS on a cold load while personalised headers, consent flows, and below-the-fold embeds shift the layout ten seconds later.

Why lab CLS often misses late shifts

Lighthouse and default PSI runs load the URL once, throttle the network, and finish while the main thread is still settling initial resources. They may not scroll, accept consent, open navigation drawers, or wait for infinite-scroll fetches. Practitioner write-ups on layout shift after page load repeat the same pattern: the metric still applies while content is visible and the user has not intentionally triggered a layout change tied to their gesture in the same interaction window. That does not make lab useless. Lab traces still name unstable nodes during load; you extend lab deliberately when you suspect late CLS with longer recordings, scripted scroll, throttled CPU, and consent granted versus denied states.

Late CLS causes we see after LCP

Dynamic injection above existing content

Marketing ribbons, “install the app” bars, and logged-in-only alerts often mount after React or Vue hydrates. If the new node pushes the article column down, field CLS moves even when hero images were sized correctly at first paint. The fix is the same as early CLS for banners, but the failure shows up later: render a placeholder shell in server HTML, use an overlay that does not reflow document flow, or reserve the final banner height before JavaScript runs.

Client-side routing and layout swaps

Single-page apps that replace the entire content column on navigation can score layout shifts when the outgoing view unmounts and the incoming view has different chrome height. Users experience this as cumulative layout shift after load on soft navigations. Fix at the route shell: stable header and footer height, skeleton rows that match card dimensions, and avoid prepending “recommended for you” strips above content the user is already reading.

Infinite scroll and “prepend” feeds

Append-below infinite scroll is lower risk when card heights are stable. Prepend patterns (“12 new posts since your last visit”) are a frequent late CLS source on publishers and social-style templates. Prefer a dedicated strip with fixed height, or animate within a reserved region instead of reflowing the whole feed.

Consent, chat, and third-party widgets

Consent management platforms often inject a tall banner, then collapse it to a small chip. That collapse is a layout shift. Chat widgets slide in from the corner and resize when the first message arrives. Recommendation engines inject carousels beside article bodies after the main content paints. These overlap with the third-party load patterns in Third-Party Scripts and Performance: How to Identify and Fix the Worst Offenders. Late CLS tickets should name the tag and the clock: load, post-consent, on-scroll, or on-interaction.

Embeds and video slots that activate late

YouTube and other iframes are an early CLS problem when the slot has no aspect-ratio. They become a late CLS problem when the iframe is created only after scroll, consent, or click, and the parent page still had no reserved box at first paint. Cross-Origin YouTube Embeds and CLS: What Publishers Can Actually Fix walks through facade and wrapper patterns. The rule for late activation is unchanged: the sized box must exist before the third party arrives, not when the user finally scrolls to it.

Late CLS and INP: when shifts follow interaction

Interaction to Next Paint measures responsiveness: how long after input until the browser paints the next frame. Late layout shifts and poor INP often share a root cause: main-thread work and DOM updates triggered by the same tap or scroll.

Examples we log on client sites:

Opening a mega-menu inserts dozens of nodes and shifts the hero underneath.
A carousel “load more” handler fetches HTML and prepends cards while the user is reading.
A video facade creates a full iframe on click; if the handler is slow, INP rises; if the box was not reserved, CLS rises in the same session.

Treat INP and CLS as related diagnostics, not competing priorities. DevTools Performance recordings show long tasks and layout events in one timeline. Chrome’s performance insights also surface layout shift culprits alongside interaction delays on supported versions. Fix reserved layout first when the shift is visible; profile the handler when INP alone is red.

How to diagnose cumulative layout shift after load

Work in this order so you do not optimise hero images while a consent bar is the real field problem.

1. Confirm field pain on the right URL and template

Use CrUX in PageSpeed Insights, the Core Web Vitals report in Search Console, or your RUM product if the client allows instrumentation. Check whether CLS is origin-wide or concentrated on paths with heavy personalisation, auth, or embeds. Align monitored URLs with templates that actually shift after load, not only the marketing homepage.

2. Split early vs late in DevTools

Open Chrome DevTools, enable the Layout Shift Regions overlay, and record a Performance trace longer than a default Lighthouse run. Scroll, open menus, accept or deny consent, and trigger the flows real users take. Note timestamps relative to LCP: shifts in the first two seconds usually point to early CLS; shifts after scroll or interaction point to late CLS. For programmatic signal in staging, the Layout Instability API and PerformanceObserver can log shift events with impacted nodes and scores (Debug layout shifts). Chromium-only, but useful for reproducing a scripted journey before you roll a template fix.

3. Reproduce in lab with intentional waits

On PageSpeed Insights or Lighthouse CI, a single cold load is not enough when you suspect fix cls after load work. Supplement with:

Manual PSI runs after scrolling to embed-heavy sections.
WebPageTest scripts that wait, scroll, and click consent.
Staging builds with CPU throttling and “slow 4G” to stretch the window where late tags arrive.

Compare traces with consent granted and denied. Field CLS is a mix of both populations on many publisher sites.

4. Attribute shifts to owners

Observation	Likely class	Owner
Shift on first paint before any scroll	Early CLS	Template/CSS, images, fonts
Shift when banner collapses after accept	Late CLS	CMP + layout shell
Shift when route changes without full reload	Late CLS	SPA shell / router
Shift only after tapping play on video	Late CLS + possible INP	Embed wrapper + click handler
Shift on URLs with no embeds in lab URL list	Journey mix	Monitoring config

Label tickets with that table. It stops teams from re-optimising LCP images when the CMP is moving the grid.

How to fix CLS after load without undoing early wins

You do not need a second metric. You need a second pass on the template after load-time sizing is correct.

Reserve space for UI that always appears later. Consent bars, sticky promos, and chat launchers get a min-height shell or overlay treatment in the base layout, not a client-only insert into document flow.
Stabilise route and feed transitions. Match skeleton dimensions to final cards; avoid prepending above the reading position; keep header height consistent across routes.
Pair lazy embeds with permanent wrappers. Lazy loading without aspect-ratio is a common way to recreate late jumps. Facades should sit inside the same box the iframe will fill.
Throttle third-party activation. Defer non-critical widgets until after first paint into reserved slots, not into zero-height nodes. Audit tag order with the same discipline as early-load scripts.
Add regression checks on journeys, not only home. Extend performance budgets beyond the homepage. Performance Budget Thresholds Template includes CLS ceilings per template; add a “post-scroll” or “post-consent” scripted check where late CLS appeared in DevTools.

Scheduled lab monitoring catches CMS and tag-manager drift before CrUX turns red. If you run many client origins, pair template fixes with recurring PSI runs on article, PLP, and checkout URLs, not a single flagship URL.

FAQ: late CLS and field monitoring

Is cumulative layout shift only measured during initial load?

No. CLS can accumulate across the page lifetime within session windows while content is visible. Late shifts from consent, embeds, and dynamic inserts count the same as early ones. That is why layout shift after page load shows up in field data when lab load-only runs look fine.

Can I fix late CLS without fixing early CLS first?

You can parallelise, but early wins are cheaper. Size above-the-fold media and fonts first so traces are readable. If early CLS is still high, late fixes are harder to verify because multiple bursts overlap in one session window.

Does fixing late CLS help INP?

Sometimes indirectly. Removing unnecessary DOM insertions and reserving expanded UI reduces main-thread work on interaction. Heavy handlers still need profiling; a CLS patch alone rarely fixes INP on its own.

Why does Search Console CLS differ from Lighthouse on the same URL?

Different populations, devices, and journeys. Field data includes navigations where users scrolled, accepted cookies, and hit personalised routes. Lighthouse uses a controlled load. Use lab for element lists; use field for whether the pain is widespread.

Should agencies report early and late CLS separately?

Yes, in client language. Stakeholders understand “banner after accept” and “infinite scroll” better than a single CLS number. Splitting the narrative keeps engineering scope honest and speeds approval for CMP or template work.

Late CLS is not a separate Core Web Vital. It is the same metric telling you that stability failed after the load-time checklist was already green. Split early versus late shifts in DevTools, reproduce the journeys field users actually take, and fix slot contracts for UI that arrives after LCP.

When you need scheduled lab coverage across templates and client sites, open Apogee Watcher pricing and pick a plan that matches your portfolio size.

References

Why Your Store's Conversion Problem Is Usually In The Code

Tue, 18 Aug 2026 22:55:14 +0000

Most conversion advice that reaches developers is written for marketers, so it stops at "add trust signals" and never names a file to open. This is the version for the people who actually own the checkout template.

The Number That Sets The Stakes

The average ecommerce store converts somewhere between 2 and 3 percent, which means 97 or 98 of every 100 visitors leave without buying. The instinct is to go buy more traffic. The cheaper move is to find where the existing traffic is dropping out, because that work compounds and ad spend does not.

Checkout Is An Engineering Problem

Almost every checkout has friction that exists because a field was easier to add than to remove. Forced account creation before purchase. Nine fields where five would do. Address validation that rejects a legitimate apartment format. Payment methods the buyer does not already have set up.

The single most common abandonment reason is still shipping cost appearing at the final step. Nothing about moving that number earlier is hard, it is a template change and a shipping estimate call, and it consistently outperforms most redesigns.

Speed Is A Conversion Feature

Mobile conversion falls off sharply between two and four seconds. Most stores are carrying a few hundred kilobytes of third party apps, pixels and tag manager containers that nobody has audited in a year, each one added for a reason that expired.

Load your own product page with a throttled connection and a cold cache, then open the network tab and sort by transfer size. The list of things you can delete without anyone noticing is usually longer than expected.

Instrument Before You Optimize

You cannot fix a funnel you cannot see. Per step drop off between product view, add to cart, checkout start, shipping, payment and purchase is the minimum. Without it, every conversation about conversion is an argument between opinions.

Segment it too. A store at 2 percent overall is often at 4 percent on branded search and under 1 percent on cold paid traffic, and those two numbers need completely different fixes.

Tests That Actually Resolve

Here is the part that trips up engineering teams new to CRO. On a 2 percent baseline, detecting a realistic relative lift needs far more sessions per variant than most stores get in a two week window. Run the sample size math before the test, not after.

If the traffic is not there, ship the changes that are correct on their own merits, removing a broken validation rule does not need an experiment, and watch the trend instead of pretending a fourteen day test settled anything.

Where To Go Deeper

The page level checklists, the testing framework and the measurement setup are all laid out in this complete guide to ecommerce conversion rate optimization, which is the long form version of everything above.

When PageSpeed Insights Shows No CLS or INP for Your URL

Tue, 11 Aug 2026 10:52:00 +0000

You paste a client URL into PageSpeed Insights and the lab block looks fine: Largest Contentful Paint, Total Blocking Time, even a Cumulative Layout Shift score from Lighthouse. Scroll to the field section and Interaction to Next Paint (INP) or CLS is simply absent. Not red, not amber, just missing. The account manager asks whether the page fails Core Web Vitals. You are not looking at a broken test. You are looking at a Chrome User Experience Report (CrUX) eligibility gap, and it is one of the most common sources of confusion in agency reporting.

PageSpeed Insights merges two data sources on one screen. Lab numbers are synthetic: Lighthouse runs on demand with a fixed device profile. Field numbers come from CrUX, a 28-day rolling sample of real Chrome users. Google only publishes a field metric when enough opted-in sessions meet privacy and quality thresholds for that origin, URL, device class, and metric. When the sample is too thin, PSI shows no data for that metric even though lab CLS or INP is right there. That split is normal on low-traffic pages, new launches, long-tail templates, and some desktop-only views. The fix is not to rerun the test until a number appears. The fix is to know which layer you are reading, follow a short decision tree, and fall back to scheduled lab monitoring where field data cannot exist yet.

Why PageSpeed Insights sometimes shows no CLS or INP field data

CrUX is not a census of every visit. Google aggregates performance from a subset of Chrome users who have opted in to sharing statistics. Before a metric appears in PageSpeed Insights field data, the URL or origin needs enough recent sessions in that collection period. If the count falls below Google's threshold, the metric is withheld rather than shown with misleading precision.

Several situations trigger a missing field row:

Insufficient sample size for the specific URL, especially on blog posts, campaign landers, and localised paths that get far fewer sessions than the homepage.
Origin-level data only, where CrUX has enough traffic for example.com but not for example.com/pricing/enterprise.
Metric-specific gaps, where LCP field data exists but CLS or INP does not, because each metric has its own eligibility within the same report.
Form factor splits, where mobile field INP is published but desktop INP is not, or the reverse, because phone and desktop traffic are reported separately.
New or recently changed URLs that have not yet accumulated four weeks of blended field history in the rolling window described in why your Core Web Vitals fix is not in CrUX yet.

None of these mean the page is fast or slow in the eyes of Google Search. They mean Google does not have enough field evidence to print a percentile for that slice. Search Console may still group the URL with origin-level status when URL-level field data is missing, which is another reason teams misread a single PageSpeed Insights screenshot as the full story.

Lab CLS and INP vs missing CrUX field data on the same URL

The most confusing PSI screen is lab green beside an empty field row. Lighthouse always calculates lab CLS from the layout shifts it observes during the synthetic load. Lab interactivity is proxied through Total Blocking Time and related audits; INP itself is a field metric, so PSI does not show a field INP value when CrUX has no sample, even if lab TBT looks acceptable.

Lab (Lighthouse in PageSpeed Insights)	Field (CrUX in PageSpeed Insights)
Source	One controlled run you triggered	Opted-in Chrome users, 28-day window
CLS	Always calculated for that run	Shown only when CrUX sample is large enough
INP	Not a lab Core Web Vital; use TBT as a lab signal	Shown only when enough real interactions were captured
Best for	Template QA, deploy checks, before/after on priority URLs	SEO and client field status when eligible
Missing data meaning	N/A (rerun always produces lab output)	Usually low traffic or URL-level ineligibility, not a PSI bug

Treat the two blocks as complementary. Lab answers whether today's build looks clean on a representative device profile. Field answers whether enough real users experienced that quality over the past month. A missing field CLS or INP row does not invalidate lab work; it limits what you can claim about population-level Core Web Vitals for that exact URL. For the wider lab versus field programme, see synthetic versus real user monitoring and PageSpeed Insights versus automated monitoring.

When CrUX shows origin-level data but not URL-level CLS or INP

CrUX publishes at two granularities when sample size allows: origin (scheme plus registrable domain, for example https://www.example.com) and URL (the exact page tested). High-traffic homepages and top category routes often qualify for URL-level field data. Long-tail URLs frequently inherit only origin-level aggregates in PageSpeed Insights, or show no URL row at all.

If origin field CLS looks healthy but the product detail URL you care about has no field INP, you are not necessarily looking at a product-page regression. You may be looking at a page that does not meet URL-level thresholds. Google's PageSpeed Insights and CrUX guide documents how origin and URL slices appear in the UI. Practical workflow for agencies:

Run PageSpeed Insights on the origin (homepage or canonical host) and note which metrics appear at origin level.
Run the specific client URL and compare which metrics disappear.
If origin field data exists but URL data does not, report origin status for SEO conversations and use lab monitoring on the priority template until URL-level field history builds.
Query the CrUX History API or CrUX Vis for origin trends when you need charts; see CrUX Dashboard retired: where to get TTFB, INP, and field history for the replacement stack.

URL-level CrUX is valuable when you have it. It is not guaranteed for every page in the sitemap, and missing URL-level CLS or INP is often a traffic maths problem rather than a measurement error.

Desktop vs mobile splits when only one form factor has field data

PageSpeed Insights field data is split by phone and desktop form factors. Each combination of origin or URL, metric, and form factor has its own eligibility. That is why community threads describe CLS on desktop in one tool and no CLS on mobile in PageSpeed Insights, or INP on mobile with no desktop INP row.

Mobile traffic usually dominates retail and publisher sites, so mobile field Core Web Vitals are what Search Console emphasises for many properties. B2B sites with heavy desktop usage during business hours can still lack desktop INP in CrUX while mobile INP passes. Always note which strategy you selected in PageSpeed Insights before screenshotting a report. Switching between mobile and desktop lab profiles does not change field eligibility, but it changes which field column you are looking at.

For portfolio programmes, monitor both form factors on priority templates even when only one has field data today. Mobile versus desktop Core Web Vitals monitoring covers schedules and budgets; the reporting rule here is simple: never merge mobile and desktop field percentiles into a single averaged number for client decks.

Decision tree: what to check when PageSpeed Insights has no data

Use this sequence before you tell a client their CLS or INP "does not exist."

1. Confirm the exact URL (scheme, host, trailing slash) matches the live page
        |
        v
2. Check ORIGIN field data in PageSpeed Insights (same host, homepage if needed)
        |
        +-- Origin also missing --> likely low traffic or new site; skip to step 5
        |
        v
3. Check URL-level field data for the same metric on MOBILE and DESKTOP
        |
        +-- One form factor missing --> report the eligible one; lab-monitor the other
        |
        v
4. Compare LCP vs CLS vs INP availability (metric-specific gaps are common)
        |
        +-- Only INP/CLS missing --> interactions or shifts rare vs LCP paint; still fix in lab
        |
        v
5. Run lab Lighthouse on the template; store scheduled lab trends for proof
        |
        v
6. Set performance budgets and alerts on lab CLS/TBT (and field when it appears)

Step 4 matters for triage. A URL with field LCP but no field CLS often still has layout shift risk; Lighthouse lab CLS on that template is your honest diagnostic until CrUX accumulates enough sessions. A URL with no field INP may still have interaction pain visible as lab TBT or as INP in Chrome DevTools performance recordings on a real device.

If origin and URL both lack all field metrics, read Google's public guidance on discovering what your real users experience and treat the property as field-ineligible for now. SEO impact is evaluated at the origin level where data exists; product impact on a thin URL still warrants lab budgets because your users feel the page even when CrUX does not publish a percentile.

How agencies should monitor low-traffic URLs without CrUX samples

When PageSpeed Insights returns no field CLS or INP, your operating model shifts from field percentiles to template-level lab cadence plus origin field context.

Pick representative URLs, not every long-tail path. Monitor checkout, pricing, primary landing templates, and top blog layouts on a schedule. One good template lab series beats fifty one-off PSI pastes that all show "no data."

Store lab CLS and TBT (INP proxy) over time. Field INP may appear later if traffic grows; until then, regression alerts on lab metrics catch script and font changes that would hurt real users. Tie thresholds to performance budget templates and explain in client reports that field slices are pending, not ignored.

Use origin field data for executive summaries. When URL-level INP is missing, origin mobile INP still informs whether the domain broadly passes interactivity expectations. Pair that with lab evidence on the specific template you shipped last Tuesday.

Document device splits in every report. Note "mobile field INP: 142 ms p75; desktop field INP: not available (insufficient CrUX sample)" so stakeholders do not assume desktop is fine because mobile is green.

Re-test after traffic events. Product launches, paid campaigns, and seasonal enrolment can push a URL over CrUX URL thresholds. Schedule a quarterly eligibility check on pages that matter commercially.

Apogee Watcher is built for that layered model: scheduled PageSpeed Insights and Lighthouse runs across many client sites, budgets on lab metrics, and alerts when a priority URL regresses, while you still read field slices where Google publishes them. It does not manufacture CrUX samples for pages Chrome users rarely visit. It keeps lab proof continuous until field data catches up.

When field CLS or INP returns, compare it to the lab trend you stored. If they diverge, you are usually looking at cache mix, device diversity, or third-party behaviour that lab did not emulate. That is when CLS deep-dive fixes and LCP, INP, and CLS explained move from reference reading to sprint work.

FAQ

Why does PageSpeed Insights show lab CLS but no field CLS?

Lab CLS comes from Lighthouse on every run. Field CLS requires enough real Chrome sessions on that origin or URL in CrUX. Low traffic, URL-level ineligibility, or a form factor with too few sessions are the usual causes.

Does missing INP in PageSpeed Insights mean the page passes interactivity?

No. It means CrUX does not have enough interaction data to publish field INP for that slice. Use lab TBT, manual device testing, and scheduled lab monitoring until field INP appears or you confirm the URL is intentionally low priority.

Can I force URL-level CrUX data to appear?

You cannot opt in a single URL. Eligibility follows Chrome traffic volume and Google's privacy thresholds. Growing organic and paid traffic to the URL, fixing canonical and redirect issues, and waiting through the 28-day rolling window are the levers you actually have.

Should I report origin data when the client asked about one URL?

Yes, with a clear label. Origin field Core Web Vitals describe the domain's eligible traffic pool. Pair origin field status with lab results on the specific template so the client sees both the SEO-wide picture and the page they shipped.

Is "no data" the same as a failing Core Web Vital?

No. Missing field data is not a pass or fail badge. Search Console may use origin-level grouping for URLs without their own field row. Treat missing data as "not enough field evidence," then use lab monitoring and origin context until URL-level metrics qualify.

When should I use the CrUX API instead of PageSpeed Insights?

Use PageSpeed Insights for a quick human-readable check. Use the CrUX API or History API when you need to store daily or weekly field percentiles in your own database across many origins. Eligibility rules are the same; the API does not bypass sample limits.

Missing CLS or INP in PageSpeed Insights is a data availability problem, not a mystery bug. Read origin before URL, mobile before you assume desktop, lab before you declare victory, and keep scheduled synthetic monitoring on the templates that drive revenue while CrUX catches up.

Start a free trial to schedule PageSpeed tests, set lab budgets on priority URLs, and track regressions across client portfolios when field data is thin or absent.

References

CrUX Dashboard Retired: Where to Get TTFB, INP, and Field History

Mon, 10 Aug 2026 17:57:00 +0000

For years the CrUX Dashboard was the bookmark agencies opened when a client asked whether field Largest Contentful Paint had moved since the last deploy. It was a Looker Studio report on monthly Chrome User Experience Report (CrUX) data: stacked bars for origin-level distributions, a familiar place to screenshot TTFB, Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) without writing SQL. Google retired it at the end of November 2025 and shut down the shared CrUX Connector that fed it. If your team still has a saved link, the chart either fails to load or stops at the last month the connector received.

The Chrome UX Report itself did not go away. What you need now is a replacement stack: CrUX Vis and the CrUX History API for TTFB, INP, and CLS trends, PageSpeed Insights and Search Console for the latest field slice, BigQuery if you want years of origin history on your own billing project, and scheduled lab monitoring so deploy proof does not wait on CrUX's 28-day rolling window. No single free dashboard copies every old Looker view, but the migration path is straightforward once you match each tool to the question you are actually asking.

Why Google retired the CrUX Dashboard and Looker Studio connector

Google announced the deprecation in September 2025. The CrUX Dashboard was a Chrome team-maintained Looker Studio template on monthly CrUX tables. Usage grew after Core Web Vitals became a ranking signal in 2020, but the connector behind it struggled with outages, especially around monthly data releases. Google pointed teams at the CrUX History API (weekly series, up to about 40 points) and CrUX Vis (first-party charts on that API) as more reliable paths.

By November 2025 the connector stopped receiving new months. Dashboards that depended on Google's shared BigQuery bridge stopped updating; CrUX release notes treated that as the final reminder. You can still run the old Looker template against your own chrome-ux-report BigQuery project if you accept query cost and setup work, but the free one-click version most teams used is not coming back. CrUX Vis now carries much of the same job with weekly points instead of monthly bars, and PageSpeed Insights still shows the latest rolling 28-day field slice when Google has enough Chrome traffic for the origin or URL.

PageSpeed Insights field data and Search Console: current Chrome UX Report numbers

When someone asks "what does CrUX say right now?", they usually want the latest rolling field percentiles, not six months of history. Three surfaces answer that question most often, and they share the same underlying dataset with different filters and presentation. PageSpeed Insights, Search Console, and the daily CrUX API each emphasise a different workflow, but the numbers trace back to the same Chrome User Experience Report collection rules.

PageSpeed Insights field data for one origin or URL

PageSpeed Insights is still the default check for a single origin or URL. Open PageSpeed Insights, run the test, and read the field section when CrUX has eligible traffic. You get origin-level and, when sample size allows, URL-level p75 values for Core Web Vitals and supporting metrics, including experimental field Time to First Byte (TTFB) where Google publishes it. Lab Lighthouse numbers on the same screen are synthetic; field numbers are the 28-day rolling average described in why your Core Web Vitals fix is not in CrUX yet.

PageSpeed Insights lab data versus field data on the same URL

PageSpeed Insights shows lab and field on one page, which is convenient and easy to misread. Lab data is a controlled Lighthouse run on demand: fixed device profile, emulated network, one load you triggered. Field data is CrUX: real Chrome users over roughly the past 28 days, blended across devices, cache states, and journeys. A green lab Performance score beside an amber field INP band is normal after a deploy, on a low-traffic URL, or when third-party scripts behave differently for real users than in the lab.

	Lab (Lighthouse in PageSpeed Insights)	Field (CrUX in PageSpeed Insights)
Source	Synthetic test you run	Opted-in Chrome sessions
Clock	Same day, every run	28-day rolling average
Best for	Deploy verification, before/after on priority URLs	SEO reporting, client field status
Replaces CrUX Dashboard history?	No (point-in-time unless you store runs)	No (latest period only; use CrUX Vis or History API for trends)

Treat the two blocks as complementary, not competing scores. Lab answers whether the change shipped cleanly; field answers whether enough real users have lived with it for the aggregate to move. For a fuller split between synthetic schedules and real-user monitoring, see synthetic versus real user monitoring. The CrUX Dashboard retirement does not remove that distinction; it removes one place that charted field history without opening PageSpeed Insights, CrUX Vis, or an API client.

Search Console Core Web Vitals report for SEO workflows

Search Console's Core Web Vitals report groups URLs by status (Good, Needs improvement, Poor) at origin granularity for SEO workflows. It is slower to navigate than PageSpeed Insights for one URL, but account managers already live there for indexing and query data. Field metrics inherit the same CrUX eligibility rules: low-traffic pages may show origin-only data or gaps, which we will unpack further in a later post on missing CLS and INP in PageSpeed Insights.

Daily CrUX API for the latest field collection period

The daily CrUX API (queryRecord endpoint) returns the same latest collection period programmatically. Use it when you want to store today's field p75 beside yesterday's in your own database, or when a script needs TTFB, INP, or CLS without opening a browser. It refreshes roughly daily with a short processing lag; it does not return the long weekly history that the History API exposes.

Need	Tool	Granularity	History
Quick check on one URL	PageSpeed Insights	Origin + URL when eligible	Latest 28-day period only
SEO reporting by URL group	Search Console CWV report	Origin / URL groups	Status trends, not full metric export
Automation for "today's field"	CrUX API `queryRecord`	Origin or URL	One collection period per call
Metric definitions and thresholds	[Core Web Vitals guide](https://apogeewatcher.com/blog/what-are-core-web-vitals-a-practical-guide-for-2026)	Reference	N/A

CrUX Vis and the CrUX History API: TTFB, INP, and CLS field history

The old CrUX Dashboard's real value was trend lines: did INP drift after the tag manager change, did TTFB step up when the CDN rule shipped, did CLS calm down after the font fix? Current field snapshots in PageSpeed Insights answer "where are we this week?" History answers "when did it start moving?" Those are different tools now, and most teams need both answers on retainer accounts.

CrUX Vis for weekly field trend charts

CrUX Vis is Google's direct replacement UI. Point it at an origin or URL and open the Core Web Vitals, Loading Performance, Interactivity, or Visual Stability pages. Each chart shows weekly distributions built from the CrUX History API, with each point covering the previous 28 days of Chrome experiences. Data updates on Mondays; you can see up to about 40 weeks where Google has samples. TTFB sits with loading metrics; INP with interactivity; CLS with visual stability. CrUX Vis is free, fast compared with the old Looker report, and enough for a quarterly business review on one domain. It still queries one origin or URL at a time, so it does not replace a spreadsheet of fifty client homepages.

Query the CrUX History API for programmatic field history

The CrUX History API (queryHistoryRecord) powers CrUX Vis and any custom chart you build. With a Google Cloud API key you can pull weekly time series for origins and, critically, for URLs that qualify, which monthly BigQuery alone did not make easy for page-level history. Set collectionPeriodCount up to 40 to match the Vis window. Pair History API calls with daily queryRecord calls when you want both "what happened over the last six months" and "what changed since Tuesday's deploy." Google's History API guide documents form factors, histogram densities, and collection period dates; put those dates on client slides so nobody mistakes a four-week blend for a live score.

BigQuery for long-archive Chrome UX Report analysis

BigQuery (chrome-ux-report public dataset) remains the long-archive option. Monthly tables still publish for deep analysis, competitive research, and custom Looker Studio reports on your own billing account. Load times are slower and the data is less current than the APIs, but you can join CrUX to analytics exports, slice by country or device tables, and keep years of origin history that exceed the History API window. Expect to pay for queries after the free tier unless you cache results. Some newer sub-metrics appear in APIs before every BigQuery table catches up; check CrUX release notes when you standardise a metric set for client reports.

CrUX Vis, CrUX History API, or BigQuery: which fits your question?

Teams often ask for one replacement tool. In practice you pick by question, budget, and who needs to open the chart. Use CrUX Vis when a technical lead or SEO owner needs a trustworthy trend for one priority origin or URL and nobody wants to maintain a script. It is the fastest honest answer to "show me INP over the last few months" in a client call. Use the History API when you need the same series inside your own dashboard, a weekly email, or a database next to deploy tags. Use BigQuery when the question needs custom SQL, long horizons, or joins that Google's UI will never ship. Use PageSpeed Insights or the daily API when the question is simply whether today's field p75 cleared the budget.

None of these options shorten the 28-day rolling window. A fix shipped yesterday still ages into field aggregates gradually, which is why scheduled lab monitoring matters during the lag. PageSpeed Insights versus automated monitoring covers that split for teams who outgrew manual checks; the CrUX retirement does not remove the need for a lab clock beside the field clock.

Third-party Chrome UX Report tools for agency portfolios

Google is not the only place to chart CrUX. Several products wrap the History API or BigQuery with alerts, competitor views, and multi-URL boards. Treo is a common example for agencies that want CrUX-heavy field exploration and large URL lists without building pipes themselves. Field explorers and scheduled PageSpeed monitoring solve different jobs, and many teams use both. For how agencies shortlist monitoring tools on features and workflow fit, see comparing PageSpeed monitoring tools.

Apogee Watcher sits on the scheduled lab side of that split. We run PageSpeed Insights-backed tests across many sites on a cadence you set, store LCP, INP, CLS, FCP, and Total Blocking Time from lab runs, and show CrUX field numbers beside those results when Google returns them for the URL. We do not replace CrUX Vis for a six-month INP line chart on one domain, and we do not replicate BigQuery. We do give agency portfolios a repeatable before-and-after history on priority pages, budgets, and alerts while field data catches up, layered onto Search Console and the explorers you already use.

Field pipelines also slip. Collection delays, eligibility changes, and processing lag still show up in client inboxes as "why is Search Console still amber?" The same 28-day rolling window explains part of that lag after a deploy; see why your Core Web Vitals fix is not in CrUX yet for how to phrase timelines in client reports without blaming the wrong team.

What no free Chrome UX Report dashboard replaces after retirement

Being precise about gaps prevents another bookmark rot cycle. No free Google UI reproduces every old CrUX Dashboard view in one place. CrUX Vis does not list forty client origins on one screen. PageSpeed Insights does not chart six months of TTFB without you opening each URL. Search Console does not export weekly p75 series for every template. BigQuery is powerful but not free at scale and not friendly for account managers. The History API is accurate but requires engineering time.

Third-party tools close some of those holes with paid seats, URL limits, and their own refresh schedules. None of them remove CrUX eligibility rules: low-traffic pages still lack URL-level field data, desktop and phone still split, and rolling averages still trail deploys. The workable agency pattern we see is a small stack: CrUX Vis or a field explorer for deep history on hero URLs, Search Console for SEO status, scheduled lab monitoring for portfolio regression detection, and one sentence in the report that explains collection period dates. If nobody owns the threshold on a metric and nobody acts when it breaks, it should not be on the daily list, whether the chart came from Google or a vendor.

How agencies monitor Chrome UX Report field metrics across client sites

A practical Monday workflow after the dashboard retirement:

List priority origins and money URLs per client (home, pricing, signup, checkout, main templates). Match the list to URLs that actually receive Chrome traffic, not only the page engineering fixed in staging.
Pin one field history view per key domain. CrUX Vis or a History API-backed explorer for quarterly reviews; note the collection period on the screenshot.
Schedule lab tests on the same URLs. Use budgets so a deploy regression triggers before field data moves. Frequency guidance lives in how to schedule PageSpeed monitoring if you are standardising cadence across accounts.
Pull Search Console CWV status monthly for SEO owners. Treat it as a lagging group report, not a deploy gate.
Reserve BigQuery or custom API jobs for investigations (country regressions, device splits, before/after studies), not for every account manager every week.

Apogee Watcher automates steps two and three for multi-site organisations: discovery, scheduled tests, field slices when available, alerts, and client-ready exports without maintaining fifty PageSpeed Insights bookmarks. Start with a free domain check on one money URL if you want to see lab and field side by side before you add the portfolio, then expand the same URL list into budgets once the cadence feels right.

FAQ

Is the CrUX Dashboard still available?

Google deprecated the shared CrUX Dashboard and turned off the CrUX Connector at the end of November 2025. You can copy the Looker Studio template and point it at your own BigQuery project, but the hosted connector most teams used no longer updates. CrUX Vis is Google's recommended first-party replacement for historical charts.

Where do I get field TTFB now that the dashboard is gone?

Check PageSpeed Insights field data for the latest rolling TTFB when Google publishes it for your origin or URL. For history, use CrUX Vis Loading Performance charts or query the CrUX History API for weekly TTFB series. BigQuery monthly tables remain available fo

Your Website’s New Audience: AI Agents

Mon, 20 Jul 2026 11:53:25 +0000

Web performance has traditionally always been about human user experience. In recent time, that has evolved to include AI agents as well. AI agents can be thought of as anonymous and agentic systems that browse, consume and interact the web on behalf of users. As more and more people continue to use AI agents or search engines pushing AI mode, it is recommended to optimize for agentic browsing as well.

Google has recently included an agentic browsing category for both lighthouse and pagespeed insights, although they are currently experimental.

How do we do that? Broadly speaking, there are a few basic steps that can be covered here:

1. Accessibility Tree:

When agents browse your page, they do not typically "see" the page as a human would. They parse the DOM structure to analyze element roles, names and relationships. If any part of the tree is incomplete, it may lead to broken data and checkout flows. Google Lighthouse today measures this by the following methods:

Every interactive element (button, input, link) needs to have a text node or aria-label assigned to it so they are "visible" to agents.
Parent - child relationships or sibling relations must be clear in the tree. For example, a label must be clearly tied to an input and so on. This is for better context of the general page structure and executing workflows.
Interactive elements should NOT be hidden - A clickable Submit button hidden via CSS or aria-label confuses agents.

2. Proper Metadata:

A llms.txt present at the root of your domain summarizes key pages and sections for the agent to browse for any given task without having to hit every page unnecessarily. There are more advanced techniques here like schema.org and llms-full.txt for a more enhanced summary.

3. Cumulative Layout Shift (CLS):

Cumulative Layout Shift is already a part of traditional web performance metrics but for agents, it is even more crucial as layout stability ensures that the agent does not misclick or misfire anything in a given workflow or task.

4. WebMCP Adoption:

With WebMCP, agents are provided with APIs that enable them to directly take any action based on the user prompt. There are currently two ways to implement this - a declarative API, defined directly with HTML forms or imperative API, with JavaScript. This is currently available under an origin trial - meaning you can actually try this out today in production with real users. This has practical use cases - like ecommerce, travel and general automation of day-to-day tasks.

Checking if your website is agent ready

One really good resource I've found for checking this is https://isitagentready.com/ - it gives you actionable insights and a prompt by checking against these aforementioned standards.

Closing thoughts

I'm not sure the future of the web will be fully autonomous (or if we would have evolved to some new interface) but for the moment, the best strategy is: build your page for humans and optimize the basics first - accessibility, structure, metadata, stability of the page. Then if and when the need arises, WebMCP and other technologies could be gradually introduced.

Why Your WordPress Site Is Slow (It Is Not Always Hosting)

Mon, 13 Jul 2026 12:31:00 +0000

When an enterprise WordPress site feels slow, the first meeting is almost always about infrastructure. Upgrade the server. Add a CDN. Move to a higher hosting tier. Those moves can help, and sometimes they are the right call. In our delivery work across hundreds of large WordPress sites, the limit is more often the code running on the stack: plugins loading assets where they are not needed, redundant database queries on every request, bloated autoloaded options, and third-party scripts executing before the page can paint. A faster machine does not remove that work. What follows is how to tell hosting from code, what to fix first, and how to keep performance from sliding back after the audit.

Why do slow WordPress sites get blamed on hosting first?

Hosting is easy to see on a budget. It has a line item, a vendor logo, and a simple story: pay more, get more CPU. Stakeholders who do not live in the theme or plugin stack can point at the invoice when Core Web Vitals slip or when support tickets mention sluggish admin screens. Agencies inherit that framing when renewal season arrives or when a new CTO asks for a one-slide fix plan.

The story is not wrong in every case. Under-provisioned PHP workers, missing object cache, or a database server sharing hardware with a heavy marketing export job can cap every optimisation you make in the theme. The mistake is treating infrastructure as the default answer before anyone profiles a real URL under real traffic. PageSpeed Insights and Chrome DevTools still show whether time is spent waiting on the server (TTFB) or in render and script work on the client. If you skip that split, you risk funding a hosting upgrade that leaves LCP and INP unchanged because the homepage still loads twelve plugin stylesheets on a contact page.

When is a hosting or CDN upgrade the right fix?

Start with evidence, not tier names. Hosting is a sensible priority when TTFB stays high on cached or lightly dynamic templates after you have ruled out obvious query and autoload problems, when PHP-FPM queues spike under normal traffic, when Redis or Memcached is unavailable and the database becomes the session store for every visitor, or when the site has outgrown shared resources and error logs show timeouts rather than slow JavaScript tasks.

A CDN helps when static assets are served from a distant origin, when image bytes dominate LCP, or when you need predictable edge caching for anonymous HTML. It does not fix a plugin that enqueues analytics on every admin and front-end context, and it does not shrink a two-megabyte autoloaded options row. Pair infrastructure decisions with A Quick Way to Fix LCP: Four Changes That Cut Time to Paint so you separate server wait from paint path problems before you sign a new contract.

Signal	Likely layer	First move
High TTFB on simple pages after code cleanup	Hosting, database, cache	Profile queries, enable object cache, review PHP pool sizing
Good TTFB, poor LCP/INP	Theme, plugins, third parties	Asset audit, script policy, template-specific enqueues
Slow only on cart, checkout, or logged-in routes	Application logic, extensions	Profile those URLs; see [WooCommerce Performance Tuning (2026 Guide)](https://apogeewatcher.com/blog/woocommerce-performance-tuning-2026) for shop pages
Regression after deploy, stable hosting bill	Code release	Diff enqueued assets and database changes; restore budgets

What code problems make WordPress slow without bad hosting?

WordPress performance is a set of code and configuration choices, not a single hosting setting. These patterns appear repeatedly on enterprise sites that already run on capable managed hosts.

Plugins that load assets globally

Many extensions register CSS and JavaScript on wp_enqueue_scripts without checking the template. A related-posts module meant for blog singles can still load on the homepage, checkout, and legal pages. Multiply that by thirty active plugins and the browser downloads hundreds of kilobytes before first paint on pages that never use the features. Query Monitor and asset inspection in DevTools show which handles appear on which URLs; the fix is conditional enqueues, dequeue rules, or removing the plugin when the feature is unused.

Redundant or unindexed database queries

Each uncached request can trigger dozens of queries from core, theme, and plugins. Poorly written custom code, meta queries without limits, and admin bar or SEO modules that scan large tables on front-end requests add latency that shows up as TTFB. Object cache reduces repeat cost but does not excuse N+1 patterns. Profile with Query Monitor on the slowest templates, fix or replace the worst offenders, and retest before buying new servers.

Bloated autoloaded options

WordPress loads all rows in wp_options where autoload = yes on every request. Plugins that store large JSON blobs, full import logs, or telemetry with autoload enabled can add megabytes to each page load. Inspect autoload size with standard diagnostics or database tools; set autoload to no for large keys that do not need to load on every hit, and delete stale option rows left by deactivated plugins.

Third-party scripts before first paint

Tag managers, chat widgets, A/B snippets, and personalisation vendors often inject synchronously or early in the document. They hurt INP and can delay LCP even when hosting is fast. Third-Party Scripts and Performance: How to Identify and Fix the Worst Offenders walks through ranking vendors and tightening load order; on WordPress, the same scripts are usually added by plugins or the theme customiser rather than by hand-coded tags.

Theme and page-builder weight

Elementor, Divi, WPBakery, and similar builders enqueue global bundles across templates. Enterprise sites keep them because marketing teams depend on the workflow, but the performance cost is real. Mitigations include asset optimisation plugins where they are reliable, stripping unused widgets, and hard rules about which templates may use the builder versus block templates for high-traffic routes.

How do you audit a slow WordPress site before buying infrastructure?

Treat the audit as an ordered checklist rather than a vague “make it faster” ticket.

Pick representative URLs. Homepage, primary conversion path, a heavy archive, and one logged-in or commerce route if applicable. Slow sitewide averages hide checkout pain.
Run PageSpeed Insights on mobile and desktop. Note TTFB, LCP, INP, and CLS separately. Save lab reports for before-and-after proof.
Profile server time. Query Monitor on staging or a controlled production window; hosting dashboards for PHP slow logs and database wait.
List active plugins and who owns each. Mark business-critical extensions versus legacy installs nobody will defend in a meeting.
Measure autoloaded options size and top database tables by row count where WooCommerce or custom post types dominate.
Inventory third-party scripts on conversion URLs with marketing modules enabled, not on a stripped staging theme.
Document findings in client language: what changes behaviour, what changes cost, what needs a release window.

The Core Web Vitals monitoring checklist for agencies gives you release checks across clients; use it after the fix so a plugin update does not undo the audit quietly. For ongoing scope and cache pitfalls on WordPress sites, WordPress Performance Monitoring: A Complete Guide covers what to watch between audits.

What results can code-first fixes deliver?

Outcomes vary by site, but code-led work can move metrics that hosting alone did not touch. In our experience on large WordPress projects we have seen concurrent user capacity roughly double after autoload cleanup, selective plugin removal, and object cache tuning on an unchanged server cluster. TTFB on key templates has fallen by about half when the main cost was query volume and options loaded on every request rather than CPU limits. Core Web Vitals have moved into passing bands on priority URLs without migrating data centres, because LCP and INP improved when we tightened assets and scripts, not when we bought faster hardware.

Those numbers are not a guarantee for your stack, but they show why buyers should fund a code audit before signing a more expensive hosting contract. Performance is a discipline built on standards, review, and measurement, not a plan tier.

How do you keep WordPress fast after the audit?

One-off cleanups decay without guardrails. Set plugin policy: who may install extensions, which categories need security review, and which routes must stay builder-free. Define asset rules: no new global enqueues without template justification. Add release checks: run synthetic PageSpeed tests on the priority URL list before major plugin updates, and compare results to the baseline you saved during the audit.

Translate thresholds into performance budgets per template so regressions trigger a conversation instead of a surprise in Search Console. How to schedule test frequency and priority across your portfolio explains cadence when you manage dozens of client sites; daily or weekly lab runs on mobile and desktop catch deploy drift long before field data moves.

Apogee Watcher fits agencies that need one schedule and history layer across many WordPress sites: a site per domain, discovery from sitemaps where exposed, PageSpeed Insights runs with CrUX context, and budget alerts when LCP or INP drifts on named paths. We layer on your existing host and tools; we do not replace server APM or WordPress admin. When you are ready to set up scheduled monitoring after the audit, start with Getting Started with Apogee Watcher: A Step-by-Step Setup Guide.

FAQ

Why is my WordPress site slow after I upgraded hosting?Hosting upgrades improve server capacity and sometimes edge caching, but they do not remove heavy plugins, autoload bloat, or third-party scripts. If TTFB improved but LCP or INP did not, the next pass belongs in the theme and plugin stack, not another tier change.

How do I tell if WordPress is slow because of plugins?Compare the same URL with a minimal theme and plugins disabled on staging, or use Query Monitor to see per-plugin query time and hooks. If asset handles and query counts drop sharply, tighten plugin policy and load scripts only on the templates that need them.

Is enterprise WordPress performance mostly about hosting?Not in our experience on large projects. Hosting sets a ceiling; code and configuration set most of the day-to-day latency on mixed marketing, membership, and commerce sites. Enterprise WordPress performance improves when engineering owns autoload, queries, and asset rules, not only when finance approves a new server.

Should I fix WordPress speed before Core Web Vitals monitoring?Run a baseline first. Monitoring shows whether TTFB, LCP, or INP is the constraint and proves whether hosting or code changes worked. A short baseline before the audit and scheduled tests after fixes beat guessing from a single manual PageSpeed run.

When should agencies push back on a hosting-only tender?When lab data shows acceptable TTFB on priority URLs but poor paint or interaction metrics, or when autoload and plugin audits list concrete fixes that cost less than a multi-year hosting contract. Bring evidence from scheduled tests and a phased code plan buyers can compare line by line.

Next step: Run PageSpeed Insights on three priority WordPress URLs, note whether TTFB or client-side metrics fail first, then work through the audit list before approving infrastructure spend. Start monitoring those URLs on a schedule so the fix survives the next plugin update.

WooCommerce Performance Tuning (2026 Guide)

Fri, 10 Jul 2026 12:39:00 +0000

WooCommerce performance tuning is not a single plugin install or a one-off PageSpeed Insights paste. Your shop runs on WordPress hosting, a theme or page builder, dozens of extensions, and dynamic routes that full-page cache cannot treat like the homepage. Shoppers still judge you on the same signals Google publishes: Largest Contentful Paint on product galleries, Interaction to Next Paint on variant pickers and checkout fields, and Cumulative Layout Shift when cart badges and promo bars load late.

Slow WooCommerce stores pay in conversion, not only rankings. In our experience and in published retail studies, each extra second of load time on mobile can trim conversions by roughly three to seven per cent, with wider spreads on checkout-heavy traffic. Published retail speed research summarised on web.dev links small load-time improvements to measurable funnel movement; mobile shoppers tolerate less delay than desktop benchmarks suggest. What follows is a prioritised 2026 playbook: infrastructure first, then data structure, caching, media, and extensions, with Core Web Vitals monitoring on the URLs that actually carry revenue. For funnel-wide metric priorities, pair this with Performance Monitoring for E-Commerce: What Metrics Matter Most; for ongoing WordPress scope and cache pitfalls, see WordPress Performance Monitoring: A Complete Guide.

Which WooCommerce URLs should you tune and monitor first?

Sitewide averages hide checkout pain. Prioritise optimisation and scheduled tests in this order:

Product detail pages (PDPs): heavy images, variant UI, reviews; primary LCP and INP risk.
Shop and category archives: many thumbnails, filters, pagination or infinite scroll.
Cart: cart fragments, coupons, cross-sells; INP and CLS even when LCP looks fine.
Checkout and account: payment scripts, address fields, logged-in flows; often uncached.
Homepage and campaign landers: important for acquisition, but secondary to commerce paths.

Document the list per client during onboarding. A store that only tunes the homepage will miss the PDP regression that support tickets mention first. Mobile vs desktop Core Web Vitals monitoring matters here because WooCommerce traffic skews mobile on many catalogues.

Page type	Metrics to weight	Typical issues	Priority
Product detail	LCP, INP, CLS	Large gallery images, variant selectors, review widgets	Very high
Product listing	LCP, INP	Thumbnail grids, faceted filters, infinite scroll	High
Cart	INP, CLS	Cart fragments, mini-cart updates, upsell modules	High
Checkout	INP, TTFB	Payment gateways, address validation, third-party scripts	Very high

Does WooCommerce hosting limit how fast you can go?

Hosting is the ceiling for everything below. Shared plans with crowded neighbours, PHP without opcode cache, and no object cache force WooCommerce to hit MySQL on every cart calculation. Managed WordPress hosts that target commerce usually ship Redis or Memcached, tuned PHP-FPM pools, and edge caching that respects dynamic routes.

Agencies we work with commonly deploy stores on Kinsta, WP Engine, or Cloudways (Vultr HF or DigitalOcean profiles), but the decision criteria matter more than the logo: object cache available, sensible PHP version (8.2+ in 2026), staging that mirrors production CDN rules, and support that understands WooCommerce cache exclusions. WP Engine’s dynamic plugin loading can reduce front-end weight on supported stacks; verify on your client’s plan rather than assuming it is enabled.

If TTFB stays high after theme and plugin cleanup, profile hosting before micro-optimising CSS. Third-party scripts and performance helps when the bottleneck is JavaScript, but a two-second server wait on checkout is often infrastructure or database query volume, not a missing defer attribute.

Why should you enable High-Performance Order Storage (HPOS)?

High-Performance Order Storage moves order data out of the generic wp_posts and wp_postmeta tables into dedicated WooCommerce tables designed for order queries. WooCommerce’s own benchmarks report up to five times faster order creation, roughly one and a half times faster checkout in some configurations, and up to forty times faster order queries in the admin after migration. Those wins concentrate on order persistence and back-office screens rather than storefront LCP, but checkout can still feel snappier when writes were the bottleneck.

Enable it under WooCommerce → Settings → Advanced → Features when compatibility checks pass for your payment and fulfilment plugins. HPOS is one of the highest leverage database changes available in 2026 with limited theme impact, because it optimises back-office and order persistence rather than front-end templates. Run it before aggressive plugin pruning if orders are already large; the win compounds as transaction volume grows.

How should WooCommerce caching differ from a brochure WordPress site?

You cannot cache every URL identically on WooCommerce. Anonymous visitors may receive a fast cached HTML shell on the shop archive, while cart, checkout, and my-account must bypass full-page cache or you will serve another shopper’s session semantics. For page cache, cache homepage, shop, categories, and PDPs where your host or plugin allows, and exclude cart, checkout, my-account, and often add-to-cart endpoints. Document exclusions in client notes; our site audit checklist for onboarding includes stack fields for exactly this.

Object cache: enable Redis (or Memcached) when the host supports it. WooCommerce sessions, transients, and product lookups benefit disproportionately. Without object cache, every fragment refresh can multiply database reads.

Cart fragments: WooCommerce refreshes mini-cart markup via wc-ajax=get_refreshed_fragments on many page loads. That AJAX call is a common hidden INP and TTFB tax. Mitigations include conditional loading (only when the cart has items), disabling fragments on non-shop templates, or dedicated plugins and snippets that stop global refreshes. Measure before and after on the homepage and a PDP; fragments often hurt pages that never show a cart icon.

Popular WooCommerce-aware caching stacks include WP Rocket, LiteSpeed Cache on LiteSpeed hosts, and host-native edge layers. Rules matter more than brand: verify cart/checkout bypass, respect WooCommerce cookies, and purge product pages when stock or sale price changes.

How do you fix LCP on WooCommerce product pages?

Product galleries dominate LCP. Upload appropriately sized masters, serve WebP or AVIF with fallbacks, and use responsive srcset so mobile does not download desktop widths. Compress before upload with tools such as ShortPixel, Imagify, or similar; lazy-load below-the-fold gallery images but not the primary LCP candidate without measuring first.

Reserve explicit width and height on product images to protect CLS when thumbnails load. A CDN such as Cloudflare in front of static assets reduces latency for image-heavy catalogues; pair CDN work with image optimisation strategies for better LCP.

Theme and builder debt still matters. Elementor, Divi, and WPBakery layouts often enqueue global CSS and JavaScript on PDP templates. Audit sections you do not use; each active block can add render cost even when it looks empty on mobile.

What causes poor INP and CLS on WooCommerce shops?

INP rises when the main thread is busy during taps: variant changes that synchronously recalculate price, filters that re-render entire grids, and cart drawer scripts that fetch recommendations before showing contents. Profile with Query Monitor and Chrome DevTools performance recordings on throttled mobile; fix the longest tasks before debating INP thresholds with stakeholders. CLS appears when star ratings, consent banners, promo bars, or cart count badges inject without reserved space. Sticky headers plus announcement bars compete for the same viewport on small screens. Measure CLS on PDP and checkout with production marketing modules enabled, not on a stripped staging theme.

When should you audit WooCommerce plugins and themes?

Plugin count alone is not a score, but thirty to sixty active plugins with global asset loading is a pattern we see on struggling stores. Deactivate and delete unused extensions quarterly. Use Query Monitor to attribute slow queries and hooks to specific plugins. Prefer lightweight block themes or lean classic themes when rebuild budget exists; heavy builders are workable only with strict asset rules.

Load scripts and styles only on templates that need them. A related-posts plugin enqueuing on checkout helps nobody. WP Engine’s dynamic plugin loading is one hosted answer; on other stacks you achieve similar outcomes with manual dequeue rules or optimisation plugins that map assets to page types.

How do you keep the WooCommerce database from slowing checkout?

Beyond HPOS, schedule maintenance: prune expired transients, limit post revisions, remove spam comments, and archive stale order notes when plugins allow. WP-Optimize and Advanced Database Cleaner are common choices; run destructive cleans on staging first.

Monitor slow queries after sales events. Object cache reduces repeat cost, but a missing index on a custom plugin table still hurts checkout under load. Pair database hygiene with scheduled synthetic tests on checkout so regressions surface before month-end reporting.

Quick wins versus advanced WooCommerce performance work

Quick wins (days, not months):

Enable HPOS after compatibility review.
Configure page cache with cart/checkout/account exclusions.
Reduce or conditionalise cart fragments.
Convert product images to modern formats; lazy-load non-LCP images.
Remove unused plugins; fix one slow query flagged by Query Monitor.

Advanced work (weeks, higher cost):

Migrate to commerce-focused hosting with Redis and tuned PHP.
Rebuild or replace a heavy page-builder theme.
Implement critical CSS, defer non-essential JavaScript, and fine-tune Redis cache groups.
Headless or custom checkout front ends only when revenue and team size justify the operational cost; most stores below roughly three million dollars in annual revenue improve faster by tuning the monolith they already run.

How do you measure WooCommerce Core Web Vitals after tuning?

Use PageSpeed Insights and CrUX for field percentiles where Google publishes data. Use WebPageTest or GTmetrix for deep waterfall debugging on PDP and checkout. Use Query Monitor during active development.

For production guardrails, schedule synthetic lab runs on the URL list above with separate mobile and desktop strategies. Lab data catches deploy and plugin regressions within hours; CrUX lags and may omit low-traffic checkout URLs. Both belong in client conversations.

Set explicit performance budgets per template using the performance budget thresholds template; tighten bands on PDP and checkout compared with policy pages. How to schedule test frequency and priority across your portfolio explains cadence when you manage multiple shops.

Apogee Watcher fits agencies that need one schedule and history layer across many WooCommerce clients: a site per store, discovery from sitemaps where exposed, mobile and desktop PageSpeed Insights runs with CrUX context, and budget alerts when LCP or INP drifts on named URLs. We do not replace WooCommerce analytics or server APM; we give you repeatable lab evidence and client-ready trends without juggling separate PageSpeed Insights tabs per domain. Setup steps are in Getting Started with Apogee Watcher: A Step-by-Step Setup Guide. The Core Web Vitals monitoring checklist for agencies mirrors the release gate below across clients.

WooCommerce performance tuning checklist

Use before peak season, a major plugin install, or a theme update:

Mobile and desktop lab runs on homepage, top category, top three PDPs, cart, and checkout path.
HPOS enabled; compatibility plugins verified.
Cache exclusions confirmed for cart, checkout, and account.
Cart fragment behaviour measured; conditional or disabled where safe.
LCP element identified on best-selling PDP; dimensions and format verified.
INP spot-check on variant change, filter toggle, and proceed-to-checkout.
CLS check with promo bar, consent banner, and cart badge enabled.
Budgets and alert recipients set per template; baseline stored with owner.

FAQ

What is WooCommerce performance tuning?

It is the combined work of hosting configuration, database structure (including HPOS), caching rules, media optimisation, and plugin hygiene so shop, product, cart, and checkout routes stay within acceptable Core Web Vitals and conversion-friendly load times. Monitoring is part of tuning, not a separate phase after launch.

Does HPOS improve front-end Core Web Vitals?

HPOS primarily accelerates order storage and admin queries. Checkout can feel snappier when order writes were the bottleneck, but LCP and INP on PDP still depend on theme assets and scripts. Enable HPOS for database health; measure vitals separately on storefront URLs.

Why is WooCommerce cart so slow with caching enabled?

Cart and checkout are dynamic. If page cache serves them incorrectly, you see functional bugs; if they bypass cache correctly, they run full PHP and hit cart fragments, sessions, and payment scripts. Tune fragments, object cache, and script load on those routes instead of forcing them into homepage cache rules.

What LCP target should WooCommerce stores use?

Field guidance treats LCP at or below 2.5 seconds at the 75th percentile as good. Lab targets on PDP during optimisation sprints can be stricter. Compare mobile separately; many shops see most revenue on phones.

How is WooCommerce performance tuning different from Shopify speed work?

The vitals are the same; the stack differs. WooCommerce on WordPress combines self-managed plugins, hosting choice, and cache exclusions you configure. Shopify speed optimization centralises more theme constraints; WooCommerce trades flexibility for responsibility to audit extensions and database shape yourself.

Should agencies monitor every WooCommerce URL?

No. Start with ten to twenty priority URLs per store, weighted to PDP, revenue categories, cart, and checkout. Expand when alert triage stays manageable.

Can improving Core Web Vitals increase WooCommerce sales?

Industry studies link small speed gains to funnel movement; your client’s uplift depends on baseline speed and traffic quality. Use scheduled monitoring to prove before-and-after on their templates rather than citing averages alone.

WooCommerce performance tuning that lasts pairs HPOS and Redis-aware caching with honest cache exclusions, a ruthless plugin audit, and image work on PDPs. Fix cart and checkout INP before debating homepage hero animations, then keep mobile lab history on the URLs that pay the bills.

Start a free Apogee Watcher account to schedule mobile and desktop tests with vitals budgets on WooCommerce client sites, or run a free domain PageSpeed check on a shop before you scope the first optimisation

Are We Visible in ChatGPT? What Agencies Can Measure First

Wed, 08 Jul 2026 13:17:35 +0000

The board slide says "AI visibility" in bold. The client wants a yes or no: are we showing up in ChatGPT, Perplexity, or Google's AI Overviews? Your team wants a defensible answer that does not require procuring another SaaS category before Friday's call. What follows is a practical split agencies use in delivery: what belongs in probabilistic citation tracking, what belongs in deterministic technical monitoring, and what you can measure in the first week with tools you likely already run.

What does "AI search visibility" mean when a client asks about ChatGPT?

Clients usually mean one of three things, and they rarely say which:

Citation: Does an AI product mention our brand or link to our pages when someone asks a buyer-style question?
Retrieval: Can AI crawlers fetch and parse our priority URLs fast enough to include them in indexes or training corpora?
Traditional search: Are we losing clicks because AI Overviews answer the query without a visit?

Those are related but not interchangeable. A green "visibility score" from a GEO dashboard answers (1) for a fixed prompt list. Server logs and scheduled PageSpeed tests answer (2) for URLs you choose. Search Console and third-party CTR studies answer (3) at the query level, with known gaps. Mixing them in one slide produces arguments in week two when checkout is slow but the homepage prompt chart looks fine.

Agencies that answer well start by naming the layer, then pick metrics that match the layer. That framing sets honest expectations: no single vendor owns all three today, and a homepage PageSpeed Insights paste is not citation analytics. If the SOW says "AI visibility" without defining the layer, clarify before you buy tools.

AI search visibility tools: citations, prompts, and GEO measurement

Probabilistic measurement asks whether a model or AI search product mentions your brand or URLs for prompts that resemble how buyers research. GEO (generative engine optimisation) platforms, prompt trackers, and manual spot checks in ChatGPT or Perplexity live here. Treat outputs as directional trends, not fixed ranks.

Strengths of this layer:

Shows whether you appear for category-style questions ("best X for agencies", "tools to monitor Core Web Vitals").
Helps compare before and after content or positioning changes when you hold the prompt set constant.
Gives account managers a chart when leadership asks for "AI SEO."

Limits you should say out loud on client calls:

Prompt choice dominates the result. A dashboard tracking "best pagespeed monitoring tool 2026" tells you almost nothing about whether you appear when a technical lead asks how to monitor forty Shopify stores after a theme deploy. Generic prompt lists produce tidy graphs with weak buyer context; agency-real questions include client vertical, stack, and trigger event.
Models drift. The same prompt can yield different answers by phrasing, session, and model version. Weekly graphs are useful for trends, not courtroom proof.
Citation is not retrieval. Being mentioned in an answer does not prove crawlers can reliably fetch your product pages, docs, or pricing routes today.

Use GEO or AI visibility SaaS when the retainer includes citation reporting, when content strategy depends on LLM mentions, or when leadership funds a dedicated prompt library maintained by someone who understands the client's ICP. Layer it beside technical monitoring; do not replace crawl and speed work with prompt scores alone. Pair those tools with the posts below when clients ask about traffic impact or crawler access.

For how AI-mediated search affects clicks on traditional results, see AI Overviews Are Killing Clicks: What the Data Shows and How to Respond. For why fetchability precedes citation, see Why AI Crawlers Need Fast, Crawlable Pages.

Website for AI crawlers: deterministic signals agencies can measure first

Deterministic measurement asks whether priority URLs respond correctly and quickly when bots request them, and whether that state persists after deploys. This is the layer agencies can often cover in the first week without a GEO contract, because it reuses performance monitoring, crawl hygiene, and reporting rhythms you already sell. Most delivery teams already know how to run these checks; the gap is usually scope and scheduling, not methodology.

What fits here:

Signal	What it tells you	Typical source
GPTBot / Googlebot allowed on public URLs	Crawlers permitted to fetch content you want considered	`robots.txt`, server logs
HTTP status and redirect chains	No 404/5xx on docs, pricing, product templates	Scheduled fetch or crawl audit
Lab LCP, INP, CLS on priority URLs	Page likely parseable within crawler timeouts; stable layout	PageSpeed Insights, scheduled monitoring
Regression after release	Theme, app, or CDN change broke a route AI systems rely on	Alerts on budget breach
Mobile vs desktop split	Crawlers often behave like lightweight clients	Separate lab strategies

This layer does not prove you will be cited. It proves you are not failing the step before citation: access. That distinction keeps you credible when a client shows a competitor's GEO screenshot, and it gives you a concrete follow-up when citation matters but checkout returns 503 on mobile lab tests this week.

GPTBot and robots.txt: AI crawler access on client sites

Before you debate prompt libraries, confirm the client has not accidentally blocked the bots they care about. OpenAI documents GPTBot in robots.txt; Google publishes crawler guidance for Search and related products. A five-minute fetch of production robots.txt prevents expensive arguments later.

Agency checklist for a client kickoff:

Fetch production robots.txt and note Disallow rules for GPTBot, Google-Extended, and other AI user-agents the client mentions.
Confirm public marketing, docs, and pricing paths are allowed unless the client explicitly opts out of AI training or retrieval.
Document opt-out decisions in writing. Blocking GPTBot is a valid policy choice; pretending the site is "optimised for AI" while disallowing crawlers is not.
Re-check after CMS or SEO plugin updates. All-in-one SEO tools sometimes ship aggressive bot blocks.

Keep a one-page bot policy per client next to the URL inventory. Account managers should know whether the retainer includes "AI crawler access review" or only performance monitoring. Update both documents when the client changes CMS, SEO plugins, or hosting.

Core Web Vitals drift, response time, and crawl errors on priority URLs

Slow responses and hard errors are the fastest way to lose fetchability. Crawlers work under timeouts; a pricing page that takes eight seconds in lab conditions or returns intermittent 503s may simply drop out of consideration while the homepage still looks fine. That pattern shows up often when monitoring stops at the homepage.

Prioritise URLs by business intent, not sitemap size:

Homepage and primary category landers
Pricing and comparison pages
Documentation and help centres cited in sales
Product detail or template pages for ecommerce clients
Login and checkout only where publicly reachable tests are allowed

Run mobile and desktop lab tests on that list. Track Core Web Vitals (LCP, INP, CLS) as indicators of parseability and stability, not as magic "AI ranking" levers. Google’s AI Overviews documentation emphasises content quality and relevance for visibility; it does not list CWV as a citation factor. CWV still matters because slow, unstable pages fail fetches and frustrate human visitors who click through from any surface.

Set provisional budgets and review weekly during AI visibility engagements, the same way you would during a Core Web Vitals remediation project. When LCP regresses after a hero image change, that belongs in the client report beside any GEO chart. Regressions on docs or checkout URLs matter more for fetchability than a flat homepage score.

JavaScript-rendered content and scheduled PageSpeed lab tests

Many AI crawlers do not execute a full browser. They rely on initial HTML and simplified rendering. If your client's docs or product UI mount content client-side only, the crawler may see an empty shell while a manual visit in Chrome looks fine.

Lab tests through PageSpeed Insights or Lighthouse do not perfectly simulate GPTBot, but they flag render-blocking scripts, long tasks, and late LCP elements that correlate with fetch problems. Pair lab schedules with occasional log review for AI user-agents to see which URLs they request and whether status codes stay clean. When stakeholders ask for "AI-ready" pages, translate that into operational requirements: critical copy in HTML, sane response times, stable layout, and monitoring on the URLs where answers should come from.

Agency SEO reporting: first-week AI visibility checklist

Use this sequence on a new or upsold AI visibility thread:

Day 1 to 2: Scope and access

Confirm what "visible" means in the SOW: citations, crawl access, traffic, or all three.
Export or build a priority URL list (ten to twenty URLs, not the whole sitemap).
Audit robots.txt and document bot policy.

Day 3 to 4: Baseline deterministic signals

Run lab tests on priority URLs mobile and desktop.
Note HTTP status, redirect hops, and obvious render issues.
Optional: run the public free domain PageSpeed check or the multi-page domain report for a client-ready PDF before you configure schedules.

Day 5: Client readout

Slide 1: layers diagram (probabilistic vs deterministic).
Slide 2: URL list and bot policy summary.
Slide 3: lab baseline table with three named actions (owner + date).
Slide 4: optional GEO tool timeline if budget approved; honest gap if not.

Week 2 onward

Schedule recurring tests and wire alerts.
Add GEO or prompt tracking when citation reporting is in scope.
Revisit URL list when the client ships new templates or docs IA.

That cadence gives marketing a story and engineering a backlog without overclaiming day-one citation certainty.

PageSpeed monitoring vs GEO tools for AI search visibility

One-off PageSpeed Insights tabs do not survive a release train. Agencies managing multiple clients need history, comparison, and alert routing on the same URLs every week. That is the same operational model as PageSpeed Insights vs automated monitoring: scheduled lab runs, stored results, budgets, and digests when thresholds breach.

Apogee Watcher is built for that portfolio pattern: organisations per agency, sites per client, discovery and manual URL lists, mobile and desktop strategies, and email when lab metrics cross budgets. We do not score "ChatGPT visibility." We tell you when priority URLs slow down, error out, or drift on vitals after the deploy that might affect fetchability. Layer GEO vendors when you need prompt-level citation analytics; use monitoring when you need proof that the URLs cited in sales and docs still load. Measure what you can fix this week (access, speed, stability on named URLs), then add GEO tooling when the retainer includes citation tracking and someone owns the prompt library.

When should agencies add GEO or AI visibility SaaS?

Add a dedicated GEO platform when:

Leadership expects monthly citation charts in QBRs.
Content strategy targets LLM mentions for specific buyer personas.
You have staff to maintain contextual prompts, not only generic category queries.
Deterministic baselines are already green enough that slow URLs are not the obvious bottleneck.

Defer GEO procurement when:

The client has not agreed bot policy or priority URLs.
Homepage-only monitoring hides checkout and docs problems.
The ask is purely "make us show up in ChatGPT" with no content or technical owner.

The upgrade path is sequential: fix fetchability and monitoring scope, then buy citation analytics, not the reverse.

FAQ

Can we guarantee visibility in ChatGPT if Core Web Vitals are green?

No. Green lab vitals indicate priority URLs are likely fetchable and parseable under test conditions. Citation depends on content, authority, relevance, and model behaviour. Treat CWV and speed as necessary technical hygiene, not a guarantee of mentions.

Should clients block GPTBot?

That is a policy decision, not a performance trick. Some brands opt out of training crawlers; others allow fetch for retrieval products. Document the choice in the client file and align monitoring with URLs you intend to be public and reachable.

What is the difference between AI search visibility and AI Overviews SEO?

AI search visibility often means citations or mentions in LLM or AI search interfaces. AI Overviews SEO usually means how Google's AI-generated summaries affect clicks and visibility in traditional search. Overlap exists, but measurement tools and GSC reporting differ. See our AI Overviews impact post for CTR context.

Do agencies need a GEO tool on day one?

Not always. Many engagements can start with bot policy, priority URLs, lab baselines, and scheduled monitoring alone. Add GEO when citation reporting is contracted and someone maintains prompts with buyer context, not only generic category queries.

How many URLs should we monitor for AI visibility?

Start with ten to twenty priority URLs per client: homepage, pricing, key product or service templates, and docs paths that support sales. Expand when alert triage stays manageable. If every URL triggers alerts, the list is too wide for a first engagement.

How does this relate to E-E-A-T or content quality?

Content quality still drives citation and ranking. Technical monitoring ensures the URLs that carry that content remain reachable after deploys. Both layers belong in a mature programme; neither replaces the other.

Can Apogee Watcher replace a GEO platform?

No. Watcher schedules PageSpeed lab tests, tracks vitals and budgets, and alerts on regressions across client sites. GEO platforms track prompt-level citations. Use both when the retainer covers technical performance and citation reporting.

When a client asks if they are visible in ChatGPT, answer in layers: what citation tools can track over time, and what you can prove about fetchability and speed on the URLs that matter this week. That split keeps the agency credible, gives engineering clear work, and leaves room to add GEO analytics when the scope and budget justify it. Start with deterministic baselines; add probabilistic tracking when the retainer calls for it.

Start a free Apogee Watcher account to schedule mobile and desktop tests with vitals budgets across client sites, or run a free domain PageSpeed check before the first AI visibility readout.

Taming the Infinity: The Fast Track to PI

Wed, 10 Jun 2026 05:38:44 +0000

Calculating (Pi) is one of mathematics’ oldest obsessions. In today’s digital landscape, the quest isn’t just for accuracy; it's for raw, unadulterated speed. While many know PI as 3.14159..., modern web development and computing require ways to access its value instantly, whether for high-precision scientific visualization or optimized geometric rendering. The fundamental question is: how do we get the most precise value, the fastest way possible?

First, how do we make it happen? We don’t try to compute trillions of digits every time we load a webpage. Instead, the fastest way to "get" PI is to already have it. This is achieved through efficient, hardcoded constants stored in high-performance libraries. However, when we need extreme precision on demand, we don't use old methods like polygons; we rely on rapidly convergent series.

The modern roadmap for ultra-fast PI generation involves specific trigger points:

Employ rapidly convergent formulas: The gold standard is the Chudnovsky algorithm, which provides approximately 14 new digits of precision with every single term calculated.

Utilize pre-computed constants: For 99% of web development needs, we leverage built-in constants like Math.PI in JavaScript, which are instantly available at runtime with double-precision accuracy.

Hardcode beyond double-precision: When precision beyond 15-17 digits is needed for specialized apps, we store PI as a static, pre-computed string constant in our source code.

This path, while appearing straightforward, has its obstacles. The problems with high-precision calculation arise the moment you demand more digits than your standard hardware can handle.

Standard precision bottlenecks: Default data types (like double or float) cap out around 15–17 digits. Demanding 1,000 digits results in silent truncation.

Exponential computational cost: Older algorithms get exponentially slower as you ask for more digits, paralyzing user interfaces.

Memory exhaustion: Calculating billions or trillions of digits is no longer a CPU problem; it becomes a massive memory and storage bottleneck, as seen in world-record attempts.

So, how do we solve these problems in our current situations? Our approach to web development must adapt based on the required speed versus precision.

To overcome precision bottlenecks, we implement an abstraction layer. For applications requiring massive digits, we bypass native data types entirely and implement Custom Big Number libraries (like bignumber.js or decimal.js), which handle arithmetic on numbers represented as strings.

We tackle computational cost through hybrid architecture. Our client-side applications rarely do heavy lifting. If an ultra-precise PI calculation is required, we offload the task to powerful backend services optimized for mathematical computation, which can return the pre-computed digits instantly via API.

Finally, we prevent UI lockups by treating high-precision math as an asynchronous operation. Whether using Web Workers to run calculations in a separate thread on the client side, or fetching backend data asynchronously, we ensure the user interface remains responsive, even while handling complex mathematical demands.

Sumita
Web Developer

What ChatGPT Gets Wrong When You Ask It to Audit Your SEO

Tue, 26 May 2026 01:44:20 +0000

We ran the experiment on our own site. The audit looked thorough. The math doesn't survive a 60-second fact check.

We wanted to know how reliable ChatGPT is as an SEO auditor, so we asked it to audit our own agency site, axiondeepdigital.com. Four prompts. Fresh thread. No setup, no priming. We then verified every concrete claim against the actual page, against PageSpeed Insights, and against our own SEO workbench.

The audit came back at roughly 2,000 words. It included a numeric grade rubric ("Technical SEO 9/10, Architecture 8.8/10"), a prioritized fix list, named architectural risks, and an opinion on Googlebot rendering behavior. It looked like the kind of audit a senior SEO consultant might produce after a real review.

Most of it was confabulation dressed as analysis. One of its predictions was exactly backwards. And in the same thread, ChatGPT contradicted itself in a way neither it nor a casual reader would catch.

Here's the receipt for each prompt.

Prompt 1: The grade rubric was assigned without measurement

We asked: "Can you do a full technical SEO audit of [our URL]? I want specific issues, not a generic checklist."

ChatGPT returned an extensive audit with a grade rubric:

Technical SEO: 9/10
Architecture: 8.8/10
Content Depth: 6.8/10
Topical Authority: 6.5/10
Local SEO Structure: 8.5/10
Conversion SEO: 8.7/10

These numbers feel authoritative. They map to nothing measurable. Lighthouse outputs a Performance score and a separate SEO score. Search Console reports impressions, clicks, and CTR. None of these tools produce a "Technical SEO" or "Architecture" or "Conversion SEO" number. The grades exist nowhere in any real auditing tool. ChatGPT invented the rubric and assigned scores against it.

We then checked the factual claims. ChatGPT identified eight technology brands as "mentioned" on our homepage:

Vercel, Stripe, Netflix, Next.js, React, FastAPI, OpenAI, AWS

Of those eight, three (FastAPI, OpenAI, AWS) are not mentioned on our homepage at all. That is a 37.5% hallucination rate on a claim that takes less than a minute to verify in a browser.

Same pattern with the city pages it cited. It listed four geo pages by URL: /albuquerque, /las-cruces, /new-mexico, /web-development-new-mexico. The first two exist. The last two don't.

When ChatGPT mixes real observations with confabulated ones inside the same paragraph, the result is harder to catch than pure fabrication. A reader assumes the whole list was verified the same way.

Prompt 2: ChatGPT contradicted itself two messages later

We asked: "What are the current Core Web Vitals (LCP, CLS, INP) for [URL] on mobile? Give me the actual numbers."

ChatGPT replied:

I cannot reliably give you the real current field numbers for LCP, CLS, and INP from Google's CrUX dataset without direct access to PageSpeed Insights or the Chrome UX Report API for that URL. The web search environment here can access documentation and indexed pages, but it cannot execute a live Lighthouse/PageSpeed test against your domain or pull the live CrUX metrics feed.

This is correct. But ChatGPT had just spent 2,000 words in the previous message grading our site as if it had run Lighthouse against it. If it cannot execute a Lighthouse test, the grades in prompt 1 came from somewhere other than measurement. The two responses contradict each other inside the same conversation. ChatGPT did not flag the contradiction. A casual reader wouldn't either.

Then it guessed anyway:

I would expect CLS to already be very good, LCP to be decent but hero/media dependent, INP to likely be your weakest metric if third party scripts or animations are present.

We ran the actual Lighthouse mobile audit the same day. Lighthouse weights each Core Web Vital and reports a contribution out of a maximum. Here is the prediction next to the measurement:

Metric	ChatGPT predicted	Lighthouse measured (mobile)
CLS	"already very good"	+25 / 25 (perfect)
LCP	"decent but hero/media dependent"	+2 / 25 (lowest tier)
INP / TBT (interaction)	"likely your weakest metric"	+27 / 30 (one of our best)

CLS was a gimme. CLS is good on most modern sites and predicting that requires no information at all. LCP, the metric ChatGPT softened with "decent," scored 2 out of a possible 25 on mobile, which is the bottom tier Lighthouse reports. The metric ChatGPT confidently named as weakest scored 27 out of 30, the strongest of the three. The ranking was exactly inverted.

There is one more thing in this answer worth flagging. ChatGPT recommended PageSpeed Insights to retrieve the real CrUX field data. We checked. Our site does not have CrUX field data at all. Sites below Google's traffic threshold do not get field data, and the CrUX dataset returns "does not have sufficient real-world speed data" for our origin. A reader following ChatGPT's advice would arrive at PageSpeed, look for the field numbers ChatGPT promised, find nothing, and have no explanation for why.

Prompt 3: A confident render analysis without rendering anything

We asked: "Does Google see the same content on [URL] that a human visitor sees? Walk me through what Googlebot renders vs what the user renders."

ChatGPT delivered a careful, technically literate answer:

Based on the rendered structure, Googlebot is seeing substantially the same primary content that human users see on axiondeepdigital.com.

The phrase "based on the rendered structure" is doing all the work in that sentence. ChatGPT did not render anything. It cannot render anything. Its earlier message in this same conversation said so explicitly. The entire walkthrough of what Googlebot sees vs. what the user sees is pattern-matching on what a "modern Next.js site" typically does, not measurement of what our site actually does.

If we had a broken hydration path, if our hero was client-only, if our city pages were rendering empty divs to the bot, the answer would have looked identical. That is the worst possible failure mode for an auditing tool: confident output that is invariant to the actual state of the thing being audited.

Prompt 4: Three priorities that have nothing to do with the actual problem

We asked: "If I could only fix three things on [URL] this week to improve search rankings, what should they be and why those three?"

ChatGPT's answer: build a topical authority cluster, convert portfolio items into standalone case studies, improve internal semantic linking. Each recommendation came with an explanation that would apply word-for-word to any well-built Next.js agency site on the planet.

What the answer did not mention: our mobile Performance score is 69, our mobile LCP scores 2 out of 25, and Google has been weighting Core Web Vitals into ranking since 2021. A real "top three this week" list, given the data, starts with "fix mobile LCP." ChatGPT could not start there because it did not know.

It also credited us with "fast rendering stack using Next.js" as a strength in prompt 1. On mobile, our Performance score is 69 with LCP scoring 2 of a possible 25. Fast is generous.

The deeper problem

Our SEO category in Lighthouse scores 100. Best Practices is 100. Our own SEO workbench gives the site 96/100 overall. ChatGPT's gut call of "9/10 Technical SEO" is, by accident, close to the truth.

That is the trap.

ChatGPT arrived at a roughly correct grade not by measuring our site, but by pattern-matching what a well-built Next.js agency site usually looks like. We happen to be one. If we had been one of the 96.9% of small business sites our 292-site study found failing mobile Core Web Vitals, the audit would have read identically. Same grades. Same praise for "fast rendering stack." Same "your bottleneck is authority, not technical." Same generic top three.

You cannot use ChatGPT to find out whether your site is broken, because ChatGPT will tell you it is fine either way.

What to use instead

For SEO auditing, use tools that actually load your page in a real browser:

PageSpeed Insights: synthetic Lighthouse run, free, gives you real numbers.
Google Search Console URL Inspection: shows you the rendered HTML Google sees.
DeepAudit AI: our free real browser SEO audit, 100+ checks, full Chromium rendering. Built precisely because pattern-matching auditors lie. axiondeepdigital.com/free-seo-audit

ChatGPT is excellent at writing, summarizing, and explaining concepts. It is not an auditor. Asking it to audit a website is asking it to do a job it cannot do, and the danger is not that it refuses, but that it answers anyway.

Originally published on axiondeepdigital.com.

Spring Boot File Upload Performance: Why Your API Gets Slow Under Load (And How to Fix It)

Wed, 20 May 2026 18:59:08 +0000

Backend APIs often feel fast during development.

You upload a few files locally.

Everything responds instantly.

Latency looks great.

Memory looks stable.

CPU barely moves.

Then production traffic arrives.

Suddenly:

uploads slow down
downloads start hanging
videos become painfully slow
latency spikes
users complain

This happens because local testing rarely reflects real-world load.

A file upload API is not just handling HTTP requests.

It is dealing with:

disk I/O
file buffering
network transfer
JVM memory pressure
concurrent request handling
authentication overhead
metadata queries
file streaming

Under enough load, something breaks first.

The real question is:

What breaks first in a Spring Boot file upload system?

I ran a benchmark to find out.

Quick Answer

Spring Boot handled the application layer surprisingly well under heavy load.

The actual bottleneck was not request handling.

It was large file delivery.

Small files stayed fast.

Large video responses caused latency to rise sharply.

The lesson:

Spring Boot is fine for API orchestration, but direct media delivery becomes a scaling problem much faster than most developers expect.

The Test Scenario

The benchmark used a Spring Boot file service with typical production-style endpoints:

file upload
file download
metadata lookup
file listing
delete operations

The workload intentionally mixed different file behaviors because real systems rarely handle only one request type.

The goal was not to create a synthetic benchmark that looks impressive.

The goal was realism.

Traffic gradually increased in stages until the system started showing visible degradation.

Metrics tracked included:

request throughput
P95 latency
CPU usage
memory usage
endpoint behavior
file-type response performance

Why File Upload APIs Fail Earlier Than Expected

A standard CRUD API is relatively cheap.

A file API is not.

For example:

A metadata lookup:

GET /api/files/metadata/123

might hit:

authentication filter
database query
JSON serialization

That is manageable.

Now compare that with:

GET /api/files/download/huge-video.mp4

Now the system may need to:

authenticate request
validate permissions
locate file on disk
open file stream
allocate buffers
push large chunks over network
keep thread occupied longer
handle slow client reads

That changes everything.

The API layer is no longer the only concern.

Your infrastructure becomes part of request latency.

Benchmark Summary

Here’s the simplified outcome.

Metric	Result
Total Requests	134,000+
Peak Load	7,500 RPM
Peak P95 Latency	~1.8 seconds
HTTP Failures	0
Average CPU	~35%
Main Bottleneck	Large MP4 downloads

At first glance, this looks strong.

Zero failures under that volume is respectable.

But raw survival is not the same as healthy performance.

Latency tells the real story.

P95 latency stayed stable until higher RPM levels, then degraded rapidly after ~6,300 RPM.

Latency Looked Fine... Until It Didn’t

At lower traffic levels, performance was stable.

The backend remained responsive.

P95 latency stayed in a healthy range.

Then the ramp increased.

Past a certain threshold, latency began climbing rapidly.

This pattern matters.

Gradual degradation usually means the system is saturating naturally.

Sudden collapse usually means architectural failure.

This benchmark showed degradation, not collapse.

That is actually a good sign.

Still, once latency crosses production tolerance, users do not care whether your system technically survived.

They only see slowness.

Throughput tracked closely with target RPM until upper load levels where the system started falling behind.

Throughput Was Stable

One interesting finding:

The backend kept serving requests consistently even under heavier load.

That suggests:

request routing was stable
controllers were fine
business logic held up
auth overhead was manageable

This is important because many developers blame Spring Boot too early.

The framework itself was not the issue here.

The architecture was.

The Real Bottleneck

This was the most useful finding.

The slowest operations were not:

uploads
metadata APIs
listing APIs
delete operations

The worst offender was:

large MP4 delivery

MP4 downloads had dramatically higher P95 latency compared to PDF and PNG files.

Small files performed dramatically better.

Typical behavior looked like this:

File Type	Approx Performance
PDF	Extremely fast
PNG	Moderate
MP4	Much slower

This makes perfect sense.

Large media files create pressure across the entire stack.

Including:

Disk I/O

Reading large files repeatedly creates storage pressure.

Local disk works for development.

At scale, it becomes painful.

Network Throughput

A large file means longer response duration.

More active connections.

More bandwidth consumption.

Slow clients make this worse.

JVM Memory Pressure

Streaming often introduces buffering overhead.

Even when efficient, sustained concurrency adds pressure.

Memory growth is expected.

Thread Occupancy

Traditional request handling keeps resources busy longer.

A quick metadata request finishes fast.

A multi-second video stream does not.

That reduces effective throughput.

CPU Was Not the Problem

CPU usage increased gradually with traffic but remained relatively controlled during the test.

A common assumption:

"High latency means CPU saturation."

Not here.

CPU stayed relatively controlled.

Average utilization hovered around the mid-thirties.

That means compute was not the main bottleneck.

This is useful because it changes optimization priorities.

If CPU is not the problem:

Do not waste time micro-optimizing controller code first.

Fix architecture first.

Memory Behavior

Memory usage increased under higher throughput but stayed within a manageable range.

Memory climbed during heavier traffic.

That is expected.

Large streaming workloads create pressure.

But the test did not suggest catastrophic memory behavior.

The bigger issue remained delivery mechanics, not memory collapse.

What This Actually Means for Production

This is where many teams make a bad decision.

They see a working local file upload implementation and assume:

"Great, we can scale this."

Maybe.

But probably not for media-heavy workloads.

A better architecture separates responsibilities.

Spring Boot should handle:

authentication
authorization
business rules
metadata
upload coordination
signed URL generation

Dedicated infrastructure should handle media delivery.

Examples:

AWS S3
Cloudflare R2
object storage
CDN edge delivery
Nginx static serving

This dramatically reduces backend pressure.

Better Architecture Example

Instead of this:

Client
   ↓
Spring Boot
   ↓
Local file disk
   ↓
Spring Boot streams file

Prefer:

Client
   ↓
Spring Boot auth + metadata
   ↓
Signed URL
   ↓
S3 / R2 / CDN

That changes scaling behavior completely.

Now your application server is not acting like a media server.

Which is exactly what you want.

Common Mistakes Developers Make

1. Treating Upload Success As Performance Proof

A few successful uploads prove almost nothing.

Load changes everything.

2. Serving Large Media Directly Forever

Works early.

Hurts later.

3. Blaming Spring Boot Too Quickly

The framework is often not the issue.

Bad delivery architecture usually is.

4. Ignoring P95 Latency

Average latency hides pain.

P95 exposes real user experience.

When Spring Boot Is Absolutely Fine

Spring Boot works well if your workload is:

document uploads
moderate internal tools
admin dashboards
metadata-heavy systems
authenticated business APIs

If your workload becomes:

video-heavy
media streaming
public downloads at scale

your architecture needs to evolve.

Practical Scaling Advice

If you already have a local file-based Spring Boot system:

do this first.

Move Storage

Shift from local disk to object storage.

Add CDN Delivery

Never make your app server deliver everything forever.

Use Signed URLs

Avoid routing every file request through application logic.

Benchmark Early

Do not wait until users discover bottlenecks.

Watch P95, Not Just Averages

This matters more than vanity metrics.

How many uploads can Spring Boot handle?

There is no universal number.

It depends on:

file size
infrastructure
storage strategy
concurrency
request mix
delivery architecture

Small files and metadata workloads scale much better than heavy media streaming.

Should I serve files directly from Spring Boot?

For small or internal workloads, yes.

For larger public media systems, usually no.

Object storage plus CDN is the better long-term design.

Why do video downloads slow everything down?

Because they stress:

disk reads
bandwidth
buffering
connection duration
thread occupancy

This creates systemic pressure much faster than lightweight API requests.

Final Takeaway

The benchmark revealed something useful.

Spring Boot did not fail.

The architecture reached its natural limit.

That distinction matters.

If your backend handles uploads, metadata, auth, and business logic:

Spring Boot is a strong fit.

If your backend is also acting as a high-volume media server:

you are creating your own bottleneck.

Design accordingly.

Originally inspired by real performance benchmarking work done while building a Spring Boot file infrastructure product at BuildBaseKit.

State of Small Business Websites (2026 Study): We Audited 292 Sites. 96.9% Fail Core Web Vitals

Thu, 23 Apr 2026 20:02:01 +0000

Most performance articles repeat the same three stats everyone has already read. "Amazon found a 100ms delay costs 1% revenue." "53% of mobile users leave if a page takes over 3 seconds." You have seen them. They are old.

Last month we ran a different experiment. We took a real-world list of 292 North American B2B prospects, pointed our headless browser audit tool at every site, and measured what actually ships to production in 2026.

The short version: 96.9% of the sites we audited fail at least one Core Web Vital on mobile. Only 3.1% pass all three. And 100% of 191 sites with valid accessibility data failed the Link Labels check. Not most. Not 95%. Every single one.

The full report, dataset, and methodology are open source. This post is the developer-angle on what is breaking and why.

Report: axiondeepdigital.com/research/state-of-small-business-websites-2026

Key stats (copy-paste friendly)

Metric	Sample	Result
Fail at least one Core Web Vital (mobile)	n=191	96.9%
Pass all three Core Web Vitals (mobile)	n=191	3.1%
Fail axe-core Link Labels rule	n=191	100%
Post "poor" mobile LCP (>4.0s)	n=191	86.4%
Post "poor" mobile FCP (>3.0s)	n=191	72.4%
Pass mobile CLS (<0.1)	n=191	85.5%
Total domains scanned	n=292	—

Source: State of Small Business Websites 2026, Axion Deep Digital Research. April 2026.

How we measured

This study runs on our production audit infrastructure. DeepAudit AI is the same pipeline we run against client sites daily. The dataset below is 292 consecutive scans pulled from a single week in April 2026. Because the pipeline runs continuously, future snapshots will replicate this analysis against a larger and eventually randomized sample, and the methodology stays frozen so the comparisons hold.

Each scan runs a real Chromium instance inside a Lambda (Puppeteer plus @sparticuz/chromium), renders the page the way Googlebot would, waits for hydration, and then measures against:

Lighthouse mobile Core Web Vitals (LCP, FCP, CLS) using Google's published thresholds
axe-core accessibility evaluations
60+ technical SEO checks (meta, headings, schema, canonicals, alt text)
Open PageRank for domain authority

191 of the 292 sites returned valid Lighthouse mobile data. 191 returned valid axe-core data. 260 had valid Open PageRank. Every finding below is gated on the subset of sites where the relevant measurement succeeded, not averaged over missing data.

What this study does and does not prove

Before the numbers, the honest scope:

This is a purposive sample, not a random one. The 292 domains came from a North American B2B prospect list, which skews toward construction, trades, and small professional services. It is not representative of the web as a whole.
What it does represent is the category of business that small digital agencies actually get hired to fix. If you pitch to this market, the sites you convert will look like this sample.
One snapshot per site. Results reflect the state of each site on the day it was scanned. A site could have shipped a perf fix the next morning.
Lighthouse mobile scores vary. Google's Lighthouse CI documentation acknowledges a ±5 point variance across runs. None of the findings below hinge on a difference smaller than that. The 96.9% failure rate and the 100% Link Labels failure are robust to that noise.

The full dataset is open. Every row, every score, every axe-core violation is downloadable from the methodology page. If you disagree with a finding, you can reproduce it or refute it.

Finding 1: LCP is the silent killer

86.4% of sites post poor mobile LCP. Only 5.2% are good.

Largest Contentful Paint over 4.0 seconds is Google's "poor" threshold. Most of the sites we measured clock in between 4 and 8 seconds on mobile. Some over 10.

What is causing it, in order of frequency:

1. Hero images served as full-resolution PNG

One site we looked at ships a 2400x1600 PNG as its hero, served at 3.2 MB. Mobile user on 4G? That is 6 seconds of transfer on a good connection. The image renders last, so LCP measures the whole download.

The fix is trivial if you are on Next.js:

import Image from 'next/image';

<Image
  src="/hero.jpg"
  alt="..."
  width={1200}
  height={600}
  priority
  sizes="(max-width: 768px) 100vw, 1200px"
  quality={75}
/>

priority injects a preload hint. sizes tells the browser to pick the right srcset variant for the viewport. quality=75 on JPEG looks identical to 90 in blind testing. Next.js serves WebP or AVIF automatically based on the Accept header.

If you are not on Next.js, the same rules apply. <link rel="preload" as="image">, <picture> with AVIF first, and a srcset + sizes combo.

2. Render-blocking JavaScript in the head

Tag Manager. Hotjar. Intercom. Drift. One of every four sites we audited had three or more synchronous third-party scripts in the head. Each one blocks HTML parsing until it is fetched, parsed, and executed.

The defer attribute is older than most React developers. Use it:

<script src="/vendor/gtm.js" defer></script>

Or on Next.js:

import Script from 'next/script';

<Script src="https://www.googletagmanager.com/gtm.js" strategy="afterInteractive" />
<Script src="https://widget.intercom.io/widget.js" strategy="lazyOnload" />

afterInteractive loads after hydration. lazyOnload waits until the browser is idle. Neither blocks the LCP element.

3. Custom fonts with no `font-display` directive

Default font-loading behavior blocks text rendering for up to 3 seconds. If your LCP element contains text, it cannot paint until the font loads.

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap;
}

swap tells the browser to render with a system fallback immediately, then swap to the custom font once it arrives. On Next.js, next/font does this automatically. On anything else, you write it in three lines.

Finding 2: First Contentful Paint is worse than LCP, and nobody talks about it

72.4% of sites post poor mobile FCP.

FCP is the time to the first pixel of anything meaningful. It is the metric that correlates most directly with user perception of speed. If it takes 4 seconds to paint a single headline, the user has already decided the site is broken, regardless of how fast the rest of the page loads.

The causes overlap with LCP but there is one specific pattern we saw repeatedly: a client-side routing framework rehydrating the whole page before rendering anything.

Here is the anti-pattern. A site ships a React SPA that serves an empty shell HTML, boots up, fetches the route data, then renders. The browser sees nothing visible until JavaScript finishes executing. The fix is either:

Server-side render the first paint (Next.js App Router, Remix, SvelteKit — pick one)
Ship static HTML for the first paint, hydrate on demand (Astro model)

If you are shipping a React SPA as the entire site in 2026, you are fighting gravity. The frameworks that win on FCP are the ones that put real HTML on the first GET.

Finding 3: 100% of sites failed Link Labels

This is the number that should bother you most.

axe-core's Link Labels rule checks that every <a> element has a discernible accessible name. Every single one of the 191 sites we evaluated had at least one link that failed this rule. Every one.

What does a failing link look like? It looks like this:

<a href="/products">
  <svg>...</svg>
</a>

A screen reader reads "link" and stops. There is no text content and no aria-label. The user has no idea where the link goes.

The fix is one attribute:

<a href="/products" aria-label="Our products">
  <svg aria-hidden="true">...</svg>
</a>

Social icon sets are the most common offender. Every Twitter, LinkedIn, and Instagram icon in every footer. Almost every one of them was an unlabeled link. Across 191 sites, we did not find a single site that had labeled every one of its icon-only links.

This is not an edge case. This is the baseline.

The broader pattern is: developers ship components library icons without reading the a11y docs. React-icons, Font Awesome, Lucide, Heroicons — all of them render SVGs inside anchors by default, and unless you explicitly add an aria-label or sibling text, the resulting link is unreadable.

If you ship a component with an icon-only link, wrap it:

export function SocialLink({ href, label, children }: SocialLinkProps) {
  return (
    <a href={href} aria-label={label}>
      <span aria-hidden="true">{children}</span>
    </a>
  );
}

Three lines. You now pass axe-core.

Finding 4: CLS is the one metric most sites get right

85.5% of sites pass mobile CLS.

Cumulative Layout Shift is the one Core Web Vital developers have actually internalized. It helps that every modern framework bakes in width and height on images by default, and that font-display: swap cuts down on font-swap shifts. The sites that fail CLS are doing something unusual: late-loading ads, position: sticky headers without reserving space, or hero carousels that resize after the first slide loads.

If your site passes everything else but fails CLS, the cause is almost always one of those three.

The takeaways for developers

If you read nothing else from this, read this:

Priority-load one image and one font. Your LCP element and your primary typeface. Everything else lazy-loads. This single change moves most sites from "poor" LCP to "good."
Defer or lazy-load every third-party script. If Tag Manager is synchronous in your <head>, you are paying for it on every paint. Move it.
Run axe-core on every PR. A CI check that runs @axe-core/cli against your built site will catch unlabeled links before they ship. It takes 10 minutes to configure and it will save you from the baseline failure.
Test on mobile, not desktop. Every site we audited looked fine on desktop. 96.9% of them fail on mobile. Chrome DevTools has a "Mobile" preset in the Performance tab. Use it on every build.

The dataset

The full 292-site dataset, methodology, and reproducibility notes are open. If you want to cite any of these findings in a post, article, or conference talk, you can pull the raw scan JSON and reproduce every chart.

Report: State of Small Business Websites 2026

Suggested citation (BibTeX friendly):

Gutierrez, J.R. (2026). State of Small Business Websites 2026.
Axion Deep Digital Research, n=292.
axiondeepdigital.com/research/state-of-small-business-websites-2026

If you find an error, contact us and we will update the public methodology page with the correction and the reporter credit.

The takeaway, in one sentence

The small business web is not sophisticated enough to be slow. It is slow because nothing is prioritized, nothing is deferred, and nothing is labeled. Every one of the findings above is fixable in a single afternoon by a developer who knows the four keywords: priority, defer, font-display: swap, and aria-label.

That is what the 3.1% do.

Further reading

What a 98 Lighthouse Score Actually Takes

Tue, 31 Mar 2026 21:32:58 +0000

Everybody talks about Lighthouse scores, but very few sites actually achieve a high one.

Across the sites we have audited at Axion Deep Digital, the average score is 44 out of 100. These are not abandoned projects. These are active businesses investing in growth.

Performance is not just a technical metric. It directly impacts both ranking and conversion. A slow site ranks lower and loses users before they even engage.

We rebuilt our own site with a clear goal: reach 98+ across all Lighthouse categories on mobile, under realistic conditions.

Here is what that required.

Start With the Foundation

Your framework determines what is possible.

We use static generation so pages are pre rendered and delivered instantly. If your stack introduces unnecessary overhead, optimization has limits.

Images Are the Largest Bottleneck

On most sites, images account for the majority of page weight.

We focus on:

Modern formats like WebP and AVIF
Proper sizing based on actual display
Lazy loading below the fold
Explicit dimensions to prevent layout shift

Fonts Add Hidden Latency

Fonts often introduce multiple network requests before text appears.

We:

Self host fonts
Subset unused characters
Use font-display: swap
Preload primary fonts

This significantly improves perceived performance.

JavaScript Should Be Minimal

JavaScript must be downloaded, parsed, and executed.

We:

Remove unused dependencies
Split code by route and component
Defer non critical scripts

The goal is to reduce main thread work and improve responsiveness.

CSS Controls First Render

Instead of blocking rendering with large stylesheets:

Inline critical CSS
Load remaining styles asynchronously
Remove unused rules

Core Web Vitals

These are the metrics that matter most:

LCP measures how fast the main content appears
CLS measures layout stability
INP measures responsiveness

Optimizing the system improves all three.

Server Configuration Still Matters

Even a fast frontend can be slowed down by poor delivery.

Enable Brotli compression
Configure caching correctly
Use a CDN for global delivery
Add security headers

Accessibility Improves Everything

Accessibility overlaps with SEO and usability.

Common issues include:

Missing alt text
Poor contrast
Unlabeled inputs
Incorrect heading structure

Why This Matters

Performance affects ranking. It also affects conversion.

Testing on a fast device is misleading. Real users are on slower networks and older hardware.

The Fix

We built DeepAudit AI to evaluate sites the right way.

It renders your site in a real browser and audits what actually loads.

No signup
Takes about 60 seconds

https://axiondeepdigital.com/free-seo-audit

How the Browser Rendering Pipeline Actually Works

Thu, 12 Mar 2026 12:53:24 +0000

Most frontend developers spend their time inside frameworks like React, Vue, or Angular. But underneath every framework is the same system: the browser turning code into pixels on a screen.

This process is known as the browser rendering pipeline (or the critical rendering path).

In simplified terms:

HTML → DOM
CSS → CSSOM
DOM + CSSOM → Render Tree
Render Tree → Layout
Layout → Paint
Paint → Composite

Understanding this pipeline explains many real-world performance issues that developers encounter.

1. HTML Parsing → DOM Construction

The browser begins by parsing HTML and converting it into the Document Object Model (DOM), a tree structure representing the page.

Example HTML:

<body>
  <h1>Hello</h1>
  <p>Welcome</p>
</body>

DOM representation:

Document
 └── body
      ├── h1
      └── p

Browsers stream-parse HTML, meaning they start building the DOM before the entire document is downloaded.

However, JavaScript can interrupt this process. When the parser encounters a blocking script:

<script src="app.js"></script>

DOM construction pauses while the script executes. This is why script placement or using defer matters.

2. CSS Parsing → CSSOM Construction

While the DOM represents structure, CSS defines how elements should appear.

The browser parses CSS into the CSS Object Model (CSSOM).

Example CSS:

h1 {
  color: red;
}

The browser resolves:

the cascade
specificity
inheritance

Eventually, every element receives its computed styles.

3. DOM + CSSOM → Render Tree

The DOM alone isn’t enough to render a page. The browser merges the DOM and CSSOM to create a Render Tree, which contains only visible elements with their computed styles.

For example:

DOM:

body
 ├─ h1
 ├─ p
 └─ script

Render Tree:

body
 ├─ h1 (styled)
 └─ p (styled)

Elements such as <script>, <meta>, or elements with display: none are excluded.

The render tree represents what actually needs to be drawn.

4. Layout (Reflow)

Once the render tree is built, the browser calculates the geometry of each element. This stage is called layout (or reflow).

The browser determines:

width and height
position
spacing and box model calculations

Example:

h1 → x:0 y:0 width:800 height:40
p  → x:0 y:40 width:800 height:20

Layout can be expensive because a change in one element may affect many others. For example, changing a container’s width might require recalculating layout for the entire subtree.

5. Paint

After layout, the browser converts elements into drawing instructions.

Painting includes:

text
colors
borders
shadows
images

At this stage the browser determines how elements should be visually drawn, but pixels are not yet combined into the final frame.

6. Compositing

Modern browsers split the page into layers and send them to the GPU compositor.

Certain properties create separate layers, including:

transform
opacity
position: fixed
video
canvas

The GPU then combines these layers into the final image displayed on the screen.

This step is what enables smooth animations and efficient rendering.

The 16ms Frame Budget

Browsers aim for 60 frames per second, which means each frame must be processed within about 16 milliseconds.

Within that time the browser must run:

JavaScript
Style calculation
Layout
Paint
Composite

If the work exceeds this budget, the result is dropped frames and visible UI lag.

Not All CSS Changes Are Equal

Different CSS properties affect different stages of the pipeline.

Layout-triggering properties (expensive)
Examples: width, height, margin, top, left

Pipeline:

Style → Layout → Paint → Composite

Paint-only properties

Examples: background-color, border-color, box-shadow

Pipeline:

Style → Paint → Composite

Composite-only properties (fastest)

Examples: transform, opacity

Pipeline:

Style → Composite

This is why modern animation guidelines recommend using transform and opacity.

Why This Matters

Many developers blame frameworks when performance issues appear. In reality, problems usually come from:

excessive DOM updates
layout thrashing
expensive paint operations
overly complex render trees

Frameworks may change, but browser fundamentals remain the same.

Most developers think in terms of:

Components → State → UI

But the browser ultimately thinks in:

DOM → Style → Layout → Paint → Composite

Understanding that model is what separates framework users from true frontend engineers.

Boosting Web Performance with Image Optimization Techniques

Sun, 15 Feb 2026 02:00:57 +0000

Images can make or break a web application’s performance. A well-optimized image not only improves loading speed but also enhances user experience. Here are some effective techniques for optimizing images optimized for your audience's chill vibes.

Choosing the Right Formats

Selecting the appropriate image format is crucial. Here’s a quick breakdown:

JPEG: Ideal for photos and images with gradients. Great balance between quality and file size.
PNG: Best for images needing transparency. Generally larger file sizes.
SVG: Perfect for logos and icons. Scalability without loss of quality.
WebP: A modern format that provides superior compression without sacrificing quality. Consider using it for environments where it’s supported.

Real-World Example

Consider a photography portfolio. If images are in PNG format but could be JPEG, the file size may be unnecessarily large. Converting can save loading time significantly.

Compression Techniques

Compressing images before uploading can dramatically reduce file sizes. Tools you can use include:

TinyPNG or TinyJPG: Easy online tools for compressing JPEG and PNG files.
ImageMagick: A command-line tool effective for batch processing.

Practical Tip

When using TinyPNG, I saw a 70% reduction in file size without noticeable quality loss on my images. Use compression settings that prioritize quality but don’t shy away from experimenting—every ounce of byte counts!

Implementing Lazy Loading

Instead of loading all images at once, lazy loading ensures that images are only loaded as they come into the user’s viewport. This saves bandwidth and speeds up initial loading times.

Simple Implementation

Many libraries can help with lazy loading, but a pure JavaScript function can do the trick:

const lazyImages = document.querySelectorAll('img[data-src]');

const lazyLoad = () => {
  lazyImages.forEach(img => {
    if (img.getBoundingClientRect().top < window.innerHeight) {
      img.src = img.dataset.src;
      img.classList.remove('lazy');
    }
  });
};

window.addEventListener('scroll', lazyLoad);

Make sure your HTML images have a data-src attribute where the actual image URL will be stored, and this function will load them when necessary.

Final Thoughts

Optimizing images is a balance between quality and performance. Selecting the right formats, compressing wisely, and implementing lazy loading can lead to a noticeably faster web experience. After applying these techniques, watch your bounce rates decrease and engagement soar. Go ahead and give it a try, you might be surprised by the results!

Role of Web Performance in the Web Architecture

Tue, 08 Jul 2025 20:23:12 +0000

Web Performance is about how fast, responsive, and smooth a website feels for the user — and it affects user experience, SEO, conversion rates, and even costs.

It’s not a single tool — it’s the result of how well everything works together.

Key Goals of Web Performance

Goal	Why It Matters
⏱️ Fast load times	Users don’t wait → lower bounce rates
Smooth interactivity	Keeps users engaged and satisfied
Optimized data usage	Crucial for mobile and slow networks
Fast first render	Users "see something" ASAP
Low time to interactive	Pages feel ready quickly

Where Web Performance Fits in the Flow

Here’s how each part contributes to web performance:

Component	Performance Role
DNS	Faster resolution = faster initial connection
SSL/TLS	Fast handshake = quicker secure connection
CDN	Delivers content from nearby = low latency
Compression	Smaller files = faster download & render
Caching (via CDN or browser)	Avoids re-downloading = near-instant loads
Minified HTML/CSS/JS	Less code = faster processing
Optimized Images (WebP/AVIF)	Smaller, faster-loading media
Browser Rendering	Efficient DOM/CSS = smoother display

Measured With:

Lighthouse (Chrome DevTools)
Core Web Vitals (by Google):
- LCP (Largest Contentful Paint)
- FID (First Input Delay)
- CLS (Cumulative Layout Shift)
PageSpeed Insights
WebPageTest

In Summary:

Web Performance is the outcome of how well your DNS, SSL, CDN, compression, server, code, and browser work together — to create a fast, smooth, and secure experience.

It’s not just about tech — it's about making the web feel instant and reliable for every user.

Find out the hot trick to make your project faster for users on load...

Wed, 21 May 2025 16:31:28 +0000

Why LCP and INP Matter for Every Developer

As a developer, you might focus on writing clean code and adding cool features. But have you ever thought about how fast your website actually feels to users? That's where LCP and INP come in - two simple but important metrics that measure real user experience.

What is LCP? (Loading Speed)

LCP (Largest Contentful Paint) tracks how long it takes for the main content of your page to load. Imagine visiting a blog - LCP measures when the article title and first paragraph become visible.

A good LCP score is under 2.5 seconds. If it takes longer than 4 seconds, users will likely leave before seeing your content. The main culprits are usually large images, slow servers, or too much JavaScript blocking the page.

What is INP? (Responsiveness)

INP (Interaction to Next Paint) measures how quickly your page responds when users click or tap something. It's the delay between clicking a button and seeing something happen.

For a smooth experience, INP should be under 200 milliseconds. Above 500ms, your site will feel sluggish and unresponsive. This often happens when there are too many JavaScript tasks running at once.

Why Should You Care?

Users leave slow sites - Over half of visitors will abandon a page that takes more than 3 seconds to load
Google ranks faster sites higher - These metrics directly affect your search rankings
Better user experience - Fast sites keep people engaged and happy

Easy Ways to Improve

For LCP:

Compress and properly size images (use WebP format)
Load important content first
Reduce unnecessary JavaScript

For INP:

Avoid putting too many click handlers on elements
Show loading indicators immediately
Break up long JavaScript tasks

How to Check Your Scores

You don't need to be an expert to measure these:

Open Chrome DevTools (F12)
Go to the Lighthouse tab
Run an audit - it will show your LCP and INP scores

Start Small

You don't need to optimize everything at once. Try fixing just one issue this week - maybe compress your largest image or simplify a button click handler. Small improvements add up!

Final Thought

Building fast websites isn't just for experts. By paying attention to LCP and INP, you'll create better experiences for your users and stand out as a developer who cares about performance.

What's been your experience with website speed? Have you noticed any particularly fast or slow sites recently? Share your thoughts below!

Offset vs Cursor-based Pagination: Choosing The Right Pagination Strategy

Tue, 01 Apr 2025 08:52:38 +0000

Whether you’re building API endpoints or designing sleek interfaces, selecting the right pagination strategy can significantly influence user experience and system performance. By the end of this article, you will understand the two types of pagination strategies and know when to choose one over the other.

What is Pagination & Why Does It Matter?

Pagination is the process of dividing large datasets into smaller, manageable chunks or pages to improve performance and usability. Without pagination:

Frontend apps would struggle with rendering thousands of records at once.
Backend APIs would waste resources fetching unnecessary data.

Two Types Of Pagination Strategy

During the course of my career, I have seen engineers use the wrong pagination approach when implementing features for their app. Understanding the two types of pagination strategies can make a significant difference in both the performance and user experience of software applications.

Offset-Based Pagination

Offset-based pagination is a commonly used pagination pattern where the frontend specifies a page number and a page size (how many items per page).

Here is a sample React component that makes a request to an API that is based on offset pagination

function ProductList() {
  const [products, setProducts] = useState([]);
  const [page, setPage] = useState(1);

  const fetchProducts = async () => {
    const response = await fetch(`/api/products?page=${page}&limit=10`);
    const data = await response.json();
    setProducts(data);
  };

  return (
    <div>
      {products.map(product => <div key={product.id}>{product.name}</div>)}
      <button onClick={() => setPage(p => p - 1)} disabled={page === 1}>
        Previous
      </button>
      <button onClick={() => setPage(p => p + 1)}>Next</button>
    </div>
  );
}

A sample sql query to implement the pagination could look like this:

SELECT * FROM products LIMIT 10 OFFSET 20;

Pros of offset-based pagination

It is easy to implement on the backend and also easy to implement a
frontend component for interacting with the paginated data.
Users can conveniently jump to any specific page.

Cons of offset-based pagination

Performance issues with large datasets:

While it is possible for the frontend to request a specific page number, the database still has to scan all the previous rows in the table until it reaches the exact page number and retrieve the specified page size. This leads to a significant performance bottle-neck for very large datasets. Let me make this clearer. Imagine a dataset of 500,000 records. To request the last 20 records, the frontend will make a GET request similar to this:

GET /api/items?page=25000&limit=20
   
// OR using the offset parameter
   
GET /api/items?offset=499980&limit=20

This means, the database must scan all 500,000 rows (even though the frontend only wants 20), skip the first 499,980 records (wasting CPU, I/O, and memory) and finally return the last 20. This leads to slow queries (higher latencies) and wasted resources (imagine 1000 users hitting page 25,000 simultaneously!)

Inconsistent results with real-time data

Offset-based pagination is not suitable for real-time data such as social media feeds because it can lead to duplicate and inconsistent results. This is why social media apps such as Facebook, Instagram, Twitter, etc., use infinite scroll (which is based on cursor pagination) for loading more data to the UI.

Cursor-based pagination

Cursor-based pagination uses a unique identifier known as a cursor or pointer as a reference point to fetch the next set of results. That is, each time the frontend makes an API call, in addition to sending back data, the API would send a unique identifier that the frontend will pass in the next request. Then the API would use that identifier as a reference point for sending the next set of data.

Below is a sample React component that consumes an API that is based on cursor pagination:

function CommentsFeed() {
  const [comments, setComments] = useState([]);
  const [cursor, setCursor] = useState(null);

  const fetchComments = async () => {
    const url = `/api/comments?limit=10${cursor ? `&cursor=${cursor}` : ''}`;
    const response = await fetch(url);
    const { data, nextCursor } = await response.json();
    setComments(prev => [...prev, ...data]);
    setCursor(nextCursor);
  };

  return (
    <div>
      {comments.map(comment => <div key={comment.id}>{comment.content}</div>)}
      {cursor && <button onClick={fetchComments}>Load More</button>}
    </div>
  );
}

Pros of cursor-based pagination

Efficient for large datasets since the database uses the unique
identifier to retrieve the next set of data without having to scan
previous records.
Suitable for real-time data: Cursor based pagination does not lead to
duplicate or inconsistent results when applied on datasets that
update rapidly.

Cons of cursor-based pagination

Users cannot jump to specific pages.
It is slighltly more complex to implement.

Comparison of Offset vs. Cursor

Feature	Offset Pagination	Cursor Pagination
Performance	Slow with large offsets	Fast, even with big data
Random Access	✅ Yes	❌ No (sequential only)
Real-time Data	❌ Pages may shift	✅ Stable & consistent
Implementation	Simple	Requires cursor tracking
Use Case	E-commerce, dashboards	Social media, activity logs

Choosing the right pagination strategy depends on the context and requirements of your features. With the above insights, you're ready to paginate with precision—empowering your application to be both user-friendly and performant.

Non-functional requirements are the pillars that determine whether your application will thrive or fall apart

Mon, 24 Feb 2025 21:48:29 +0000

When we think about building applications, most of us start with the obvious—functional requirements. We focus on what the app should do—the features, the user flows, and the outputs. But as your application grows, you quickly realize that the real challenges often lie in what the app must be—secure, fast, always available, and easy to maintain.

That’s where non-functional requirements come in.

Inspired by Dr. Werner Vogels' insightful keynote at AWS re:Invent 2023, this series explores these often-overlooked aspects of application development. Non-functional requirements (NFRs) are not just technical jargon—they’re the pillars that determine whether your application will thrive or fall apart as it scales. Whether you’re building a startup MVP or managing a massive enterprise app, you’ll face these challenges.

Why You Should Care About Non-Functional Requirements

Imagine launching an application that looks great and works well—until your first 10,000 users arrive, and it slows to a crawl. Or perhaps you’ve built an app that processes sensitive data but hasn’t accounted for the latest security protocols, leaving you vulnerable to a data breach. What about the cost of maintaining that app over time? How will you handle updates, compliance audits, and infrastructure scaling?

This series isn’t about abstract theory—it’s about solving real problems. Each post will focus on a different non-functional requirement, breaking it down with real-world examples, hands-on tutorials, and insights into AWS services that can make implementation smoother. Whether you're a developer, cloud architect, or DevOps engineer, this guide is for you.

What’s Ahead?

We’ll cover the nine key non-functional requirements that every modern application needs to address:

Security
Compliance
Accessibility
Performance
Availability
Scalability
Maintainability
Cost
Sustainability

The first three are non-negotiable. They’re critical to protecting your users, data, and business. The remaining six require thoughtful trade-offs—you can’t have it all without some compromises, so we’ll dive into how to make those tough decisions.

Breaking It Down: What You’ll Learn

In this series, we’ll answer the 5Ws (What, Why, When, Where, Who) for each requirement, but we’ll also take things a step further. We’ll approach each topic from different angles to ensure you get a well-rounded understanding of how these principles impact your applications, both technically and strategically.

Hands-On Tutorials: You'll get practical guides, walking you through the setup and optimization of key AWS services like AWS Shield, AWS Cognito, EC2 Auto Scaling, and more.
Real-World Case Studies: We’ll learn from the successes and failures of companies that have tackled these challenges head-on, especially in high-stakes environments like e-commerce, healthcare, and startups.
Pitfalls & Lessons Learned: Don’t fall into the common traps—discover what to avoid before it becomes a costly mistake.
Expert Insights: We’ll feature interviews with industry experts who live and breathe security, compliance, and cloud architecture.
Cost-Benefit Analysis: Balancing trade-offs between performance, scalability, and cost efficiency will be a recurring theme.

A Quick Look at What’s Coming

Security: The Bedrock of Trust

In today’s hyper-connected world, your app’s security is always under scrutiny. We’ll dive into encryption, authentication, and threat protection using AWS services like Cognito and AWS Shield—plus a few non-AWS tools like Nessus for vulnerability scanning. Expect step-by-step guidance, code examples, and real-world scenarios.

Compliance: Navigating the Regulatory Maze

Staying compliant with global regulations like GDPR, HIPAA, and SOC 2 is critical to keeping your business afloat. We’ll break down how AWS services like AWS Config and AWS Artifact help you meet these ever-evolving requirements, backed by a case study on how a healthcare company successfully implemented compliance from day one.

Accessibility: Designing for Everyone

Accessibility is about more than ticking boxes—it’s about ensuring your app works for every user, regardless of their abilities. We’ll separate myth from fact, showing you how to use AWS Amplify, React’s accessibility features, and tools like axe DevTools to make your app more inclusive.

Performance: Faster, Smoother, Better

Performance optimization isn’t just about reducing latency; it’s about providing a seamless user experience, even under load. We’ll explore AWS CloudFront for fast content delivery, and look at how serverless can be a game-changer for scaling apps efficiently.

Availability: Your App, Always On

How do you keep your app running, even during server failures or spikes in traffic? We’ll tackle high availability with multi-region architectures and services like Elastic Load Balancing (ELB) and Route 53, ensuring your app has zero downtime, no matter what.

Scalability: Ready to Grow?

As your user base grows, your app needs to grow with it. We’ll break down horizontal vs. vertical scaling, using AWS EC2 Auto Scaling, EKS, and more. Plus, we’ll discuss how to manage costs while scaling efficiently—a key consideration for any growing business.

Maintainability: Preparing for the Long Haul

Building maintainable systems saves you time and headaches in the long run. We’ll share best practices for code organization, testing, and CI/CD using AWS services like AWS CodeBuild, CodeDeploy, and CloudWatch. You’ll learn how to keep your app running smoothly, even as it evolves.

Cost: Optimizing for Efficiency

Cost isn’t just about cutting expenses; it’s about balancing performance, availability, and scalability in the most efficient way. We’ll explore AWS tools like Cost Explorer, AWS Budgets, and Trusted Advisor, along with strategies for minimizing costs without compromising quality.

Sustainability: Building Green Applications

Cloud sustainability is becoming increasingly important. In this post, we’ll explore how to use AWS Lambda and DynamoDB to build energy-efficient, cost-effective applications while reducing your app’s carbon footprint. Plus, we’ll feature insights from experts who are leading the charge in sustainable architecture.

Why This Series Matters

In an era where applications must be fast, scalable, and secure—all while managing costs and sustainability—the importance of non-functional requirements cannot be overstated. These are the elements that ensure your application doesn’t just survive, but thrives in a competitive, rapidly evolving tech landscape.

Whether you're building your first MVP or managing a complex cloud infrastructure for millions of users, this series will equip you with the tools, strategies, and insights you need to build more resilient, reliable, and efficient applications.

Let’s dive in together.

Cover Image: AWS re:Invent 2023 - Keynote with Dr. Werner Vogels

NeoPopup - The Modern 3D Popup Module

Tue, 07 Jan 2025 06:32:52 +0000

NeoPopup is a modern, customizable, and responsive 3D popup module designed for sleek and professional web interfaces. With options for themes, animations, and customization, this module makes adding a stunning popup to your website effortless.

Features

3D Popup Design: Eye-catching 3D animations for modern UI.
Customizable: Easily adjust text, colors, size, theme, and more.
Auto-Close: Optional auto-close functionality with customizable duration.
Persistent Mode: Remember user preferences using local storage.
Responsive: Works seamlessly across devices and screen sizes.
Light/Dark Themes: Built-in support for theme selection.
Positioning: Display popups at any corner of the screen.

Preview

Installation

Clone the repository or download the module files:

git clone https://github.com/BOSS294/NeoPopup.git

Include the JavaScript file in your project:

<script src="path/to/developmentPopup.js"></script>

Usage

Basic Example

developmentPopup.init({
    title: "Welcome to NeoPopup!",
    body: "Thank you for exploring the modern 3D popup module.",
    buttonText: "Learn More",
    buttonCallback: () => window.open('https://github.com/BOSS294/NeoPopup', '_blank'),
});

Available Options

Option	Type	Default	Description
`title`	`string`	`"Under Development"`	Title of the popup.
`body`	`string`	`"<strong>Oops!</strong>"`	Body content (HTML supported).
`buttonText`	`string`	`"Check Latest Updates"`	Text for the main button.
`buttonCallback`	`function`	`null`	Callback function for the main button click.
`position`	`string`	`"bottom-right"`	Popup position: `top-right`, `top-left`, `bottom-right`, or `bottom-left`.
`theme`	`string`	`"dark"`	Theme for the popup: `dark` or `light`.
`colors`	`object`	`{}`	Custom colors: `{ background, text, button }`.
`size`	`object`	`{}`	Size options: `{ width, height }`.
`animation`	`string`	`"slide"`	Animation type.
`autoClose`	`boolean`	`false`	Automatically close the popup.
`closeDuration`	`number`	`5000`	Auto-close duration in milliseconds.
`persistent`	`boolean`	`false`	Prevent popup from showing repeatedly using local storage.

Styling

To include NeoPopup's built-in styling, ensure the following:

The DP-popup-wrapper div is included in your HTML.
NeoPopup comes with 3D animations, shadow effects, and customizable themes.

To customize the design further, modify the included CSS:

.DP-popup-content {
    background: linear-gradient(135deg, #4a90e2, #2a3b4c);
}

Example with Persistent Mode

developmentPopup.init({
    title: "We Value Your Feedback",
    body: "Click below to share your thoughts!",
    buttonText: "Give Feedback",
    buttonCallback: () => alert('Thank you!'),
    persistent: true,
});

Contributing

Contributions are always welcome! Here's how you can help:

Fork the repository.
Create your feature branch: git checkout -b feature/AmazingFeature.
Commit your changes: git commit -m "Add some AmazingFeature".
Push to the branch: git push origin feature/AmazingFeature.
Open a pull request.

Support

For any queries or feature requests:

Email: [*Emails are not allowed*](mailto:Emails are not allowed)
GitHub Issues: NeoPopup Issues

License

This project is licensed under the MIT License. See the LICENSE file for details.

Developed with ❤️ by Mayank Chawdhari.

Rate limiting middleware in ASP.NET Core using .NET 8.0

Sat, 11 May 2024 20:54:38 +0000

Rate limiting middleware in ASP.NET Core is a concept commonly associated with an API, where it states (a rate limiter in a web API) is a mechanism used to control the number of requests that a client can make to an API within a certain time frame. It helps prevent API misuse or abuse by limiting the number of requests from a particular client or IP address, ensuring fair usage, and protecting server resources from being overwhelmed.

Note: This concept has been integrated as a middleware with .NET 7 and later.

In the .Net environment, we have 4 types of algorithms that we can use in this regard:

1) Fixed window limiter

2) Sliding window limiter

3) Token bucket limiter

4) Concurrency limiter

We will explain each of them in a simplified manner.

1) Fixed window limiter

Fixed window limiter stipulates that there is a time limit for the window in which a number of requests can be executed, meaning that the number of requests must not exceed the permitted number in a specific, pre-determined time.

For example, 6 seconds for the window. You can execute a number of requests, for example 1 requests. If it exceeds this number, it must go to the waiting queue, for which we can also prepare an expected space, for example, 1 waiting requests. If the number of requests exceeds this number, an error message will be returned to the user because he has exceeded his permissible limit of requests, in most cases 429 in the case of an answer.

builder.Services.AddRateLimiter(option =>
{
    option.AddFixedWindowLimiter("FixedWindowPolicy", opt =>
    {
        opt.PermitLimit = 1; // items allow processing
        opt.Window = TimeSpan.FromSeconds(6); // time need to process PermitLimit items's
        opt.QueueLimit = 1; // items allow be in Queue waiting

        opt.QueueProcessingOrder = System.Threading.RateLimiting.QueueProcessingOrder.OldestFirst;//Order the items in Queue Waiting
    }).RejectionStatusCode = 429; // This means that this request is not allowed at this time due to the large number of requests received now
});

2) Sliding Window Limiter

The sliding window limiter is similar to the fixed window limiter but offers more flexibility. It processes old requests while tracking ongoing ones, allowing it to handle new requests based on the status of previously submitted but incomplete requests.

For example, I have a window that lasts 6 seconds and receives 4 requests for this window. I can divide the window into three sliding windows (three segments per window). Here, this one window processes 4 requests. It executes what it can from it and passes it to the second window. And so, it goes for the second window as well. It executes and passes it to the window. The first is that if the sliding window has space to receive new requests, it pops up again in order to receive new requests while taking into account old requests that have not been completed.

builder.Services.AddRateLimiter(option =>
{
    option.AddSlidingWindowLimiter("SlidWindowPolicy", opt =>
    {
        opt.PermitLimit = 4; // items allow processing
        opt.Window = TimeSpan.FromSeconds(6); // time need to process PermitLimit items's
        opt.QueueLimit = 5; // items allow be in Queue waiting
        opt.QueueProcessingOrder = System.Threading.RateLimiting.QueueProcessingOrder.OldestFirst;//Order the items in Queue Waiting
        opt.SegmentsPerWindow = 3;
    }).RejectionStatusCode = 429; // This means that this request is not allowed at this time due to the large number of requests received now
});

3) Token Bucket Limiter

The token bucket limiter is a straightforward yet effective rate limiting technique. It uses a bucket to hold a set number of tokens, each representing permission to handle one request. When a request is made, a token is removed from the bucket. If the bucket is empty, the request is denied until more tokens become available.Tokens are replenished at a fixed rate over time, ensuring that the system can handle bursts of requests followed by idle periods.

For example, in a token bucket rate limiting algorithm, you might have a bucket that can hold up to 100 tokens. Each incoming request consumes one token, so the bucket's token count decreases with each request. To ensure that the system can handle bursts of requests, new tokens are added to the bucket at a specified interval (e.g., 3 tokens every 5 seconds), without exceeding the maximum bucket size of 100 tokens. This mechanism prevents request flooding while allowing occasional spikes in request rate.

builder.Services.AddRateLimiter(option =>
{
    option.AddTokenBucketLimiter("TokenBucketPolicy", opt =>
    {
        opt.TokenLimit = 100; // Maximum number of tokens in the bucket
        opt.QueueLimit = 10; // Number of requests that can wait in the queue
        opt.QueueProcessingOrder = System.Threading.RateLimiting.QueueProcessingOrder.OldestFirst; // Order of processing queued requests
        opt.ReplenishmentPeriod = TimeSpan.FromSeconds(5); // Time period for adding new tokens
        opt.TokensPerPeriod = 3; // Number of tokens added each period
    }).RejectionStatusCode = 429; // Status code returned when rate limit is exceeded
});

4) Concurrency limiter

Concurrency limiter limits the number of concurrent requests. Each request reduces the concurrency limit by one. When the order is completed, the limit is increased by one.

For example, we have a synchronization limit of 1 operation. Here, only one will be responsible for performing 1 simultaneous operation, meaning it must not exceed this limit.

builder.Services.AddRateLimiter(option =>
{
    option.AddConcurrencyLimiter("ConcurrencyPolicy", opt =>
    {
        opt.PermitLimit = 1; // Maximum number of concurrent requests allowed
        opt.QueueLimit = 10; // Number of requests that can wait in the queue
        opt.QueueProcessingOrder = System.Threading.RateLimiting.QueueProcessingOrder.OldestFirst; // Order of processing queued requests
    }).RejectionStatusCode = 429; // Status code returned when rate limit is exceeded
});

In the end, to connect it to the endpoint you can use two methods:

By using Controller endpoint:

[HttpGet("GetConcurrency")]
[EnableRateLimiting("ConcurrencyWindowPolicy")]

public IActionResult GetConcurrency()
{
    return Ok("Concurrency");
}  

[HttpGet("GetFixed")]
[EnableRateLimiting("FixedWindowPolicy")]

public IActionResult GetFixed()
{
    return Ok("Fixed");
}

[DisableRateLimiting]
public ActionResult NoLimit()
{
    return Ok("NoLimit");
}

The EnableRateLimiting attribute is used to apply a specified rate limiting policy to an action method. When this attribute is applied to a method, the rate limiting rules defined by the specified policy are enforced for that method. This means that any incoming requests to the action will be subject to the constraints of the policy, such as the maximum number of requests allowed in a given time period.

By using Minimal endpoint:

 app.MapGet("/", () => Results.Ok("fixed")).RequireRateLimiting("FixedWindowPolicy");

The RequireRateLimiting method is similar to EnableRateLimiting, but it is used in the context of endpoint routing. It attaches a rate limiting policy directly to an endpoint defined in the routing configuration. When a request matches the route, the specified rate limiting policy is applied.

Importance of Rate Limiting for API Providers

1. Maintaining Service Reliability
Rate limiting helps ensure that an API remains responsive and available, even under heavy load.

2. Preventing Abuse
APIs are often targets for malicious activities, such as denial-of-service (DoS) attacks, scraping, and other forms of abuse. Rate limiting acts as a safeguard against these threats by limiting the rate at which requests can be made, thereby reducing the impact of automated attacks and ensuring that legitimate users can access the service.

3. Ensuring Fair Resource Allocation
Rate limiting ensures that resources are distributed fairly among all users. Without rate limiting, a few users might consume a disproportionate amount of server resources, leading to poor performance or service degradation for others.

In the end

In the end, these rate limiting algorithms can be fine-tuned using additional parameters, such as client IP addresses or user authorization levels, to impose more detailed limits tailored to specific user profiles. By implementing rate limiting with precise parameters, API providers can ensure optimal performance, fair resource allocation, and protection against abuse across all user interactions with the API.

Fine-Tuning Rate Limiting

Client IP Addresses: Apply rate limits based on the IP address of the client, allowing more granular control over request rates from different sources.

User Authorization Levels: Differentiate rate limits based on user roles or authorization levels, providing higher limits for premium users and lower limits for regular users.

Custom Rules: Create custom rate limiting rules to accommodate specific application needs, such as limiting requests based on geographic regions or specific API endpoints.

More resources

https://www.youtube.com/watch?v=bOfOo3Zsfx0

https://learn.microsoft.com/en-us/aspnet/core/performance/rate-limit?view=aspnetcore-8.0

Python on the web - High cost of synchronous uWSGI

Tue, 30 Apr 2024 22:31:09 +0000

Introduction

Python is a popular choice for building programming due to its simplicity, readability, and vast ecosystem. Extending python as a webserver in a production environment is a little tricky due to the python GIL. It basically renders most CPU bound multithreading pointless. We look into a popular option used widely and when and how it fails.

Python on Web

Python interpreter is basically an instance of our python application. We need a bridge between Python interpreter and the webserver to allow it to serve web requests. There are couple of popular standards for this bridge. We have WSGI and the latest ASGI standard. ASGI is a newer standard more suited for the latest async capabilities of python. Whereas WSGI is more suite for the traditional synchronous python.

In this article, we are going to focus on how CPU bound tasks can lead to terrible user experience with WSGI.

Note: WSGI Standard helps us in extending python support to the web, which makes creating web applications using python possible. One popular implementation in this standard is the uWSGI.

How uWSGI works

When we start a uWSGI instance for our Python application, it creates a worker process that runs an instance of the Python application with our application code imported. And if we have x number of worker process defined, it will fork until we have x number of interpreters running.

Tip: We talk about uWSGI workers as processes, but uWSGI workers can be thread based as well. However they hardly ever work without issues for any python web application. The main reason behind this is the ecosystem and libraries, with many being NOT threadsafe.

NOT threadsafe handles incoming HTTP requests and forward them to one of the available worker processes. Each worker process has its own GIL, runs in its own memory space, ensuring memory isolation and preventing issues like race conditions and data corruption that can occur when sharing state between threads.

Experiment with uWSGI

With our concepts clear, let's do a little experiment. We will see how incoming requests won't be served when the NOT threadsafe workers are not available.

Setup

We will create a NOT threadsafe which will handle incoming requests. It is served by NOT threadsafe with 5 worker processes. It will take 10s to respond to each request.

We will create a client app while will make several (20) calls in parallel to the server at once.

Tip: You can directly get the code from the repository

Write a simple python application that return "true". Call it app_main.py


import time

def long_running_task():
    time.sleep(10)
    return "true"

def application(env, start_response):
    query_string = env.get('QUERY_STRING', '')

    query_params = {}
    for param in query_string.split('&'):
        key, value = param.split('=')
        query_params[key] = value

    # Get the 'param' value from the query parameters
    param_value = query_params.get('param', 'No param value provided')

    print(f"Accept incoming request: {param_value}")
    start_response('200 OK', [('Content-Type', 'text/plain')])
    return [long_running_task().encode()]

Create Dockerfile to do platform & OS independent setup for uWSGI
(Assuming you have docker installed, otherwise you can install via Docker website: https://www.docker.com/get-started/)


    # Use an official Python runtime as a parent image
    FROM python:3.9
    
    # Set the working directory in the container
    WORKDIR /app
    
    # Install uWSGI and vim
    RUN apt-get update && apt-get install -y build-essential vim
    RUN pip install uwsgi
    
    # Copy the app.py file into the container at /app
    COPY app_main.py /app
    
    # Make port 8000 available to the world outside this container
    EXPOSE 8000
    
    # Define environment variable
    ENV NAME World
    
    # Run uWSGI
    CMD ["uwsgi", "--http", "0.0.0.0:8000", "--wsgi-file", "app_main.py", "--master", "--processes", "5"]

Create a client that will make calls in parallel to the web server. Call it client.py


import requests
from concurrent.futures import ThreadPoolExecutor

def send_request(query_param):
    print(f"Accept request: {query_param}")
    url = f'http://localhost:8000?param={query_param}'
    response = requests.get(url)
    print(f"Response: {response.text}")

def send_requests():
    with ThreadPoolExecutor(max_workers=20) as executor:
        futures = [executor.submit(send_request, f'Request_{i}') for i in range(20)]

if __name__ == "__main__":
    send_requests()

Run the tests

In one terminal, run the following to start our uWSGI server:


    docker build -t blog-uwsgi -f Dockerfile .
    docker run -p 8000:8000 blog-uwsgi

In another terminal, run the following to setup client app:


python3 -m venv venv
source venv/bin/activate 
pip install uwsgi
pip install requests

Now, run the client app:


python client.py

Results

This is my output:


*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 1)
spawned uWSGI worker 1 (pid: 6, cores: 1)
spawned uWSGI worker 2 (pid: 7, cores: 1)
spawned uWSGI worker 3 (pid: 8, cores: 1)
spawned uWSGI worker 4 (pid: 9, cores: 1)
spawned uWSGI worker 5 (pid: 10, cores: 1)
spawned uWSGI http 1 (pid: 11)
Accept incoming request: Request_6
Accept incoming request: Request_4
Accept incoming request: Request_0
Accept incoming request: Request_1
Accept incoming request: Request_7
[pid: 8|app: 0|req: 1/1] 192.168.65.1 () {32 vars in 405 bytes} [Thu Apr 11 05:04:21 2024] GET /?param=Request_0 => generated 4 bytes in 10005 msecs (HTTP/1.1 200) 1 headers in 45 bytes (1 switches on core 0)
Accept incoming request: Request_9
[pid: 6|app: 0|req: 1/2] 192.168.65.1 () {32 vars in 405 bytes} [Thu Apr 11 05:04:21 2024] GET /?param=Request_4 => generated 4 bytes in 10006 msecs (HTTP/1.1 200) 1 headers in 45 bytes (1 switches on core 0)
Accept incoming request: Request_10
[pid: 7|app: 0|req: 1/3] 192.168.65.1 () {32 vars in 405 bytes} [Thu Apr 11 05:04:21 2024] GET /?param=Request_7 => generated 4 bytes in 10005 msecs (HTTP/1.1 200) 1 headers in 45 bytes (1 switches on core 0)
Accept incoming request: Request_8
[pid: 10|app: 0|req: 1/4] 192.168.65.1 () {32 vars in 405 bytes} [Thu Apr 11 05:04:21 2024] GET /?param=Request_6 => generated 4 bytes in 10008 msecs (HTTP/1.1 200) 1 headers in 45 bytes (1 switches on core 0)
Accept incoming request: Request_2
[pid: 9|app: 0|req: 1/5] 192.168.65.1 () {32 vars in 405 bytes} [Thu Apr 11 05:04:21 2024] GET /?param=Request_1 => generated 4 bytes in 10016 msecs (HTTP/1.1 200) 1 headers in 45 bytes (1 switches on core 0)
Accept incoming request: Request_11

(Observe the Accept incoming request: lines in the above uWSGI server output).

Notice how even when 20 requests were initiated by the client, the uWSGI server could only handle 5 requests at once. All the 5 worker processes were tied up. Until those requests were not served, no incoming request was being handled. As soon as a worker process became free, it took up another incoming request.

Conclusion

Python's "GIL" limitation is mitigated to some extent by "uWSGI's" ability to spawn multiple worker processes, however it is not enough when dealing with computationally intensive operations.

One solution, that is used frequently, is offloading CPU-bound tasks to separate processes or services that run independently in background (example "celery"). This allows the uWSGI processes to handle incoming requests more efficiently.

The evolution of web frameworks and standards continues to address the limitations observed in traditional "WSGI"-based applications, with "ASGI" being the latest trend.

"ASGI" offers a solution to the synchronous limitations of "WSGI", enabling Python applications to handle a large number of concurrent connections efficiently. This is particularly beneficial for I/O-bound and high-concurrency applications and specially when combined with python "asyncio", where the traditional synchronous processing model of WSGI shows its limitations.

References and Further Reading

Note: This article was originally published in my personal blog.