DEV Community

Joseph Anady
Joseph Anady

Posted on • Originally published at thatdevpro.com

Core Web Vitals (LCP, INP, CLS): the page experience playbook

#webdev #performance #seo #corewebvitals

Originally published at thatdevpro.com. Part of ThatDevPro's open SEO + AI framework library. ThatDevPro is an SDVOSB-certified veteran-owned web + AI engineering studio. Open-source AI citation toolkit: github.com/Janady13/aio-surfaces.

Core Web Vitals (LCP, INP, CLS), Mobile Optimization, HTTPS, Intrusive Interstitials, and the User-Side Quality Floor

A comprehensive installation and audit reference for page experience — the user-facing performance and usability layer Google uses as a ranking factor and, more importantly, the layer that actually determines whether visitors stay on a page or bounce. Dual-purpose: installation manual and audit document.

Cross-stack implementation note: the code samples in this framework are written in plain HTML for clarity. For React, Vue, Svelte, Next.js, Nuxt, SvelteKit, Astro, Hugo, 11ty, Remix, WordPress, Shopify, and Webflow equivalents of every pattern below, see framework-cross-stack-implementation.md. For pure client-rendered SPAs (no SSR/SSG) see framework-react.md. For Tailwind-specific concerns (purge, dynamic classes, dark-mode CLS, focus accessibility) see framework-tailwind.md.

1. Document Purpose

This is the canonical reference for page experience. Where framework-technicalseo.md covers the bot-facing foundation, this document covers the human-facing one. The two intersect: a slow page is bad for users and bad for crawl budget; an unstable layout is bad for users and bad for INP. Page experience is the discipline of measuring and fixing the metrics Google uses to model what users actually feel.

In 2026, page experience differs from page experience in 2020 in three ways. First, INP (Interaction to Next Paint) replaced FID (First Input Delay) as the responsiveness metric in March 2024 — INP is harder to pass because it measures every interaction, not just the first. Second, mobile-first indexing means mobile vitals are the only vitals that matter for ranking. Third, the threshold for "good" has tightened: Google now expects 75% of page loads to meet all three CWV thresholds at the 75th percentile of real-user data.

1.1 Required Tools

  • PageSpeed Insights — pagespeed.web.dev — both lab and field data
  • Chrome User Experience Report (CrUX) — field data source for CWV
  • Lighthouse (via Chrome DevTools) — lab measurement
  • WebPageTest — webpagetest.org — deeper waterfall analysis with location/device/connection control
  • Google Search Console — Core Web Vitals report — sitewide field data
  • Chrome DevTools Performance panel — interaction profiling for INP
  • Chrome DevTools Coverage tab — unused CSS/JS detection
  • Chrome DevTools Network panel — resource waterfall
  • Real User Monitoring (RUM) — Vercel Speed Insights, Cloudflare Web Analytics, SpeedCurve, Calibre
  • Web Vitals JS library — web-vitals npm package for custom RUM
  • GTmetrix — alternative lab + waterfall

1.2 Document Scope

Covers: the three Core Web Vitals (LCP, INP, CLS), mobile usability, HTTPS posture, intrusive interstitials, image optimization for performance, font loading, JavaScript performance, third-party tag management, and validation methodology. Touches but does not exhaust: deeper performance optimization (framework-performance.md), accessibility (framework-accessibility.md), security (framework-security.md), platform-specific tuning (framework-nextjs.md, framework-wordpress.md).

2. Client Variables Intake 

domain: ""
hosting: ""                            # Vercel | Netlify | Cloudflare | shared | VPS | dedicated
cdn: ""                                # Cloudflare | Fastly | KeyCDN | Bunny | none
cms_or_framework: ""                   # WordPress | Next.js | Astro | Hugo | Shopify | Webflow | static
current_lcp_p75: 0                     # in milliseconds, from CrUX or RUM
current_inp_p75: 0
current_cls_p75: 0
mobile_score_baseline: 0               # PageSpeed Insights mobile
desktop_score_baseline: 0
known_performance_issues: []
third_party_scripts_inventory: []      # GA4, GTM, ad tags, chat widgets, etc.
hsts_deployed: false
mobile_friendly_test_passes: false
Enter fullscreen mode Exit fullscreen mode

3. Core Web Vitals — The Three Metrics

3.1 LCP — Largest Contentful Paint

