## Giới thiệu

Trong các ứng dụng web hiện đại, hiệu suất là một yếu tố quan trọng ảnh hưởng trực tiếp đến trải nghiệm người dùng. Một trong những nguyên nhân chính gây ra tình trạng giật lag, hoặc block UI là do các tác vụ tính toán nặng (heavy tasks) được thực thi trực tiếp ngay trên **(main thread)**.

Để giải quyết vấn đề này, JavaScript cung cấp giải pháp **Web Workers**, cho phép chạy các đoạn mã song song trong một luồng riêng biệt, giúp **tránh xử lí trên main thread** và **tăng hiệu suất ứng dụng**.

## 1. Web Workers là gì?

Web Workers là một API của trình duyệt cho phép bạn thực thi JavaScript trong một luồng riêng biệt với luồng chính của ứng dụng.

- Web Workers có thể **giao tiếp với main thread** thông qua `postMessage`.
- Phù hợp để xử lý: tính toán nặng, phân tích dữ liệu, xử lý ảnh, nén file,...

## 2. Tại sao nên sử dụng Web Workers?

### **Lợi ích**:
- **Không làm block UI**: vì không chạy trên luồng chính.
- **Cải thiện UX**: giao diện vẫn phản hồi trong khi xử lý tác vụ.
- **Tăng hiệu suất cho các tác vụ tính toán phức tạp**.

### **Khi không sử dụng Web Workers**:
- UI dễ bị đơ khi xử lý JSON lớn, vòng lặp nhiều, hoặc xử lí thuật toán nặng.
- User có thể nhầm tưởng ứng dụng bị crash nếu không phản hồi.

## 3. Ví dụ về cách sử dụng Web Workers cho bài toán tính giai thừa

Giả sử bạn cần thực hiện phép tính giai thừa (`n!`) với các số lớn – đây là một tác vụ có thể gây chậm hoặc "đơ" giao diện nếu xử lý trực tiếp trong main thread. Web Worker sẽ giúp tách việc xử lý ra luồng riêng, đảm bảo UI luôn mượt mà.

Chúng ta sẽ xây dựng một ví dụ đơn giản gồm:

- Một **file Web Worker** để tính giai thừa.
- Một **component React (TSX)** gồm ô input, button nhấn để gửi dữ liệu vào worker, và các thẻ p để hiển thị kết quả.

### 🧮 `factorialWorker.ts` – File worker

```ts
self.onmessage = function (e) {
  const number = e.data;
  const result = factorial(number);
  self.postMessage(result);
};

function factorial(n: number): BigInt {
  let result = BigInt(1);
  for (let i = 2; i <= n; i++) {
    result *= BigInt(i);
  }
  return result;
}

export {};
```


### 🧑‍💻 `FactorialCalculator.tsx` – React component

```tsx
import React, { useState, useRef } from "react";

const FactorialCalculator: React.FC = () => {
  const [input, setInput] = useState<number>(100000);
  const [result, setResult] = useState<number | null>(null);
  const [loading, setLoading] = useState(false);
  const [totalTime, setTotalTime] = useState(0);
  const workerRef = useRef<Worker | null>(null);

  const handleCalculate = () => {
    setResult(null);
    setTotalTime(0);
    setLoading(true);
    const startTime = performance.now(); // Start timing

    const worker = new Worker(new URL("@src/worker/factorialWorker", import.meta.url));
    workerRef.current = worker;

    worker.postMessage(input);

    worker.onmessage = (e: MessageEvent<number>) => {
      const endTime = performance.now(); // End timing
      setTotalTime(endTime - startTime); // Calculate total time in milliseconds

      setResult(e.data);
      setLoading(false);
      worker.terminate();
    };
  };

  return (
    <div>
      <input
        type="number"
        value={input}
        onChange={(e) => setInput(Number(e.target.value))}
        placeholder="Nhập số nguyên dương"
      />
      <button onClick={handleCalculate} disabled={loading}>
        {loading ? "Đang tính..." : "Tính giai thừa"}
      </button>
      {result !== null && <p>Kết quả: {result}</p>}
      {totalTime > 0 && <p>Thời gian tính toán: {totalTime.toFixed(3)} ms</p>}
    </div>
  );
};

export default FactorialCalculator;
```

Kết quả:

| Khi không sử dụng Web Worker | Khi sử dụng Web Worker |
|-----------|----------------------|
| ![Cách hoạt động của Web Worker](/blogs/blog24/not-using-ww.gif) | ![Cách hoạt động của Web Worker](/blogs/blog24/using-ww.gif) |


Ta có thể thấy khi sử dụng web-worker, UI mượt mà hơn rất nhiều so với khi không sử dụng nó.




## 4. Lưu ý khi sử dụng web worker

- Không thể truy cập đến DOM từ trong worker file.
- Đảm bảo luồng giao tiếp `postMessage` rõ ràng và không gây race condition.
- Có thể dùng `Comlink` để đơn giản hóa giao tiếp.

## 5. Khi nào nên dùng Web Workers?

| Tình huống | Có nên dùng Worker? |
|-----------|----------------------|
| Tính toán nặng như mã hóa, nén file | ✅ Cần |
| Xử lý file JSON lớn (>1MB) | ✅ Cần |
| Cập nhật UI đơn giản | ❌ Không cần |
| Fetch API, gọi server | ❌ Không cần (dùng async/await cho lẹ :D) |

## 6. Các option nâng cao khác

- **SharedWorker**: chia sẻ worker giữa nhiều tab.
- **Service Worker**: xử lý request, cache – khác với Web Worker.
- **OffscreenCanvas**: render canvas trong worker (đặc biệt hữu ích với đồ họa).

## Kết luận

Web Workers là công cụ mạnh mẽ giúp cải thiện hiệu suất của các ứng dụng web hiện đại. Việc tách biệt các tác vụ nặng ra khỏi luồng chính sẽ giúp UI luôn mượt mà, thân thiện với người dùng. Hãy cân nhắc sử dụng Web Workers khi bắt đầu thấy trình duyệt bị "lag" khi xử tác vụ phức tạp.




## Introduction

In modern web applications, performance is a critical factor that directly affects the user experience. One of the main causes of lagging or UI blocking is due to heavy tasks being executed directly on the **main thread**.

To address this issue, JavaScript provides the **Web Workers** API, which allows running code in parallel in a separate thread, helping **avoid blocking the main thread** and **improving application performance**.

## 1. What are Web Workers?

Web Workers are a browser API that allows you to execute JavaScript in a separate thread from the main application thread.

- Web Workers can **communicate with the main thread** via `postMessage`.
- Ideal for handling: heavy computation, data analysis, image processing, file compression, etc.

## 2. Why use Web Workers?

### **Benefits**:
- **No UI blocking**: since it doesn't run on the main thread.
- **Better UX**: the UI remains responsive while the task is being processed.
- **Improved performance for complex calculations**.

### **Without Web Workers**:
- The UI can easily freeze when processing large JSON files, long loops, or complex algorithms.
- Users may think the app crashed if there's no response.

## 3. Example: Using Web Workers to Calculate Factorial

Suppose you need to calculate factorial (`n!`) of large numbers — this can be a task that slows down or freezes the UI if processed on the main thread. Web Workers help offload this task to a separate thread, ensuring a smooth UI.

We’ll build a simple example including:

- A **Web Worker file** to calculate factorial.
- A **React (TSX) component** with an input box, a button to send data to the worker, and `<p>` tags to display the result.

### 🧮 `factorialWorker.ts` – Worker file

```ts
self.onmessage = function (e) {
  const number = e.data;
  const result = factorial(number);
  self.postMessage(result);
};

function factorial(n: number): BigInt {
  let result = BigInt(1);
  for (let i = 2; i <= n; i++) {
    result *= BigInt(i);
  }
  return result;
}

export {};
```

### 🧑‍💻 `FactorialCalculator.tsx` – React component

```tsx
import React, { useState, useRef } from "react";

const FactorialCalculator: React.FC = () => {
  const [input, setInput] = useState<number>(100000);
  const [result, setResult] = useState<number | null>(null);
  const [loading, setLoading] = useState(false);
  const [totalTime, setTotalTime] = useState(0);
  const workerRef = useRef<Worker | null>(null);

  const handleCalculate = () => {
    setResult(null);
    setTotalTime(0);
    setLoading(true);
    const startTime = performance.now(); // Start timing

    const worker = new Worker(new URL("@src/worker/factorialWorker", import.meta.url));
    workerRef.current = worker;

    worker.postMessage(input);

    worker.onmessage = (e: MessageEvent<number>) => {
      const endTime = performance.now(); // End timing
      setTotalTime(endTime - startTime); // Calculate total time in milliseconds

      setResult(e.data);
      setLoading(false);
      worker.terminate();
    };
  };

  return (
    <div>
      <input
        type="number"
        value={input}
        onChange={(e) => setInput(Number(e.target.value))}
        placeholder="Enter a positive integer"
      />
      <button onClick={handleCalculate} disabled={loading}>
        {loading ? "Calculating..." : "Calculate Factorial"}
      </button>
      {result !== null && <p>Result: {result}</p>}
      {totalTime > 0 && <p>Calculation time: {totalTime.toFixed(3)} ms</p>}
    </div>
  );
};

export default FactorialCalculator;
```

Result:

| Without Web Worker | With Web Worker |
|--------------------|-----------------|
| ![Without Web Worker](/blogs/blog24/not-using-ww.gif) | ![With Web Worker](/blogs/blog24/using-ww.gif) |

As you can see, using a Web Worker results in a much smoother UI compared to not using one.

## 4. Notes When Using Web Workers

- You cannot access the DOM from inside a worker file.
- Make sure `postMessage` communication is clear and avoids race conditions.
- You can use `Comlink` to simplify communication.

## 5. When Should You Use Web Workers?

| Scenario | Should You Use a Worker? |
|----------|---------------------------|
| Heavy computation like encryption, file compression | ✅ Yes |
| Processing large JSON files (>1MB) | ✅ Yes |
| Simple UI updates | ❌ No |
| Fetch API, server calls | ❌ No (just use async/await 😄) |

## 6. Other Advanced Options

- **SharedWorker**: share a worker across multiple tabs.
- **Service Worker**: handles requests, caching – different from Web Worker.
- **OffscreenCanvas**: render canvas inside a worker (great for graphics).

## Conclusion

Web Workers are a powerful tool to improve performance in modern web applications. Offloading heavy tasks from the main thread helps keep the UI smooth and user-friendly. Consider using Web Workers when you notice your browser lagging during complex operations.

## Introduction

In modern web applications, performance is a critical factor that directly affects the user experience. One of the main causes of lagging or UI blocking is due to heavy tasks being executed directly on the **main thread**.

To address this issue, JavaScript provides the **Web Workers** API, which allows running code in parallel in a separate thread, helping **avoid blocking the main thread** and **improving application performance**.

## 1. What are Web Workers?

Web Workers are a browser API that allows you to execute JavaScript in a separate thread from the main application thread.

- Web Workers can **communicate with the main thread** via `postMessage`.
- Ideal for handling: heavy computation, data analysis, image processing, file compression, etc.

## 2. Why use Web Workers?

### **Benefits**:
- **No UI blocking**: since it doesn't run on the main thread.
- **Better UX**: the UI remains responsive while the task is being processed.
- **Improved performance for complex calculations**.

### **Without Web Workers**:
- The UI can easily freeze when processing large JSON files, long loops, or complex algorithms.
- Users may think the app crashed if there's no response.

## 3. Example: Using Web Workers to Calculate Factorial

