DEV Community: lichongyang130

Your hero background is a JPEG. It could be zero kilobytes.

lichongyang130 — Thu, 24 Sep 2026 06:19:53 +0000

Your hero background is a JPEG. It could be zero kilobytes.

I audited a landing page last month and the heaviest thing on it was not the framework, not the fonts, not the analytics script. It was a 412 KB hero image.

The image was a gradient. A soft purple-to-teal wash with a bit of grain. Someone had built it in a design tool and exported it as a JPEG, because that is how we have always done it.

It was also the LCP element. So the single biggest number on the performance report was a decoration.

The real cost of a background image

A background image is never just a background image. Count what it actually costs you:

One network request on the critical path, before the hero can render.
Multiple exports if you support dark mode, or a second brand colour, or a seasonal campaign.
Multiple resolutions if you care about retina. A 1x and a 2x, at minimum.
A build step nobody remembers to re-run when the brand colour shifts two degrees.
An LCP penalty, because you cannot lazy-load the thing above the fold.

Five costs, zero of which are the gradient itself. The gradient is trivial. Everything around it is the tax.

What CSS gives you for free

Here is an aurora wash in pure CSS. No image, no request, no export step:

.aurora {
  background:
    radial-gradient(60% 80% at 20% 10%, oklch(72% 0.18 300 / 0.55), transparent 70%),
    radial-gradient(50% 70% at 80% 20%, oklch(70% 0.16 200 / 0.50), transparent 70%),
    radial-gradient(70% 60% at 50% 90%, oklch(78% 0.14 160 / 0.40), transparent 70%),
    #0b0b12;
}

That is it. Four layers, a few hundred bytes, and it scales to any viewport without a second export. Change 300 to 320 and you have a new brand direction — in one commit, not one afternoon.

The grain is the part people assume needs an image. It does not:

.grain::after {
  content: "";
  position: absolute;
  inset: 0;
  pointer-events: none;
  opacity: 0.28;
  mix-blend-mode: soft-light;
  background-image: url("data:image/svg+xml,\
<svg xmlns='http://www.w3.org/2000/svg' width='140' height='140'>\
<filter id='n'><feTurbulence type='fractalNoise' baseFrequency='0.9' numOctaves='3'/></filter>\
<rect width='140' height='140' filter='url(%23n)'/></svg>");
}

An inline SVG turbulence filter, URL-encoded into the stylesheet. It is a data URI, so it ships inside the CSS bundle — no extra round trip. The browser generates the noise procedurally.

And glass, which is the one everybody reaches for a PNG to fake:

.glass {
  background: color-mix(in oklab, white 12%, transparent);
  backdrop-filter: blur(18px) saturate(140%);
  border: 1px solid color-mix(in oklab, white 22%, transparent);
}

backdrop-filter is genuinely doing the work here — it samples what is behind the element. A blurred PNG of a blurred background is a snapshot of a moment that stops being true the second anything moves behind it.

The part nobody warns you about

CSS backgrounds are cheap, not free. backdrop-filter and large animated gradients both cost GPU time, and on a low-end Android device a full-viewport animated blur can turn a smooth 60 fps into a stutter.

So the useful mental model is not "CSS good, images bad." It is tiering.

Low tier — static CSS gradients, SVG turbulence, solid fills. Safe everywhere, including old devices.
Mid tier — animated gradients, backdrop-filter, mix-blend-mode. Fine on modern hardware, measurable cost on cheap hardware.
High tier — WebGL / canvas particle fields. Beautiful, and the first thing that should degrade.

The tier is a property of the effect, and it should be documented next to the effect. That is exactly how the background section on Motif UI is organised — each background is labelled with its implementation (Pure CSS, CSS / SVG, CSS / WebGL) and its performance tier, so you can pick with your eyes open instead of discovering the cost in production.

Degrading well

Once you accept tiers, the fallback writes itself. Keep the static gradient as the base layer, and only add the expensive layer when the device can take it:

.motes { background: /* static gradient base */; }

@media (prefers-reduced-motion: no-preference) and (min-width: 768px) {
  .motes::before { animation: drift 24s linear infinite; }
}

Two guards, both free. prefers-reduced-motion handles the users who asked for stillness. The width check is a crude but effective proxy for "probably not a 2016 budget phone."