The time until the largest visible content element finishes rendering. Measured in seconds.

Thresholds (75th percentile of users):

  • Good: ≤ 2.5 seconds
  • Needs improvement: 2.5 – 4.0 seconds
  • Poor: > 4.0 seconds

What counts as the LCP element?

Usually the hero image or the largest text block. Watch the LCP candidate in DevTools Performance panel — the element flagged with the LCP marker is the one to optimize.

Common LCP causes:

Cause Fix
Hero image too large / unoptimized Compress, modern format (WebP/AVIF), loading="eager" for hero, fetchpriority="high"
Hero image lazy-loaded Hero image must NOT be lazy-loaded. Lazy-load below-fold only.
Server response slow Reduce TTFB. Cache, CDN, faster hosting.
Render-blocking CSS/JS Inline critical CSS, defer non-critical, async third-party
Font swap delays font-display: swap, preload critical fonts
Client-side rendering of hero Server-render hero content, hydrate after
Layout depends on JS to display Don't gate hero behind JS execution

Measurement approach:

  • Lab measurement (Lighthouse, WebPageTest) catches gross issues.
  • Field measurement (CrUX, RUM) is what Google uses for ranking.
  • A site can have great lab scores and bad field scores (or vice versa). Both must pass.

3.2 INP — Interaction to Next Paint

The 75th-percentile latency between a user interaction (click, tap, key press) and the next paint reflecting the result. Replaced FID in March 2024.

Thresholds (75th percentile of interactions):

  • Good: ≤ 200 ms
  • Needs improvement: 200 – 500 ms
  • Poor: > 500 ms

Why INP is harder than FID:

FID measured only the first interaction. INP measures every interaction across the page lifecycle and reports the worst (or near-worst) one. A page that responds fast to the first click but stalls on the third scrolls a poor INP.

Common INP causes:

Cause Fix
Long-running JavaScript on click handler Break work into smaller tasks; use requestIdleCallback; defer non-essential work
Heavy event listener (single handler on document) Use specific listeners; debounce; avoid synchronous heavy work
Re-render of large component on state change Virtualize lists; memoize; reduce render scope
Third-party scripts blocking main thread Audit and defer/remove
Layout thrashing in interaction handler Batch reads/writes; avoid forcing layout in tight loops
Animations on the main thread Move to CSS transforms or compositor thread

INP attribution:

Use Chrome DevTools Performance panel. Record an interaction. The "Interaction" track shows input delay + processing time + presentation delay. Identify which is dominant and fix accordingly.

3.3 CLS — Cumulative Layout Shift

A measure of visual stability — how much the page jumps around as it loads. Unitless score; lower is better.

Thresholds (75th percentile of users):

  • Good: ≤ 0.1
  • Needs improvement: 0.1 – 0.25
  • Poor: > 0.25

Common CLS causes:

Cause Fix
Images without explicit dimensions Always set width and height attributes (or CSS aspect-ratio)
Embeds (videos, iframes) without dimensions Same — reserve space
Web fonts causing reflow when they load font-display: optional or swap with size-adjusted fallback
Ads injecting late and pushing content Reserve ad slot dimensions; lazy-render only below fold
Dynamic content injected above existing content Inject below or in reserved space
CSS loaded late changing styles Inline critical CSS for above-fold

The cookie banner exception:

Cookie consent banners that appear after a delay are a major CLS source. Either render the banner with reserved space from page load, or apply it as a fixed-position overlay that doesn't shift content.

4. Mobile Usability

Since 2023 Google indexes the mobile version of every site. Mobile vitals are the only vitals that matter for ranking.

4.1 The Viewport Tag

Every page must include:

<meta name="viewport" content="width=device-width, initial-scale=1.0">
Enter fullscreen mode Exit fullscreen mode

Without this, mobile browsers render the page at desktop width and zoom out, failing nearly every mobile usability check.

4.2 Tap Target Size

Tap targets (buttons, links) must be at least 48 × 48 CSS pixels. Targets smaller than 48px or with less than 8px spacing between them fail mobile usability.

.btn, .link-as-button {
  min-height: 48px;
  min-width: 48px;
  padding: 12px 20px;
}
nav a {
  padding: 12px 16px;  /* generous click area */
}
Enter fullscreen mode Exit fullscreen mode

4.3 Text Size

Body text on mobile should be at least 16px. Smaller text triggers automatic zoom on iOS form fields and fails mobile usability.