Suppose you need to calculate factorial (`n!`) of large numbers — this can be a task that slows down or freezes the UI if processed on the main thread. Web Workers help offload this task to a separate thread, ensuring a smooth UI.

We’ll build a simple example including:

- A **Web Worker file** to calculate factorial.
- A **React (TSX) component** with an input box, a button to send data to the worker, and `<p>` tags to display the result.

### 🧮 `factorialWorker.ts` – Worker file

```ts
self.onmessage = function (e) {
  const number = e.data;
  const result = factorial(number);
  self.postMessage(result);
};

function factorial(n: number): BigInt {
  let result = BigInt(1);
  for (let i = 2; i <= n; i++) {
    result *= BigInt(i);
  }
  return result;
}

export {};
```

### 🧑‍💻 `FactorialCalculator.tsx` – React component

```tsx
import React, { useState, useRef } from "react";

const FactorialCalculator: React.FC = () => {
  const [input, setInput] = useState<number>(100000);
  const [result, setResult] = useState<number | null>(null);
  const [loading, setLoading] = useState(false);
  const [totalTime, setTotalTime] = useState(0);
  const workerRef = useRef<Worker | null>(null);

  const handleCalculate = () => {
    setResult(null);
    setTotalTime(0);
    setLoading(true);
    const startTime = performance.now(); // Start timing

    const worker = new Worker(new URL("@src/worker/factorialWorker", import.meta.url));
    workerRef.current = worker;

    worker.postMessage(input);

    worker.onmessage = (e: MessageEvent<number>) => {
      const endTime = performance.now(); // End timing
      setTotalTime(endTime - startTime); // Calculate total time in milliseconds

      setResult(e.data);
      setLoading(false);
      worker.terminate();
    };
  };

  return (
    <div>
      <input
        type="number"
        value={input}
        onChange={(e) => setInput(Number(e.target.value))}
        placeholder="Enter a positive integer"
      />
      <button onClick={handleCalculate} disabled={loading}>
        {loading ? "Calculating..." : "Calculate Factorial"}
      </button>
      {result !== null && <p>Result: {result}</p>}
      {totalTime > 0 && <p>Calculation time: {totalTime.toFixed(3)} ms</p>}
    </div>
  );
};

export default FactorialCalculator;
```

Result:

| Without Web Worker | With Web Worker |
|--------------------|-----------------|
| ![Without Web Worker](/blogs/blog24/not-using-ww.gif) | ![With Web Worker](/blogs/blog24/using-ww.gif) |

As you can see, using a Web Worker results in a much smoother UI compared to not using one.

## 4. Notes When Using Web Workers

- You cannot access the DOM from inside a worker file.
- Make sure `postMessage` communication is clear and avoids race conditions.
- You can use `Comlink` to simplify communication.

## 5. When Should You Use Web Workers?

| Scenario | Should You Use a Worker? |
|----------|---------------------------|
| Heavy computation like encryption, file compression | ✅ Yes |
| Processing large JSON files (>1MB) | ✅ Yes |
| Simple UI updates | ❌ No |
| Fetch API, server calls | ❌ No (just use async/await 😄) |

## 6. Other Advanced Options

- **SharedWorker**: share a worker across multiple tabs.
- **Service Worker**: handles requests, caching – different from Web Worker.
- **OffscreenCanvas**: render canvas inside a worker (great for graphics).

## Conclusion

Web Workers are a powerful tool to improve performance in modern web applications. Offloading heavy tasks from the main thread helps keep the UI smooth and user-friendly. Consider using Web Workers when you notice your browser lagging during complex operations.

## Giới thiệu

Trong các ứng dụng web hiện đại, hiệu suất là một yếu tố quan trọng ảnh hưởng trực tiếp đến trải nghiệm người dùng. Một trong những nguyên nhân chính gây ra tình trạng giật lag, hoặc block UI là do các tác vụ tính toán nặng (heavy tasks) được thực thi trực tiếp ngay trên **(main thread)**.

Để giải quyết vấn đề này, JavaScript cung cấp giải pháp **Web Workers**, cho phép chạy các đoạn mã song song trong một luồng riêng biệt, giúp **tránh xử lí trên main thread** và **tăng hiệu suất ứng dụng**.

## 1. Web Workers là gì?

Web Workers là một API của trình duyệt cho phép bạn thực thi JavaScript trong một luồng riêng biệt với luồng chính của ứng dụng.

- Web Workers có thể **giao tiếp với main thread** thông qua `postMessage`.
- Phù hợp để xử lý: tính toán nặng, phân tích dữ liệu, xử lý ảnh, nén file,...

## 2. Tại sao nên sử dụng Web Workers?

### **Lợi ích**:
- **Không làm block UI**: vì không chạy trên luồng chính.
- **Cải thiện UX**: giao diện vẫn phản hồi trong khi xử lý tác vụ.
- **Tăng hiệu suất cho các tác vụ tính toán phức tạp**.

### **Khi không sử dụng Web Workers**:
- UI dễ bị đơ khi xử lý JSON lớn, vòng lặp nhiều, hoặc xử lí thuật toán nặng.
- User có thể nhầm tưởng ứng dụng bị crash nếu không phản hồi.

## 3. Ví dụ về cách sử dụng Web Workers cho bài toán tính giai thừa

Giả sử bạn cần thực hiện phép tính giai thừa (`n!`) với các số lớn – đây là một tác vụ có thể gây chậm hoặc "đơ" giao diện nếu xử lý trực tiếp trong main thread. Web Worker sẽ giúp tách việc xử lý ra luồng riêng, đảm bảo UI luôn mượt mà.

Chúng ta sẽ xây dựng một ví dụ đơn giản gồm:

- Một **file Web Worker** để tính giai thừa.
- Một **component React (TSX)** gồm ô input, button nhấn để gửi dữ liệu vào worker, và các thẻ p để hiển thị kết quả.

### 🧮 `factorialWorker.ts` – File worker

```ts
self.onmessage = function (e) {
  const number = e.data;
  const result = factorial(number);
  self.postMessage(result);
};

function factorial(n: number): BigInt {
  let result = BigInt(1);
  for (let i = 2; i <= n; i++) {
    result *= BigInt(i);
  }
  return result;
}

export {};
```


### 🧑‍💻 `FactorialCalculator.tsx` – React component

```tsx
import React, { useState, useRef } from "react";

const FactorialCalculator: React.FC = () => {
  const [input, setInput] = useState<number>(100000);
  const [result, setResult] = useState<number | null>(null);
  const [loading, setLoading] = useState(false);
  const [totalTime, setTotalTime] = useState(0);
  const workerRef = useRef<Worker | null>(null);

  const handleCalculate = () => {
    setResult(null);
    setTotalTime(0);
    setLoading(true);
    const startTime = performance.now(); // Start timing

    const worker = new Worker(new URL("@src/worker/factorialWorker", import.meta.url));
    workerRef.current = worker;

    worker.postMessage(input);

    worker.onmessage = (e: MessageEvent<number>) => {
      const endTime = performance.now(); // End timing
      setTotalTime(endTime - startTime); // Calculate total time in milliseconds

      setResult(e.data);
      setLoading(false);
      worker.terminate();
    };
  };

  return (
    <div>
      <input
        type="number"
        value={input}
        onChange={(e) => setInput(Number(e.target.value))}
        placeholder="Nhập số nguyên dương"
      />
      <button onClick={handleCalculate} disabled={loading}>
        {loading ? "Đang tính..." : "Tính giai thừa"}
      </button>
      {result !== null && <p>Kết quả: {result}</p>}
      {totalTime > 0 && <p>Thời gian tính toán: {totalTime.toFixed(3)} ms</p>}
    </div>
  );
};

export default FactorialCalculator;
```

Kết quả:

| Khi không sử dụng Web Worker | Khi sử dụng Web Worker |
|-----------|----------------------|
| ![Cách hoạt động của Web Worker](/blogs/blog24/not-using-ww.gif) | ![Cách hoạt động của Web Worker](/blogs/blog24/using-ww.gif) |


Ta có thể thấy khi sử dụng web-worker, UI mượt mà hơn rất nhiều so với khi không sử dụng nó.




## 4. Lưu ý khi sử dụng web worker

- Không thể truy cập đến DOM từ trong worker file.
- Đảm bảo luồng giao tiếp `postMessage` rõ ràng và không gây race condition.
- Có thể dùng `Comlink` để đơn giản hóa giao tiếp.

## 5. Khi nào nên dùng Web Workers?

| Tình huống | Có nên dùng Worker? |
|-----------|----------------------|
| Tính toán nặng như mã hóa, nén file | ✅ Cần |
| Xử lý file JSON lớn (>1MB) | ✅ Cần |
| Cập nhật UI đơn giản | ❌ Không cần |
| Fetch API, gọi server | ❌ Không cần (dùng async/await cho lẹ :D) |

## 6. Các option nâng cao khác

- **SharedWorker**: chia sẻ worker giữa nhiều tab.
- **Service Worker**: xử lý request, cache – khác với Web Worker.
- **OffscreenCanvas**: render canvas trong worker (đặc biệt hữu ích với đồ họa).

## Kết luận

Web Workers là công cụ mạnh mẽ giúp cải thiện hiệu suất của các ứng dụng web hiện đại. Việc tách biệt các tác vụ nặng ra khỏi luồng chính sẽ giúp UI luôn mượt mà, thân thiện với người dùng. Hãy cân nhắc sử dụng Web Workers khi bắt đầu thấy trình duyệt bị "lag" khi xử tác vụ phức tạp.

Learn how Web Workers help offload heavy computations from the main thread to improve performance and user experience.

Tìm hiểu cách Web Workers giúp tách tác vụ nặng ra khỏi luồng chính nhằm tăng hiệu suất và trải nghiệm người dùng.

Using Web Workers to Handle Heavy Tasks in the Browser

Sử dụng Web Workers để xử lý tác vụ nặng trong trình duyệt

## Debounce và Throttle là gì?

Khi người dùng tương tác với trang web – như gõ tìm kiếm, cuộn chuột, thay đổi kích thước trình duyệt – những hành động này có thể xảy ra liên tục và với tần suất rất cao. Nếu mỗi lần tương tác đó đều khiến JavaScript xử lý ngay lập tức, ứng dụng sẽ bị chậm, giật lag, thậm chí treo trình duyệt.

Đó là lý do tại sao chúng ta cần đến **debounce** và **throttle** – hai kỹ thuật đơn giản nhưng cực kỳ hữu ích để kiểm soát tần suất gọi hàm, giúp nâng cao hiệu suất và trải nghiệm người dùng.

---

## 1. Debounce là gì?

**Debounce** là một cơ chế giúp trì hoãn việc thực thi một hàm cho đến khi người dùng **dừng tương tác trong một khoảng thời gian nhất định**.

Nói cách khác, nếu người dùng cứ tiếp tục tương tác (ví dụ: tiếp tục gõ ký tự vào ô tìm kiếm), hàm sẽ không được gọi. Chỉ khi họ dừng lại (ví dụ: dừng gõ trong 300ms), hàm mới được thực thi.

### 🎯 Ví dụ thực tế:
Bạn đang làm tính năng tìm kiếm realtime. Mỗi khi người dùng gõ, bạn gọi API để lấy kết quả. Nếu họ gõ liên tục 10 ký tự, bạn không muốn gọi API 10 lần – mà chỉ gọi khi họ gõ xong. Debounce giúp bạn làm điều đó.

```ts
function debounce(fn, delay) {
  let timeout;
  return (...args) => {
    clearTimeout(timeout);
    timeout = setTimeout(() => fn(...args), delay);
  };
}

const handleSearch = debounce((query) => {
  console.log("Gọi API với:", query);
}, 300);

input.addEventListener("input", (e) => {
  handleSearch(e.target.value);
});
```