For the genuinely low-end case, a @supports check on backdrop-filter keeps you honest:

@supports not (backdrop-filter: blur(1px)) {
  .glass { background: rgb(22 22 30 / 0.92); }
}

A near-opaque panel instead of glass. Slightly less pretty, completely legible, and it never causes a repaint storm.

Two accessibility details that bite

Mark decoration as decoration. A purely visual background layer should be aria-hidden="true" if it is an element, and must never be the only carrier of meaning. If your gradient encodes a state — red for error, green for success — that is a text problem, not a background problem.

Check contrast against the worst case, not the average. A gradient means the contrast ratio varies across the panel. Measure your text against the lightest and darkest points the text actually sits on. A wash that passes at the top can fail badly at the bottom corner where the third radial layer lands.

What I would do this week

Open DevTools, filter the network panel by Img, and find the largest image above the fold.
Ask honestly: is this a photograph, or is it a gradient / noise / blur?
If it is the latter, rebuild it as CSS. Keep the image as a <picture> fallback only if you genuinely need one.
Write the tier next to the effect in a comment. Future-you will not remember.

The gradient was never the expensive part. The pipeline around it was.

I keep the ones I actually ship — with their tier labels and audit notes attached — over at Motif UI, if you would rather start from something measured than from a blank stylesheet.

Your animations are fine. Your prefers-reduced-motion handling probably isn't.

lichongyang130 — Tue, 22 Sep 2026 08:08:03 +0000

Your animations are fine. Your prefers-reduced-motion handling probably isn't.

Here's a trap I fell into for years: I did add a reduced-motion block. It was right there at the bottom of my global CSS, three lines long, and I felt good about it. It looked like this:

@media (prefers-reduced-motion: reduce) {
  * { animation: none !important; transition: none !important; }
}

This passes an automated a11y audit. It also breaks your product for the exact people it was written for.

Why the nuclear option backfires

animation: none doesn't "reduce" anything. It deletes the motion — including the motion that carries meaning. Kill that and you get:

Drawers and modals that teleport. A slide-in panel that used to take 240ms now appears instantly in its final position. There's no longer any spatial relationship between where it was and where it went.
Focus loss on scroll-triggered content. A section that faded in on scroll now just doesn't render its transition state — and depending on how you built it, sometimes doesn't render at all.
Skeletons that lie. A pulsing loading skeleton frozen mid-opacity can read as "finished, empty" instead of "still loading."

Reduced motion is not "no motion." It's less vestibular-triggering motion. The WCAG target is animation that doesn't involve large-scale movement, parallax, or scaling — not the absence of all feedback.

What I do instead

The rule I've landed on: replace, don't remove. Four patterns cover almost everything.

1. Swap a transform for a cross-fade. Movement is the trigger, opacity isn't. So a slide becomes a fade at the same duration.

.panel {
  transition: transform 240ms ease, opacity 240ms ease;
}
@media (prefers-reduced-motion: reduce) {
  .panel { transform: none !important; transition: opacity 240ms linear; }
}

2. Keep the easing, cap the travel. A 16° tilt or a 400px parallax is the problem. 2° of tilt still reads as "interactive" and triggers nothing.

3. Animate a non-spatial property. Progress is the useful half of a loading animation. Drive it with width, a background gradient position, or a text counter instead of a spinning element.

4. Keep state changes, shorten them. A 40ms opacity flip is not a vestibular trigger. It's still enough to tell the user "this changed because of you."

And the part people forget: reduced motion is also about scroll and pointer. Smooth-scroll libraries, scroll-jacking, magnetic cursor effects, and auto-playing background loops all need the same treatment as your CSS transitions. Your <html> scroll-behavior counts.

The testing gap

Here's the honest part: most of this passes automated checks. A script can verify that a reduced-motion media query exists. It cannot tell you whether your modal now teleports.

The only way I've found to actually catch it:

Toggle the OS setting for real — macOS Reduce motion, Windows Show animations off, or Firefox's ui.prefersReducedMotion flag if you want to avoid changing your desktop.
Walk your five most important flows with it on. Open the modal. Submit the form. Scroll the pricing page.
Ask one question per interaction: can I still tell what happened?

If the answer is no, you didn't reduce the motion. You removed the information.

Receipts over vibes

