Why beautiful websites feel slow is a question I keep running into, and this week a Magic: The Gathering card browser gave me a very clean example of it. Oracle went up on Hacker News with the tagline "Search every Magic card ever printed", built, per the site's own footer, by Egstad from DBCo.
It got 3 points and 2 comments. The first comment was not about the design. It was a complaint that the logo animation was eating CPU. That gap between what was built and what was noticed first is the part worth writing about.
🎴 What Oracle actually ships
Ignore the visuals for a second and the feature list is a serious search tool. From the site itself:
| Capability | What it covers |
|---|---|
| Colour filters | Mono, two, three and five-colour combinations, named guilds like Azorius and Rakdos |
| Type filters | Planeswalkers, Legends, Battles, Sagas, Equipment, Vehicles, Lands, Artifacts, Enchantments, Tokens |
| Format filters | Standard, Pioneer, Modern, Legacy, Vintage, Pauper, Commander with EDHREC ranking |
| Effect search | Counterspells, board wipes, removal, card draw, ramp, mill, lifegain, landfall, reanimation |
| Sorting | Name, release date, set number, rarity, colour, price in USD / EUR / TIX, mana value, power/toughness, artist, EDHREC rank |
| Display modes | Small grid, large grid, list, text |
| Result granularity | One per card, every artwork, every printing, or paper only |
That last row is a detail most people would skip. "Every printing" versus "one per card" is a real data-modelling decision, and exposing it as a user-facing toggle means someone thought hard about who is actually searching.
The site does not state where its card data comes from, so I won't guess. What it does state is the intent, and the creator said it plainly in the thread.
🎭 The real bet: the data is commodity, the feel is the product
The top comment made the obvious objection: Gatherer already "has all the same info in a much snappier package." The creator's reply was that they knew about both Gatherer and Scryfall and wanted something that felt "a bit more cinematic and photorealistic."
That is not a dodge. It is the entire product thesis, stated honestly.
Key takeaway: when the underlying data is public and everyone can have it, the only remaining place to compete is the experience layer. That's a legitimate strategy, but it means presentation is no longer decoration. It is the feature, and it gets judged as harshly as a wrong tax bracket would be.
This matters for anyone here building tools. Almost every dataset a small team can build on is already available to competitors. Bus timetables, exchange rates, exam results, public gazette data. You will not win on having the numbers. You might win on the ten seconds it takes someone to find the one number they came for.
But if the experience is your product, then a stutter is a bug in your core feature, not a cosmetic nit. Which is exactly what happened here.
⚡ What "cinematic" costs on a mid-range phone
The complaint was specific: a particle animation on the logo pulling roughly 5% CPU, on a page whose job is to sit there while you read card text. The creator asked, reasonably, what hardware that was measured on.
Both people are right, and that's the interesting part. On a recent laptop, 5% is noise. Here is what the same background cost looks like as you move down the device ladder:
| Device class | 5% sustained CPU means |
|---|---|
| Recent laptop, plugged in | Genuinely nothing |
| Laptop on battery | Fan spins up, measurable battery drain on a long session |
| Mid-range Android, 4GB RAM | Competes with your own scroll and image decode; jank shows up first here |
| Older phone, thermally throttled | The animation and the content fight, and the content loses |
The device most Sri Lankan students and freelancers are browsing on is not the device most of us develop on. An effect that costs nothing on a MacBook is a frame budget you've already spent before the user has scrolled once.
There's a second bill too. A card browser is, by definition, a very large number of high-quality images. Photorealistic rendering of card faces and foils means bigger assets, and mobile data in Sri Lanka is bought in finite bundles. Anything image-heavy should be compressing aggressively before it ships. We keep a free image compressor and an HTML/CSS/JS minifier online for exactly this reason, and both run in your browser rather than uploading anything.
🧭 The Escape-key problem
The second complaint was navigation: the commenter couldn't get out of a full-screen card view without pressing Escape. The creator's answer was that cards open in a lightbox, so Escape returns you to the grid, and called it a common pattern.
He's right that it's a common pattern. He's also, I'd argue, losing the argument, because the user reported being stuck anyway.
A convention only works when the user recognises it. If someone has to be told the pattern after the fact, the pattern didn't do its job on their screen.
Two things break the lightbox convention quietly:
- On touch, there is no Escape key. The entire keyboard affordance is unavailable to a phone user, and the visual close target has to carry the full load.
- A photorealistic full-bleed view can swallow the exit. The more immersive the view, the more the close control looks like part of the artwork instead of a control.
The fix is cheap and unglamorous. A visible close button with a real hit area, a click on the backdrop, and browser-back mapped to close. Three of them, not one, because you don't know which one any given person will reach for.
💡 What this means for you
Oracle is a well-made thing built on a defensible bet, and I'd rather see this than the tenth identical minimal-grey search page. But the feedback loop it hit in public is the one to learn from. Here's what I take from it:
- Pick your competitive layer deliberately. If the data is commodity, say out loud that experience is the product, then hold yourself to that standard.
- Set a frame budget before you add the effect. Idle animation should be near-zero cost, because "idle" is where users spend most of their time.
- Test on the cheapest device your audience owns, not the one on your desk. Chrome DevTools CPU throttling at 4x costs nothing to turn on.
- Never let a keyboard shortcut be the only exit. Half your traffic has no keyboard.
- Compress before you ship. Especially with image-heavy pages on metered mobile data.
Delight is worth paying for. Just know the price, and know whose device is paying it.