---

## 2. Throttle là gì?

**Throttle** hoạt động ngược lại một chút. Thay vì chờ người dùng dừng lại, throttle **giới hạn tần suất thực thi**: cứ mỗi khoảng thời gian cố định, hàm chỉ được gọi **một lần**, bất kể người dùng tương tác bao nhiêu.

### 🎯 Ví dụ thực tế:
Bạn muốn cập nhật vị trí cuộn trang khi người dùng scroll. Scroll có thể xảy ra hàng chục lần mỗi giây. Nếu mỗi lần đều xử lý logic nặng, trình duyệt sẽ chậm thấy rõ. Throttle giúp bạn chỉ gọi hàm xử lý scroll mỗi 200ms chẳng hạn.

```ts
function throttle(fn, interval) {
  let lastTime = 0;
  return (...args) => {
    const now = Date.now();
    if (now - lastTime >= interval) {
      lastTime = now;
      fn(...args);
    }
  };
}

const handleScroll = throttle(() => {
  console.log("Scroll vị trí:", window.scrollY);
}, 200);

window.addEventListener("scroll", handleScroll);
```

---

## 3. Khi nào dùng Debounce và Throttle?

| Tình huống sử dụng               | Nên dùng       | Giải thích |
|----------------------------------|----------------|------------|
| Người dùng gõ ô tìm kiếm         | `debounce`     | Chờ người dùng gõ xong mới gọi API |
| Resize cửa sổ trình duyệt        | `debounce`     | Tránh gọi lại logic resize liên tục |
| Theo dõi cuộn trang              | `throttle`     | Cập nhật thông tin cuộn mỗi khoảng thời gian |
| Kéo thả hoặc di chuyển chuột     | `throttle`     | Giới hạn số lần xử lý vị trí chuột |
| Validate form khi nhập           | `debounce`     | Chờ người dùng nhập xong trước khi kiểm tra |


## 4. So sánh nhanh giữa Debounce và Throttle

|                     | **Debounce**                                      | **Throttle**                                       |
|---------------------|--------------------------------------------------|----------------------------------------------------|
| Cách hoạt động      | Chờ đến khi không còn tương tác thì mới gọi hàm | Gọi hàm đều đặn sau mỗi khoảng thời gian cố định  |
| Tần suất thực thi   | Một lần sau cùng                                 | Nhiều lần nhưng giới hạn tần suất                 |
| Dễ hiểu như          | “Chờ yên mới làm”                                 | “Làm đều đặn, không quá thường xuyên”             |
| Trường hợp sử dụng  | Input, search, resize                            | Scroll, mouse move, resize                        |

Dưới đây là phần bổ sung về cách sử dụng **Lodash** với **debounce** và **throttle**:


## 5. Dùng Lodash để Cải Thiện Debounce và Throttle

Lodash cung cấp sẵn các hàm **`debounce`** và **`throttle`**, giúp bạn dễ dàng sử dụng mà không cần phải tự cài đặt lại các giải thuật.

### 🎯 Cách sử dụng Lodash với Debounce

Lodash cung cấp một hàm `debounce` rất dễ sử dụng, cho phép bạn chỉ cần truyền vào hàm cần gọi và thời gian trì hoãn. Ví dụ:

```ts
import { debounce } from "lodash";

const handleSearch = debounce((query) => {
  console.log("Calling API with:", query);
}, 300);

input.addEventListener("input", (e) => {
  handleSearch(e.target.value);
});
```

### 🎯 Cách sử dụng Lodash với Throttle

Tương tự như `debounce`, Lodash cũng cung cấp một hàm `throttle` để giới hạn tần suất thực thi hàm:

```ts
import { throttle } from "lodash";

const handleScroll = throttle(() => {
  console.log("Scroll position:", window.scrollY);
}, 200);

window.addEventListener("scroll", handleScroll);
```

Sử dụng Lodash giúp bạn tiết kiệm thời gian và tránh lỗi trong quá trình cài đặt lại các hàm debounce và throttle. Hơn nữa, Lodash còn hỗ trợ thêm nhiều tính năng tiện ích như kiểm tra kiểu dữ liệu, làm việc với mảng và đối tượng, giúp mã nguồn của bạn gọn gàng và dễ duy trì hơn.

## 6. Kết luận

Cả debounce và throttle đều là những kỹ thuật cực kỳ hữu ích để tối ưu hiệu suất trong các ứng dụng web hiện đại. Biết cách sử dụng đúng lúc, đúng chỗ không chỉ giúp code của bạn chạy mượt hơn mà còn nâng cao trải nghiệm người dùng một cách rõ rệt.

Hãy xem lại các tính năng của bạn – có thể đang có những đoạn code đang “chạy quá sức” mà chỉ cần một dòng debounce hoặc throttle là đủ để “giải cứu” chúng rồi đấy!




## What are Debounce and Throttle?

When users interact with your website – like typing into a search bar, scrolling the page, or resizing the window – those actions can happen frequently and rapidly. If your JavaScript code responds to every single event immediately, performance can degrade quickly.

That’s why **debounce** and **throttle** are essential techniques to control how often a function is executed, helping your application remain smooth and responsive.

---

## 1. What is Debounce?

**Debounce** ensures that a function is only executed after a specific amount of time has passed **without any further interaction**.

In other words, if the user keeps triggering the event (e.g., typing), the function will be delayed until they stop for a set time (e.g., 300ms).

### 🎯 Real-world example:
In a live search feature, you don’t want to call the API every time the user types a letter. Debounce waits until the user finishes typing and then makes a single call.

```ts
function debounce(fn, delay) {
  let timeout;
  return (...args) => {
    clearTimeout(timeout);
    timeout = setTimeout(() => fn(...args), delay);
  };
}

const handleSearch = debounce((query) => {
  console.log("Calling API with:", query);
}, 300);

input.addEventListener("input", (e) => {
  handleSearch(e.target.value);
});
```

---

## 2. What is Throttle?

**Throttle** limits how often a function can be called by **only allowing one call per specified time interval**.

### 🎯 Real-world example:
When tracking scroll events, you don’t want to run your logic dozens of times per second. Throttle ensures your function runs at regular intervals – say every 200ms – no matter how often the user scrolls.

```ts
function throttle(fn, interval) {
  let lastTime = 0;
  return (...args) => {
    const now = Date.now();
    if (now - lastTime >= interval) {
      lastTime = now;
      fn(...args);
    }
  };
}

const handleScroll = throttle(() => {
  console.log("Scroll position:", window.scrollY);
}, 200);

window.addEventListener("scroll", handleScroll);
```

---

## 3. When to Use Debounce vs Throttle?

| Use Case               | Choose          | Reason |
|------------------------|------------------|--------|
| Typing in search input | `debounce`       | Wait until the user stops typing |
| Window resize          | `debounce`       | Avoid frequent layout recalculations |
| Scroll tracking        | `throttle`       | Limit how often logic runs |
| Mouse move tracking    | `throttle`       | Prevent performance issues |
| Input validation       | `debounce`       | Reduce unnecessary validations |

## 4. Quick Comparison

|                     | **Debounce**                                    | **Throttle**                                   |
|---------------------|------------------------------------------------|-----------------------------------------------|
| How it works        | Waits for inactivity before running function   | Runs function at regular intervals             |
| Execution rate      | Once, after delay                              | Many times, but limited                       |
| Think of it like    | “Wait until user stops”                        | “Run every X ms”                              |
| Best for            | Search, resize                                 | Scroll, drag, mouse movement                  |


## 5. Using Lodash to Improve Debounce and Throttle

Lodash provides ready-made **`debounce`** and **`throttle`** functions, making it easier to use without needing to implement the algorithms from scratch.

### 🎯 How to Use Lodash with Debounce

Lodash provides a `debounce` function that is simple to use, allowing you to just pass in the function you want to call and the delay time. For example:

```ts
import { debounce } from "lodash";

const handleSearch = debounce((query) => {
  console.log("Calling API with:", query);
}, 300);

input.addEventListener("input", (e) => {
  handleSearch(e.target.value);
});
```

### 🎯 How to Use Lodash with Throttle

Similar to `debounce`, Lodash also provides a `throttle` function to limit the frequency of function execution:

```ts
import { throttle } from "lodash";

const handleScroll = throttle(() => {
  console.log("Scroll position:", window.scrollY);
}, 200);

window.addEventListener("scroll", handleScroll);
```

Using Lodash helps you save time and avoid errors when re-implementing debounce and throttle functions. Moreover, Lodash also supports many other useful utilities like type checking, array and object manipulation, making your code more concise and easier to maintain.


## 6. Conclusion

Debounce and throttle are powerful techniques that help you control how often your functions execute, making your web apps more efficient and user-friendly.

Next time you're working with real-time inputs or high-frequency events, consider whether your code needs a bit of “restraint” — and let debounce or throttle handle it for you!

## What are Debounce and Throttle?

When users interact with your website – like typing into a search bar, scrolling the page, or resizing the window – those actions can happen frequently and rapidly. If your JavaScript code responds to every single event immediately, performance can degrade quickly.

That’s why **debounce** and **throttle** are essential techniques to control how often a function is executed, helping your application remain smooth and responsive.

---

## 1. What is Debounce?

**Debounce** ensures that a function is only executed after a specific amount of time has passed **without any further interaction**.

In other words, if the user keeps triggering the event (e.g., typing), the function will be delayed until they stop for a set time (e.g., 300ms).

### 🎯 Real-world example:
In a live search feature, you don’t want to call the API every time the user types a letter. Debounce waits until the user finishes typing and then makes a single call.

```ts
function debounce(fn, delay) {
  let timeout;
  return (...args) => {
    clearTimeout(timeout);
    timeout = setTimeout(() => fn(...args), delay);
  };
}

const handleSearch = debounce((query) => {
  console.log("Calling API with:", query);
}, 300);

input.addEventListener("input", (e) => {
  handleSearch(e.target.value);
});
```

---

## 2. What is Throttle?

**Throttle** limits how often a function can be called by **only allowing one call per specified time interval**.

### 🎯 Real-world example:
When tracking scroll events, you don’t want to run your logic dozens of times per second. Throttle ensures your function runs at regular intervals – say every 200ms – no matter how often the user scrolls.

```ts
function throttle(fn, interval) {
  let lastTime = 0;
  return (...args) => {
    const now = Date.now();
    if (now - lastTime >= interval) {
      lastTime = now;
      fn(...args);
    }
  };
}

const handleScroll = throttle(() => {
  console.log("Scroll position:", window.scrollY);
}, 200);

window.addEventListener("scroll", handleScroll);
```

---

## 3. When to Use Debounce vs Throttle?

| Use Case               | Choose          | Reason |
|------------------------|------------------|--------|
| Typing in search input | `debounce`       | Wait until the user stops typing |
| Window resize          | `debounce`       | Avoid frequent layout recalculations |
| Scroll tracking        | `throttle`       | Limit how often logic runs |
| Mouse move tracking    | `throttle`       | Prevent performance issues |
| Input validation       | `debounce`       | Reduce unnecessary validations |

## 4. Quick Comparison

|                     | **Debounce**                                    | **Throttle**                                   |
|---------------------|------------------------------------------------|-----------------------------------------------|
| How it works        | Waits for inactivity before running function   | Runs function at regular intervals             |
| Execution rate      | Once, after delay                              | Many times, but limited                       |
| Think of it like    | “Wait until user stops”                        | “Run every X ms”                              |
| Best for            | Search, resize                                 | Scroll, drag, mouse movement                  |


