“Lighthouse 100” is printed directly into brndle.com’s own browser tab: open the homepage and the title reads “Brndle – Free, open-source WordPress theme. Lighthouse 100. 100% GPL.” It is a clean, confident claim, and like most four-word performance claims on a product page, it arrives with no screenshot, no audit date, no tested URL, and no note on which page, which host, or which throttling profile earned it. That is not unusual. Browse any theme marketplace and you will find “blazing fast,” “100/100 Lighthouse,” and “built for speed” attached to products nobody has publicly re-tested since the listing went up. The claim is cheap to print and expensive to verify, so almost nobody verifies it – including, in most cases, the team selling the theme.

This post is us trying to verify it anyway, for the theme this blog writes about every week. We went in expecting one of two clean outcomes: confirm the number with a fresh audit, or catch the marketing exaggerating. We got neither. We ran into a real tooling limit, a real distinction between the theme and the site that markets it, and a real set of architectural decisions that explain why the number is plausible even though we could not personally produce a dated screenshot of it. The honest version of this story turned out to be more useful than a clean screenshot would have been, so that is the version below: what we tried, where it broke, what we could confirm from the theme’s own source, and what any of it actually predicts for a client site that is not brndle.com.

In this guide

Why “Lighthouse 100” claims are usually unverifiable marketing copy
Methodology: what we actually tried, and exactly where it broke
The results we could get, with every caveat attached
Performance: architecture decisions mapped to specific Lighthouse audits
Accessibility: what is structural versus what is still unverified
Best Practices and SEO: what the theme controls and what it doesn’t
What this means for an actual client site
Questions people ask

Why “Lighthouse 100” claims are usually marketing fluff

A Lighthouse score is not a property of a theme. It is a property of one specific page, loaded from one specific host, on one specific day, under one specific throttling profile, carrying whatever images, fonts, and third-party scripts happened to be installed at the moment someone ran the audit. Change any one of those five things and the number moves, sometimes by a lot. A theme vendor quoting a single number with none of that context is not lying exactly – the number probably did come from a real Lighthouse run, once – but it is reporting a result without reporting the conditions that produced it, which makes the number unfalsifiable. You cannot go check it, because you do not know what was checked.

The vendor’s own marketing site is also the worst possible subject for this kind of claim, for a reason that will matter a lot later in this post: the marketing team controls every variable on their own property. A theme can render a flawless, lightweight single page template and still watch its own homepage sink under a chat widget, an analytics tag, and a cookie banner the marketing team added after the “100” screenshot was taken. Whether the number still holds is an open question the vendor rarely revisits, because revisiting it risks finding out it does not.

Methodology: what we actually tried, and exactly where it broke

We did not want to repeat the pattern above, so we tried to get a real, current number before writing a single sentence about architecture. Here is the sequence, in the order we actually ran it, including the parts that did not work.

First, the Google PageSpeed Insights public API against brndle.com’s homepage. This is the same engine behind pagespeed.web.dev and the same one most “100 Lighthouse” marketing screenshots come from. We ran:

curl "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https%3A%2F%2Fbrndle.com%2F&category=performance&category=accessibility&category=best-practices&category=seo&strategy=mobile"

The response, verbatim, was an HTTP 429: “Quota exceeded for quota metric 'Queries' and limit 'Queries per day' of service 'pagespeedonline.googleapis.com'”. We tried it twice, a few minutes apart, from two different request paths. Both failed the same way. The public, unauthenticated quota for that endpoint was exhausted for the day by the time we ran this piece, on October 30, 2026. We are reporting that failure rather than quietly retrying until something came back, because a number obtained by brute-forcing an API until it finally returns one is not meaningfully different from guessing.

Second, we checked whether a public, running instance of the actual Brndle WordPress theme exists anywhere – a demo site, a WordPress Playground preview, anything we could point an audit at instead of the marketing pages. We read the theme’s GitHub repository at github.com/brndle-themes/brndle looking specifically for a demo URL. There is none in the README. We also checked the WordPress.org theme directory on the chance the theme is dual-listed there with its own reviewer-moderated preview; wordpress.org/themes/brndle/ returns a 404. Brndle is distributed only as a GitHub-hosted, pre-built ZIP, which other posts on this blog have already confirmed is the project’s intended release process. That also means there is no independently hosted, review-team-audited install anywhere we could run a clean test against. Every live instance of the theme, if any exist, is on a client’s own server, not ours to test.

