I wasn't grading design or page speed. I was looking for one kind of problem only: the kind that loses a customer today. Someone already found the business, clicked through, and hit a wall.

The first pass flagged 200 sites. I checked every one of them again by a different route, and for sites that looked down, from three monitoring nodes inside the country, because some sites block foreign traffic. 156 held up. Then I removed subdomains of big chains and landing pages that hide from search on purpose. That left 125 company main sites with a real, working-hours problem. About 1 in 36.

Hidden from search: 36 sites

The site works, the owner opens it every day, and search engines are told not to show it. Either the home page carries a noindex tag, or robots.txt says this:

User-agent: *
Disallow: /

This is almost always left over from development. A developer closes the site from search while it's being built, launches it, and forgets to open it again. Of the cases I looked at closely, about 6 in 10 were robots.txt and the rest were a meta tag or an X-Robots-Tag header.

The owner has no reason to notice. They reach the site from a bookmark or by typing the address. New customers searching for the service never see it.

The site doesn't open: 31 sites

Server errors, a domain that no longer resolves, or a timeout, on every version of the address: with and without www, http and https. Directory listings, maps and old ads keep sending people there. If you pay for a listing or for clicks, you're paying for visits that end on an error page.

The phone link goes to a 404: 27 sites

This one surprised me the most. On a phone, the most valuable thing on a small-business site is the number you can tap to call. On 27 sites the tap opens "page not found" instead of the dialer. The link looks like this:

<a href="/+15550100">+1 555-0100</a>

instead of this:

<a href="tel:+15550100">+1 555-0100</a>

Without the tel: prefix the browser treats the number as a page on the site, and that page doesn't exist. It is easy to do in a site builder, when someone pastes the number into a link field. On a desktop nobody clicks the number, so the owner never sees it break.

Domain expired, parked or for sale: 23 sites

Instead of the site there's a hosting placeholder: "domain expired", "account suspended", "this domain is for sale". Business cards, signs and directory listings still point to it. Every customer who types the address sees a business that looks closed, and if the domain stays unpaid long enough, someone else can buy it.

Certificate warning: 7 sites

Expired, issued for a different domain, or self-signed. The browser shows a full-page warning before the site, and most people close the tab right there. Certificates are free now and renew on their own when set up properly, so this is usually a renewal that silently stopped working.

A form that sends without https: 1 site

One contact form on an https site sent requests to a bare IP address over plain http. Chrome warns the visitor that the form isn't secure as they submit it, and many people stop right there. Only one in this run, but it sits exactly where a customer is already writing to you.

Why owners don't see this

None of these problems break loudly. The site looks fine from the office computer, from the bookmark, on a desktop. The phone link only fails on a phone. The search block only shows in search. The expired domain is noticed when calls drop, and by then it's been weeks.

That's also why I didn't count slow pages, missing mobile versions or certificates that expire next week. Those matter, but they aren't losing anyone a customer today.

How the check worked

At most 5 requests per site, 2 on average: robots.txt, the home page, up to three variants of the address, or the link behind the phone number. At least one second between requests to the same site, a 10-second timeout, 16 sites at a time, and robots.txt rules respected. A problem only counted after the second check confirmed it.

Check your own site in a minute

You can do the most important part by hand:

1. Open yoursite.com/robots.txt. If you see Disallow: / with nothing else allowed, your site is hidden from search.
2. Open the site on your phone and tap your phone number. It should open the dialer.
3. Open the address with and without www, and with http and https. All four should land on the same working page without a warning.
4. Look up when your domain and hosting expire, and turn on auto-renewal.
5. Send yourself a message through your own contact form.

Or paste your address into the free check I made: https://gad-production.ru/proverka/en/. It goes through up to 25 pages, shows hidden pages, broken links, phone numbers that can't be tapped, missing https redirects and the rest, and it doesn't store your address. No sign-up.

If it finds something and you'd rather not fix it yourself, message me on Telegram https://t.me/smirnovarturr or email paladei702@gmail.com. Artur Smirnov, g.a.d.

This is a concept site for a jewellery brand. It shows one engagement ring, a one-carat round brilliant on a gold band, and there is no photo anywhere on the page. The ring is geometry and shaders: you can drag it, scroll through it, take it apart, change the metal, the cut and the carat weight, and the price follows.

