DEV Community: Dominik

Why your three.js scene gets a bad PageSpeed score (and it is not JavaScript)

Dominik — Mon, 28 Sep 2026 07:51:18 +0000

Originally published on grodev.pl.

Your 3D scene runs smoothly on your machine. Sixty frames, no jank. You drop the page into PageSpeed Insights and get a 48. Total Blocking Time is red, and the main-thread breakdown shows one long task blamed on gsap.min.js. The first instinct is "too much JavaScript" or "too many particles". Both are almost always wrong, and chasing them can eat a whole day.

This post is the diagnosis, not the recipe. I will show you why a heavy three.js scene scores badly in PageSpeed and where the cost really sits.

PageSpeed has no GPU

This is the key that changes everything else, so start here. Google does not measure your page on a graphics card. Lighthouse and PageSpeed run headless Chrome where WebGL goes through software rendering on the CPU (SwiftShader). Your scene, which takes a fraction of a millisecond on your GPU, runs on the CPU on Google's machine.

You can confirm it with one read of the renderer name. If WEBGL_debug_renderer_info returns swiftshader, llvmpipe, softpipe or software, you are in that mode. Real users on virtual machines and weak hardware get the same. As long as you measure on your own card, you are not seeing what Google sees.

Why it is not JavaScript

In the main-thread breakdown you look at categories: "Script Evaluation", "Style & Layout", "Other". With a heavy WebGL scene, "Other" can be bigger than "Script Evaluation". That is not a bucket to ignore. Other is usually the GPU work and pixel scans, which a script profile does not show at all.

Then there is the misleading label. A long task tagged gsap.min.js or requestAnimationFrame is usually not GSAP. In one frame, every requestAnimationFrame call lands in a single task that takes the label of whoever started it. The GSAP ticker registers first, so it takes the blame for someone else's work. Optimizing GSAP here is aiming at the wrong target.

The first frame is the most expensive frame

A scene usually draws one frame on start and then waits for the user to move. Google's measurement does not move the mouse, so it sees exactly that one frame. And that one frame compiles every shader program at once.

On one of my production builds the scene had fourteen programs: particles, arcs, several bloom layers, composite, output. Each compiled in the first frame, and after every compile the library asked the card for the result. Every such query waits until the card has worked through its whole command queue. The result: one 656 ms task on Google's machine and a score of 73 on desktop. Total Blocking Time sat around 700 ms. None of it was JavaScript in the sense most guides mean.

Cutting particles does not help, and it ruins mobile

The most common reflex is to lower the particle count "for performance". That misreads the problem on two levels.

First, particles are cheap. A point is one vertex. What is expensive is fill: bloom, transparency, overdraw, not the number of points. Cut the particles and you cut the cheap resource while leaving the expensive one untouched.

Second, an image made of particles has a resolution equal to their count. Text built from ten thousand particles looks different from the same text built from seventy thousand. When you give the phone ten times fewer particles "to make it lighter", the text goes blurry or sparse, and you still have not touched the real cost. On one build I raised the phone particle count from seven thousand to seventy-two thousand and the text finally looked sharp, while the score did not drop, because the problem was never the point count.

How to measure without chasing noise

Before you fix anything, you need a measurement that does not lie. Here are the three traps almost everyone falls into.

What you do	Why it lies	What to do instead
Profile in DevTools on your own GPU	The second load has the programs cached on disk, the compilation disappears	A fresh profile with no cache, software rendering (`--disable-gpu`)
A single PageSpeed run	Noise of 7 to 10 points, the same file gives 80 and 95	Median of three, a 7-point significance threshold
Looking at categories instead of tasks	"Other" tells you nothing about the cause	Read the list of long tasks with their start times

The rule is simple. Measure in Google's conditions, not on your card. Read specific tasks, not categories. Treat a change smaller than seven points as chance, not success. Only with a measurement like that does it make sense to touch the scene.