Third, and this is the finding that changed the shape of this whole post: brndle.com itself does not run the Brndle WordPress theme. We captured the real network requests the homepage makes on load, and the first-party asset paths are unambiguous – /_astro/Layout.CqEKD6xw.css, /_astro/index@_@astro.afMVNTci.css. That naming convention belongs to the Astro static site framework, not to a WordPress theme’s enqueued stylesheet. This blog and the marketing pages around it are a separate, statically built site that talks about the Brndle WordPress theme; they are not a deployment of it. Testing brndle.com’s Lighthouse score, even if the API quota had not blocked us, would not have measured the theme this post is supposed to be a case study of. We are stating that plainly instead of quietly testing the wrong site and letting the result imply something it does not.

Fourth, with a dated, authoritative number blocked on two independent fronts, we still captured the real browser network waterfall for brndle.com’s homepage, specifically because it is real, reproducible data, and because what it contains turns out to be directly relevant to the “what breaks a 100 on a real site” section later in this post. We are presenting it as exactly what it is: evidence about the marketing site’s own front-end choices, not a proxy for the WordPress theme’s performance.

The results we could get, with every caveat attached

No Lighthouse performance, accessibility, best-practices, or SEO score for brndle.com or for a live Brndle WordPress installation appears anywhere in this post. We do not have one we could stand behind, so we are not printing one. What we do have is a real captured network log from the homepage, taken October 30, 2026, which recorded 41 requests. The relevant pattern:

Category	What we actually saw
Live chat widget	Crisp (client.crisp.chat) – loader script, client JS bundle, client CSS, two settings endpoint calls, and an avatar image: six separate requests for one chat bubble.
Analytics / tag management	Google Tag Manager (`googletagmanager.com/gtag/js`) loaded on the main thread.
Performance/analytics beacon	Cloudflare’s own RUM beacon (`cdn-cgi/rum`) plus a Cloudflare Insights script.
Cross-domain embed	A wbcomdesigns.com announcement widget: one script plus a separate JSON fetch for the announcement content.
Extra web font	A display font (Grenze Gotisch) pulled from Google Fonts – one CSS request plus one WOFF2 file, in addition to the Inter variable font self-hosted from the site’s own `_astro` path.
First-party CSS	Two Astro-bundled stylesheets, served with far-future caching (one returned as an HTTP 304 on reload).

To be clear about what this does and does not prove: it is not evidence about Brndle the WordPress theme, because brndle.com is not running Brndle the WordPress theme. It is evidence that even a team writing a weekly blog about block theme performance ships a chat widget, a tag manager, an analytics beacon, and a cross-domain embed on its own front page – the exact category of addition that determines whether any given real site keeps or loses a high Lighthouse score. We will come back to that in the section on real client sites, because it is the most honest data point in this entire piece.

With a live number off the table, the rest of this post does the thing we think is actually defensible when you cannot produce a fresh audit screenshot: trace the specific, source-confirmed architecture decisions in the Brndle theme itself, and connect each one to the specific Lighthouse audit it would need to satisfy. We previously read the theme’s block registration code directly for another post on this blog and confirmed, among other things, that all of its blocks render server-side through a shared callback rather than hydrating client-side. We are reusing that confirmed groundwork here rather than re-deriving it, and we will flag anywhere we are inferring rather than quoting source.

Performance: architecture decisions mapped to specific Lighthouse audits

Lighthouse’s performance category is a weighted set of individual audits, not one holistic feeling of speed. The theme’s documented and source-confirmed choices line up with a specific subset of those audits:

No client-side block hydration. A previous audit of this theme’s own repository confirmed that all of its registered blocks resolve through one shared render_callback in a BlockServiceProvider class, which maps an attributes object to a server-rendered Blade view. There is no client-side component framework shipping a runtime to hydrate those blocks in the browser. That directly targets Lighthouse’s total-blocking-time, bootup-time, and mainthread-work-breakdown audits: a page with no client-rendered component tree has nothing competing with user input on the main thread beyond whatever script a plugin adds separately.
A documented split between app.js and editor.js. The theme’s own development structure keeps front-end script separate from editor-only script, so a visitor loading a published page is not also downloading block-editor tooling meant for wp-admin. This is the kind of separation Lighthouse’s unused-javascript and legacy-javascript audits are built to catch when it is missing.
Tailwind v4 with a closed utility vocabulary. The theme’s own internal styling rule, stated in its repository documentation, is to use predefined theme utilities (bg-surface-primary, text-accent) and never an arbitrary escape hatch like text-[var(--color-*)]. Tailwind’s build step only emits CSS for classes it can find referenced in the source, so a closed utility vocabulary is exactly the condition that makes aggressive purging reliable; an arbitrary-value escape hatch is the kind of pattern that can confuse a purge step into keeping rules nothing uses. This is the mechanism behind Lighthouse’s unused-css-rules audit, though we want to be precise about a limit here: the README does not publish an actual compiled CSS file size in kilobytes, so we can describe the mechanism that should keep the stylesheet lean without citing a verified number for how lean it actually is.
A documented “lazy images” and font-preload toggle in the theme’s own Performance settings panel. This maps to Lighthouse’s offscreen-images audit (deferring below-the-fold images) and its font-display / preconnect-adjacent checks for web font loading. We can confirm the toggle exists and is documented as a setting; we did not have access to a running install to confirm every content-image template actually emits a loading="lazy" attribute by default versus requiring the toggle to be switched on, so we are stating the setting’s existence as confirmed and its default-on behavior as unverified.
No WordPress.org directory listing. This cuts both ways and is worth stating honestly rather than only as a positive. The WordPress Theme Review Team’s guidelines would normally force a lean functions.php, no mystery script enqueues, and no theme-side tracking beacons as a condition of listing. Brndle, distributed only via GitHub as a pre-built ZIP, has no such external gate. That can mean tighter self-discipline than a committee review enforces, or it can mean nobody outside the Brndle team has independently checked. We have no way to tell which from outside the source, and we are not going to imply the absence of a listing is itself evidence of quality either way.

We previously wrote a full five-part series on this exact category of optimization – lazy loading and deferred assets, critical CSS extraction, and the full rendering audit workflow that ties them together with Query Monitor and WebPageTest. That series is the general methodology; everything in the bullet list above is Brndle-specific evidence inside that same framework.

Accessibility: what is structural versus what is still unverified

Lighthouse’s accessibility category runs a set of automated axe-core rules – things like button-name, aria-required-attr, aria-valid-attr-value, color-contrast, heading-order, and bypass (the skip-link check) – and explicitly does not catch everything a human accessibility audit would. Here is what the theme’s own documentation confirms against that list, and where it stops:

Confirmed: the theme’s FAQ block is documented as “Accessible accordion FAQ with ARIA attributes” that also emits FAQPage JSON-LD. An accordion that correctly manages aria-expanded state on its trigger and associates the trigger with its panel is exactly the pattern aria-required-attr and aria-valid-attr-value check for. We have the documented claim; we did not have a running install to click through and confirm the attribute values update correctly at runtime.
Confirmed: the lead-capture block is documented as including aria-live status handling for form submission feedback, the pattern that lets a screen reader announce “message sent” without a visual page reload. This is the right pattern; Lighthouse’s automated category does not have a dedicated single audit for form-submission live regions, so this is a case where the theme is doing more than Lighthouse’s own automated check would require, which is a point in its favor that a Lighthouse score alone would never surface.
Partially confirmed, with an explicit limit: the theme’s twelve named color schemes are a closed, auditable set – in principle, someone could run a contrast check against all twelve once and know the result for every site built on the theme. We have not run that check ourselves, and we are not going to claim all twelve schemes pass color-contrast in every text-and-background combination the theme allows without having tested it. We made exactly this caveat about Brndle’s token system in an earlier post – a closed design-token system is “a floor, not a certificate” – and it applies here without modification.
Not covered in the available documentation: skip links, explicit heading-order enforcement across templates, and landmark roles (header, nav, main, footer) are not mentioned in the theme’s README at all. Their absence from the documentation is not the same claim as their absence from the actual Blade templates – plenty of correctly built themes simply don’t advertise basic semantic HTML as a feature – but we did not have template-level source access for this specific piece to confirm either way, so we are listing it as unverified rather than assuming it in Brndle’s favor.

We wrote a full WCAG 2.2 checklist specifically for block theme authors, including failure modes we found in our own themes, in Is Your Block Theme Really Accessible? – the same checklist applies to auditing any claim like this one before trusting it.

Best Practices and SEO: what the theme controls and what it doesn’t