## 5. Using Lodash to Improve Debounce and Throttle

Lodash provides ready-made **`debounce`** and **`throttle`** functions, making it easier to use without needing to implement the algorithms from scratch.

### 🎯 How to Use Lodash with Debounce

Lodash provides a `debounce` function that is simple to use, allowing you to just pass in the function you want to call and the delay time. For example:

```ts
import { debounce } from "lodash";

const handleSearch = debounce((query) => {
  console.log("Calling API with:", query);
}, 300);

input.addEventListener("input", (e) => {
  handleSearch(e.target.value);
});
```

### 🎯 How to Use Lodash with Throttle

Similar to `debounce`, Lodash also provides a `throttle` function to limit the frequency of function execution:

```ts
import { throttle } from "lodash";

const handleScroll = throttle(() => {
  console.log("Scroll position:", window.scrollY);
}, 200);

window.addEventListener("scroll", handleScroll);
```

Using Lodash helps you save time and avoid errors when re-implementing debounce and throttle functions. Moreover, Lodash also supports many other useful utilities like type checking, array and object manipulation, making your code more concise and easier to maintain.


## 6. Conclusion

Debounce and throttle are powerful techniques that help you control how often your functions execute, making your web apps more efficient and user-friendly.

Next time you're working with real-time inputs or high-frequency events, consider whether your code needs a bit of “restraint” — and let debounce or throttle handle it for you!

## Debounce và Throttle là gì?

Khi người dùng tương tác với trang web – như gõ tìm kiếm, cuộn chuột, thay đổi kích thước trình duyệt – những hành động này có thể xảy ra liên tục và với tần suất rất cao. Nếu mỗi lần tương tác đó đều khiến JavaScript xử lý ngay lập tức, ứng dụng sẽ bị chậm, giật lag, thậm chí treo trình duyệt.

Đó là lý do tại sao chúng ta cần đến **debounce** và **throttle** – hai kỹ thuật đơn giản nhưng cực kỳ hữu ích để kiểm soát tần suất gọi hàm, giúp nâng cao hiệu suất và trải nghiệm người dùng.

---

## 1. Debounce là gì?

**Debounce** là một cơ chế giúp trì hoãn việc thực thi một hàm cho đến khi người dùng **dừng tương tác trong một khoảng thời gian nhất định**.

Nói cách khác, nếu người dùng cứ tiếp tục tương tác (ví dụ: tiếp tục gõ ký tự vào ô tìm kiếm), hàm sẽ không được gọi. Chỉ khi họ dừng lại (ví dụ: dừng gõ trong 300ms), hàm mới được thực thi.

### 🎯 Ví dụ thực tế:
Bạn đang làm tính năng tìm kiếm realtime. Mỗi khi người dùng gõ, bạn gọi API để lấy kết quả. Nếu họ gõ liên tục 10 ký tự, bạn không muốn gọi API 10 lần – mà chỉ gọi khi họ gõ xong. Debounce giúp bạn làm điều đó.

```ts
function debounce(fn, delay) {
  let timeout;
  return (...args) => {
    clearTimeout(timeout);
    timeout = setTimeout(() => fn(...args), delay);
  };
}

const handleSearch = debounce((query) => {
  console.log("Gọi API với:", query);
}, 300);

input.addEventListener("input", (e) => {
  handleSearch(e.target.value);
});
```

---

## 2. Throttle là gì?

**Throttle** hoạt động ngược lại một chút. Thay vì chờ người dùng dừng lại, throttle **giới hạn tần suất thực thi**: cứ mỗi khoảng thời gian cố định, hàm chỉ được gọi **một lần**, bất kể người dùng tương tác bao nhiêu.

### 🎯 Ví dụ thực tế:
Bạn muốn cập nhật vị trí cuộn trang khi người dùng scroll. Scroll có thể xảy ra hàng chục lần mỗi giây. Nếu mỗi lần đều xử lý logic nặng, trình duyệt sẽ chậm thấy rõ. Throttle giúp bạn chỉ gọi hàm xử lý scroll mỗi 200ms chẳng hạn.

```ts
function throttle(fn, interval) {
  let lastTime = 0;
  return (...args) => {
    const now = Date.now();
    if (now - lastTime >= interval) {
      lastTime = now;
      fn(...args);
    }
  };
}

const handleScroll = throttle(() => {
  console.log("Scroll vị trí:", window.scrollY);
}, 200);

window.addEventListener("scroll", handleScroll);
```

---

## 3. Khi nào dùng Debounce và Throttle?

| Tình huống sử dụng               | Nên dùng       | Giải thích |
|----------------------------------|----------------|------------|
| Người dùng gõ ô tìm kiếm         | `debounce`     | Chờ người dùng gõ xong mới gọi API |
| Resize cửa sổ trình duyệt        | `debounce`     | Tránh gọi lại logic resize liên tục |
| Theo dõi cuộn trang              | `throttle`     | Cập nhật thông tin cuộn mỗi khoảng thời gian |
| Kéo thả hoặc di chuyển chuột     | `throttle`     | Giới hạn số lần xử lý vị trí chuột |
| Validate form khi nhập           | `debounce`     | Chờ người dùng nhập xong trước khi kiểm tra |


## 4. So sánh nhanh giữa Debounce và Throttle

|                     | **Debounce**                                      | **Throttle**                                       |
|---------------------|--------------------------------------------------|----------------------------------------------------|
| Cách hoạt động      | Chờ đến khi không còn tương tác thì mới gọi hàm | Gọi hàm đều đặn sau mỗi khoảng thời gian cố định  |
| Tần suất thực thi   | Một lần sau cùng                                 | Nhiều lần nhưng giới hạn tần suất                 |
| Dễ hiểu như          | “Chờ yên mới làm”                                 | “Làm đều đặn, không quá thường xuyên”             |
| Trường hợp sử dụng  | Input, search, resize                            | Scroll, mouse move, resize                        |

Dưới đây là phần bổ sung về cách sử dụng **Lodash** với **debounce** và **throttle**:


## 5. Dùng Lodash để Cải Thiện Debounce và Throttle

Lodash cung cấp sẵn các hàm **`debounce`** và **`throttle`**, giúp bạn dễ dàng sử dụng mà không cần phải tự cài đặt lại các giải thuật.

### 🎯 Cách sử dụng Lodash với Debounce

Lodash cung cấp một hàm `debounce` rất dễ sử dụng, cho phép bạn chỉ cần truyền vào hàm cần gọi và thời gian trì hoãn. Ví dụ:

```ts
import { debounce } from "lodash";

const handleSearch = debounce((query) => {
  console.log("Calling API with:", query);
}, 300);

input.addEventListener("input", (e) => {
  handleSearch(e.target.value);
});
```

### 🎯 Cách sử dụng Lodash với Throttle

Tương tự như `debounce`, Lodash cũng cung cấp một hàm `throttle` để giới hạn tần suất thực thi hàm:

```ts
import { throttle } from "lodash";

const handleScroll = throttle(() => {
  console.log("Scroll position:", window.scrollY);
}, 200);

window.addEventListener("scroll", handleScroll);
```

Sử dụng Lodash giúp bạn tiết kiệm thời gian và tránh lỗi trong quá trình cài đặt lại các hàm debounce và throttle. Hơn nữa, Lodash còn hỗ trợ thêm nhiều tính năng tiện ích như kiểm tra kiểu dữ liệu, làm việc với mảng và đối tượng, giúp mã nguồn của bạn gọn gàng và dễ duy trì hơn.

## 6. Kết luận

Cả debounce và throttle đều là những kỹ thuật cực kỳ hữu ích để tối ưu hiệu suất trong các ứng dụng web hiện đại. Biết cách sử dụng đúng lúc, đúng chỗ không chỉ giúp code của bạn chạy mượt hơn mà còn nâng cao trải nghiệm người dùng một cách rõ rệt.

Hãy xem lại các tính năng của bạn – có thể đang có những đoạn code đang “chạy quá sức” mà chỉ cần một dòng debounce hoặc throttle là đủ để “giải cứu” chúng rồi đấy!

Understand the difference between debounce and throttle in JavaScript and how to apply them effectively

Hiểu sự khác nhau giữa debounce và throttle trong JavaScript và cách áp dụng chúng hiệu quả

Debounce vs Throttle in JavaScript: When and Why to Use Them?

Debounce và Throttle trong JavaScript: Khi nào dùng và vì sao?

## Cách browser thực thi JavaScript: Hiểu rõ `defer`, `async`, và `inline`

Khi bạn nhúng JavaScript vào HTML, việc browser **thực thi script ở đâu và khi nào** sẽ ảnh hưởng trực tiếp đến **hiệu suất tải trang**, **trải nghiệm người dùng**, và **thứ tự thực thi code**.

3 phương pháp phổ biến để nhúng script là:

- **Inline script**
- **Script với `defer`**
- **Script với `async`**

Hiểu rõ sự khác nhau giữa chúng là kỹ năng quan trọng của một frontend developer.

---

## 1. Inline script là gì?

Inline script là đoạn JavaScript được viết trực tiếp trong file HTML, thường nằm trong thẻ `<script>` không có thuộc tính `src`.

Ví dụ:

```html
<script>
  console.log("Hello from inline script");
</script>
```

### Đặc điểm:

- **Thực thi ngay lập tức** khi trình duyệt parser đến đoạn này.
- **Chặn quá trình render HTML tiếp theo** cho đến khi script thực thi xong.
- Không thể cache vì nằm trực tiếp trong HTML.

### Khi nào nên dùng?

- Đoạn script nhỏ, chạy rất nhanh (dưới 1–2ms).
- Các biến cấu hình cần thiết sớm (như `window.__ENV__ = {...}`).
- Tracking code bắt buộc chạy đầu tiên (như Google Tag Manager snippet).

---

## 2. Script có thuộc tính `defer`

Ví dụ:

```html
<script defer src="/main.js"></script>
```

### Đặc điểm:

- **Tải song song với quá trình phân tích HTML.**
- **Chỉ thực thi sau khi toàn bộ HTML đã được parser xong.**
- **Giữ thứ tự** giữa các script có `defer`.

Trình duyệt sẽ:

1. Bắt đầu phân tích HTML.
2. Gặp `<script defer>`, tải file JS song song.
3. Tiếp tục phân tích HTML.
4. Sau khi HTML parser xong → thực thi các script `defer` theo thứ tự.

> Ưu điểm lớn của `defer` là **không chặn render** và **giữ được thứ tự**.

---

## 3. Script có thuộc tính `async`

Ví dụ:

```html
<script async src="/analytics.js"></script>
```

### Đặc điểm:

- **Tải song song với HTML**, **thực thi ngay khi tải xong**, **không chờ HTML parser hoàn tất.**
- **Không đảm bảo thứ tự** giữa các script async.

Tức là:

- Nếu `analytics.js` tải xong trước `ads.js`, nó sẽ chạy trước, bất kể thứ tự bạn khai báo.
- Trong lúc chạy `async`, việc parser HTML sẽ **tạm dừng** → có thể gây layout jank nhẹ.

> Sử dụng `async` khi script **độc lập**, không phụ thuộc vào nội dung DOM hoặc các script khác.

---

## So sánh `inline`, `defer`, `async`

| Thuộc tính       | Tải song song | Chặn HTML parser | Thực thi sau HTML parser | Giữ thứ tự |
|------------------|---------------|-------------------|---------------------------|-------------|
| Inline           | ❌            | ✅                | ❌                        | ✅          |
| `<script defer>` | ✅            | ❌                | ✅                        | ✅          |
| `<script async>` | ✅            | ❌ (tạm)          | ❌                        | ❌          |

---