What to do about it

The fix exists and it is repeatable. In short: the first frame must not compile programs, so you compile them ahead of time and warm them up in the background, in the right render conditions. Pixel loops and scene building cannot sit in one task at load. The phone gets the same particle count, only the shots without text are lighter. On the same build where I started at 73, I ended at 97 on desktop, with Total Blocking Time cut from 700 to 140 ms and the first frame from 656 ms to a few milliseconds, with no change to how the scene looks.

I packaged the full method, with copy-ready code, a measurement protocol and a PageSpeed script, as a ready-made skill for developers and coding agents. If you would rather hand the work to me, send the scene URL and I will tell you plainly where the cost sits and how much I will take off.

FAQ

Does a bad PageSpeed score on a WebGL scene hurt my Google ranking?
Google ranks mostly on field data from real users (Core Web Vitals: LCP, CLS, INP), not on the lab score. A <canvas> is not an LCP candidate, so a WebGL scene does not hurt LCP. It does hurt Total Blocking Time, a lab metric, and real INP if the scene blocks the thread during interaction. Worth fixing for the user and the score, without panic that one red lab number sinks the page.

Why is the long task labelled GSAP when I barely use GSAP?
Because a long task label points to the script that started it, not the one that did the work. All requestAnimationFrame calls in a frame go in one task and take the name of the first. The GSAP ticker registers early, so it takes the blame. The real weight is usually shader compilation in the first frame. Do not optimize GSAP on that basis.

Can I just move the scene to a Web Worker or OffscreenCanvas?
Usually not, and usually not as the first move. A Web Worker is a day of work, while the problem is most often solved by task ordering and compiling programs ahead of time, a change of a few hours. Reach for a Worker when you genuinely have heavy CPU work in the render loop, not to hide shader compilation from the measurement.

Can it be fixed without changing how the scene looks?
Yes, and that is the whole point. The method keeps the desktop image untouched to the percent, and the phone just as sharp, only smaller. It is about order and the way things are drawn, when programs compile and what sits in the first frame, not about cutting graphics.

Server-side pricing in Three.js configurators - why client-side gets DevTools-hacked

Dominik — Fri, 04 Sep 2026 17:52:51 +0000

The setup that looks fine

You build a 3D product configurator in Three.js. User picks material, size, options - and next to the model, a live price updates as they configure. The frontend calculates it because that is fast, feels responsive, and does not need a network trip.

The code looks like this:

function calculatePrice(config) {
  let price = BASE_PRICE;
  price += MATERIAL_PRICING[config.material];
  price += config.width * config.height * PER_SQ_METER;
  return price;
}

// Live update on any config change
someSlider.addEventListener('input', () => {
  state.config = readConfig();
  state.price = calculatePrice(state.config);
  updatePriceDisplay(state.price);
});

// On order submission, send the whole state
function submitOrder() {
  fetch('/api/orders', {
    method: 'POST',
    body: JSON.stringify(state)
  });
}

This is what most tutorials show. It is also what I shipped in my first configurator.

The obvious problem I missed

A user opens DevTools. window.state.price = 1. Clicks 'Buy'. Order goes to my backend with price = 1. Backend has no independent pricing logic - it trusts what the frontend sends.

This is not paranoia. This is a 5-second exploit that anyone with basic browser knowledge can do. I caught it because a friend I asked to test the configurator did exactly this within 20 seconds of opening the page.

The fix that is actually secure

Separate two responsibilities:

Frontend: preview the price. This is UX, not truth.
Backend: calculate the final price from raw config, independently. This is truth.

// Frontend - preview only
function previewPrice(config) {
  // Same math as before, but purely for display
  // Explicitly labeled 'estimate' in UI
}

function submitOrder() {
  fetch('/api/orders', {
    method: 'POST',
    body: JSON.stringify({ config: state.config }) // No price sent
  });
}

