DEV Community: Mai Chi Bao

I’ll be honest with you: I didn’t wake up one morning thinking “Let me reverse-engineer TikTok today.” It started with something much simpler: “I just want to upload videos to TikTok programmatically… why is this so damn hard?”

Mai Chi Bao — Mon, 17 Nov 2025 14:05:37 +0000

Mai Chi Bao

Nov 17 '25

Breaking Down API Defenses: UA - Cookies - Signatures Browser 🤖

#webdev #api #security #mrzaizai2k

Comments 3

4 min read

Breaking Down API Defenses: UA - Cookies - Signatures Browser 🤖

Mai Chi Bao — Mon, 17 Nov 2025 13:06:00 +0000

Introduction

I’ll be honest with you:
I didn’t wake up one morning thinking “Let me reverse-engineer TikTok today.”

It started with something much simpler:

“I just want to upload videos to TikTok programmatically…
why is this so damn hard?”

No matter what I tried — simple requests, faked headers, even stolen cookies — TikTok kept slamming the door in my face.

But every failure taught me something.
Every blocked request revealed the next security layer.

So I dug in.
I became the “hacker” TikTok didn’t want.

And in this post, I’ll take you through the exact journey — from the most naive HTTP request… all the way to running TikTok’s own obfuscated JavaScript in a Node VM to generate browser signatures.

All code here comes from my real TikTok automation stack (based on my repo:
github.com/mrzaizai2k/auto_tiktok).

Raw Request — My First Dumb Attempt
User-Agent — “Fine, I’ll Pretend to Be Chrome”
Cookies — The Real Passport
Browser Signatures — When TikTok Got Serious
Summary
Final Thoughts
Resources

Raw Request

🧠 What I Tried

The first time I tried calling TikTok’s API, I thought it would be as easy as:

import requests
print(requests.get("https://www.tiktok.com/api/whatever").text)

TikTok looked at me like:

“Bro, who even are you?”

No headers.
No cookies.
No browser identity.
Instant block.

To understand why, I built a minimal FastAPI to simulate what TikTok sees when a bot sends a naked request:

from fastapi import FastAPI, Request, HTTPException

app = FastAPI()

@app.get("/api/data")
def get_data(request: Request):
    # no checks, no identity
    return {"data": "public info"}

This is how the early internet worked.
And this is why it died.

User-Agent

“I’ll wear Chrome’s clothes… surely that will work.”

I added:

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

My FastAPI simulation:

@app.get("/api/data")
def get_data(request: Request):
    ua = request.headers.get("User-Agent")
    if not ua:
        raise HTTPException(403, "Missing UA")
    return {"data": "public info"}

And my crawler:

import requests
requests.get(url, headers={"User-Agent": "Mozilla/5.0"})

This worked…
…for exactly 5 minutes.

Because any idiot can fake a UA.
Including me.

So TikTok uses the next level.

Cookies

“Fine, TikTok, you want identity? Here’s my passport.”

Cookies are small pieces of data the server sets in your browser.
When I login to TikTok on Chrome, the browser stores cookies like:

sessionid
msToken
tt-target-idc
csrf_session_id

These aren’t random strings — they’re TikTok’s way of saying:

“This browser is logged in. We know this guy.”

To get these cookies, I use this extension (the best one I’ve found):
👉 J2Team Cookies (Chrome)

It exports cookies into a neat JSON file — perfect for automation.

Then in Python:

cookies = load_cookies_from_file("cookies/tiktok.json")

session = requests.Session()
session.cookies.set("sessionid", session_id, domain=".tiktok.com")
session.cookies.set("tt-target-idc", dc_id, domain=".tiktok.com")

Now TikTok was finally willing to talk to me.
For a while.

Because cookies can still be:

stolen
copied
reused
shared

TikTok needed something harder.

Browser Signatures

“Prove you’re a real browser or get lost.”

This is where TikTok gets nasty.

Even with:

Valid cookies
Valid User-Agent

TikTok still blocks you unless you generate:

X-Bogus
_signature
msToken validation
device/environment fingerprints
obfuscated JS crypto outputs

TikTok literally sends JavaScript that only a real browser can execute.

So to bypass it…
I used their own JavaScript.

👉 Running TikTok’s JS in a Node VM

This is my real browser.js (the one doing the magic):

// Browser.js
const Signer = require("./index");

var url = process.argv[2];
var userAgent = process.argv[3];