4.4 Content Width

Content must fit the viewport. Horizontal scrolling on mobile fails the test.

img, video, iframe { max-width: 100%; height: auto; }
.container { max-width: 100vw; overflow-x: hidden; }
Enter fullscreen mode Exit fullscreen mode

4.5 The Mobile-Friendly Test

Run every important page through search.google.com/test/mobile-friendly (deprecated; replaced by URL Inspection in GSC). The Lighthouse mobile audit covers most of the same checks.

5. HTTPS

Page experience requires HTTPS. The full implementation is in framework-technicalseo.md Section 11; the page-experience-relevant pieces:

  • Valid certificate (no browser warning)
  • HSTS deployed
  • No mixed content (HTTPS page loading HTTP resources)
  • HTTP/2 or HTTP/3 enabled (performance benefit, not strict requirement)

6. Intrusive Interstitials

Pop-ups, overlays, and interstitials that block content access on mobile are a ranking penalty. The penalty applies to:

  • Pop-ups covering the main content immediately on page load
  • Standalone interstitials the user must dismiss before reaching the page
  • Above-the-fold layouts where the visible portion is dominated by an ad or pop-up

Exempted:

  • Login dialogs on pages that legitimately require login
  • Age verification on pages that legitimately require it
  • Cookie consent banners (provided they don't dominate the viewport)
  • Small banner ads that don't dominate the visible area

Common offenders:

  • Email signup overlays triggered immediately on landing
  • "Subscribe to our newsletter" full-screen modals
  • Discount-offer pop-ups before user has read anything
  • Chat widgets that auto-expand to fill the screen

The fix is timing and proportion. Show the overlay after engagement (15+ seconds, 50%+ scroll, exit intent) and keep it under ~30% of the viewport.

7. Image Optimization for Performance

Images are usually the LCP element and often the biggest CLS contributor. Optimize aggressively.

7.1 Format Selection

Format Use case
AVIF Best compression. Photographic content. ~95% browser support in 2026.
WebP Excellent compression. Universal fallback for AVIF.
JPEG Legacy fallback. Photographic content where AVIF/WebP unavailable.
PNG Only when alpha transparency required. Use PNG-8 where possible.
SVG Logos, icons, illustrations. Inline when small (<2KB).
GIF Never. Use MP4 or WebM.

The <picture> pattern serves the right format per browser:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="..." width="1200" height="800" loading="eager" fetchpriority="high">
</picture>
Enter fullscreen mode Exit fullscreen mode

7.2 Responsive Images

Serve different sizes per viewport:

<img src="hero-800.jpg"
     srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w, hero-1600.jpg 1600w"
     sizes="(max-width: 768px) 100vw, 50vw"
     alt="..." width="1200" height="800">
Enter fullscreen mode Exit fullscreen mode

7.3 Lazy Loading 

<img src="..." loading="lazy" alt="..." width="..." height="...">
Enter fullscreen mode Exit fullscreen mode

Critical: the LCP image must NOT be lazy-loaded. Lazy-load below-the-fold images only. Use loading="eager" (or omit; eager is default) for the hero image and add fetchpriority="high" to signal priority.

7.4 Dimensions Always

Every <img>, <video>, and <iframe> requires width and height attributes (or CSS aspect-ratio). This reserves layout space and prevents CLS.

7.5 Image CDN

For sites with many images, an image CDN (Cloudinary, imgix, Cloudflare Images, Vercel Image Optimization, Next.js next/image) provides:

  • On-the-fly format conversion
  • On-the-fly resizing
  • Automatic AVIF/WebP serving
  • Caching at the edge

Cross-reference: framework-imageseo.md for SEO-side image considerations.

8. Font Loading

Fonts are a frequent LCP and CLS culprit.

8.1 font-display

Always specify font-display:

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap;  /* show fallback immediately, swap when font loads */
}
Enter fullscreen mode Exit fullscreen mode
Value Behavior
swap Show fallback immediately; swap when web font loads. CLS risk if fallback metrics differ.
optional Use web font only if loaded within 100ms. Otherwise stick with fallback. Best for CLS.
fallback 100ms blocking, 3s swap window, then fallback locked in. Compromise.
block Up to 3s blocking. Avoid.

8.2 Preload Critical Fonts 

<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>
Enter fullscreen mode Exit fullscreen mode