// Backend - authoritative
function calculateFinalPrice(array $config): float {
  $price = self::BASE_PRICE;
  $price += self::MATERIAL_PRICING[$config['material']] ?? throw new \InvalidArgumentException();
  $price += $config['width'] * $config['height'] * self::PER_SQ_METER;
  return $price;
}

Frontend never sends price. Backend never trusts frontend price. If someone hacks the DevTools price display, they only change what they see - the order still calculates correctly server-side.

The 'but performance' objection

One network trip per configuration change would kill UX. So do not do that. Frontend preview stays instant (client-side math), but is labeled 'preview' or 'estimate'. Backend calculation happens ONCE, at order submission. User never waits during configuration.

Add a 'Confirm order' step where the real price is fetched from backend and displayed for confirmation - so there is no surprise between what they saw and what they pay. This is the pattern Bagisto, Shopify custom apps and Zakeke all use.

The gotcha with variant validation

Same principle applies to configuration validity. Frontend might allow user to set impossible combinations (glass thickness 20mm with hinge type 'lightweight'). Backend must validate independently and reject.

I keep validation logic in a shared JSON schema (JSON Schema draft-07) that both frontend and backend read. Frontend uses it for real-time feedback. Backend uses it as the final gate.

{
  "if": { "properties": { "thickness": { "minimum": 15 } } },
  "then": { "properties": { "hinge": { "enum": ["heavy-duty"] } } }
}

One source of truth. Both sides read it. Backend is authoritative on submission.

Reference implementation

My starter threejs-product-configurator-starter has the frontend preview pattern wired in. Backend calculator is not in the starter (it is deliberately frontend-only for education), but the client-side code is structured so that adding server-side pricing later is a one-file change.

The pricing question is one of five I hit building configurators. The full list is in my 4programmers.net Polish-language thread - WebGL context leaks, material vs new material for color changes, pixel ratio caps for 4K, OrbitControls vs TrackballControls for touch. Different post, same theme: things Three.js tutorials skip.

I am Dominik Groński / GroDev - a new studio in Poznań, Poland (JDG since May 2026), building custom 3D configurators and Laravel panels for manufacturers. Available for first paid deployments.

How I built @grodev/claude-chat-react — architecture notes

Dominik — Tue, 18 Aug 2026 12:59:38 +0000

TL;DR

A drop-in React chat widget on the Claude API — @grodev/claude-chat-react — with a headless hook (useClaudeStream) if you want to bring your own UI, or a <ClaudeChat/> component if you don't. 8 KB gzipped, zero runtime deps beyond React. Companion project to my vanilla-JS widget — same wire contract, same PHP proxy, different frontend stack.

This is a notes-from-the-build post: three decisions that shaped the API, and one thing I audited line-by-line because I don't trust the model with it.

Decision 1: Two ways in, not one

Every React library eventually gets asked "can I use just the state, not the UI?" — so I built both from day one:

// Drop-in — 5 lines
import { ClaudeChat } from '@grodev/claude-chat-react';
<ClaudeChat endpoint="/api/chat" accentColor="#1D9E75" />

// Headless — bring your own UI
import { useClaudeStream } from '@grodev/claude-chat-react';
const { messages, status, sendMessage } = useClaudeStream({ endpoint: '/api/chat' });

The hook does the streaming, state, and abort control; the component adds layout, dark mode, and a11y on top. Consumers who need a different look pay zero cost — they import only the hook and ~2 KB drops out of the bundle.

Decision 2: The API key never touches the browser (and I mean never)

Central design choice — the widget calls your server-side proxy, never api.anthropic.com directly. If you look at the source, there is no place where you can accidentally pass an API key as a prop. It's not in the type definitions. It's not a hidden config. The escape hatch does not exist.

This is the boring kind of security: not a validator that checks for keys, but an API shape where the wrong pattern isn't representable. Companion repo claude-chat-widget ships a working PHP proxy with the exact wire contract this library expects — copy it, deploy anywhere PHP runs, done.