The reason I care about this beyond principle: motion components are the ones people paste in blind. You grab a tilt card or an aurora background, it looks great, and nobody checks what it does under reduced-motion until an audit or a complaint.

That's a fixable information problem. Every animated asset on Motif UI ships with an accessibility score next to its bundle size and dependency count — the library is nothing but original components, all MIT, and the a11y number is part of the audit gate an item has to clear before it gets a card at all. Tilt Card is 2.9 KB with zero deps; Aurora Veil is pure CSS and runs at 60fps with 0 JS. Those numbers are on the page, which is the point — you can check them instead of trusting a screenshot.

Six lines of CSS is not accessibility. Knowing what those six lines do to your users is.

I stopped trusting AI website prompts. Here's how I verify them instead.

lichongyang130 — Mon, 21 Sep 2026 00:03:18 +0000

I stopped trusting AI website prompts. Here's how I verify them instead.

Every "10 jaw-dropping prompts for your landing page" thread has the same problem: the screenshot is real, but the prompt they actually pasted is not the one that made it. You copy it, get something three steps uglier, and assume you did it wrong.

You didn't. The prompt was just oversold.

The test I started running

I stopped reading prompt round-ups cold. Instead, for any prompt I was about to use, I ran it through three different frontier models and scored the output against a fixed rubric — layout fidelity, typography, spacing, whether it actually matched the description. Not vibes. A number.

The results were loud. Across a batch of prompts I'd collected:

a chunk of them held up across all three models
several only produced that "screenshot" on one specific model and fell apart on the other two
a few failed every time and were just… bad, hidden behind a nice thumbnail

That last bucket is the one nobody publishes. Which is exactly the problem.

What I look for now

Three things, in order:

Fidelity scores per model, not per author. If a prompt only works on one model, I want to know that before I build a workflow around it.
Failures shown, not buried. A list where every entry has a perfect score is a marketing page, not a tool.
A score I can reproduce. A rubric I can hold up against my own output and get roughly the same number.

I ended up putting this scoring into the library I was already building — https://www.56juqingba.com runs each AI website prompt through 3 frontier models and shows the real fidelity score, including the runs that scored low. No cherry-picked screenshots; the receipts are the product.

The takeaway

You don't need to distrust every prompt you find. You just need to stop treating a screenshot as proof. Verify on your stack, against more than one model, and keep the score where you can see it later.

The prompt section on that site is free to browse — poke at the ones with low scores and judge for yourself whether the scoring is honest.

I shipped an animated landing page in 90 minutes (and what I'll never hand-code again)

lichongyang130 — Sun, 20 Sep 2026 23:00:52 +0000

I shipped an animated landing page in 90 minutes (and what I'll never hand-code again)

The hard parts of a modern landing page aren't the layout. They're the small motions: the tilt that makes the CTA feel clickable, the text that scrambles in on load, the aurora background that looks expensive but doesn't tank your Largest Contentful Paint.

I used to hand-code all of that. Now I don't — and I tracked a full build minute-by-minute to prove the point.

The build

I gave myself 90 minutes and one rule: no bespoke animation code. Every motion had to come from a verified source with a number attached to it.

Here's what I pulled together, in order:

Hero section — a tilt card that reacts to the pointer, plus scramble-text on the headline to draw the eye on load.
Background — an aurora veil with a performance tier, so I knew exactly what it cost before I shipped it.
CTA + stats — a counter that animates in with an easing curve instead of a jump cut.

Why I stopped hand-coding this

Every copy-paste component site I've used does the same bait-and-switch: a pretty screenshot, and then the code you paste is either broken or bloated with 40KB of dependencies.

The library I used for this build is different — and that's the actual point of this post. It ships receipts instead of marketing:

every animated component has an a11y audit and a bundle-size number
every AI website prompt is tested against 3 frontier models with a real fidelity score (failures shown, not hidden)
a public run log, including the runs that didn't make the cut

The three pieces I used — tilt card, scramble text, aurora veil — are all in the free tier at https://www.56juqingba.com. Steal the patterns; that's the whole idea.

What I'd still hand-code

For the record, not everything belongs in a library. Your business logic, your data fetching, your design system tokens — keep those yours. Components and motion are the last thing you should be reinventing.

If you're a frontend dev who's tired of shipping hero sections by hand, go poke around the library. It's free.