## Khi nào dùng cái nào?

| Tình huống | Cách dùng đề xuất |
|------------|-------------------|
| Script phụ thuộc vào DOM (manipulate DOM) | `defer` |
| Script tracking, analytics, ads độc lập | `async` |
| Biến cấu hình nhỏ cần sớm | `inline` |
| Thư viện JS lớn như React, Vue | `defer` |

---

## Bonus: Dùng `type="module"` có tác dụng gì?

Từ HTML5+, bạn có thể dùng:

```html
<script type="module" src="/app.js"></script>
```

Tự động **ngầm hiểu là `defer`**, nên:

- Không chặn HTML parser.
- Được thực thi sau khi HTML đã parser xong.
- Hỗ trợ `import/export`.

> `type="module"` thích hợp khi bạn dùng ES Modules và bundler hiện đại như Vite, Webpack, hoặc Next.js.

---

## Kết luận

Hiểu được `defer`, `async`, và `inline` sẽ giúp bạn:

- Kiểm soát được **trình tự thực thi script**
- **Tối ưu hiệu suất tải trang**
- Tránh bug do script chạy trước khi DOM sẵn sàng

Hãy chọn cách nhúng script phù hợp với mục đích sử dụng và đặc điểm của từng loại để mang lại trải nghiệm tốt nhất cho người dùng.



## How Browsers Execute JavaScript: Understanding `defer`, `async`, and `inline`

When you embed JavaScript in HTML, the **location and timing** of execution will directly affect the **page load performance**, **user experience**, and **execution order** of the code.

Three common methods to include JavaScript are:

- **Inline script**
- **Script with `defer`**
- **Script with `async`**

Understanding the differences between these methods is a key skill for any frontend developer.

---

## 1. What is Inline Script?

An inline script is a JavaScript code that is written directly within the HTML file, typically inside a `<script>` tag without the `src` attribute.

Example:

```html
<script>
  console.log("Hello from inline script");
</script>
```

### Characteristics:

- **Executes immediately** when the browser parser encounters it.
- **Blocks further HTML rendering** until the script finishes executing.
- Cannot be cached, as it's directly in the HTML.

### When should you use it?

- For small, quick scripts (under 1-2ms).
- For configuration variables that need to be available early (like `window.__ENV__ = {...}`).
- For tracking scripts that must execute first (like Google Tag Manager snippet).

---

## 2. What is a `defer` Script?

Example:

```html
<script defer src="/main.js"></script>
```

### Characteristics:

- **Loads in parallel with the HTML parsing.**
- **Executes after the HTML has been fully parsed.**
- **Maintains the order** of deferred scripts.

In this case, the browser will:

1. Start parsing the HTML.
2. Encounter the `<script defer>` tag, loading the JS file in parallel.
3. Continue parsing the rest of the HTML.
4. After the HTML parsing is complete, execute the deferred scripts in the order they were encountered.

> The main advantage of `defer` is that it **does not block rendering** and **preserves execution order**.

---

## 3. What is an `async` Script?

Example:

```html
<script async src="/analytics.js"></script>
```

### Characteristics:

- **Loads in parallel with HTML**, **executes as soon as it's loaded**, **does not wait for the HTML parser to finish.**
- **Does not maintain order** between async scripts.

In this case:

- If `analytics.js` finishes loading before `ads.js`, it will execute first, regardless of the order you declared them in.
- While an async script is executing, the HTML parsing **pauses**, which may cause layout jank.

> Use `async` for **independent scripts** that don’t rely on the DOM or other scripts.

---

## Comparison of `inline`, `defer`, and `async`

| Attribute        | Loads in Parallel | Blocks HTML Parsing | Executes After HTML Parsing | Maintains Order |
|------------------|-------------------|----------------------|-----------------------------|-----------------|
| Inline           | ❌                | ✅                   | ❌                         | ✅              |
| `<script defer>` | ✅                | ❌                   | ✅                         | ✅              |
| `<script async>` | ✅                | ❌ (temporarily)     | ❌                         | ❌              |

---

## When Should You Use Which?

| Scenario                              | Recommended Usage |
|---------------------------------------|-------------------|
| Scripts that depend on DOM (manipulate DOM) | `defer` |
| Independent tracking, analytics, ads scripts | `async` |
| Small configuration variables that need to run early | `inline` |
| Large JavaScript libraries like React, Vue | `defer` |

---

## Bonus: What Does `type="module"` Do?

Starting from HTML5+, you can use:

```html
<script type="module" src="/app.js"></script>
```

This implicitly means **`defer`**, so:

- Does not block HTML parsing.
- Executes after HTML parsing completes.
- Supports `import/export`.

> `type="module"` is ideal when using ES Modules and modern bundlers like Vite, Webpack, or Next.js.

---

## Conclusion

Understanding `defer`, `async`, and `inline` allows you to:

- Control the **order of script execution**.
- **Optimize page load performance**.
- Avoid bugs caused by scripts executing before the DOM is ready.

Choose the appropriate method for embedding scripts based on the use case to ensure the best possible user experience.

## How Browsers Execute JavaScript: Understanding `defer`, `async`, and `inline`

When you embed JavaScript in HTML, the **location and timing** of execution will directly affect the **page load performance**, **user experience**, and **execution order** of the code.

Three common methods to include JavaScript are:

- **Inline script**
- **Script with `defer`**
- **Script with `async`**

Understanding the differences between these methods is a key skill for any frontend developer.

---

## 1. What is Inline Script?

An inline script is a JavaScript code that is written directly within the HTML file, typically inside a `<script>` tag without the `src` attribute.

Example:

```html
<script>
  console.log("Hello from inline script");
</script>
```

### Characteristics:

- **Executes immediately** when the browser parser encounters it.
- **Blocks further HTML rendering** until the script finishes executing.
- Cannot be cached, as it's directly in the HTML.

### When should you use it?

- For small, quick scripts (under 1-2ms).
- For configuration variables that need to be available early (like `window.__ENV__ = {...}`).
- For tracking scripts that must execute first (like Google Tag Manager snippet).

---

## 2. What is a `defer` Script?

Example:

```html
<script defer src="/main.js"></script>
```

### Characteristics:

- **Loads in parallel with the HTML parsing.**
- **Executes after the HTML has been fully parsed.**
- **Maintains the order** of deferred scripts.

In this case, the browser will:

1. Start parsing the HTML.
2. Encounter the `<script defer>` tag, loading the JS file in parallel.
3. Continue parsing the rest of the HTML.
4. After the HTML parsing is complete, execute the deferred scripts in the order they were encountered.

> The main advantage of `defer` is that it **does not block rendering** and **preserves execution order**.

---

## 3. What is an `async` Script?

Example:

```html
<script async src="/analytics.js"></script>
```

### Characteristics:

- **Loads in parallel with HTML**, **executes as soon as it's loaded**, **does not wait for the HTML parser to finish.**
- **Does not maintain order** between async scripts.

In this case:

- If `analytics.js` finishes loading before `ads.js`, it will execute first, regardless of the order you declared them in.
- While an async script is executing, the HTML parsing **pauses**, which may cause layout jank.

> Use `async` for **independent scripts** that don’t rely on the DOM or other scripts.

---

## Comparison of `inline`, `defer`, and `async`

| Attribute        | Loads in Parallel | Blocks HTML Parsing | Executes After HTML Parsing | Maintains Order |
|------------------|-------------------|----------------------|-----------------------------|-----------------|
| Inline           | ❌                | ✅                   | ❌                         | ✅              |
| `<script defer>` | ✅                | ❌                   | ✅                         | ✅              |
| `<script async>` | ✅                | ❌ (temporarily)     | ❌                         | ❌              |

---

## When Should You Use Which?

| Scenario                              | Recommended Usage |
|---------------------------------------|-------------------|
| Scripts that depend on DOM (manipulate DOM) | `defer` |
| Independent tracking, analytics, ads scripts | `async` |
| Small configuration variables that need to run early | `inline` |
| Large JavaScript libraries like React, Vue | `defer` |

---

## Bonus: What Does `type="module"` Do?

Starting from HTML5+, you can use:

```html
<script type="module" src="/app.js"></script>
```

This implicitly means **`defer`**, so:

- Does not block HTML parsing.
- Executes after HTML parsing completes.
- Supports `import/export`.

> `type="module"` is ideal when using ES Modules and modern bundlers like Vite, Webpack, or Next.js.

---

## Conclusion

Understanding `defer`, `async`, and `inline` allows you to:

- Control the **order of script execution**.
- **Optimize page load performance**.
- Avoid bugs caused by scripts executing before the DOM is ready.

Choose the appropriate method for embedding scripts based on the use case to ensure the best possible user experience.

## Cách browser thực thi JavaScript: Hiểu rõ `defer`, `async`, và `inline`

Khi bạn nhúng JavaScript vào HTML, việc browser **thực thi script ở đâu và khi nào** sẽ ảnh hưởng trực tiếp đến **hiệu suất tải trang**, **trải nghiệm người dùng**, và **thứ tự thực thi code**.

3 phương pháp phổ biến để nhúng script là:

- **Inline script**
- **Script với `defer`**
- **Script với `async`**

Hiểu rõ sự khác nhau giữa chúng là kỹ năng quan trọng của một frontend developer.

---

## 1. Inline script là gì?

Inline script là đoạn JavaScript được viết trực tiếp trong file HTML, thường nằm trong thẻ `<script>` không có thuộc tính `src`.

Ví dụ:

```html
<script>
  console.log("Hello from inline script");
</script>
```

### Đặc điểm:

- **Thực thi ngay lập tức** khi trình duyệt parser đến đoạn này.
- **Chặn quá trình render HTML tiếp theo** cho đến khi script thực thi xong.
- Không thể cache vì nằm trực tiếp trong HTML.

### Khi nào nên dùng?

- Đoạn script nhỏ, chạy rất nhanh (dưới 1–2ms).
- Các biến cấu hình cần thiết sớm (như `window.__ENV__ = {...}`).
- Tracking code bắt buộc chạy đầu tiên (như Google Tag Manager snippet).

---

## 2. Script có thuộc tính `defer`

Ví dụ:

```html
<script defer src="/main.js"></script>
```

### Đặc điểm:

- **Tải song song với quá trình phân tích HTML.**
- **Chỉ thực thi sau khi toàn bộ HTML đã được parser xong.**
- **Giữ thứ tự** giữa các script có `defer`.

Trình duyệt sẽ:

1. Bắt đầu phân tích HTML.
2. Gặp `<script defer>`, tải file JS song song.
3. Tiếp tục phân tích HTML.
4. Sau khi HTML parser xong → thực thi các script `defer` theo thứ tự.

> Ưu điểm lớn của `defer` là **không chặn render** và **giữ được thứ tự**.

---

## 3. Script có thuộc tính `async`

Ví dụ:

```html
<script async src="/analytics.js"></script>
```

### Đặc điểm:

- **Tải song song với HTML**, **thực thi ngay khi tải xong**, **không chờ HTML parser hoàn tất.**
- **Không đảm bảo thứ tự** giữa các script async.

Tức là:

- Nếu `analytics.js` tải xong trước `ads.js`, nó sẽ chạy trước, bất kể thứ tự bạn khai báo.
- Trong lúc chạy `async`, việc parser HTML sẽ **tạm dừng** → có thể gây layout jank nhẹ.

> Sử dụng `async` khi script **độc lập**, không phụ thuộc vào nội dung DOM hoặc các script khác.

---

## So sánh `inline`, `defer`, `async`