Decision 3: Streaming with a real abort

The streaming loop looks like a hundred other SSE readers on GitHub. Three things I got specifically right:

AbortController lives in useRef, not useState. State would re-render every send, and downstream components would blink.
setMessages((prev) => ...) — never closure-based. Tokens arriving during a re-render need current state, not stale state, or you'll see torn text.
if (payload.error) throw — routes upstream errors through the same catch, so onError fires once with a real Error, not on each malformed frame.

The a11y I refuse to leave to Claude

When I let the model draft the JSX, it produced a working panel. It also produced a working panel without any of these:

role="dialog" on the panel
aria-live="polite" on the message log
aria-expanded on the launcher
Focus management (input focus on panel open, escape close)
Enter sends, Shift+Enter inserts a newline

Every one of these is in the final code. Every one was added by me after the draft, not before. LLMs don't skip a11y out of malice — they skip it because most tutorial code they trained on skipped it. If you don't audit specifically for the boring accessibility bits, you don't get them.

That pattern generalizes: audit the AI's work for what the training data underrepresents, not for what the model gets "wrong."

What's not in the package

Deliberately out of scope, documented in the README:

Rate limiting → add on your proxy
Retrieval-augmented context → your job; feed the system prompt from your data
Session persistence → the hook exposes messages, you decide where to store

Each of those turns a demo into a product, and each one is where your particular use case matters more than a shared abstraction.

Full write-up

Project decisions, human-vs-AI split, and the security checklist I run before every proxy change are in CLAUDE.md in the repo. Or the broader post about how I document AI-first workflow across all six of my repos.

I'm Dominik Groński / GroDev — a new studio in Poznań, Poland (JDG since May 2026), available for first paid deployments. This library is MIT.

How I document my AI-first workflow in every public repo

Dominik — Wed, 12 Aug 2026 06:10:46 +0000

TL;DR

In every one of my public repos I keep three artifacts that make my AI-first workflow visible from the file tree, not just claimed in a README:

CLAUDE.md — a literal table of "who did what" (human vs AI) per layer of the project, plus a list of things I rejected from the AI's draft, plus "known gotchas for the next AI pass."
.claude/commands/ — one slash command per repo, tuned to the most expensive failure mode (security review, math invariants, WebGL disposal, hook chain audit, React contract).
For one representative repo — a full CASE_STUDY.md: 90-minute build retrospective, step by step, threat model → SDK lookup → AI draft → line-by-line audit → hardening → in-browser verification → docs.

Decision authority (architecture, security posture, API contract, cost engineering, what to reject) stays with the human. AI gets boilerplate and first drafts. This post shows the how, with links to five working repos as reference.

Why publish this at all

Because AI-augmented work isn't worth hiding. Developers who cover it up today will be the ones saying "I don't do computers" in two years. Companies hiring devs already write "AI-first (Claude, Copilot, Cursor)" straight into job posts — and they want to see evidence, not statements.

But "evidence of AI-first work" isn't "I have ChatGPT open in a tab." It's artifacts in the file tree. This post shows three concrete ones I've deployed across every public repo I own.

Artifact 1: `CLAUDE.md` with a human/AI split

CLAUDE.md is the file Claude Code reads as project context (analogous to .cursorrules or AGENTS.md). But I use it for two audiences at once:

For the next AI pass — so the model knows what's sacred and what's flexible in this repo.
For humans — so anyone browsing the file tree (a client, a recruiter, a teammate) sees, in black and white: who did what.

The table shape I use in every repo:

Layer	Who did it	Why
Threat model & architecture (proxy, not client-side call)	Human	The whole reason this repo exists. Delegating "should the API key touch the browser?" to an AI is how you ship a leaked-key incident. Not negotiable.
Server-side proxy skeleton	AI-drafted, human-reviewed line by line	Claude wrote the first pass; I audited every line for four things: (1) key never in response headers or logs, (2) `role` validated, not trusted, (3) input length capped, (4) SSE framing correct.
Widget UI (vanilla JS, ~6 KB)	AI-drafted, human-styled	Dependency-free was a hard constraint from me. `textContent` (not `innerHTML`) on user text is mine — XSS prevention isn't a call to leave to the model's discretion.
Prompt caching decision	Human	Cost engineering — the difference between $10/mo and $1/mo of API spend.

Three things make this useful and not fluff:

The "Why" column is the part most people skip. It's also the only place you can tell the author understood why they delegated (or didn't).
A "What I rejected from the AI's draft" section — I write out, in plain text, what Claude proposed, what I refused to merge, and why. This is what separates "I use AI" from "I use AI well." An example from one of my repos:

Rejected two things Claude proposed initially:
(1) logging the request body — would log user PII to a plain file. Removed.
(2) falling back to $_ENV['ANTHROPIC_API_KEY'] if getenv() returned false — unnecessary, and on some hosting stacks it could pick up stale values. Removed.

A "Known gotchas for the next AI pass" section — spots where the next iteration of AI would do something dumb. This protects both me and the model — because Claude reads this file as context, so the next round it won't re-propose an idea that's already been rejected.

Working examples:
CLAUDE.md in claude-chat-widget ·
claude-chat-react ·
booking-slots-php ·
woocommerce-custom-product-data ·
threejs-product-configurator-starter.

Artifact 2: A case study — one build, step by step

CLAUDE.md tells you what someone did. A case study tells you how and in what order. Two different documents, both needed.

The case study I wrote for claude-chat-widget has eight sections, each one concrete step of a 90-minute build:

Threat model and architecture (human, before writing a single line of code)
Looking up the exact SDK shape (human, from the claude-api skill) — because the model's training data may be stale for SDK APIs
AI drafts the proxy skeleton (Claude, ~10 min)
Line-by-line audit + hardening (human, ~20 min) — the most important section
AI drafts the widget (Claude, ~10 min)
Widget audit + hardening (human, ~15 min) — XSS, dark mode, mobile, UX
Verification in a real browser (human, ~10 min)
Documentation (human, ~15 min) — because LLMs write generic READMEs

This format has one unexpected side effect: it forces honesty. When you write "AI wrote 60% of the lines, human made every load-bearing decision" — you have to say which decisions those were. Suddenly it's visible where you actually did the work, versus where you just signed off on a generated file.

Full case study: CASE_STUDY.md.

Artifact 3: `.claude/commands/` — automating the review

Claude Code (and most agents) support slash commands — Markdown files under .claude/commands/ invoked in a session as /name. They load as part of the prompt, so I can save a checklist and pull it up with one word.

Every repo I own has one such file, tuned to the class of failure I most want to catch:

security-review.md (claude-chat-widget) — 6-invariant audit of the proxy's security posture (key only in Anthropic\Client(apiKey:), role validated, length capped, X-Accel-Buffering: no, etc.). Runs before every merge to server/chat.php.
react-security-review.md (claude-chat-react) — 8-invariant audit for the React version (no @anthropic-ai/sdk import in src/, no dangerouslySetInnerHTML, setMessages(prev => ...) never closure-based, AbortController in a ref not state, react in peerDependencies, a11y attributes preserved).
verify-slot-math.md (booking-slots-php) — audit of the overlap math (half-open intervals [start, end), < not <=, symmetric buffer). Because booking bugs come from off-by-one errors right there.
hook-audit.md (woocommerce-custom-product-data) — audit of the three-hook WooCommerce chain.
webgl-review.md (threejs-product-configurator-starter) — geometry disposal (so WebGL doesn't leak) and "no build step" invariant (so nobody sneaks Vite in).

The effect: repeatable code review that doesn't depend on my discipline on a given day. Instead of remembering all six points every time I touch the proxy, I type /security-review and get the checklist.

Why these three artifacts

Because they cover the three levels of question anyone evaluating your AI-first work actually asks:

Question	The artifact that answers it
"What specifically did you do vs the AI?"	`CLAUDE.md` — one-screen table
"What does your process look like — order of decisions, what you reject from AI drafts?"	`CASE_STUDY.md` — one build retrospective
"Can you configure agents, or do you just type in a chat?"	`.claude/commands/` — config tuned to a specific failure class

A recruiter reviewing 40 GitHub profiles a week isn't going to read your code. They are going to scan your file tree. If they see CLAUDE.md, CASE_STUDY.md, and .claude/commands/ there — they immediately know they're looking at someone who actually practices the workflow, not someone who put it in their CV.

The philosophy I'm trying to make routine

AI is a fast typist and a reasonable reviewer. Decision authority — architecture, threat model, validation strategy, dependency selection, what to reject — stays with the human. When I hand decision authority to a model, I get a repo that lints clean and blows up in production.

This philosophy works well enough that I shipped 5 working public repos (a WordPress plugin, a PHP booking-slots engine, a Three.js configurator starter, a vanilla-JS chat widget, and a React chat widget on Claude API) — each with a full CLAUDE.md, docs, badges, and a pinned v1.0.0 release. Every load-bearing decision documented, every AI draft audited before merge.

Full profile: github.com/GronskiDeveloper. Fork any repo and check what CLAUDE.md looks like in practice.

I build websites, e-commerce, custom 3D configurators and AI assistants — see grodev.pl or grodev.pl/ai. Poznań, Poland, remote across PL and EU.

Building a 3D Product Configurator in Three.js — Lessons From 9 Client Deployments

Dominik — Wed, 05 Aug 2026 06:47:15 +0000

Over the last year I shipped 9 production 3D configurators for polish manufacturers — pools, garage doors, saunas, pergolas, greenhouses, packaging, decorative lamps, terrace roofs, and light-boxes. Each one runs live on its own subdomain of my studio at grodev.pl.

Some of the lessons were obvious in hindsight. Some cost me a weekend of debugging. Sharing the non-obvious ones here.

1. Draco compression is not optional for CAD-heavy models

Manufacturers send you STEP or SolidWorks files exported to glTF. Raw output is 40–120 MB per variant. On 4G mobile that's a 20-second load with an empty white canvas.

Draco compression brings that to 2–5 MB with no visible quality loss on product shots:

import { GLTFLoader } from 'three/examples/jsm/loaders/GLTFLoader.js'
import { DRACOLoader } from 'three/examples/jsm/loaders/DRACOLoader.js'

const dracoLoader = new DRACOLoader()
dracoLoader.setDecoderPath('/draco/')  // self-hosted, don't use CDN

const loader = new GLTFLoader()
loader.setDRACOLoader(dracoLoader)

loader.load('/models/pool-3.5m.glb', (gltf) => {
  scene.add(gltf.scene)
})

Self-host the decoder — Google's CDN version added ~600 ms to first paint in my measurements. Copy node_modules/three/examples/jsm/libs/draco/ to your public/ folder.

Tooling: gltf-pipeline -i model.glb -o model.draco.glb --draco.compressionLevel 10

2. Instancing beats individual meshes past ~200 objects

A pergola with 40 louvres × 3 tilt positions × user color picker = 120 meshes updating on every frame. Naive approach tanks FPS to 12 on mid-range phones.

InstancedMesh batches identical geometry into one draw call:

const geo = new THREE.BoxGeometry(1, 0.05, 3)
const mat = new THREE.MeshStandardMaterial()
const louvres = new THREE.InstancedMesh(geo, mat, 40)

const dummy = new THREE.Object3D()
for (let i = 0; i < 40; i++) {
  dummy.position.set(0, 0, i * 0.15)
  dummy.rotation.x = userTilt  // update per frame is fine
  dummy.updateMatrix()
  louvres.setMatrixAt(i, dummy.matrix)
}
louvres.instanceMatrix.needsUpdate = true
scene.add(louvres)

Same for basen tiles, brama slats, sauna wall boards. One material change updates all instances.

3. Ship the price calculator to the server, not the client

Every configurator eventually needs a "Show price" button. Tempting to compute client-side — you already have all the state.

Don't. Manufacturers change prices monthly. Every hardcoded PHP-in-JS multiplication is a redeploy. Also: users open DevTools.

Instead:

// Only what changed goes over the wire
const config = {
  model: 'pool-3.5m',
  finish: 'granite-grey',
  extras: ['lighting', 'cover'],
}

const { price, currency, deliveryWeeks } = await fetch('/api/quote', {
  method: 'POST',
  body: JSON.stringify(config)
}).then(r => r.json())

Server (Laravel in my case) hits a pricing_rules table with monthly-updated coefficients. Client only knows what a valid config looks like, never the pricing logic.

Bonus: the same endpoint powers the "email me a PDF quote" flow. Zero duplication.

4. Mobile is your target device, not a "nice to have"

70% of my configurator traffic is mobile. Sauna buyers browse on the couch, pool buyers browse at the site. Any deployment that assumes desktop-first will feel broken.

Concrete mobile survival kit:

renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2)) — clamping to 2 saves ~40% GPU on retina phones
Detect WEBGL_lose_context and reload cleanly when the browser tab is backgrounded on iOS
Preload one hero material, lazy-load the rest — first paint at 400 ms feels instant even if full swatch library is still coming

