Full transparency — know exactly what tools we use, how we calculate every score, and what each metric means. No black boxes.
The engines that power every AuditWave scan
We use Playwright for headless browser automation. It launches real Chromium browsers to render your website exactly as users see it across 4 device profiles with device-specific user agents and scaling factors.
The industry-standard accessibility testing engine by Deque Systems. axe-core runs against the live DOM to detect WCAG 2.2 AA violations, mapping each issue to specific WCAG criteria with severity levels and actionable fix suggestions.
Performance scores are calculated using the Lighthouse v10 scoring algorithm, which uses a log-normal cumulative distribution function (CDF). Each metric is scored 0–100 based on real-world performance data distributions, then weighted to produce a final score.
SEO analysis is performed by injecting evaluation scripts into the browser context via Playwright. We parse the live DOM to extract meta tags, heading hierarchy, Open Graph tags, Twitter Cards, JSON-LD structured data, link analysis, and image audits.
Uses Chrome DevTools Protocol (CDP) to collect JavaScript/CSS code coverage and resource transfers. Technology detection uses signature matching against response headers, script content, DOM elements, and meta tags to identify frameworks, CMS, CDNs, analytics, and more.
Specialized analysis for Next.js applications. Inspects the rendered DOM and network requests to evaluate next/image usage, hydration payload size, rendering mode (SSR vs SSG vs ISR), and component patterns specific to the Next.js framework.
Launches parallel browser sessions to load two URLs under identical conditions and captures performance metrics for both. Computes metric-by-metric diffs and determines the winner based on overall score and individual Core Web Vitals.
Transparent scoring methodology for every audit type
Calculated as the ratio of passing rules to total rules evaluated by axe-core. The score accounts for violation severity — critical and serious issues have a heavier impact than moderate or minor ones.
Each violation is mapped to one of the 4 WCAG principles (Perceivable, Operable, Understandable, Robust), giving you a per-principle breakdown. The final score represents the percentage of rules your page passes, weighted by severity.
Uses the Lighthouse v10 log-normal scoring model. Core Web Vitals (LCP, FCP, TBT, CLS) are individually scored using cumulative distribution functions based on real-world data.
Network throttling simulates real conditions per device. Each metric value is mapped to a 0-100 score using a log-normal distribution curve. The final performance score is a weighted combination of all individual metric scores.
Evaluated through a weighted checklist of SEO best practices. Each check contributes to the total score with critical issues weighing more heavily.
Checks include: meta title length, description presence, heading hierarchy validity, canonical URL, HTTPS enforcement, structured data, Open Graph completeness, image alt text, and internal link structure. Missing critical elements (like titles) have a larger score impact than informational checks.
Combines resource efficiency metrics (total transfer size, unused JavaScript ratio) with technology detection completeness.
Transfer sizes are categorized (JS, CSS, images, fonts, other) and scored against efficiency thresholds. Code coverage analysis identifies unused JavaScript as a percentage of total JS. Technologies are identified with confidence scores based on multiple signal matches (headers, DOM, scripts).
Evaluates Next.js-specific best practices including image optimization, hydration efficiency, rendering strategy, and bundle patterns.
Checks for next/image usage vs native img tags, measures __NEXT_DATA__ hydration payload size, verifies rendering mode choices, and audits component patterns. Each insight is classified by severity (critical, warning, info, pass) and category.
Every term and metric explained in plain language
A set of real-world, user-centered metrics defined by Google that quantify key aspects of user experience. They measure loading performance, interactivity, and visual stability of a page. Google uses these as ranking signals in search results.
Measures how long it takes for the largest visible content element (image, video, or text block) to render on screen. It reflects perceived loading speed — when users feel the page has mostly loaded.
The time from navigation to when the browser renders the first piece of DOM content (text, image, SVG, or canvas). It marks when users first see something on screen.
The total amount of time the main thread was blocked long enough to prevent input responsiveness, measured between FCP and Time to Interactive. High TBT means the page feels sluggish to interact with.
Measures visual stability by quantifying how much visible content unexpectedly shifts during page load. High CLS means elements jump around while loading, causing users to misclick or lose their place.
The time between the browser requesting a page and receiving the first byte of response from the server. It measures server responsiveness and network latency.
The latest version of the international standard for web accessibility published by the W3C. It defines how to make web content more accessible to people with disabilities, organized into 4 principles: Perceivable, Operable, Understandable, and Robust. We test against the AA conformance level.
The first WCAG principle. Information and user interface components must be presentable to users in ways they can perceive. This includes text alternatives for images, captions for audio, sufficient color contrast, and content that can be presented in different ways.
The second WCAG principle. User interface components and navigation must be operable. This means all functionality must be available from a keyboard, users have enough time to read content, content doesn't cause seizures, and users can easily navigate and find content.
The third WCAG principle. Information and the operation of the user interface must be understandable. This means text is readable, pages appear and operate in predictable ways, and users are helped to avoid and correct mistakes.
The fourth WCAG principle. Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies. This involves valid HTML, proper ARIA usage, and correct name/role/value attributes.
A set of HTML attributes that define ways to make web content more accessible. ARIA roles, states, and properties supplement native HTML semantics to convey information to assistive technologies like screen readers.
A protocol created by Facebook that enables web pages to become rich objects in social media feeds. OG tags (og:title, og:description, og:image, etc.) control how your page appears when shared on Facebook, LinkedIn, and other platforms.
Meta tags (twitter:card, twitter:title, twitter:description, twitter:image) that control how your content appears when shared on X (Twitter). Card types include summary, summary_large_image, app, and player.
A method of encoding Linked Data using JSON, recommended by Google for structured data markup. It helps search engines understand your content and can enable rich results (snippets, carousels, FAQs) in search results. Common schemas include Article, Product, Organization, and BreadcrumbList.
An HTML link element (rel="canonical") that tells search engines which version of a URL is the primary one. It prevents duplicate content issues when the same page is accessible via multiple URLs.
The logical structure of headings (H1-H6) on a page. A valid hierarchy starts with a single H1, followed by H2s, H3s nested under H2s, and so on. Breaking hierarchy (e.g., jumping from H1 to H4) confuses screen readers and hurts both accessibility and SEO.
An HTML meta tag that tells search engine crawlers how to index a page. Common directives include "index" (allow indexing), "noindex" (prevent indexing), "follow" (follow links), and "nofollow" (don't follow links).