Lighthouse’s Best Practices category checks things like errors-logged-to-console, deprecations (flagging deprecated browser APIs in use), uses-https, and correctly sized/aspect-ratio-safe images. Some of these are genuinely theme-controllable; some are not. A minimal, server-rendered front end with no custom client-side framework gives a theme a reasonable shot at zero console errors and zero deprecated API usage from its own code, which is plausible given Brndle’s documented “minimal JS” structure – but uses-https is entirely a hosting decision, and image aspect-ratio and sizing depend on what a site owner actually uploads, not on anything the theme enforces at upload time, as far as its documentation states.

SEO is where the theme’s integrations are most explicit: the repository documents “built-in support for Yoast SEO / RankMath – breadcrumbs, fallback JSON-LD schema.” That maps to real Lighthouse SEO audits like document-title and meta-description, which check that a title and description tag exist and are non-empty – something an SEO plugin integration is specifically built to guarantee rather than leave to a content editor’s memory. One nuance worth being precise about: Lighthouse’s SEO category no longer runs an automated “structured data is valid” check in current versions; validating JSON-LD is listed there as a manual check, not something the 0–100 score reflects automatically. So the FAQ block’s FAQPage schema is real, documented, and relevant to whether Google can show a rich result – it just isn’t something a Lighthouse SEO score itself would catch missing or broken. We made the identical point about this exact block in an earlier architecture post on this theme: the theme’s job is emitting valid schema, not guaranteeing a result, because the result depends on Google’s own ranking systems.

What this means for an actual client site

No. A theme cannot promise a 100 on every site built with it, and the honest version of “Lighthouse 100” marketing copy would say so. Our own network capture of brndle.com, earlier in this post, is the clearest evidence we have for why: even the team building this theme ships a six-request chat widget, a tag manager, an analytics beacon, and a cross-domain embed on their own front page. None of that is Brndle’s fault – brndle.com is not running the theme – but it is precisely the category of addition that determines a real client site’s score in week two of a launch, after the agency that built it has moved on.

Concretely, here is what erodes a high starting ceiling on a real Brndle-powered client site, roughly in order of how often we see each one in practice:

Full-resolution uploaded images. A theme can lazy-load and can serve WebP if its media pipeline supports it, but it cannot force-compress a 6MB camera photo a client drags into the media library unless the theme ships its own enforced image pipeline, which Brndle’s documentation does not claim to do. This is the single most common cause of a blown largest-contentful-paint score on real WordPress sites, regardless of theme.
Third-party scripts added after launch. Chat widgets, Google Analytics or GTM, a Meta pixel, a Hotjar or Clarity session recorder – each one is a plugin or a snippet that runs entirely outside the theme’s registered asset list. A theme has no mechanism to purge, defer, or even see a script a site owner pasted into a “header scripts” field, which is exactly what our own captured waterfall shows happening on the vendor’s own marketing site.
Additional plugins stacked on top of the 18 native blocks. If a client’s page needs something Brndle’s block catalog doesn’t cover – a booking calendar, a specific form plugin with its own validation library, a page builder bolted on for one landing page – each addition brings its own CSS and JS enqueue, outside the theme’s control.
A brand font outside the eight documented pairs. If a client insists on a specific brand typeface loaded from an external CDN instead of one of Brndle’s eight bundled font pairs, the preload and local-hosting advantages the theme’s font handling is built around stop applying to that font.
Hosting. Time to first byte, server response time, and the presence or absence of a page cache are entirely a hosting decision. A lean, server-rendered theme on slow shared hosting will still show a slow server-response-time audit; no front-end architecture fixes a backend problem.

None of this is specific to Brndle. It is true of every theme marketed as fast, because a Lighthouse score measures a specific page as deployed, not a theme in the abstract. What a theme’s architecture actually controls is the ceiling – how high a score is reachable before anything else gets added – and the mechanisms documented and partially confirmed above (server-rendered blocks, a closed and purge-friendly utility CSS vocabulary, a lazy-loading toggle, structural ARIA on specific blocks, SEO-plugin integration) genuinely put that ceiling in a good place. Whether any specific client site stays there is a decision made by everyone who touches the site after the theme is installed, which is the actual, less quotable truth behind every “100 Lighthouse” theme tagline on the internet, including the one on this blog’s own homepage.

Questions people ask

Did you actually get a Lighthouse score for brndle.com?