Only for fonts used above the fold. Preloading too many resources hurts LCP.

8.3 Font Subsetting

Modern Google Fonts are typically already subset. Self-hosted custom fonts: subset to the character set you actually use (Latin, Cyrillic, etc.). A 200KB unsubset font becomes 30KB after Latin subset.

8.4 Variable Fonts

Variable fonts (Inter, Fraunces, etc.) deliver multiple weights from one file. Net win at scale.

8.5 size-adjust and Fallback Metrics

Match fallback font metrics to web font to eliminate CLS on swap:

@font-face {
  font-family: 'fallback-inter';
  src: local('Arial');
  size-adjust: 107%;
  ascent-override: 90%;
  descent-override: 22%;
  line-gap-override: 0%;
}
body { font-family: 'Inter', 'fallback-inter', sans-serif; }
Enter fullscreen mode Exit fullscreen mode

The fontaine library automates this for popular fonts.

9. JavaScript Performance

9.1 Bundle Size Budget

For mobile-first 2026:

Resource Target
Initial JS bundle (compressed) < 100 KB
Initial CSS (compressed) < 30 KB
Initial HTML < 50 KB
Total page weight (initial load) < 500 KB
Total page weight (with all resources) < 1.5 MB

These are aggressive targets and not always achievable, but they're the bar.

9.2 Code Splitting

Load only what's needed for the initial route. Defer route-specific bundles:

// Next.js dynamic import
const HeavyChart = dynamic(() => import('./HeavyChart'), { ssr: false });
Enter fullscreen mode Exit fullscreen mode

9.3 Tree Shaking

Modern bundlers (esbuild, Vite, Rollup, Turbopack) tree-shake automatically. Verify by checking final bundle for unused imports — Coverage tab in Chrome DevTools shows unused JS.

9.4 Defer and Async 

<!-- Async: download in parallel, execute as soon as ready -->
<script src="analytics.js" async></script>

<!-- Defer: download in parallel, execute in order after HTML parsing -->
<script src="enhancement.js" defer></script>
Enter fullscreen mode Exit fullscreen mode

Most third-party scripts should be async or defer. Inline blocking <script> tags are the worst case for LCP.

9.5 Long Tasks

A "long task" is any JS execution over 50ms. Long tasks block input and hurt INP. Find them in Chrome DevTools Performance panel — they appear as red-flagged blocks. Common sources:

  • Heavy initial render (React/Vue hydration)
  • Large state updates
  • Synchronous loops over big arrays
  • Third-party SDK initialization

Break into smaller tasks with setTimeout(0), requestIdleCallback, or scheduler.yield.

10. Third-Party Tag Management

Most page-experience problems on real client sites trace to third-party scripts: analytics, ads, chat widgets, A/B testing tools, marketing automation pixels.

10.1 The Audit

For every site, inventory every third-party script and ask:

  • What does it do?
  • Does the client actually use the data it produces?
  • What's its INP impact?
  • Can it be loaded later (defer, async, post-interaction)?
  • Is there a lighter alternative?

Common removals after audit:

  • Old A/B testing platforms no longer in use
  • Multiple competing analytics (GA4 + Adobe + Heap + Hotjar + Mixpanel)
  • Chat widgets the client doesn't monitor
  • Pixel tags from agencies long since departed
  • "Just in case" tags whose purpose nobody remembers

10.2 Tag Manager Hygiene

If using GTM:

  • Audit triggers — many fire on every page load even when only relevant on specific pages
  • Audit tags — disable or remove unused tags
  • Use built-in tag templates rather than custom HTML where possible
  • Set "Wait for tags" thresholds that don't block CWV

10.3 The Self-Hosted Pattern

For high-impact third-party scripts (especially analytics), self-hosting can reduce DNS, TCP, and TLS overhead. Plausible, Fathom, Cloudflare Web Analytics all support self-hosting.

For Google Analytics, gtag.js itself can't be self-hosted easily, but the analytics.js payload can be proxied via Cloudflare Worker / nginx to reduce third-party origin connections.

10.4 Privacy and Performance

EU privacy law (GDPR) and US state laws (CCPA) increasingly require consent before tags fire. The consent gate has a side benefit: tags don't load until interaction, which is great for CWV. Consent Mode v2 in GTM is the conventional implementation.

11. Server-Side Performance

11.1 Time to First Byte (TTFB)