5. The integration is 60% of the project

Building the WebGL viewer takes 2–3 weeks. Making it actually feed the manufacturer's WooCommerce / CRM / ERP takes another 4–6 weeks — and the client only sees the shiny part.

Budget accordingly. I now quote 12–55k PLN depending on catalog depth and integration surface, not per screen.

Live examples if you want to see any of these techniques in production:

basen3d.grodev.pl — pool configurator (Draco + PWA)
pergola3d.grodev.pl — bioclimatic pergola (InstancedMesh louvres)
lampy3d.grodev.pl — decorative lamp (white-label)

Full studio at grodev.pl — happy to chat if you're integrating similar for a manufacturer.

What tripped you up on your first Three.js production project? Reply — always curious about other people's disaster stories.

DEV Community: Dominik

Why your three.js scene gets a bad PageSpeed score (and it is not JavaScript)

PageSpeed has no GPU

Why it is not JavaScript

The first frame is the most expensive frame

Cutting particles does not help, and it ruins mobile

How to measure without chasing noise

What to do about it

FAQ

Server-side pricing in Three.js configurators - why client-side gets DevTools-hacked

The setup that looks fine

The obvious problem I missed

The fix that is actually secure

The 'but performance' objection

The gotcha with variant validation

Reference implementation

How I built @grodev/claude-chat-react — architecture notes

TL;DR

Decision 1: Two ways in, not one

Decision 2: The API key never touches the browser (and I mean never)

Decision 3: Streaming with a real abort

The a11y I refuse to leave to Claude

What's not in the package

Full write-up

How I document my AI-first workflow in every public repo

TL;DR

Why publish this at all

Artifact 1: CLAUDE.md with a human/AI split

Artifact 2: A case study — one build, step by step

Artifact 3: .claude/commands/ — automating the review

Why these three artifacts

The philosophy I'm trying to make routine

Building a 3D Product Configurator in Three.js — Lessons From 9 Client Deployments

1. Draco compression is not optional for CAD-heavy models

2. Instancing beats individual meshes past ~200 objects

3. Ship the price calculator to the server, not the client

4. Mobile is your target device, not a "nice to have"

5. The integration is 60% of the project

Artifact 1: `CLAUDE.md` with a human/AI split

Artifact 3: `.claude/commands/` — automating the review