(async function main() {
  try {
    const signer = new Signer(url, userAgent);
    await signer.init();

    const sign = await signer.sign(url);
    const navigator = await signer.navigator();

    let output = JSON.stringify({
      status: "ok",
      data: {
        ...sign,
        navigator: navigator,
      },
    });
    console.log(output);
    await signer.close();
  } catch (err) {
    console.error(err);
  }
})();

And this is how my Python script calls it:

def subprocess_jsvmp(js, user_agent, url):
    proc = subprocess.Popen(['node', js, url, user_agent], stdout=subprocess.PIPE)
    return proc.stdout.read().decode('utf-8')

Every API request needs this signature.
Without it — TikTok spits on you.

With it — you suddenly become “a real browser.”

This is exactly how I upload videos automatically:

signatures = subprocess_jsvmp(js_path, user_agent, sig_url)
tt = json.loads(signatures)["data"]

headers = {
    "User-Agent": user_agent,
    "X-Bogus": tt["x-bogus"],
    "_signature": tt["signature"],
}

Now TikTok believes me.
And lets me upload videos through automation.

Summary

Layer	What I Did	Why It Failed
Raw request	Called API directly	“Who are you?”
User-Agent	Pretended to be Chrome	Too easy to fake
Cookies	Exported real TikTok cookies	Reusable → insecure
Browser Signatures	Ran TikTok’s own JS	Finally works

Final Thoughts

There are even more authentication methods out there:

OAuth
JWT tokens
PKCE
Rotating keys
Device-bound tokens

If you want, I can continue this series:

👉 Hit follow + drop a comment if you want the next chapter.

Resources

My TikTok uploader code: auto_tiktok → tiktok.py

Everything worked perfectly on my laptop. 🚀 The UI loaded, uploads succeeded, APIs responded instantly. But on demo day, in front of my boss, everything collapsed. 💥

Mai Chi Bao — Wed, 01 Oct 2025 02:55:55 +0000

TIL: CORS, IPs, and the Day My Demo Crashed 🔒

Mai Chi Bao ・ Sep 29 '25

#webdev #mrzaizai2k #vscode #devops

TIL: CORS, IPs, and the Day My Demo Crashed 🔒

Mai Chi Bao — Mon, 29 Sep 2025 12:00:00 +0000

Everything worked perfectly on my laptop. 🚀 The UI loaded, uploads succeeded, APIs responded instantly.

But on demo day, in front of my boss, everything collapsed. 💥

This post is a breakdown of how VS Code Remote-SSH port forwarding tricked me, how I fixed it, and what I learned.

If you’ve ever wondered why your app works fine locally but fails when someone else tries — this story might save you some embarrassment.

Key Takeaways 📝

Why localhost tricks you in Remote-SSH and how VS Code port forwarding can hide real network issues.
How to correctly configure backend (0.0.0.0), frontend (server IP/hostname), and CORS so others can access your app.
Why testing in a clean environment (without port forwarding) is essential before demo day.

⚡ The Setup and Demo Day Disaster
🔍 Chasing the Problem
🎭 VS Code Port Forwarding: The Hidden Culprit
🛠️ The Fix
🔄 The CORS Twist
✅ Conclusion

The Setup and Demo Day Disaster ⚡

In my frontend .env I had:

REACT_APP_API_BASE=http://localhost:6489

And in backend:

BACKEND_PORT=6489
BACKEND_HOST=localhost

On my laptop (via VS Code Remote-SSH) everything worked. UI loaded, uploads went through, API calls succeeded.

But demo day came. My boss opened:

http://10.X.X.X:6485

The frontend loaded, but every upload and API call failed.
I was lost — why does it only work on my machine, but not his?

Chasing the Problem 🔍

At first, I thought the backend had crashed. Logs were fine.
Then I suspected CORS. No issues there either.

Finally, I asked ChatGPT. It suggested:

Change backend host to 0.0.0.0 and frontend API base to server IP.

I tried it — and it worked. 🎉
But I still didn’t understand why it only worked for me before.

VS Code Port Forwarding: The Hidden Culprit 🎭

Digging deeper, I discovered the real cause:
VS Code Remote-SSH was auto-forwarding my ports.

On my laptop:

localhost:6485 → tunneled to frontend on the server
localhost:6489 → tunneled to backend

So for me, everything looked fine. But for my boss, localhost pointed to his own machine — which had no backend at all.

Visual proof of the trick:

Before (VS Code auto port forwarding): You now can access via localhost:6485 and 10.X.X.X:6485