| Thuộc tính       | Tải song song | Chặn HTML parser | Thực thi sau HTML parser | Giữ thứ tự |
|------------------|---------------|-------------------|---------------------------|-------------|
| Inline           | ❌            | ✅                | ❌                        | ✅          |
| `<script defer>` | ✅            | ❌                | ✅                        | ✅          |
| `<script async>` | ✅            | ❌ (tạm)          | ❌                        | ❌          |

---

## Khi nào dùng cái nào?

| Tình huống | Cách dùng đề xuất |
|------------|-------------------|
| Script phụ thuộc vào DOM (manipulate DOM) | `defer` |
| Script tracking, analytics, ads độc lập | `async` |
| Biến cấu hình nhỏ cần sớm | `inline` |
| Thư viện JS lớn như React, Vue | `defer` |

---

## Bonus: Dùng `type="module"` có tác dụng gì?

Từ HTML5+, bạn có thể dùng:

```html
<script type="module" src="/app.js"></script>
```

Tự động **ngầm hiểu là `defer`**, nên:

- Không chặn HTML parser.
- Được thực thi sau khi HTML đã parser xong.
- Hỗ trợ `import/export`.

> `type="module"` thích hợp khi bạn dùng ES Modules và bundler hiện đại như Vite, Webpack, hoặc Next.js.

---

## Kết luận

Hiểu được `defer`, `async`, và `inline` sẽ giúp bạn:

- Kiểm soát được **trình tự thực thi script**
- **Tối ưu hiệu suất tải trang**
- Tránh bug do script chạy trước khi DOM sẵn sàng

Hãy chọn cách nhúng script phù hợp với mục đích sử dụng và đặc điểm của từng loại để mang lại trải nghiệm tốt nhất cho người dùng.

An explanation of the differences between defer, async, and inline in JavaScript execution and how they impact web performance.

Giải thích sự khác nhau giữa defer, async, và inline trong việc thực thi JavaScript và cách chúng ảnh hưởng đến hiệu suất trang web.

Defer - Async - Inline, how Browsers Execute JavaScript

Defer - Async - Inline, cách browser thực thi JavaScript

## Vì sao bạn cần hiểu Reflow, Repaint và Layout Shift?

Khi xây dựng giao diện web, đặc biệt là các ứng dụng SPA hay các trang thương mại điện tử, bạn thường tối ưu hình ảnh, bundle nhỏ gọn, code chia nhỏ... Nhưng có một thứ tinh tế mà đôi khi chúng ta bỏ qua: **trải nghiệm người dùng khi trang đang render**.

Các hiện tượng như:

- Giao diện bị “nhảy” khi ảnh vừa tải xong
- Văn bản tự động bị đẩy xuống vì banner xuất hiện chậm
- Người dùng định click thì nút trượt sang chỗ khác

Tất cả đều liên quan đến **Reflow**, **Repaint**, và **Layout Shift**. Và những điều này ảnh hưởng trực tiếp đến **CLS – Cumulative Layout Shift**, một chỉ số quan trọng trong Core Web Vitals của Google.

---

## Reflow là gì?

**Reflow (hay còn gọi là Layout)** là quá trình trình duyệt tính toán lại kích thước và vị trí của các phần tử trên trang.

Reflow xảy ra khi:

- Thêm, xóa hoặc thay đổi phần tử DOM
- Thay đổi các thuộc tính CSS như `width`, `font-size`, `position`, `display`...
- Thay đổi nội dung text
- Kích thước cửa sổ trình duyệt thay đổi (resize)

Ví dụ:

```js
element.style.width = "200px";
```

Thao tác này yêu cầu trình duyệt tính toán lại bố cục các phần tử liên quan – đó chính là Reflow.

> Reflow rất tốn kém tài nguyên. Một thay đổi nhỏ có thể ảnh hưởng đến nhiều phần tử, đặc biệt trong layout phức tạp.

---

## Repaint là gì?

**Repaint** là quá trình vẽ lại phần tử trên màn hình mà **không cần tính toán lại layout**.

Repaint xảy ra khi:

- Thay đổi màu sắc (`background-color`, `color`)
- Thay đổi `visibility`
- Đổ bóng, viền, opacity…

Ví dụ:

```js
element.style.backgroundColor = "blue";
```

Không cần tính lại bố cục, chỉ cần tô lại màu => Repaint.

> So với Reflow, Repaint nhẹ hơn. Tuy nhiên nếu diễn ra liên tục (ví dụ animation không tối ưu), vẫn gây drop FPS và lag.

---

## Layout Shift là gì?

**Layout Shift** xảy ra khi một phần tử bất ngờ thay đổi vị trí trên màn hình **mà người dùng không tương tác gì cả**. Khi điều này xảy ra quá nhiều hoặc quá trễ, trải nghiệm người dùng sẽ bị ảnh hưởng mạnh mẽ.

Đây chính là thứ mà **CLS – Cumulative Layout Shift** đo lường.

Một số nguyên nhân phổ biến:

- Ảnh chưa có kích thước trước khi tải => ảnh “đẩy” phần tử khác xuống
- Font hiển thị muộn => văn bản bị dịch chuyển (FOIT/FOUT)
- Quảng cáo, popup render trễ => đẩy nội dung đi
- Sử dụng JavaScript thêm nội dung bất ngờ vào DOM

---

## Cách đo CLS (Cumulative Layout Shift)

CLS đo bằng công thức:

```text
CLS = Tổng Layout Shift Score = Impact Fraction * Distance Fraction
```

Nói đơn giản:

- **Impact Fraction**: bao nhiêu phần trăm vùng màn hình bị thay đổi
- **Distance Fraction**: khoảng cách phần tử đã bị dịch chuyển bao nhiêu

> Google khuyến nghị: **CLS < 0.1** để đạt tiêu chuẩn tốt cho Core Web Vitals.

---

## Cách giảm Reflow và Repaint không cần thiết

1. **Tránh thao tác DOM liên tục**

```js
// KHÔNG nên
for (let i = 0; i < 100; i++) {
  document.body.style.margin = `${i}px`;
}

// NÊN
document.body.style.margin = "100px";
```

2. **Dùng class thay vì thay đổi style trực tiếp**

```js
element.classList.add("expanded"); // Gọn hơn, dễ maintain
```

3. **Đọc và ghi DOM riêng biệt**

```js
const height = element.offsetHeight; // Đọc layout
element.style.height = height + 10 + "px"; // Ghi layout

// Gộp nhiều thay đổi vào cùng một frame
requestAnimationFrame(() => {
  // Thay đổi nhiều thứ tại đây
});
```

---

## Cách tối ưu để tránh CLS cao

### 1. Luôn đặt chiều cao cố định cho ảnh

```html
<img src="/logo.png" width="200" height="100" alt="Logo" />
```

Hoặc dùng CSS:

```css
img { 
  aspect-ratio: 2 / 1;
}
```

> Next.js dùng `next/image` sẽ tự động xử lý việc này.

---

### 2. Tránh font nhảy – preload font sớm

```html
<link rel="preload" href="/fonts/custom.woff2" as="font" type="font/woff2" crossorigin="anonymous" />
```

Hoặc dùng `font-display: swap` để tránh chặn render quá lâu.

---

### 3. Đặt chỗ sẵn cho component động (banner, quảng cáo...)

Nếu biết chiều cao của một thành phần sẽ xuất hiện muộn, hãy dành sẵn khoảng trống trong layout:

```css
.banner-placeholder {
  min-height: 120px;
}
```

---

### 4. Tránh chèn DOM bất ngờ từ JS

Hạn chế `setTimeout` để render component động sau vài giây. Nếu cần animation, dùng `opacity`, `transform` để transition mượt mà mà không gây layout shift.

---

## Tổng kết

Reflow, Repaint và Layout Shift là ba yếu tố quan trọng ảnh hưởng trực tiếp đến trải nghiệm người dùng – và đặc biệt là chỉ số CLS trong Core Web Vitals.

Việc hiểu cách trình duyệt hoạt động giúp bạn:

- Tối ưu hiệu suất mà không cần chỉ nhìn vào Lighthouse
- Tránh “trượt điểm” SEO vì lỗi UX
- Làm chủ frontend một cách chuyên nghiệp hơn

Hãy bắt đầu tối ưu từ những điều nhỏ: đặt kích thước ảnh, preload font, tránh layout shift không cần thiết. Dần dần, bạn sẽ thấy trang web mượt mà hơn, nhanh hơn – và người dùng hài lòng hơn.



## Why should you understand Reflow, Repaint, and Layout Shift?

When building a website UI—especially in modern SPAs or e-commerce pages—you might already optimize images, split your code, lazy load, or minify scripts. But there's one subtle yet crucial aspect many developers overlook: **how stable and smooth the page appears while rendering**.

You may have seen things like:

- The layout “jumps” after an image finishes loading  
- A block of text suddenly moves down because of a late banner  
- A button shifts right when the user is just about to click it  

All of these are related to **Reflow**, **Repaint**, and **Layout Shift**. These behaviors directly impact **CLS – Cumulative Layout Shift**, one of the key metrics in Google’s Core Web Vitals.

---

## What is Reflow?

**Reflow** (also called **Layout**) is when the browser recalculates the size and position of elements on the page.

Reflow is triggered when:

- A DOM element is added, removed, or modified  
- CSS properties like `width`, `font-size`, `position`, `display`, etc. are changed  
- Text content is updated  
- The browser window is resized  

For example:

```js
element.style.width = "200px";
```

This forces the browser to recalculate the layout for that element and potentially for its siblings, parent, or children—hence, a reflow.

> Reflow is resource-intensive. A small change can cascade and affect many parts of the layout, especially in complex structures.

---

## What is Repaint?

**Repaint** is when the browser redraws elements visually **without recalculating their layout**.

Repaint happens when:

- You change styles like `background-color`, `color`, `border`, or `visibility`  
- You apply shadow effects, opacity changes, etc.

Example:

```js
element.style.backgroundColor = "blue";
```

No layout change needed, just visual re-rendering.

> Repaint is less expensive than Reflow, but if triggered repeatedly (e.g., through poorly optimized animations), it can still hurt performance.

---

## What is Layout Shift?

**Layout Shift** refers to elements unexpectedly moving on the screen **without user interaction**. If this happens too often or too late in the load process, it can lead to a very poor user experience.

This is exactly what **CLS – Cumulative Layout Shift** measures.

Common causes:

- Images that load without predefined dimensions  
- Custom fonts replacing fallback fonts (FOIT/FOUT)  
- Late-loaded ads or banners pushing content around  
- JavaScript injecting DOM elements dynamically without space reservations  

---

## How is CLS calculated?

CLS is determined by this formula:

```text
CLS = Total Layout Shift Score = Impact Fraction × Distance Fraction
```

Simply put:

- **Impact Fraction**: how much of the screen is affected by the shift  
- **Distance Fraction**: how far the shifted elements move  

> Google recommends keeping CLS **below 0.1** for good Core Web Vitals.

---

## How to reduce unnecessary Reflows and Repaints

1. **Avoid continuous DOM manipulations**

```js
// NOT recommended
for (let i = 0; i < 100; i++) {
  document.body.style.margin = `${i}px`;
}

// Recommended
document.body.style.margin = "100px";
```

2. **Use CSS classes instead of inline styles**

```js
element.classList.add("expanded");
```

3. **Read and write DOM separately**

```js
const height = element.offsetHeight; // Read layout
element.style.height = height + 10 + "px"; // Write layout

// Better: batch DOM updates in requestAnimationFrame
requestAnimationFrame(() => {
  // Make multiple changes here
});
```

---

## How to optimize and reduce CLS

### 1. Always set fixed dimensions for images

```html
<img src="/logo.png" width="200" height="100" alt="Logo" />
```