While not a CWV metric directly, TTFB feeds into LCP. Good TTFB is under 600ms; great is under 200ms.

Cause Fix
Slow database queries Add indexes, cache, denormalize
Slow templating / rendering Cache rendered output (HTML cache, full-page cache)
Slow PHP / Python / Node app Profile, optimize hot paths
Distant origin server Add CDN, choose hosting near user base
Cold-start serverless Use provisioned concurrency or always-warm tier

11.2 Caching Layers

In order of preference (cheapest to most expensive lookup):

  1. CDN edge cache — Cloudflare, Fastly, etc. — milliseconds, free at scale
  2. Application-level page cache — WP Super Cache, Vercel ISR, Astro static — single-digit ms
  3. Object cache — Redis, Memcached — for query results, session data
  4. Database query cache — built into MySQL/PostgreSQL — invalidate carefully
  5. Database itself — last resort

11.3 HTTP/2, HTTP/3, Brotli

  • HTTP/2 — supported everywhere, multiplexes connections.
  • HTTP/3 — emerging; supported by Cloudflare, Fastly. Minor performance gain on lossy mobile networks.
  • Brotli compression — better than gzip for text resources. Enable at server or CDN level.

12. Real User Monitoring (RUM)

Lab tests catch some problems. Field data catches the rest. Set up RUM on every client site.

12.1 Free Options

  • Google Search Console — Core Web Vitals report — sitewide CrUX data, no setup
  • Cloudflare Web Analytics — free, privacy-respecting, includes CWV
  • Vercel Speed Insights — free for Vercel-hosted sites

12.2 Paid Options

  • SpeedCurve — comprehensive RUM with synthetic monitoring
  • Calibre — performance budgets, alerting
  • Pingdom RUM — basic monitoring

12.3 DIY with web-vitals

For full control, use the web-vitals library:

import { onLCP, onINP, onCLS } from 'web-vitals';

function sendToAnalytics({name, value, id}) {
  navigator.sendBeacon('/rum', JSON.stringify({name, value, id, url: location.href}));
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);
Enter fullscreen mode Exit fullscreen mode

Ship to your own endpoint and analyze with whatever tooling suits.

13. The Validation Workflow

For every client engagement:

  1. Baseline (week 0) — record LCP, INP, CLS at 75th percentile from PageSpeed Insights field data, GSC CWV report, and any RUM available. Document mobile and desktop separately.
  2. Diagnose — Lighthouse audit on representative pages. WebPageTest for waterfall. Identify top 5 contributing issues.
  3. Fix — implement changes. Verify in lab tests first.
  4. Measure — wait 28 days for CrUX field data to update (CrUX uses 28-day rolling window).
  5. Iterate — if not yet "good," continue diagnosing.
  6. Monitor — RUM and GSC CWV report ongoing.

14. Audit Mode

# Criterion Pass/Fail
PE1 Mobile LCP at 75th percentile under 2.5s
PE2 Mobile INP at 75th percentile under 200ms
PE3 Mobile CLS at 75th percentile under 0.1
PE4 Desktop LCP under 2.5s, INP under 200ms, CLS under 0.1
PE5 Lighthouse mobile performance score ≥ 90 on representative pages
PE6 GSC Core Web Vitals report shows zero "poor" URLs
PE7 Viewport meta tag present on every page
PE8 All tap targets ≥ 48 × 48 CSS pixels
PE9 Body text ≥ 16px on mobile
PE10 No horizontal scrolling on mobile
PE11 Mobile-Friendly Test (or URL Inspection) passes
PE12 HTTPS enforced; HSTS deployed
PE13 No mixed content on any page
PE14 No intrusive interstitials on mobile
PE15 Hero image NOT lazy-loaded; has fetchpriority="high"
PE16 All images have width and height (or aspect-ratio)
PE17 Below-fold images use loading="lazy"
PE18 Modern image formats (AVIF / WebP) served via <picture>
PE19 Responsive images via srcset and sizes
PE20 Fonts use font-display: swap or optional
PE21 Critical fonts preloaded; non-critical not
PE22 Initial JS bundle < 100KB compressed
PE23 Third-party scripts deferred or async (no inline blocking)
PE24 Third-party tag inventory documented and audited
PE25 TTFB at 75th percentile under 600ms
PE26 Brotli or gzip compression on all text resources
PE27 HTTP/2 or HTTP/3 enabled
PE28 Edge / CDN caching layer present
PE29 RUM tooling deployed (any of: GSC CrUX, Vercel Insights, Cloudflare Web Analytics, custom web-vitals)
PE30 No long tasks > 100ms on initial interaction (DevTools Performance)