It's one index.html: three.js 0.170 and Lenis from a CDN, no build step, no model files, no image textures. The stone, the band, the claws and the studio light are generated in code when the page opens.

Live: https://smirnov-artur.github.io/demo/gad-ring/

The stone is real geometry

Most web diamonds are a glass material on a low-poly mesh, and they look like glass. A diamond gets its look from proportions: light enters through the top, bounces off the angled pavilion facets and comes back out the top. Get the angles wrong and the light leaks out the bottom, and the stone goes dark. So I started from the numbers a cutter works with:

// round brilliant, girdle diameter 1: table 56 %, crown 34.5°, pavilion 40.75°, star 50 %, lower girdle 77 %
const P = [], R = .5, rt = .28, gt = .011, c8 = Math.cos(Math.PI / 8);
const hc = gt + (R - rt) * Math.tan(34.5 * DEG), hp = gt + R * Math.tan(40.75 * DEG);

From these the function places the table corners, star points, lower girdle points and the culet, and hands them to ConvexGeometry. Two details took longer than everything else. The star points are computed so every kite facet stays flat. And the girdle has 32 points, every second of which sits on its facet plane, so the girdle edge scallops like a real one instead of being a clean circle. Total depth comes out at 60.4 %, inside the range cutters aim for.

After the hull is built, its triangles are merged back into facet planes: same normal, same offset, one plane. The round brilliant ends up with 89 of them, the classic 57 facets plus 32 girdle faces. The oval is the same points stretched 0.82 × 1.24, and the princess has its own point list with a step crown and a chevron pavilion.

Tracing light inside the stone

The planes go into the shader as a vec4 uniform array, normal and distance. The stone is convex, and that makes tracing cheap: from any point inside, the facet the ray exits through is simply the nearest plane in front of it. No BVH, no triangle tests, one loop over planes. Slightly trimmed:

for (int b = 0; b < BOUNCE; b++) {
  float tm = 1e5; vec3 nh = vec3(0., 1., 0.);
  for (int i = 0; i < MAXP; i++) {    // the stone is convex: nearest facet plane ahead is the exit
    if (i >= np) break;
    vec4 pl = planes[i]; float dn = dot(pl.xyz, d);
    if (dn > 1e-5) { float t = (pl.w - dot(pl.xyz, p)) / dn; if (t < tm) { tm = t; nh = pl.xyz; } }
  }
  p += d * tm;
  float c = dot(d, nh), s2 = ior * ior * (1. - c * c);
  vec3 rf = reflect(d, -nh);
  if (s2 < 1.) {                      // not total internal reflection: some light leaves here
    float Fo = fres(sqrt(1. - s2), r0);
    vec3 dr = refract(d, -nh, iv.r), dg = refract(d, -nh, iv.g), db = refract(d, -nh, iv.b);
    // ...one environment lookup per channel...
    col += thr * (1. - Fo) * o;
    thr *= Fo;
  }
  d = rf;
}

Per pixel it goes like this. On the surface, Schlick's Fresnel with IOR 2.42 gives about 17 % reflection head-on: that's the polish on the facet. The rest refracts inside. At every wall the shader checks for total internal reflection, and with an IOR that high the critical angle is only about 24°, so most rays bounce. Where light does get out, it is refracted three times, once per colour channel, with IORs of 2.375, 2.42 and 2.4875. Red bends least, blue most, and that split is the fire, the coloured flashes. The spread is wider than a real diamond's: at the size a stone takes on screen, the physical value barely shows. The reflected part goes on to the next bounce, 7 of them on desktop and 4 on phones.

All of it runs in the stone's own object space. Each frame, onBeforeRender moves the camera position into the gem's local space and builds one matrix, the environment rotation times the gem's rotation with scale removed, so the 89 planes never get transformed.

What the stone reflects matters as much as the tracing. The environment is a small scene built in code: a dark dome, long softboxes for the metal, a lime kicker in the brand colour and 64 small hard "pin lights" with intensities up to 15. The metal gets that scene through PMREMGenerator, which prefilters and slightly softens it. The stone samples an unfiltered 512 px half-float cube map of the same scene (256 px on phones), because softening would wash out the pin lights, and pin lights are what a diamond breaks into sparkle. The studio turns slowly with scroll, time and the cursor, so the facets keep flashing even when the ring stands still.