Or use CSS:

```css
img {
  aspect-ratio: 2 / 1;
}
```

> If you’re using Next.js, the `next/image` component does this automatically.

---

### 2. Prevent font swap shifts – preload fonts early

```html
<link rel="preload" href="/fonts/custom.woff2" as="font" type="font/woff2" crossorigin="anonymous" />
```

Or use:

```css
font-display: swap;
```

This avoids layout-blocking and reduces font-related shifts.

---

### 3. Reserve space for dynamic components (banners, ads...)

If a component is going to appear late (e.g., a newsletter banner), reserve its space upfront:

```css
.banner-placeholder {
  min-height: 120px;
}
```

---

### 4. Avoid unexpected DOM insertions via JavaScript

Avoid using `setTimeout` to inject large UI blocks without prior layout preparation.  
If animations are necessary, prefer `opacity` or `transform`, which don’t cause layout recalculations.

---

## Conclusion

Reflow, Repaint, and Layout Shift are fundamental to understanding how your page behaves during render—and directly affect **CLS**, a major Core Web Vital.

By learning how the browser processes your layout, you can:

- Optimize performance beyond Lighthouse scores  
- Prevent frustrating user experiences  
- Build more stable and professional frontend interfaces  

Start with the small things: define image sizes, preload fonts, and reserve layout space. Over time, your pages will load smoother, feel faster, and earn better trust from your users.

## Why should you understand Reflow, Repaint, and Layout Shift?

When building a website UI—especially in modern SPAs or e-commerce pages—you might already optimize images, split your code, lazy load, or minify scripts. But there's one subtle yet crucial aspect many developers overlook: **how stable and smooth the page appears while rendering**.

You may have seen things like:

- The layout “jumps” after an image finishes loading  
- A block of text suddenly moves down because of a late banner  
- A button shifts right when the user is just about to click it  

All of these are related to **Reflow**, **Repaint**, and **Layout Shift**. These behaviors directly impact **CLS – Cumulative Layout Shift**, one of the key metrics in Google’s Core Web Vitals.

---

## What is Reflow?

**Reflow** (also called **Layout**) is when the browser recalculates the size and position of elements on the page.

Reflow is triggered when:

- A DOM element is added, removed, or modified  
- CSS properties like `width`, `font-size`, `position`, `display`, etc. are changed  
- Text content is updated  
- The browser window is resized  

For example:

```js
element.style.width = "200px";
```

This forces the browser to recalculate the layout for that element and potentially for its siblings, parent, or children—hence, a reflow.

> Reflow is resource-intensive. A small change can cascade and affect many parts of the layout, especially in complex structures.

---

## What is Repaint?

**Repaint** is when the browser redraws elements visually **without recalculating their layout**.

Repaint happens when:

- You change styles like `background-color`, `color`, `border`, or `visibility`  
- You apply shadow effects, opacity changes, etc.

Example:

```js
element.style.backgroundColor = "blue";
```

No layout change needed, just visual re-rendering.

> Repaint is less expensive than Reflow, but if triggered repeatedly (e.g., through poorly optimized animations), it can still hurt performance.

---

## What is Layout Shift?

**Layout Shift** refers to elements unexpectedly moving on the screen **without user interaction**. If this happens too often or too late in the load process, it can lead to a very poor user experience.

This is exactly what **CLS – Cumulative Layout Shift** measures.

Common causes:

- Images that load without predefined dimensions  
- Custom fonts replacing fallback fonts (FOIT/FOUT)  
- Late-loaded ads or banners pushing content around  
- JavaScript injecting DOM elements dynamically without space reservations  

---

## How is CLS calculated?

CLS is determined by this formula:

```text
CLS = Total Layout Shift Score = Impact Fraction × Distance Fraction
```

Simply put:

- **Impact Fraction**: how much of the screen is affected by the shift  
- **Distance Fraction**: how far the shifted elements move  

> Google recommends keeping CLS **below 0.1** for good Core Web Vitals.

---

## How to reduce unnecessary Reflows and Repaints

1. **Avoid continuous DOM manipulations**

```js
// NOT recommended
for (let i = 0; i < 100; i++) {
  document.body.style.margin = `${i}px`;
}

// Recommended
document.body.style.margin = "100px";
```

2. **Use CSS classes instead of inline styles**

```js
element.classList.add("expanded");
```

3. **Read and write DOM separately**

```js
const height = element.offsetHeight; // Read layout
element.style.height = height + 10 + "px"; // Write layout

// Better: batch DOM updates in requestAnimationFrame
requestAnimationFrame(() => {
  // Make multiple changes here
});
```

---

## How to optimize and reduce CLS

### 1. Always set fixed dimensions for images

```html
<img src="/logo.png" width="200" height="100" alt="Logo" />
```

Or use CSS:

```css
img {
  aspect-ratio: 2 / 1;
}
```

> If you’re using Next.js, the `next/image` component does this automatically.

---

### 2. Prevent font swap shifts – preload fonts early

```html
<link rel="preload" href="/fonts/custom.woff2" as="font" type="font/woff2" crossorigin="anonymous" />
```

Or use:

```css
font-display: swap;
```

This avoids layout-blocking and reduces font-related shifts.

---

### 3. Reserve space for dynamic components (banners, ads...)

If a component is going to appear late (e.g., a newsletter banner), reserve its space upfront:

```css
.banner-placeholder {
  min-height: 120px;
}
```

---

### 4. Avoid unexpected DOM insertions via JavaScript

Avoid using `setTimeout` to inject large UI blocks without prior layout preparation.  
If animations are necessary, prefer `opacity` or `transform`, which don’t cause layout recalculations.

---

## Conclusion

Reflow, Repaint, and Layout Shift are fundamental to understanding how your page behaves during render—and directly affect **CLS**, a major Core Web Vital.

By learning how the browser processes your layout, you can:

- Optimize performance beyond Lighthouse scores  
- Prevent frustrating user experiences  
- Build more stable and professional frontend interfaces  

Start with the small things: define image sizes, preload fonts, and reserve layout space. Over time, your pages will load smoother, feel faster, and earn better trust from your users.

## Vì sao bạn cần hiểu Reflow, Repaint và Layout Shift?

Khi xây dựng giao diện web, đặc biệt là các ứng dụng SPA hay các trang thương mại điện tử, bạn thường tối ưu hình ảnh, bundle nhỏ gọn, code chia nhỏ... Nhưng có một thứ tinh tế mà đôi khi chúng ta bỏ qua: **trải nghiệm người dùng khi trang đang render**.

Các hiện tượng như:

- Giao diện bị “nhảy” khi ảnh vừa tải xong
- Văn bản tự động bị đẩy xuống vì banner xuất hiện chậm
- Người dùng định click thì nút trượt sang chỗ khác

Tất cả đều liên quan đến **Reflow**, **Repaint**, và **Layout Shift**. Và những điều này ảnh hưởng trực tiếp đến **CLS – Cumulative Layout Shift**, một chỉ số quan trọng trong Core Web Vitals của Google.

---

## Reflow là gì?

**Reflow (hay còn gọi là Layout)** là quá trình trình duyệt tính toán lại kích thước và vị trí của các phần tử trên trang.

Reflow xảy ra khi:

- Thêm, xóa hoặc thay đổi phần tử DOM
- Thay đổi các thuộc tính CSS như `width`, `font-size`, `position`, `display`...
- Thay đổi nội dung text
- Kích thước cửa sổ trình duyệt thay đổi (resize)

Ví dụ:

```js
element.style.width = "200px";
```

Thao tác này yêu cầu trình duyệt tính toán lại bố cục các phần tử liên quan – đó chính là Reflow.

> Reflow rất tốn kém tài nguyên. Một thay đổi nhỏ có thể ảnh hưởng đến nhiều phần tử, đặc biệt trong layout phức tạp.

---

## Repaint là gì?

**Repaint** là quá trình vẽ lại phần tử trên màn hình mà **không cần tính toán lại layout**.

Repaint xảy ra khi:

- Thay đổi màu sắc (`background-color`, `color`)
- Thay đổi `visibility`
- Đổ bóng, viền, opacity…

Ví dụ:

```js
element.style.backgroundColor = "blue";
```

Không cần tính lại bố cục, chỉ cần tô lại màu => Repaint.

> So với Reflow, Repaint nhẹ hơn. Tuy nhiên nếu diễn ra liên tục (ví dụ animation không tối ưu), vẫn gây drop FPS và lag.

---

## Layout Shift là gì?

**Layout Shift** xảy ra khi một phần tử bất ngờ thay đổi vị trí trên màn hình **mà người dùng không tương tác gì cả**. Khi điều này xảy ra quá nhiều hoặc quá trễ, trải nghiệm người dùng sẽ bị ảnh hưởng mạnh mẽ.

Đây chính là thứ mà **CLS – Cumulative Layout Shift** đo lường.

Một số nguyên nhân phổ biến:

- Ảnh chưa có kích thước trước khi tải => ảnh “đẩy” phần tử khác xuống
- Font hiển thị muộn => văn bản bị dịch chuyển (FOIT/FOUT)
- Quảng cáo, popup render trễ => đẩy nội dung đi
- Sử dụng JavaScript thêm nội dung bất ngờ vào DOM

---

## Cách đo CLS (Cumulative Layout Shift)

CLS đo bằng công thức:

```text
CLS = Tổng Layout Shift Score = Impact Fraction * Distance Fraction
```

Nói đơn giản:

- **Impact Fraction**: bao nhiêu phần trăm vùng màn hình bị thay đổi
- **Distance Fraction**: khoảng cách phần tử đã bị dịch chuyển bao nhiêu

> Google khuyến nghị: **CLS < 0.1** để đạt tiêu chuẩn tốt cho Core Web Vitals.

---

## Cách giảm Reflow và Repaint không cần thiết

1. **Tránh thao tác DOM liên tục**

```js
// KHÔNG nên
for (let i = 0; i < 100; i++) {
  document.body.style.margin = `${i}px`;
}

// NÊN
document.body.style.margin = "100px";
```

2. **Dùng class thay vì thay đổi style trực tiếp**

```js
element.classList.add("expanded"); // Gọn hơn, dễ maintain
```

3. **Đọc và ghi DOM riêng biệt**

```js
const height = element.offsetHeight; // Đọc layout
element.style.height = height + 10 + "px"; // Ghi layout

// Gộp nhiều thay đổi vào cùng một frame
requestAnimationFrame(() => {
  // Thay đổi nhiều thứ tại đây
});
```

---

## Cách tối ưu để tránh CLS cao

### 1. Luôn đặt chiều cao cố định cho ảnh

```html
<img src="/logo.png" width="200" height="100" alt="Logo" />
```

Hoặc dùng CSS:

```css
img { 
  aspect-ratio: 2 / 1;
}
```

> Next.js dùng `next/image` sẽ tự động xử lý việc này.

---

### 2. Tránh font nhảy – preload font sớm

```html
<link rel="preload" href="/fonts/custom.woff2" as="font" type="font/woff2" crossorigin="anonymous" />
```

Hoặc dùng `font-display: swap` để tránh chặn render quá lâu.

---

### 3. Đặt chỗ sẵn cho component động (banner, quảng cáo...)

Nếu biết chiều cao của một thành phần sẽ xuất hiện muộn, hãy dành sẵn khoảng trống trong layout:

```css
.banner-placeholder {
  min-height: 120px;
}
```

---

### 4. Tránh chèn DOM bất ngờ từ JS

Hạn chế `setTimeout` để render component động sau vài giây. Nếu cần animation, dùng `opacity`, `transform` để transition mượt mà mà không gây layout shift.

---