No. The public PageSpeed Insights API returned an HTTP 429 quota-exceeded error both times we tried it on October 30, 2026, and we chose not to keep retrying until it happened to succeed. No performance, accessibility, best-practices, or SEO number for brndle.com appears anywhere in this post.

Why not just run a Lighthouse audit from a browser’s own DevTools panel instead of the API?

Because the practical difference is smaller than it looks. A DevTools Lighthouse run uses the same underlying Lighthouse engine and the same scoring curve as the API; our available browser automation for this research did not expose a packaged Lighthouse report export, and estimating a 0–100 score by eyeballing a raw performance trace would mean presenting a guess with a number attached, which is worse than stating plainly that we don’t have one.

Is brndle.com actually running the Brndle WordPress theme?

No. Its own first-party asset paths (/_astro/Layout.CqEKD6xw.css, for example) show it is built on the Astro static site framework, not deployed as a WordPress install running this theme. It is the project’s marketing and documentation site, not a live demo of the product.

Where does the “0 KB JS” figure in Brndle’s own documentation actually come from?

It appears in the theme’s repository documentation as example copy describing what a site owner could type into the theme’s own stats block feature – the documentation literally lists “100 Lighthouse Score” and “0 KB JS” as sample text for that block, not as a measured specification of Brndle’s own compiled build output. The standalone “Lighthouse 100” tagline on the site itself is a separate, real claim – it just isn’t one we were able to independently verify either.

Was there a public demo of the actual theme you could have tested?

No. We checked the GitHub repository’s README for a demo link and found none, and checked the WordPress.org theme directory on the chance it was dual-listed there with a reviewer-hosted preview; that URL returns a 404. The theme ships only as a GitHub-hosted, pre-built ZIP.

What’s the single biggest performance risk on a real Brndle client site?

Based on what we measured on the vendor’s own marketing site – a chat widget, a tag manager, an analytics beacon, and a cross-domain embed, six-plus requests total for features with no connection to the theme itself – third-party scripts added after launch are the most likely thing to erode a high starting score, because a theme has no mechanism to see or defer a script a site owner adds independently.

Does the theme’s lack of a WordPress.org listing matter?

It cuts both ways. It means there was no Theme Review Team gate forcing a lean functions.php and no mystery script enqueues before release, which can reflect either tighter internal discipline or simply the absence of an outside check. We have no way to tell which from the outside, and we are not treating the absence of a listing as evidence of quality in either direction.

Does a closed set of twelve color schemes guarantee every one passes a contrast check?

No, and we are not claiming it does. A closed palette makes a contrast audit possible to run once and know the answer for every site using a given scheme; it does not substitute for actually running that audit. We described this exact tradeoff in an earlier post about the same token system: it is a floor, not a certificate.

Can someone verify these claims themselves instead of trusting this post?

Yes, and that is the point of being specific about methodology above. Clone the repository, build the theme following its own documented process, install it on a clean WordPress site with a known host, and run PageSpeed Insights or a local Lighthouse CI run against it directly. Any vendor’s unmoderated screenshot – including the tagline on this theme’s own homepage, and including this post’s architectural claims where we flagged them as unverified – should be treated as a starting hypothesis until someone has independently re-run it.

Will this post be followed up with real, dated numbers later?

That would be the natural next step: a follow-up that successfully captures a live, dated, URL-attached Lighthouse run against an actual Brndle-powered WordPress install, once a quota allows it or a demo install exists to point a test at. That follow-up should carry more weight than this one specifically, for the simple reason that it would have a number this one does not.

The takeaway

We set out to turn a marketing tagline into evidence and ran into the two problems that make most “100 Lighthouse” claims unverifiable in the first place: a quota wall on the tool that would normally supply the number, and a test subject – the vendor’s own site – that turned out not to be the product at all. Rather than paper over either problem with an invented score, we are reporting both, along with the real network waterfall we did capture and the specific, source-confirmed architecture decisions that explain why the underlying claim is plausible. Server-rendered blocks with no client-side hydration, a closed and purge-friendly Tailwind vocabulary, a documented lazy-loading toggle, structural ARIA and schema on specific blocks, and built-in SEO-plugin integration are real things we could point to in the theme’s own source. A verified, dated, 0–100 number for a specific page is not one of them, and anyone telling you otherwise – about this theme or any other – should be asked for the URL, the date, and the page weight before you believe it.

Reaching Lighthouse 100 on a Real Client Site: A Brndle Case Study