On top sits one extra draw call: a point sprite on each of the 32 crown facets. Its vertex shader mirrors the view direction off the facet, looks up the same environment and only lights up when that reflection hits something bright. The fragment shader draws a small four-armed star, the glint a photographer gets from a hard light.

Metal: platinum is not white gold

The metal is a stock MeshPhysicalMaterial with metalness: 1 and three presets:

const METALS = [
  { color: 0xffc766, rough: .09, base: 690 },   // 18k yellow gold
  { color: 0xf7b196, rough: .09, base: 690 },   // 18k rose gold
  { color: 0xd9dbde, rough: .07, base: 1090 },  // platinum 950
];

The third is platinum 950, not white gold, and the ring knows it. Inside the band there's an engraving (the brand, a hallmark and "N°03 · 1/1") drawn on a canvas and used as an alpha map on a thin strip that follows the inner surface. The hallmark reads "750 · AU" for both golds and "PT 950" for platinum, and the texture is rebuilt only when the hallmark actually changes. Switching metals blends colour and roughness over 0.8 s instead of snapping.

The band is a cross-section swept around the finger: flat outside, slightly domed inside like a comfort-fit band, wider and thicker under the stone. Each claw is a TubeGeometry along a Catmull-Rom curve from the collar up the pavilion, over the girdle and onto the crown: six for round and oval, four for princess. The princess gallery rail is a TorusGeometry with four radial segments, which is to say a square.

Configurator and price

Price is metal plus stone:

const stone = 5600 * Math.pow(cfg.ct, 1.85) * SHAPES[cfg.shape].k, base = METALS[cfg.metal].base;

The exponent is the point. Diamond prices grow faster than weight, so a 2 ct stone costs about 3.6 times a 1 ct one, not twice. An oval is 0.92 of a round's price, a princess 0.8. A 1.00 ct round in yellow gold shows $6,290, split as "setting $690 · stone $5,600". The number goes through Intl.NumberFormat with rounding to a step, and the Russian version of the page swaps only a small block of words, currency and rate.

The carat slider scales the whole head by 0.76 · ∛ct, because weight follows volume and diameter follows its cube root: a 1 ct round is 6.5 mm across, a 2 ct is 8.2 mm, not 13. Changing the cut shrinks the stone away, rebuilds the geometry at the halfway point and grows it back, so nothing pops.

The film on scroll

There's no timeline library. Each section has a pose for the ring: position, scale, three rotations, an explode value, a pivot and a spin speed, with a separate set for phones. layout() reads the real section offsets from the DOM and pins the poses to scroll positions, and between two keys the pose is eased. On top of that, every frame the current pose chases the target by 1 − exp(−dt·7), so the motion is the same at 60 Hz and 144 Hz.

The pivot moves the axis the ring turns around. In the stone section it moves up to the diamond, so the close-up stays centred on it while it spins. In the exploded view the stone lifts out and tilts, the claws rotate open around their base, and labels with thin leader lines point to the parts. Their anchors are 3D points projected every frame and stacked into a column so they never overlap. Drag the ring and it keeps turning with inertia, then settles on the nearest full turn.

Performance

Phones (under 760 px wide or with a coarse pointer) get a pixel ratio of 1.5 instead of 2, 4 bounces instead of 7, a 256 px cube map and about half the segments on the band and claws. The expensive shader runs only on pixels the stone covers, but each of them pays 89 plane tests and up to four cube lookups per bounce, which is why the bounce count is the first thing phones lose. renderer.compile() runs before the loader fades, fonts load before the engraving canvas is drawn, and old geometry is disposed of when the cut changes. With prefers-reduced-motion, smooth scrolling is off and idle motion drops to 15 %.

Demo: https://smirnov-artur.github.io/demo/gad-ring/ · More work: https://smirnov-artur.github.io/works/en · I build sites like this for brands — from $290.

LUSTRE is a concept site I made for a car detailing studio. The brand is made up and there is no client behind it; it's a demo of one idea.