## Tổng kết

Reflow, Repaint và Layout Shift là ba yếu tố quan trọng ảnh hưởng trực tiếp đến trải nghiệm người dùng – và đặc biệt là chỉ số CLS trong Core Web Vitals.

Việc hiểu cách trình duyệt hoạt động giúp bạn:

- Tối ưu hiệu suất mà không cần chỉ nhìn vào Lighthouse
- Tránh “trượt điểm” SEO vì lỗi UX
- Làm chủ frontend một cách chuyên nghiệp hơn

Hãy bắt đầu tối ưu từ những điều nhỏ: đặt kích thước ảnh, preload font, tránh layout shift không cần thiết. Dần dần, bạn sẽ thấy trang web mượt mà hơn, nhanh hơn – và người dùng hài lòng hơn.

Understand the critical rendering concepts of Reflow, Repaint, and Layout Shift that impact web performance and how to minimize CLS.

Tìm hiểu về Reflow, Repaint và Layout Shift – ba khái niệm quan trọng ảnh hưởng đến trải nghiệm người dùng và điểm Core Web Vitals của trang web bạn.

What are Reflow, Repaint, and Layout Shift? Optimizing to Reduce CLS in Core Web Vitals

Reflow, Repaint, Layout Shift là gì? Tối ưu để tránh CLS cao trong Core Web Vitals


## Project Introduction:

[Vuong Khang Home](https://vuongkhanghome.com/) is a website dedicated to showcasing **home design and construction services**, including building, interior renovation, and providing comprehensive solutions for modern living spaces.

This project was developed to help potential customers easily access information about construction services, explore completed projects, and connect with professional consultants.

**Main objectives of the project:**

- Create a professional and visually appealing interface that reflects the high-quality services offered by Vương Khang Home.
- Improve website SEO and performance using **NuxtJS** for better search engine visibility and faster loading speeds.
- Enhance user experience with an intuitive and well-structured layout, making navigation seamless and efficient.

![Project 1 Interface](/projects/project1/vuongkhanghome.webp)

## Key Features:

- Fully responsive design that adapts to all screen sizes, from desktops to mobile devices.
- A well-structured service catalog covering: **design, construction, and interior renovation**.
- A portfolio showcasing completed projects, giving potential clients a clear view of previous work.
- An interactive contact form that allows users to request consultations effortlessly.
- Optimized images and caching techniques for a faster browsing experience.

## Technologies Used:

- **NuxtJS**: Enables server-side rendering for better SEO and performance, ensuring a smooth and dynamic user experience.
- **SCSS**: Provides a structured and scalable approach to styling, making it easier to maintain and expand the design.
- **Lazy Loading & Caching**: Improves site performance by loading images and resources only when needed.

## Achievements:

- Successfully delivered a stable and high-performance website with fast loading times.
- Improved SEO rankings, increasing online visibility and attracting more potential clients.
- A modern and professional website design that enhances brand credibility and user engagement.
- Enhanced mobile compatibility, ensuring an excellent experience across all devices.


A landing page showcasing the products and services of Vuong Khang Home, built with NuxtJS and SCSS to ensure high performance and a seamless user experience.

Một trang landing giới thiệu các sản phẩm và dịch vụ của Vương Khang Home, được xây dựng với NuxtJS và SCSS để đảm bảo hiệu suất cao và trải nghiệm người dùng mượt mà.

Vuong Khang Home


## About the Project:

[The Five](https://thefive.com.vn/) is the official website of a **leading architectural firm in Vietnam**, specializing in modern, luxurious, and sustainable building solutions. The site is designed to serve as a **digital portfolio**, highlighting The Five's expertise in designing and constructing high-end residential and commercial projects.  

With a focus on **aesthetics, functionality, and performance**, this project was developed to provide potential clients with a **seamless browsing experience** while exploring architectural concepts and completed projects.  

### Why This Project Was Built:

- **Brand Representation**: Establish a **strong online presence** that reflects the company's vision and architectural expertise.  
- **Engagement & Lead Generation**: Provide an intuitive way for visitors to explore projects and get in touch for consultations.  
- **Content Scalability**: Utilize **Strapi CMS** to enable easy updates without developer intervention.  
- **Performance & SEO Optimization**: Ensure high-speed loading, smooth navigation, and top-notch **search engine rankings**.  

![The Five Interface](/projects/project2/thefive.webp)

## Core Features:

- **Elegant, Minimalist UI** – A visually striking yet functional design that enhances user engagement.  
- **Comprehensive Project Portfolio** – Showcases high-resolution images, architectural insights, and project details.  
- **Interactive Project Filtering** – Users can filter and explore designs based on categories like residential, commercial, and sustainable projects.  
- **Seamless Mobile Experience** – Optimized for all devices to ensure an uninterrupted browsing experience.  
- **SEO & Performance Enhancements** – Implemented SSR (Server-Side Rendering) for faster page load speeds and better search rankings.  
- **Dynamic Content Management** – Powered by **Strapi**, allowing The Five’s team to update content effortlessly.  

## Tech Stack:

- **Next.js** – For server-side rendering and optimized performance.  
- **TypeScript** – Ensures type safety and better maintainability.  
- **SCSS** – Enables modular and reusable styles for a polished UI.  
- **Strapi** – A headless CMS for flexible and scalable content management.  

## Outcomes & Impact:

- **Increased Client Engagement** – The new website has improved visitor interaction, leading to **higher consultation requests**.  
- **Better SEO Rankings** – Optimized architecture and fast-loading pages have boosted organic reach.  
- **Enhanced Brand Identity** – The Five now has a **modern, professional, and credible online presence**.  
- **Scalable & Future-Proof** – The website is designed to support future expansions and content growth.  


A premium website for The Five, an architectural firm in Vietnam, showcasing innovative designs and high-end construction services. Built with Next.js, TypeScript, and Strapi for seamless performance and easy content management.

Một website cao cấp cho The Five, công ty kiến trúc tại Việt Nam, giới thiệu các thiết kế sáng tạo và dịch vụ xây dựng cao cấp. Được xây dựng với Next.js, TypeScript và Strapi để đảm bảo hiệu suất mượt mà và quản lý nội dung dễ dàng.

The Five


## About the Project

**VNB Node** is a landing page designed to **showcase and provide insights into various blockchain networks**. The goal of this project is to create an intuitive and visually appealing platform where users can explore different blockchain technologies, their use cases, and their impact on the decentralized ecosystem.  

This project was developed as an **informational hub** for blockchain enthusiasts, developers, and investors looking to learn about emerging networks such as:  
- **XAI** – AI-driven blockchain technology.  
- **Grass** – A decentralized data-sharing network.  
- **Q Blockchain** – A smart contract platform with advanced governance.  
- **Commune AI** – A decentralized AI computing platform.  
- **Kuzco** – A blockchain focused on scalability and efficiency.  
- **IO.NET** – High-performance decentralized cloud computing.  
- **EigenLayer** – A restaking protocol for Ethereum.  
- **Subspace** – A decentralized storage and consensus layer.  

![VNB Node Interface](/projects/project3/vnbnode.webp)

## Key Features

- **Dynamic Blockchain Listings** – Highlights various networks with descriptions and key data points.  
- **Live Updates & Integrations** – Potential for API connections to fetch real-time blockchain statistics.  
- **Clean & Modern UI** – Built with Next.js and SCSS for a smooth, responsive user experience.  
- **SEO-Optimized Content** – Designed to attract search traffic and provide valuable insights to users.  
- **Expandable & Modular Design** – Allows easy addition of new blockchain projects in the future.  

## Technologies Used

- **Next.js** – Provides fast performance and SEO benefits with SSR.  
- **TypeScript** – Ensures type safety and better maintainability.  
- **SCSS** – Enables clean and structured styling for a modern design.  

## Future Enhancements

- **Interactive Charts & Visualizations** – Display blockchain statistics with engaging data visualizations.  
- **Educational Content** – Articles and explanations about each network’s unique features.  
- **Community & Social Integration** – Links to official documentation, communities, and Twitter feeds of featured projects.  

## Project Impact

- Offers a **single platform** to explore multiple blockchain ecosystems.  
- Helps users stay updated with **new and emerging blockchain projects**.  
- Lays the foundation for potential integrations with **real-time data sources**.  


A landing page built to showcase various blockchain projects, providing insights into emerging networks like XAI, Grass, Q Blockchain, Commune AI, Kuzco, IO.NET, EigenLayer, and Subspace.

Một trang landing được xây dựng để giới thiệu các dự án blockchain, cung cấp cái nhìn sâu sắc về các mạng mới nổi như XAI, Grass, Q Blockchain, Commune AI, Kuzco, IO.NET, EigenLayer và Subspace.

VNB Node


## About the Project

[Arobid.com](https://arobid.com/) is a **B2B & B2C e-commerce platform** designed to facilitate transactions between businesses and consumers through an **efficient procurement and bidding system**.  

The platform supports **multi-language functionality**, allowing businesses to operate across different markets, making it easier for international buyers and suppliers to connect.  

### Key Objectives

- **Seamless B2B & B2C Experience** – Support both bulk procurement for businesses and direct sales for consumers.  
- **Multilingual Support** – Provide **language localization** to improve user experience for international markets.  
- **Advanced Bidding & RFQ System** – Empower businesses to **request and compare supplier quotations** easily.  
- **Scalable & High-Performance** – Built with **Next.js, TypeScript, and Tailwind CSS** for speed, responsiveness, and reliability.  

![Arobid.com Interface](/projects/project4/arobid.webp)

## Core Features

- **B2B Marketplace** – Connect businesses with verified suppliers for bulk purchases and long-term contracts.  
- **B2C Shopping** – Provide a smooth retail experience for consumers, similar to traditional e-commerce.  
- **Multilingual Support** – **Enable users to switch languages** for a localized experience.  
- **RFQ (Request for Quotation) System** – Buyers can request quotes and compare supplier offers.  
- **Bidding System** – Suppliers can **compete** for business deals, ensuring competitive pricing.  
- **Dynamic Pricing & Bulk Discounts** – Businesses can negotiate **custom pricing** based on volume.  
- **Supplier & Customer Dashboards** – Manage orders, track bids, and handle transactions in one place.  
- **Mobile-Responsive Design** – Ensures a seamless experience across **desktop and mobile**.  

## Tech Stack

- **Next.js** – Delivers **fast performance & SEO benefits** with SSR.  
- **TypeScript** – Enhances maintainability and type safety.  
- **Tailwind CSS** – Provides a clean, modern, and responsive UI.  
- **i18n (Internationalization)** – Allows seamless **language switching and localization**.  

## Future Enhancements

- **AI-Driven Product Recommendations** – Personalize the shopping experience based on user behavior.  
- **Logistics & Payment Integrations** – Connect with **shipping providers and payment gateways** for seamless order fulfillment.  
- **Supplier Verification & Ratings** – Build trust with **verified supplier profiles and customer feedback**.  

## Business Impact

- **Expanded Market Reach** – Supports **global trade with multilingual capabilities**.  
- **Increased Efficiency** – **Automates procurement** and improves the **negotiation process** for businesses.  
- **Cost Savings & Competitive Pricing** – The **bidding system ensures** buyers get the best deal possible.  



Arobid.com is a multilingual B2B & B2C e-commerce platform designed to connect businesses and consumers with an efficient procurement and bidding system.

Arobid.com là nền tảng thương mại điện tử đa ngôn ngữ B2B và B2C, được thiết kế để kết nối doanh nghiệp và người tiêu dùng với hệ thống đấu thầu và mua sắm hiệu quả.

Hey, I am VuNguyen.

Active Projects

Stay up to date