DEV Community: Mai Chi Bao

Investigating a Hybrid LLM-GNN Model to Enhance the Efficiency of ADAPT-QAOA for Quantum Circuit Optimization

Mai Chi Bao — Sat, 20 Jun 2026 13:25:00 +0000

Introduction: A Quantum Adventure
What Is This Project About?
The Problems We Face
My Journey and Discoveries
Results: What Did I Find?
Conclusion: The Road Ahead
Resources

Introduction: A Quantum Adventure

Welcome to the fascinating world of quantum computing! Imagine a world where we can solve complex problems in logistics, resource allocation, and network design. But to reach that world, we face significant challenges. In my journey through the realm of quantum computing, I've been working on something exciting: a framework that helps us create quantum circuits more efficiently. And let me tell you, it’s like embarking on a thrilling adventure filled with puzzles and discoveries.

What Is This Project About?

At its core, my project is about solving combinatorial optimization problems using ADAPT-QAOA (the Adaptive Quantum Approximate Optimization Algorithm). Now, that might sound like a mouthful, but think of it as a powerful recipe for making quantum circuits—circuits that can help us find the best solutions to tricky problems.

In simple terms, my framework blends modern machine learning techniques with quantum computing to produce quantum circuits tailored for graph-based problems like Max-Cut. Adapting these circuits efficiently can save time and computational resources, allowing quantum computing to shine in real-world applications.

The Problems We Face

As I delved deeper into this project, I collected a few challenges that the quantum computing community faces when dealing with adaptive quantum circuits:

1. Complex Circuit Design

Designing quantum circuits isn't as simple as following a recipe; it requires creativity and insight. The challenge is that the possibilities are almost endless—choosing the right components (or operators) can be like finding a needle in a haystack.

2. Parameter Initialization

Even if we can design a great circuit, if we don’t set the parameters properly from the start, our circuit could perform poorly. Think of it like baking: if your ingredients are off, the cake won’t rise.

3. Limited Generalization

Methods that work well for one graph structure often fail when faced with a different one. This lack of flexibility makes it hard to scale solutions to larger or different problems.

My Journey and Discoveries

On this fascinating journey, I learned that the answer lies in combining advanced techniques. I decided to integrate Large Language Models (LLMs), like Transformer networks, with Graph Neural Networks (GNNs). This combination allows the framework to generate circuits based on learned relationships between graph structures and quantum operations.

Imagine teaching a language model not to write sentences, but to generate step-by-step instructions for building quantum circuits. This makes the whole process a lot more efficient and robust.

Results: What Did I Find?

After a series of experiments using graphs with 9, 10, and 11 nodes, I was thrilled to discover a treasure trove of results.

1. Fast Learning and Adaptation

The model learned rapidly, with the approximation ratio climbing above 0.9 early in the training.

2. Compact Circuit Designs

As training progressed, the model not only created good circuits but also reduced their complexity, yielding more efficient outputs.

3. Stability and Scalability

Among the architectures I tested, NanoGPT stood out as an exceptional performer. It consistently achieved high results while keeping circuit depths manageable.

4. Interacting with Different Embedding Types

I tried different graph representation techniques—NetLSD, FEATHER, and GNN. Each had its strengths, with FEATHER often leading in performance while NetLSD offered stability.

5. Surpassing Traditional Methods

Most importantly, my framework showed that it could outperform traditional approaches like Vanilla QAOA by achieving better approximation ratios with less computational effort.

6. Inference Time Comparison

A comparison of inference times illustrated the efficiency of my approach. The proposed hybrid framework maintained low and stable inference times across different graph sizes, showcasing its scalability advantage.

Conclusion: The Road Ahead

As I conclude this adventure, I'm filled with excitement for the road ahead. While my framework shows considerable promise, it still struggles with generalization beyond what it was trained on. However, there's so much potential for improvement!

With more diverse datasets and further exploration, I believe we can refine this framework to tackle even more complex problems. The journey into quantum computing has only just begun, and it's turning out to be an exhilarating ride!

Resources

Thank you for joining me on this journey! If you're as enthusiastic about quantum computing as I am, let’s explore this brilliant world together! Who knows? The next big discovery might just be around the corner.

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

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

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

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

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

3 min read