Detailing is hard to sell with photos. In a phone-sized picture, swirl marks and haze barely show, and that difference is the whole service. So on this page the visitor does the work: they scroll, and the car goes from hazed to polished, then gets a ceramic coat, then protection film, then a new colour. A light bar follows the cursor, the same way a detailer walks an inspection lamp along a panel to find swirls.

The stack is small: three.js 0.186 and Lenis from a CDN, no build step. One index.html, one app.js of 467 lines, and a 1.6 MB car model.

Live site: https://smirnov-artur.github.io/demo/lustre-detailing/

The car and the studio

The car is ferrari.glb from the three.js examples ("Ferrari 458 Italia" by vicent091036, CC BY 4.0), Draco-compressed. All the materials are replaced after loading: the loader walks the scene, gives the body mesh my own paint material, turns rims and trim into dark metal and darkens the interior. The brand on the site is fictional, so the badges are cut out right in the chrome shader with a discard inside two small world-space boxes.

The studio around it is a hexagonal LED ceiling, like the ones in real detailing bays. It's 53 cells drawn as one InstancedMesh, so the whole ceiling is a single draw call. Each cell has an aOn attribute, and on load the cells switch on from the centre outwards with a short flicker, like fluorescent tubes warming up.

Reflections come from a second, invisible scene: the same hex grid, two side softboxes, a dark floor and a cylinder wall with a gradient. The bright band in that gradient sits at body height, and it's what draws the long highlight along the sides of the car. That scene is baked once through PMREMGenerator and used as the environment map: 512 px on desktop, 256 on phones.

Scroll drives the camera

There are four service sections (correction, ceramic, film, colour), and each has a camera pose: azimuth, elevation, distance, look-at height and a screen offset that pushes the car left or right to make room for the text card. Keyframes sit at the centre of each section:

const P = POSE[tall ? 'tall' : 'wide'];
let i = 0; while (i < K.length - 2 && ys > K[i + 1]) i++;
const f = sstep(0.2, 0.8, (ys - K[i]) / Math.max(1, K[i + 1] - K[i]));
const a = P[i], b = P[i + 1];
cam.az = mix(a[0], b[0], f); cam.el = mix(a[1], b[1], f); cam.d = mix(a[2], b[2], f);

The sstep(0.2, 0.8, …) is the part that matters. The camera stands still for the first and last 20% of each stretch and only moves in the middle, so it isn't drifting while someone reads a price.

Lenis runs with autoRaf: false and is ticked from the same requestAnimationFrame as the renderer, and the scroll value gets one more exponential smoothing on top (ys += (lenis.animatedScroll - ys) * (1 - Math.exp(-dt * 7))). Portrait screens get their own set of poses: the car stays centred and higher in the frame, and the text card sits at the bottom.

Elevation has a guard, Math.asin((CEIL - 0.8 - cam.ty) / d), so on the steep poses and during the intro zoom-out the camera never rises through the light ceiling.

The inspection light

The light bar is a RectAreaLight, 5 by 0.3 units. It's placed on the camera's side of the car and slides with the cursor:

const auto = t - lastPtr > 2500;
const tx = auto ? Math.sin(T * 0.55) * 0.85 : px, ty = auto ? -0.25 + Math.sin(T * 0.37) * 0.25 : py;
mx += (tx - mx) * (1 - Math.exp(-dt * 3)); my += (ty - my) * (1 - Math.exp(-dt * 3));

If the mouse hasn't moved for 2.5 seconds, the bar sweeps along the body by itself. On phones nobody hovers, so that sweep is mostly what people see there.

Polishing with one shader

This is the main effect. The body uses a MeshPhysicalMaterial with clearcoat, patched through onBeforeCompile. The shader always holds two paint states, A and B, and a wipe position along the car's length (world Z). On one side of the line the shader draws A, on the other B, and scrolling moves the line from one end of the car to the other:

float nw = 1.0 - smoothstep(uWipe - 0.012, uWipe + 0.012, vWP.z);
vec4 pm = mix(uMatA, uMatB, nw); vec2 px = mix(uXA, uXB, nw);
float dirt = px.x * smoothstep(0.3, 0.8, n3(vWP * 2.6) * 0.6 + n3(vWP * 9.0) * 0.4);
diffuseColor.rgb = mix(mix(uColA, uColB, nw), vec3(0.16, 0.16, 0.165), dirt * 0.55);