Deleting ports → no more fake localhost:

Now only server IP works:

⚠️ Note on VS Code Port Forwarding
If you run two VS Code Remote-SSH sessions for different projects, and both try to use the same port, VS Code will automatically increment the port number.

That’s why sometimes when you open http://localhost:6485, it gets auto-routed to http://localhost:6486.

Why Auto Port Forwarding Matters 🔑

When I added authentication, using the server IP broke Microsoft login — it only accepts localhost or HTTPS.

Error when opening via server IP (10.X.X.X:6485) without port forwarding:

Fix: forward ports in VS Code (or manually with SSH):

ssh -L 6485:localhost:6485 -L 6489:localhost:6489 user@10.X.X.X

Now login works again on http://localhost:6485:

⚠️ But there’s a catch:
This solution is fine for local development, but not practical for demos — you can’t expect customers to forward ports.

If your app relies on Microsoft login (or similar auth), you should set up HTTPS on the server.
That way, customers can simply access it via:

https://10.X.X.X:6485

But after that, new CORS problems surfaced — which leads to the next lesson.

The Fix 🛠️

I fixed configs:

BACKEND_PORT=6489
BACKEND_HOST=0.0.0.0

Frontend:

REACT_APP_API_BASE=http://10.X.X.X:6489

Why this works:

localhost (127.0.0.1)
Binding your backend to localhost means it only accepts connections from the same machine it’s running on.
In other words, the server is listening only to itself. Anyone trying to reach it from another device on the network won’t be able to connect.
0.0.0.0
Binding to 0.0.0.0 tells the backend to listen on all available network interfaces (LAN, Wi-Fi, etc.).
This makes your service accessible not just from the local machine, but also from other devices on the same network — such as your boss’s laptop during the demo.
Frontend API calls
Since the frontend runs in your user’s browser, it can’t resolve your localhost (that points to their machine, not your server).
The frontend must call the backend using the server’s IP address or hostname (e.g., http://10.X.X.X:6489), so that it correctly points to the server where the backend is actually running.

The CORS Twist 🔄

Later, I caught another mistake.
My backend allowed only SERVER_IP, but when the frontend ran on a different machine (FRONT_END_IP), the requests were blocked.

Fix was to add both:

if FRONT_END_IP:
    allowed_origins.append(f"http://{FRONT_END_IP}/")
    allowed_origins.append(f"https://{FRONT_END_IP}/")

I had lazily assumed SERVER_IP == FRONT_END_IP. Wrong — and it silently broke requests.

Conclusion ✅

localhost ≠ server IP.
Remote-SSH port forwarding can trick you.
Always bind backend to 0.0.0.0.
Always point frontend to server IP or hostname.
Align CORS with the actual machine hosting frontend.
Test from a clean environment, not your tunneled setup.
And before demo day → disable VS Code auto port-forwarding.

👉 Future me: no more blind trust in localhost.

No subscriptions, no paywalls — just a straightforward QR generator that works right in your browser 🚀.

Mai Chi Bao — Tue, 16 Sep 2025 02:46:09 +0000

Mai Chi Bao

Sep 15 '25

TIL: Building a Simple QR Generator

#tooling #mrzaizai2k #css #html

Comments 2

2 min read

TIL: Building a Simple QR Generator

Mai Chi Bao — Mon, 15 Sep 2025 12:49:00 +0000

I built a lightweight, open-source tool to create customized QR codes.

No subscriptions, no paywalls — just a straightforward QR generator that works right in your browser 🚀.

👉 Try it here: Simple QR Generator

📑 Table of Contents

Why I Built This
Features
How It Works
Demo Screenshot
Why I Like It
Reference

💭 Why I Built This

Most QR code tools online feel bloated or restrictive:

Many require accounts or subscriptions just to download a QR code.
Some lock basic features like color, logo, or export behind a paywall.
Others are overloaded with ads, making them slow and frustrating.

I just wanted something clean, simple, and free — a tool where you can generate and customize QR codes without hassle.

That’s why I created Simple QR Generator — a project that anyone can use instantly in their browser.

✨ Features

Generate QR codes from any text or URL.
Customize:
- Colors
- Shapes
- Styles
Add a logo (upload your own or use an image URL).
Adjust:
- Size
- Margin
- Error correction level
Export to PNG or SVG.
Copy QR codes directly to clipboard.

⚡ How It Works

Enter your text or URL in the input box.
Adjust customization options (color, style, size, error correction).
(Optional) Upload or link a logo to embed inside the QR code.
Click Generate, then either:
- Export as PNG or SVG, or
- Copy directly to clipboard for quick use.

All of this happens entirely in your browser — no server-side processing, no data collection.

🖥️ Demo Screenshot

Here’s a quick look at the tool in action 👇

You can try it live here 👉 Simple QR Generator

💡 Why I Like It

Lightweight: works instantly in any browser.
No limits: all features are free and open-source.
Customizable: from logos to colors, you can make QR codes match your style.
Practical: whether it’s sharing a link, business info, or Wi-Fi credentials, it just works.

It started as a small side project for myself, but it turned into a neat tool worth sharing.

🔗 Reference

All the code is open-source on my GitHub:

👉 mrzaizai2k/simple_qr_generator

Feel free to clone it, star it ⭐, or suggest improvements.

Hi do you guys want to test?

Mai Chi Bao — Thu, 11 Sep 2025 14:43:24 +0000

Mai Chi Bao

Sep 8 '25

TIL: Building a Simple Typing Practice Tool

#tooling #mrzaizai2k #html #css

Comments 1

2 min read

TIL: Building a Simple Typing Practice Tool

Mai Chi Bao — Mon, 08 Sep 2025 13:05:00 +0000

📝 Today I Learned: Building a Simple Typing Practice Tool

I built a really small web-based tool to enhance typing skills with real-time feedback.

It’s just a single HTML file — no backend, no frameworks, no setup. You open it in your browser and start typing 🚀.

📑 Table of Contents

Why I Built This
Features
How It Works
Demo Screenshot
Why I Like It
Reference

💭 Why I Built This

Most typing practice tools I tried don’t support Vietnamese text well:

Their UI looks broken or ugly when practicing with Vietnamese.
They rarely offer fresh, real-world Vietnamese content.
I wanted to auto-generate practice text from news so I don’t get bored.
I also wanted to customize the metrics I care about (e.g., word accuracy, correct WPM).
Plus, having a dark mode toggle and a cleaner UI makes practice more enjoyable.

That’s why I created this simple tool — just for myself at first — but it turned out useful enough to share.

✨ Features

Works everywhere — pure HTML, CSS, and JS.
Auto-fetches Vietnamese 🇻🇳 or English 🇺🇸 news text for practice.
Customizable reference text (you can paste or write your own).
Tracks:
- Time (seconds)
- Character Accuracy (%)
- Word Accuracy (%)
- Words Per Minute (WPM)
- Correct WPM
- Progress (typed vs total characters)
Real-time color coding: ✅ correct, ❌ incorrect, and 🎯 current character.
Auto-scrolls while typing.
Completion message when done.
Dark mode + Reset button.

⚡ How It Works

You type directly on the displayed reference text.
Each keystroke updates:
- Character accuracy → (correct chars ÷ total typed).
- Word accuracy → (correct full words ÷ attempted words).
- WPM → counts total words per minute (including mistakes).
- Correct WPM → only correct words per minute.
A progress bar and completion message keep you motivated.
You can fetch real news text from VnExpress and practice with something fresh.

🖥️ Demo Screenshot

You can try my Simple Typing

You can also visit my repo here 👉 mrzaizai2k/simple-typing.

Just download the typing.html file, open it in any browser — and you’re ready to practice 🚀.

💡 Why I Like It

Minimalistic: no dependencies, just one .html file.
Real-time feedback keeps me aware of typing mistakes instantly.
The news fetch feature means I can always practice with new content, instead of boring lorem ipsum.
Great for improving not just speed, but also accuracy.

🔗 Reference

All the code is live here on my GitHub:

👉 mrzaizai2k/simple-typing

Feel free to clone it, star it ⭐, or ask me anything.

A few weeks ago, I built a Docker image for my personal portfolio project (a React app). Everything worked fine — until I checked the size... 💣 1.5 GB! For a static frontend app?! I realized this could slow down deployment, consume more storage, and mak

Mai Chi Bao — Sun, 27 Jul 2025 03:34:52 +0000

Mai Chi Bao

Jul 21 '25

From 1.5GB to 200MB: How I Slimmed Down My Docker Image Like a Pro 🚀

#mrzaizai2k #webdev #docker #devops

Comments 1

3 min read

From 1.5GB to 200MB: How I Slimmed Down My Docker Image Like a Pro 🚀

Mai Chi Bao — Mon, 21 Jul 2025 12:26:00 +0000

A real journey of "less is more" in Docker 🐳

📚 Table of Contents

🎯 The Problem: Bloated Docker Image
🔍 The Investigation
🧠 The Solution Explained
- 1. Add .dockerignore
- 2. Use Multi stage Builds
- 3. Choose Lighter Base Images
📊 Before vs After: What Changed?
🎁 Conclusion
🔗 Reference

🎯 The Problem: Bloated Docker Image

A few weeks ago, I built a Docker image for my personal portfolio project (a React app). Everything worked fine — until I checked the size...

💣 1.5 GB! For a static frontend app?!

I realized this could slow down deployment, consume more storage, and make CI/CD pipelines sluggish. I had to fix this.

🔍 The Investigation

When I looked into my Docker setup, I noticed some rookie mistakes:

I didn’t have a .dockerignore file 😅
I was using only a single-stage build
The base image was node:18-alpine, which seemed fine but not optimal for production delivery
I was copying everything (including node_modules, .git, and build files) into the image

This is my previous Dockerfile:

  # Use official Node image
  FROM node:18-alpine
  # Set working directory
  WORKDIR /app
  # Copy dependency files first (for better Docker caching)
  COPY package.json package-lock.json ./
  # Install dependencies
  RUN npm ci
  # Copy rest of the application
  COPY . .
  # Build the React app
  RUN npm run build
  # Install a lightweight static server
  RUN npm install -g serve 
  # Expose port
  EXPOSE 3000
  # Serve the static build
  CMD ["serve", "-s", "build", "-l", "3000"]

It was time to clean house.

🧠 The Solution Explained

1. Add dockerignore

Think of .dockerignore as .gitignore for Docker. Without it, Docker copies everything from your working directory — including huge folders like:

node_modules/
.git/
build/
*.md docs

I added this .dockerignore:

  node_modules/
  npm-debug.log
  .git
  .gitignore
  Dockerfile
  docker-compose.yml
  build/
  dist/
  .env
  *.md

👉 Result: Way less junk copied into the image = faster build time + smaller size

2. Use Multi stage Builds

Instead of one bloated Dockerfile, I split it into two stages:

Builder Stage: Installs dependencies and runs the build
Production Stage: Copies only what’s needed to serve the app

  # Stage 1: Build
  FROM node:18-slim AS builder
  WORKDIR /app
  COPY package*.json ./
  RUN npm ci --only=production
  COPY . .
  RUN npm run build

  # Stage 2: Serve
  FROM node:18-slim
  WORKDIR /app
  COPY --from=builder /app/build ./build
  RUN npm install -g serve
  EXPOSE 3000
  CMD ["serve", "-s", "build", "-l", "3000"]

👉 Result: No dev dependencies or source code in the final image. Just the build output. Lean & clean.

3. Choose Lighter Base Images

Originally I used node:18-alpine. It’s small but sometimes causes compatibility issues with native modules.

I switched to node:18-slim, which is slightly larger than Alpine but more stable for multi-stage builds and still much smaller than the full Node image.

👉 Result: Better balance between size and reliability.

📊 Before vs After: What Changed?

Aspect	Before	After
📦 Image Size	~1.5 GB	~200 MB
⚙️ Build Strategy	Single-stage	Multi-stage
📁 Base Image	`node:18-alpine`	`node:18-slim`
🚫 .dockerignore	❌ None	✅ Included to skip unneeded files
🔁 Copied Files	Everything (including `node_modules`)	Only `build/` output copied
🚀 Performance	Slow build + large deploy	Faster build + minimal production image

🎁 Conclusion

If you apply the same strategies, you’ll get:

✅ Smaller Docker Images → Faster pulls/pushes, lower storage cost
⚡ Faster Builds → Especially in CI/CD pipelines
🔒 Better Security → No unnecessary source code or secrets inside image
🌍 Portable & Lightweight Images → Ideal for microservices, serverless, and edge deployments

🔗 Reference

All the code is live here on my GitHub:
👉 mrzaizai2k/Portfolio

Feel free to clone it, star it ⭐, or ask me anything.

Thanks for reading!
If this helped you, share it with a friend who might still be shipping 1GB containers 😄

I'm not a professional web developer — but even so, just by following these 5 simple steps, I managed to hit 95 on PageSpeed 🚀 But hey — don’t just skim this. The last tip could make or break all your efforts. Stick around until the end for the real gam

Mai Chi Bao — Tue, 15 Jul 2025 08:29:17 +0000

Mai Chi Bao

Jul 14 '25

Let’s Be Honest… Slow Websites Scare People Away 😢

#react #mrzaizai2k #webdev #performance

Comments 2

3 min read

Let’s Be Honest… Slow Websites Scare People Away 😢

Mai Chi Bao — Mon, 14 Jul 2025 12:27:00 +0000

I'm not a professional web developer — but even so, just by following these 5 simple steps, I managed to hit 95 on PageSpeed 🚀

But hey — don’t just skim this. The last tip could make or break all your efforts.

Stick around until the end for the real game-changer!

📚 Table of Contents

🔍 Analyze with PageSpeed
✂️ Code Splitting and Reducing Unused Stuff
🖼️ Optimize Images
🔬 Code Review and Lazy Loading
🎨 CSS Optimizations
🌐 Real-World Network Testing
🎁 What's Next
📎 References

🔍 Analyze with PageSpeed

Start with the easiest step — use PageSpeed Insights to check your site’s performance.

Here’s the result I got for my website mrzaizai2k.xyz:

It not only gives you a score — it shows you exactly what’s slowing your site down:

✅ Step 1: Done — you now know where your site stands and what to fix!

✂️ Code Splitting and Reducing Unused Stuff

JavaScript can be a performance killer if not handled properly.

By default, browsers download and parse all JS — even if parts aren’t needed right away.

That’s why we:

Split code using tools like Webpack or dynamic imports.
Remove unused code, especially third-party scripts or unused CSS classes.

This reduces the size of initial payloads, speeds up rendering, and improves the Time to Interactive metric ⚡

💡 Imagine JS as a buffet — don’t serve the whole menu if the user only asked for a sandwich.

🖼️ Optimize Images

Use tools like TinyPNG to compress your images — no quality loss, just smaller size!

I optimized this image and saved 68% in size with just a few clicks:

📸 Also:

Crop unnecessary parts.
Use WebP or AVIF formats when possible.
Set correct image dimensions to avoid layout shifts.

🔬 Code Review and Lazy Loading

Here’s how I use React.lazy() and Suspense to load components only when they’re needed:

<Suspense fallback={<div>Loading...</div>}>
  <Home2 />
</Suspense>

<img
  src={homeLogo}
  alt="home pic"
  className="img-fluid"
  style={{ maxHeight: "450px" }}
  loading="lazy"
/>

Why this works:

React.lazy: breaks your app into smaller chunks. This means non-critical parts don’t load until needed.
loading="lazy" on images: tells the browser not to load off-screen images until the user scrolls to them.

This greatly reduces initial load time, especially for users on low-end devices or slow networks 🌍

🎨 CSS Optimizations

I keep my CSS minimal, responsive, and optimized for rendering.
Here’s one example from my code:

  .tech-icons {
    font-size: 4.5em;
    margin: 15px;
    padding: 10px;
    box-shadow: 4px 5px 4px 3px rgba(89, 4, 168, 0.137);
    transition: all 0.4s ease;
  }

What’s going on here:

🧽 Clean layout: Simple margin/padding, avoiding deep nesting.
🧠 Efficient rendering: transition, box-shadow, and no heavy animations.
📱 Responsive by default: Paired with media queries to scale well on mobile.

Avoid bloated libraries and unnecessary CSS classes. Stick to what you use — nothing more.

🌐 Real World Network Testing

Your site might be fast for you, but what about users on 3G or rural networks?

I tested my Projects page:
🔗 mrzaizai2k.xyz/project

Looked fine on fast Wi-Fi:

But in Edge DevTools, I:

Pressed F12
Opened the Network tab
Enabled Disable Cache
Switched to Slow 3G

What happened?

YouTube previews didn’t load.
No visual feedback = bad UX.
User probably leaves before seeing your work.

My Fix:

I added a "Demo" button as a fallback, so users can still explore projects even if previews fail to load 🔁

Always think like a user:

"If I saw a blank screen, would I wait? Probably not."

🎁 What's Next

🎯 Here’s the big one:
Even with all the above, it’s not enough without thinking about build and deployment.

In the next post, I’ll show you:

How to create a super-light Dockerfile
How npm run build makes your app production-ready
Why deploying static files the right way boosts speed like crazy

👉 Don’t miss it — follow me so you get notified when it’s live!
👍 If this post helped you, please like, comment, or share
⭐️ A star on the repo also means a lot!

📎 References

PageSpeed Analysis
💻 My Website: mrzaizai2k.xyz
📁 My Repo: GitHub Portfolio