Score: 30. World-class: 28+/30.

15. Common Mistakes

  1. Lazy-loading the hero image. Slows LCP dramatically.
  2. No image dimensions. Largest CLS source.
  3. Cookie banner injected late, pushing content. Reserve space or use overlay.
  4. Multiple analytics SDKs running concurrently. Pick one, remove the rest.
  5. Synchronous third-party scripts. Use async / defer.
  6. Optimizing only desktop. Mobile is what Google ranks.
  7. Lab scores look great, field scores poor. Field data is what counts.
  8. Long-running click handlers. INP killer; break into chunks.
  9. font-display: block (or unspecified, which defaults to block). Hides text until font loads.
  10. JavaScript-heavy "interactive" landing pages with sub-second blocking work. INP catastrophe on mid-tier mobile devices.
  11. No CDN. Origin server in one region serves users globally; LCP suffers everywhere except near the origin.
  12. Render-blocking CSS. Inline critical above-fold CSS; defer the rest.
  13. Web fonts loading from external CDN with no preconnect. Add <link rel="preconnect"> for font origin.
  14. Poll-based polling JavaScript. Use server-sent events or WebSockets.
  15. Unused JS frameworks loaded. "We're using React for one widget" but shipping the whole bundle.
  16. <iframe> embeds without dimensions. Major CLS source.
  17. Treating CWV as a checkbox once and never again. CWV regress over time as features are added.

16. Maintenance

Weekly:

  • Spot-check PageSpeed Insights for representative pages
  • Review GSC Core Web Vitals report for new errors

Monthly:

  • Sitewide GSC CWV review
  • RUM dashboard review
  • New third-party scripts audit
  • Lighthouse audit on top 10 pages

Quarterly:

  • Comprehensive performance audit (WebPageTest + Lighthouse)
  • Third-party tag inventory refresh
  • Image/font/CSS/JS budget review
  • CDN configuration review
  • Cache hit ratio review

Annually:

  • Full performance budget reassessment
  • Hosting/CDN evaluation
  • New CWV metric watch (Google revises CWV periodically)
  • Major framework / CMS update planning

17. Companion Documents

  • framework-technicalseo.md — Indexing, HTTPS, server-side foundation
  • framework-performance.md — Deeper performance optimization beyond CWV
  • framework-imageseo.md — Image SEO including format and alt text
  • framework-mobileseo.md — Mobile-specific deep dive
  • framework-accessibility.md — A11y patterns (overlap with mobile usability)
  • framework-security.md — HTTPS, HSTS, security headers
  • framework-nextjs.md — Next.js performance patterns
  • framework-wordpress.md — WordPress performance patterns
  • framework-headless.md — Headless architecture performance
  • framework-cro.md — Performance and conversion correlation

Document version: 1.0
Last updated: 2026-05-05
Owner: Joseph W. Anady — ThatDeveloperGuy — SDVOSB

About this framework library

This article is the Dev.to republish of a framework reference document from ThatDevPro's SEO + AI engineering library. Canonical source: https://www.thatdevpro.com/insights/framework-pageexperience/

ThatDevPro is an SDVOSB-certified veteran-owned web + AI engineering studio operating from Cassville, Missouri. The studio runs the full 14-tier Engine Optimization stack and ships open-source tooling for AI citation engineering.

Companion 14-tier Engine Optimization stack (each tier is its own article):

  1. Tier 1 — Foundation
  2. Tier 2 — Search Visibility
  3. Tier 3 — AI Domination
  4. Tier 4 — Entity and Authority
  5. Tier 5 — Local Domination
  6. Tier 6 — Content and Multimedia
  7. Tier 7 — Social and Community
  8. Tier 8 — Data, Analytics, Conversion
  9. Tier 9 — Monitoring and Intelligence
  10. Tier 10 — Workflow and Operations
  11. Tier 11 — Marketplace and Retail
  12. Tier 12 — International
  13. Tier 14 — Advanced and Immersive

Need this framework implemented on your site? See the Engine Optimization service or hire through ThatDevPro contact.

Top comments (0)