Each state is a small set of numbers: colour, roughness, metalness, clearcoat, clearcoat roughness, dirt and iridescence. "As it arrived" has roughness 0.6, clearcoat 0.5 and full dirt. "Gloss" is roughness 0.2 with clearcoat 1. "Ceramic 9H" goes down to 0.14 and adds some iridescence. "Stealth film" is a satin 0.5. The dirt is two octaves of 3D value noise in world space: it greys the colour, adds roughness and eats the clearcoat, so the haze sits in patches instead of as a flat filter.

The line itself glows. The emissive term is added right at the wipe position:

float gd = abs(vWP.z - uWipe);
totalEmissiveRadiance += uGlowCol * uGlow * (exp(-gd * 40.0) * 1.6 + exp(-gd * 5.0) * 0.12);

The glow colour tells you which service is running: warm orange for polishing, cyan for ceramic, white for film. Its strength is sin(π·w)^0.4, so it fades in and out at both ends of the pass and doesn't pop.

Before the first pass there's one step without a line: the car gets hazed as a whole, so the visitor sees what "as it arrived" means before the polishing starts.

The colour buttons reuse the same wipe. A click remembers which paint is on the car right now and runs A → B over 1200 ms with a smoothstep curve. The new colour sweeps along the car behind the same glowing line as the polish. There are five colours: liquid chrome, racing green, papaya, Nardo grey and pearl white.

Phones and weak GPUs

The page checks matchMedia('(pointer: coarse)') or a width under 760 px, and phones get a lighter scene:

• pixel ratio capped at 1.5 instead of 2;

• iridescence off;

• environment map at 256 px instead of 512;

• 150 dust particles instead of 380;

• no floor reflection. On desktop the reflection is a cheap trick: a clone of the car flipped with scale.y = -1 under a floor that's 80% opaque. Phones get a solid floor and no second car.

A ?hq parameter forces full quality on a phone, which I use when recording video.

On top of that there's a runtime check for any device:

if (t0 !== null && ti > 1 && ti < 6 && slow < 2) {
  frames = dt > 1 / 42 ? frames + 1 : Math.max(0, frames - 1);
  if (frames > 45) { slow++; frames = 0; dpr = Math.max(TOUCH ? 0.85 : 1, dpr * 0.75); renderer.setPixelRatio(dpr); layout(); }
}

It runs between the first and the sixth second after the intro starts. A frame slower than 1/42 s adds a point, a fast frame takes one away. At 45 points the page renders 25% fewer pixels per side, at most twice. It never goes lower than 0.85 on phones or 1 on desktop.

A few smaller things keep frames even. renderer.compile(scene, camera) runs before the loader fades out, so shaders don't compile on the first scroll. The HUD text and the section rail only touch the DOM when their value actually changes. prefers-reduced-motion removes the slow camera drift and stops the film grain.

Things that went wrong on the way

A few things broke along the way, and the fixes are still visible in the code.

On Windows, Chrome's D3D backend flooded the console with warnings about three.js shader constants. Shader error checking is now on only with ?debug.

The big LUSTRE word behind the car is a canvas texture, and a canvas draws with whatever font is loaded at that moment. So the texture is built right away and again when document.fonts.load reports that Archivo is ready. On tall screens it's rebuilt as two lines, LUS and TRE.

On portrait phones the text cards covered the car while the next section came in. Now a card fades out as its bottom edge leaves the lower part of the screen.

If the phone is too weak even for that

The fallback I'd use is a scroll-scrubbed video of the same camera path. It's cheap to produce here because all animation time comes only from requestAnimationFrame: the page plays the same way in a browser and in a frame-by-frame recording. That's how it can be recorded for video, like this short: https://youtube.com/shorts/-pgQFCKBG0c

Live site: https://smirnov-artur.github.io/demo/lustre-detailing/ · Portfolio: https://smirnov-artur.github.io/works/en · I build 3D sites like this one for businesses, prices here: https://smirnov-artur.github.io/works/pricing/