> FastAPI stands on the shoulders of giants:
> - Starlette for the web parts.
> - Pydantic for the data parts.


Theo lời tác giả, [FastAPI](https://fastapi.tiangolo.com) được xây dựng trên 2 thư viện vô cùng tốt là [Starlette](https://www.starlette.io) và [Pydantic](https://docs.pydantic.dev/latest).

Starlette là một web toolkit để phát triển web trong Python. Nếu như [Flask](https://flask.palletsprojects.com/en/2.3.x) được xây dựng trên [Werkzeug](https://werkzeug.palletsprojects.com/en/2.3.x/) với interface [WSGI](https://peps.python.org/pep-3333/) thì FastAPI được xây dựng từ Starlette trên giao diện [ASGI](https://asgi.readthedocs.io/en/latest/).

Pydantic là một thư viện cho data validator và data serialize/deserialize.

Đó là theo lời tác giả, còn đây là phân tích của bản thân mình.

> FastAPI framework, high performance, easy to learn, fast to code, ready for production. 

Đó là tiêu đề trên trang chủ của FastAPI.

Vậy "fast" ở đây là "fast" về cái gì?

Theo mình, FastAPI có thể xử lí request nhanh (hiệu năng cao) và quá trình phát triển sản phẩm bằng FastAPI nhanh chóng.

## FastAPI giúp quá trình phát triển sản phẩm nhanh chóng

Điều này là đúng tuyệt đối. 

FastAPI được tích hợp một hệ thống Dependency Injection (tương tự [NestJS](https://nestjs.com)) giúp đơn giản hóa công việc phát triển.

FastAPI sử dụng [type hint](https://peps.python.org/pep-0484) của Python với nhiều mục đích. Chúng ta có thể định nghĩa headers, query string, param url, body của endpoint của API bằng type hint. Điều này vừa giúp bạn định nghĩa và validate được request, response của API, vừa giúp các IDE có thể trợ giúp trong quá trình phát triển như auto-completion, type checking, từ đó làm giảm lỗi tiềm ẩn trong runtime.

Bên cạnh đó, việc định nghĩa type kiểu này giúp FastAPI có thể tự generate API doc, từ đó quá trình phát triển sẽ rõ ràng và thuận tiện hơn. Việc tích hợp API không còn là nỗi ám ảnh của developer. Chúng ta sẽ không phải vừa code vừa viết API doc bằng yaml, không lo sai lệch giữa API doc và response thực tế trả về của service.

Ngoài ra, FastAPI có tích hợp nhiều chức năng trong việc định nghĩa type như cơ chế bảo mật của API, rule validate schema phức tạp của request, response,...

Nói chung, FastAPI là sự kết hợp tuyệt vời giữa Flask và những tính năng mới mà Python 3.7+ đem lại.


## FastAPI có thể xử lí request nhanh, hiệu năng cao

Điều này là đúng tương đối (không phải tuyệt đối).

Xử lí request nhanh chóng phụ thuộc vào rất nhiều yếu tố như thiết kế dữ liệu, thuật toán xử lí, thiết kế hệ thống, dùng framework đúng cách,...

Tuy nhiên, FastAPI cho phép các nhà phát triển có nhiều cơ hội để tối ưu ứng dụng của mình hơn các framework khác. Vậy đó là gì?

FastAPI xử dụng chuẩn ASGI cho web server interface, nghĩa là nó hỗ trợ xử lí request bất đồng bộ trong 1 thread của webserver. Một trong những ASGI nổi tiếng là [uvicorn](https://www.uvicorn.org). Uvicorn xử lí request bất đồng bộ (giống như NodeJS), hơn nữa, uvicorn có thể thay thế bộ event loop mặc định của Python bằng [libuv](https://libuv.org) - một thư viện event loop được NodeJS sử dụng.

Thứ hai, uvicorn có thể sử dụng thư viện [http-parser](https://github.com/nodejs/http-parser) để parsing các HTTP message, bộ parser này cũng được sử dụng bởi NodeJS luôn. Do đó, việc handle request/response ở low-level của FastAPI được uvicorn xử lí cực kì tốt.

Quá trình xử lí HTTP message đã xong, lên đến tầng cao hơn của FastAPI lại được hỗ trợ bởi Pydantic, toàn bộ quá trình validate và parse raw data từ request sẽ do Pydantic đảm nhận.

Với các HTTP message(request/response) có body là JSON sẽ được Pydantic serialize/deserialize và validate, nếu quá trình này xử lí không tốt có thể làm giảm hiệu năng xử lí request.

Nhưng Pydantic có [core](https://github.com/pydantic/pydantic-core) được xây dựng từ Rust, do đó việc handle những công việc liên quan đến CPU-bound như serialize/deserialize hay validate sẽ có hiệu năng tốt nhất có thể, và tất nhiên sẽ tốt hơn những thư viện được viết từ Python.

Với những ngôn ngữ kiểu tĩnh như Rust hay C, hiệu năng nó đem lại là cực kì lớn khi so với những ngôn ngữ kiểu động như Python hay Javascript, điều này là dễ hiểu khi những công việc đòi hỏi hiệu năng cao hay low-level lại được viết bằng những ngôn ngữ kiểu tĩnh.

Đó là một sự kết hợp hoàn hảo mà FastAPI đã đem lại cho chúng ta, tuy nhiên không phải ai cũng sử dụng nó đúng cách!!!

## Xử dụng async/sync một cách hợp lí

FastAPI hỗ trợ cả sync/async function khi định nghĩa endpoint. Vậy dùng nó như thế nào cho đúng? Khi nào chọn sync, khi nào chọn async.

Đi từ gốc rễ, mình sẽ chỉ cho các bạn thấy một nghịch lí trong Python. Hãy đọc kĩ gist này của mình [https://gist.github.com/magiskboy/1b7a49b3f195c819829eb303e7ee1479](https://gist.github.com/magiskboy/1b7a49b3f195c819829eb303e7ee1479)

Từ đó suy ra, các hàm sync xử lí các tác vụ IO-bound vẫn có thể được handle tốt nếu dùng multi-thread, hãy nhớ điều này.

Trong FastAPI có một logic như sau: nếu endpoint là một hàm sync, nó sẽ fork 1 thread đễ xử lí hàm đó một các async. Nếu endpoint là một hàm async, nó sẽ được chạy trong event loop của main thread.
[Chi tiết](https://github.com/encode/starlette/blob/0.28.0/starlette/routing.py#L67)

Vậy đoạn code sau có vấn đề gì?

```python
import sleep

app = FastAPI()

@app.get("/")
async def index():
    time.sleep(1)
    return Response("Hello world")
```

Với cách sử dụng ở trên, endpoint này là một hàm async do đó nó sẽ được xử lí trong event loop của main-thread. Nhưng bên trong nó lại có một hàm sync nên hàm này sẽ block tất cả các request đến endpoint được xử lí ở main-thread, dẫn tới giảm khả năng xử lí request của ứng dụng.

Hãy dùng nó như sau:

```python
import sleep

app = FastAPI()

@app.get("/")
def index():
    time.sleep(1)
    return Response("Hello world")
```

Bằng cách này, endpoint sẽ được chạy trong một thread khác và không làm ảnh hưởng tới main-thread, giúp main-thread có thể tiếp nhận thêm request mà không bị block.

Chi tiết hơn các bạn có thể xem ở đây: [https://github.com/tiangolo/fastapi/discussions/7095](https://github.com/tiangolo/fastapi/discussions/7095)


## Tóm lại

FastAPI nhanh cả về mặt phát triển sản phẩm và hiệu năng nếu dùng đúng cách.

Để đạt được hiện năng tốt như vậy, FastAPI được phát triển trên interface gọi là ASGI, interface này cho phép xử lí request tốt hơn WSGI. Uvicorn là một trong những web server implement theo ASGI có thể tích hợp được 2 thư viện tốt từ NodeJS là libuv và http-parser cho xử lí HTTP message. 

Ngoài ra, FastAPI xử dụng Pydantic cho serialize/deserialize/validate data - được viết bằng Rust nên hiệu năng đem lại cũng cực kì tốt.

Cuối cùng, hãy dùng FastAPI đúng cách để tận dụng được tối đa những gì nó đem lại. Với quan điểm của mình, FastAPI là một framework ấn tượng, xứng đáng là người kế nhiệm của Flask khi Python đang dần trở nên tốt hơn cả về syntax, hiệu năng và design.


# Trang web được load và hiển thị như thế nào?

1. Browser load HTML file (block)
2. Parsing HTML  (non block)
3. Load các tài nguyên khác như JS, CSS, ảnh, font,.... (non block)
4. Render (loop) 
    - Calculate style, layout và painting các element (block)
    - Thực thi codeJS (block)

<Image 
  src="/images/optimize-web-perf.webp"
  priority
  width={900}
  title="Quá trình hiển thị một trang web trên trình duyệt"
/>

Người dùng cảm nhận một trang web nhanh nếu tất cả các quá trình trên nhanh nhất có thể. __Hiệu năng của các quá trình trước ảnh hưởng trực tiếp tới toàn bộ quá trình sau__.

# Web performance

Để đánh giá hiệu năng của một trang web, Google đưa ra 6 chỉ số ảnh hưởng đến hiệu năng và trải nghiệm người dùng (user centric metrics)

- Largest Contentful Paint 
- First Contentful Paint
- Cumulative Layout Shift 
- Total Blocking TIme
- Time To Interactive
- Speed Index

6 chỉ số này là kết quả của các quá trình load và render page ở phần trên, nên để optimize, ta phải nắm được chi tiết cách một trang web được render như thế nào.

## Largest Contentful Paint

Thời gian mà phần tử lớn nhất trên màn hình được hiển thị. Thời gian này càng ngắn, người dùng sẽ cảm thấy trang web dường như khá nhanh mặc dù các nội dùng khác có thể chưa đựọc render.

Ví dụ: thời gian banner hiển thị được lấy làm điểm LCP cho trang homepage của phongvu.vn

<Image 
  src="/images/optimize-web-perf-2.png"
  width={900}
  title="Phần tử LCP trên trang phongvu.vn"
/>

Một số lưu ý:
- với các phần tử LCP, nên được load nhanh nhất khi có thể
- LCP thường là các phần từ __img__ hoặc các phần tử __p__
- LCP nên được bố cục một cách rõ ràng trên trang web tại thời điểm load, tránh các phần tử nhỏ, làm cho việc khó xác định LCP

## First Contentful Paint

Thời gian để browser có thể render nội dung ra màn hình, FCP luôn là thời điểm trước FCP nên nếu FCP nhỏ thì LCP sẽ nhỏ theo. FCP ảnh hưởng bởi các blocking resource như CSS, font nên việc tối ưu CSS và load font sẽ làm giảm FCP.

## Cumulative Layout Shift 

CLS là tình trạng các phần tử trong màn hình thay đổi vị trí và kích thước trong thời gian tải trang. Nếu CLS cao sẽ dẫn tới trải nghiệm không tốt về UI như ví dụ sau

<center>
<video controls width="640" style={{
    maxWidth: "100%"
}}>
  <source src="https://storage.googleapis.com/web-dev-assets/layout-instability-api/layout-instability2.webm" type="video/webm" />
  Your browser does not support the video tag.
</video>
</center>

## Total blocking time

Thông số ảnh hưởng do CPU phải thực thi các tác vụ trên main thread quá dài như:
- JS parsing
- HTML parsing
- calculate style
- layout
- JS executing

Nếu thời gian này cao có thể gây ra một số vấn đề sau:
- giảm frame rate, mỗi frame nên được update và render trong khoảng 16.6ms để đảm bảo 60fps
- thời gian user có thể tương tác được với web dài sẽ mang lại trải nghiệm không tốt 

Một số cách để làm giảm thời gian này:
- giảm code JS browser phải thực thi khi load trang
- tránh việc style lại các element như insert thẻ style, thay đổi các attribute liên quan đến vị trí, kích thước của các element ([recalculate style](https://web.dev/reduce-the-scope-and-complexity-of-style-calculations/), [layout thrashing](https://web.dev/avoid-large-complex-layouts-and-layout-thrashing/))

## Time To Interactive

Thời gian người dùng có thể tương tác được với trang web, thời gian này càng ngắn, người dùng sẽ cảm giác trang web đang chạy nhanh. Thông số này bị ảnh hưởng bởi việc CPU bị các tác vụ khác chiếm quá nhiều nên để tối ưu chỉ số này cần giảm các tác vụ dùng CPU đến mức tối thiểu. Các tác vụ đó đã được nói đến ở phần Total blocking time.


## Speed Index

Thời gian hiển để hiển thị nội dung trang web. Cũng như các phần khác, thời gian này bị ảnh hưởng bởi CPU bị chiếm do các tác vụ khác hoặc do các block resource như font, css. Để giảm thời gian này, cần giảm thời gian CPU bị chiếm cũng như load các block resource nên được load nhanh nhất có thể.


## Cheetsheet

### Cumulative Layout Shift	
- Ý nghĩa: 
  - Mức độ các phần tử thay đổi kích thước và vị trí khi load trang
- Yếu tố ảnh hưởng:
  - thời gian load các resource chậm như font
  - các phần tử chưa được render không được xác đinh 1 placeholder cụ thể 
- Phương pháp tối ưu:
  - xác định trước 1 placeholder cụ thể cho các phần tử, đặc biệt là img.  Với img, nên set thuộc tính width, height rõ ràng.
  - trong react, với các component SSR, nên khởi tạo useState với server data nếu state đó tham gia vào quá trình render. Ví dụ thay vì list = useState([]) thì list = useState(serverList)  
  - SSR

### First Contentful Paint	
- Ý nghĩa:
  - Thời gian để browser băt đầu painting lên màn hình	
- Yếu tố ảnh hưởng:
  - blocking resource như css, font
- Phương pháp tối ưu:
  - tối ưư việc load các blocking resource
  - SSR các phần từ được hiển thị trong viewport trong loading time 


### Largest Contentful Paint
- Ý nghĩa: 
  - Thời gian hiển thị phần tử lớn nhất trên viewport trong loading time, __thường là các phần từ img hoặc các text element như p__
- Yếu tốt ảnh hưởng:
  - với các text element: thời gian load font
  - với các img element: thời gian load image
- Phương pháp tối ưu:
  - tối thiểu hóa việc load font, không nên load font dư thừa
  - với image, nên preload một số ảnh đóng vai trò là lcp
  - không thực hiện việc hiển thị LCP element bằng code JS hay CSS (background-image), sử dụng thẻ img
  - nên server side rendering (SSR) với các LCP element
  - các component LCP không nên lazy render 


### Speed Index	
- Ý nghĩa: 
  - Thời gian trang web có thể hiển thị nội dung	
- Yếu tố ảnh hưởng:
  - blocking resource
  - main thread blocking time
- Phương pháp tối ưu:
  - giảm thời gian xử lí các yếu tố ảnh hưởng theo các phương thức ở trên


### Time to interactive	
- Ý nghĩa:
  - Thời gian người dùng có thể tương tác được với trang web	
- Yếu tố ảnh hưởng:
  - main thread blocking time
- Phương pháp tối ưu:
  - giảm thời gian main thread bị block bằng các phương pháp ở trên
  - không nên lạm dụng idle time (sử dụng requestIdleCallback quá nhiều), thời gian idle cũng là khoảng thời gian browser chờ để xử lí user input

### Total blocking time	
- Ý nghĩa:
  - Thời gian main thread bị block 	
- Yếu tố ảnh hưởng: 
  - JS parsing
  - HTML parsing
  - calculate style
  - layout
  - JS executing
- Phương pháp tối ưu:
  - treeshaking: [https://web.dev/reduce-javascript-payloads-with-tree-shaking](https://web.dev/reduce-javascript-payloads-with-tree-shaking)
  - giảm lượng HTML trả về do SSR
  - tránh việc load quá nhiều style hoặc lazy load style - recalculate style
  - tránh việc truy cập/chỉnh sửa các thuộc tính về vị trí và kích thước của các phần tử - layout thrashing 

## Một số vấn đề cần lưu ý

### Treeshaking

Tree shaking là phương pháp loại bỏ các deadcode ra khỏi bundle, làm giảm kích thước file JS trả về client. Phương pháp này được hỗ trợ bởi các bunudler như webpack, esbuild, rollup,...

Một số chú ý về tree shaking:

- tree shaking chỉ thực hiện ở application, không thực hiện ở library
- để giúp các bundler có thể tree shake, nên consider set trường sideEffects trong package.json với giá trị phù hợp 
- chỉ nên tách function ra shared package nếu chúng được sử dụng ít nhất 2 lần trở lên
- tránh việc __import * from__ ... để bundler có thể tree shake
- tree shaking chỉ thực hiện được trong ESM, các bundler không hỗ trợ tree shaking trên CommonJS, do đó, hạn chế tối đa sử dụng CommonJS cho các ứng dụng trên browser
- với các ứng dụng hybrid như NextJS, code trên server rất dễ lẫn với code trên client, do đó cần lưu ý và sử dụng các bundle anaylzer như [webpack-bundle-analyzer](https://www.npmjs.com/package/webpack-bundle-analyzer) để theo dõi
- các resource nhưng image nên được tách ra file và sử dụng CDN để serve, tránh việc bundle cả ảnh vào trong JS bundle

Đọc thêm: [https://blog.theodo.com/2021/04/library-tree-shaking](https://blog.theodo.com/2021/04/library-tree-shaking)

### Lazy import, lazy load

lazy import được sử dụng để giảm bundle size. Thay vì bundle code của tất cả tính năng, chúng ta chỉ nên import code của những tính năng cần thiết.

Ví dụ: code cho popup thông báo lỗi chỉ được load về khi popup cần hiện lên khi có lỗi xảy ra. Tại thời điểm load trang, phần code đó không được bundle vào JS, giúp thời gian load giảm.

Một số lưu ý:
- không lazy load những đoạn code làm ảnh hưởng đến LCP, CLS
- lazy import không làm ảnh hưởng tới code trên server
- tránh lạm dụng lazy import không cần thiết, điều này có thể tạo ra những file JS quá nhỏ, giảm khả năng nén của web server, ảnh hưởng tới hiệu năng chung  
- sử dụng lazy loading của HTML như img

### Lazy hydrate

Lazy hydrate tránh việc code được thực thi không cần thiết.

Ví dụ: chỉ render các component trong viewport (nhất là tại loading time) sẽ làm giảm thời gian CPU bị blocking. Kết hợp với IntersectionObserver, chúng chỉ nên được render khi ở trong viewport.

Do việc detect một component có ở trong viewport hay không do JS thực thi nên những phần từ LCP cũng không nên được render bằng cách lazy hydrate này.

### Time to first byte

Tuy không phải là 1 user centric metric nhưng TTFB lại rất quan trọng trong web performance do nó ảnh hưởng tới tất cả các chỉ số web performance. Trong tất cả các TTFB của các resource, TTFB của file HTML là quan trong nhất vì nó là entrypoint của 1 webpage. Tối ưu chỉ số này sẽ làm tăng điểm số chung đáng kể.

Để improve chỉ số này, có 1 vài phương pháp như:
- caching
- giảm thời gian SSR bằng cách loại bỏ các component không cần thiết

### Optimize bandwidth

Tại thời điểm loading, giảm bandwidth giúp các resource quan trọng được load nhanh hơn. trang web sẽ được hiển thị lên màn hình nhanh nhất có thể.

Lưu ý:
- tránh load các thirdparty không quan trọng tại thời điểm này như tracking hay các script phục vụ marketing
- tránh preload quá nhiều resource
- chỉ nên đặc các resource quan trọng, cần load nhanh nhất có thể trong thẻ head của html, chuyển các script không quan trọng xuống cuối thẻ body
- Ưu tiên xử lí HTML tĩnh trước các resource như JS hay các image chưa được hiển thị trên trang web

# Chuyện gì đã xảy ra trước ECOM-338?

Note: ECOM-338 là Epic tối ưu web performance cho phongvu.vn

Điểm tổng quan do [google pagespeed](https://pagespeed.web.dev/) khá thấp trên cả desktop và mobile. 

Sử dụng lighthouse hoặc google pagespeed, chúng ta có được các đầu mối để có thể investigate nguyên nhân và cách tối ưu.

Trước ECOM-338, có một số vấn đề sau:
- Thời gian CPU bị block quá lớn: ảnh hưởng đến trực tiếp đến hiệu năng quả trang web __(Smoothness)__
- Cumulative Layout Shift cao: các phần từ trên màn hình thay đổi vị trí và kích thước liên tục dẫn tới trải nghiệm về UI không tốt __(Visual stability)__
- Time To Interactive cao: làm tăng thời gian người dùng có thể tương tác được với trang web __(Runtime responsiveness)__
- Trên mobile, các chỉ số như Largest Contentful Paint và First Contentful Paint cao: làm giảm khả năng trải nghiệm của người dùng __(Meaningful)__

<div style={{ "display": "flex", "flexDirection": "row" }}>
<Image
  src="/images/optimize-web-perf-3.png"
  title="Desktop"
/>

<Image
  src="/images/optimize-web-perf-4.png"
  title="Mobile"
/>
</div>

# Làm thế nào để tìm ra nguyên nhân?

Có nhiều công cụ giúp tìm hiểu vấn đề và gợi ý hướng giả quyết cho các vấn đề về hiệu năng của website.

Lighthouse và [google pagespeed](https://pagespeed.web.dev)

Công cụ này sẽ phân tích và đưa ra điểm số tổng quan trong trang web. Nó sẽ đo lường [6 user centric metric](https://web.dev/user-centric-performance-metrics) về hiệu năng web, đây là những đầu mối quan trọng để tiến hành tối ưu về sau. Nó cũng đưa ra một điểm số tổng quan để chúng ta có thể theo dõi tiến độ tối ưu. Ngoài ra, nó cũng đưa ra những vấn đề gặp phải và gợi ý hướng  giải quyết. Theo mình, công cụ này nên được sử dụng trước mỗi lần tối ưu và sau khi tối ưu, nó sẽ giúp theo dõi được tiến độ cũng như đưa ra hướng đi tiếp theo cần phải làm.

Để sử dụng Lighthouse, mở __Chrome Dev Tools__ bằng cách nhấn Ctrl+Shift+I và chọn tab __Lighthouse__

<Image
  src="/images/optimize-web-perf-5.png"
  width={900}
/>

Chúng ta có thể đo lường trang web với các khía cạnh khác nhau như Hiệu năng (Performance), SEO, ... Tuy nhiên, trong bài này chỉ tập trung tới phần hiệu năng nên các khía cạnh khác sẽ được uncheck. Ngoài ra, Lighthouse có thể đo lường trên cả thiết bị desktop và mobile. Với từng thiết bị, Lighthouse sẽ thiết lập các chỉ số tương đương như throtting network thành mạng 3G cho các thiết bị mobile hay làm quá trình xử lí tác vụ chậm đi (throtting CPU).

Sau khi chọn xong các tùy chỉnh, click vào __Analyze page load__. Lưu ý, trong quá trình Lighthouse đang phân tích, tránh thực hiện các tác vụ khác để làm giảm sai sót trong quá trình phân tích. 

Từ lighthouse, chúng ta có thể nhận thấy một vài vấn đề trong project shop-front như sau:
- Lượng code JS được bundle vào output dư thừa
- Thời gian thực thi code JS quá dài, chiếm nhiều CPU làm giảm khả năng render trang web 
- Lựa chọ thư viện chưa hợp lí dẫn tới hiệu năng giảm trên các thiết bị mobile
- Không tuân thủ các best practice về web performance
- Thời gian phản hồi của server không cao làm ảnh hưởng toàn bộ các chỉ số khác trong đánh giá

<Image 
  src="/images/optimize-web-perf-6.png"
  width={900}
/>

## Performance insight

Để mở công cụ này, vào __Chrome Dev Tools > Performance Insight__

<Image 
  src="/images/optimize-web-perf-7.png"
  title="Performance Insight"
  width={900}
/>

Công cụ này giúp chúng ta cái nhìn chi tiết hơn về trang web theo thời gian. Nó sẽ cho ta biết các vấn đề, user centric metric xảy ra như thế nào theo thời gian, từ đó giúp ta dễ dàng biết được nên tối ưu ở đâu, cho chỉ số nào.

<Image 
  src="/images/optimize-web-perf-8.png"
  width={900}
/>

Nếu như __Lighthouse__ cho chúng ta biết được các vấn đề là gì, chỉ số cao hay thấp thì __Performance Insight__ cho chúng ta biết được chúng có quan hệ như thế nào. Khi chúng ta có nhận thức chỗ cần tối ưu, bước tiếp theo là tối ưu như thế nào? Công cụ tiếp theo sẽ cho ta biết điều đó.

## Performance

Để sử dụng công cụ này, mở __Chrome Dev Tools > Performance__

<Image 
  src="/images/optimize-web-perf-9.png"
  title="Performance in Google Chrome"
  width={900}
/>

Có 4 phần chúng ta cần lưu ý:
1. Biểu đồ này cho chúng ta cái nhìn tổng quan về khối lượng công việc mà browser phải làm khi load trang web. Các màu trong biểu đồ ứng với các loại công việc (chi tiết ở phần 4).
2. Khối này cho chúng ta biết chi tiết resource và thứ tự được tải về khi load trang (Network)
3. Chi tiết các function/task đươc thực thi trong main thread, chúng cho ta biết thứ tự thực thi và quan hệ giữa chúng.
4. Giống khối 3 nhưng các thông tin đó được hiển thị theo các cách khác nhau như Summary, Bottom-Up, Call Tree, Event Log

## Webpack bundle analyzer 

Bundle có thể được phân tích bằng [webpack-bundle-analyzer](https://www.npmjs.com/package/webpack-bundle-analyzer), với công cụ này, một số issue có thể được phát hiện như:
- code server được bundle lẫn với client
- duplicate module 
- bundle bị thừa hoặc các thư viện đang sử dụng commonjs → không thể tree shaking

<Image 
  src="/images/optimize-web-perf-10.gif"
  width={900}
/>


# Kết quả sau khi optimize

Điểm số đã đạt được khá cao khi đo trên mobile là 60 và desktop là 80-90

Tuy nhiên còn một vấn đề khó và ảnh hưởng rất lớn đến kết quả đó là script do người quản lí website nhúng vào. Đó là những đoạn mã có thể phá bỏ mọi kết quả tối ưu mà mình đã không lường trước do thiếu kinh nghiệm trong quá trình tìm hiểu

Google Tag Manager (GTM) cho phép nhúng các đoạn mã JS, CSS, HTML vào trang web một cách linh động.

__Điểm số cho phiên bản desktop__
<div style={{ "display": "flex", "flexDirection": "row" }}>
<Image
  src="/images/optimize-web-perf-11.png"
  title="Không nhúng GTM"
/>
<Image
  src="/images/optimize-web-perf-12.png"
  title="Nhúng GTM"
/>
</div>

__Điểm số cho phiên bản mobile__
<div style={{ "display": "flex", "flexDirection": "row" }}>
<Image
  src="/images/optimize-web-perf-13.png"
  title="Không nhúng GTM"
/>
<Image
  src="/images/optimize-web-perf-14.png"
  title="Nhúng GTM"
/>
</div>

Ngoài ra, điểm số còn phụ thuộc khá nhiều vào những yếu tố bên ngoài như thời gian trả kết quả của API, network người dùng, cấu hình máy tính,...


## 1. Viết code và sử dụng các thư viện hỗ trợ định dạng ESModule thay cho CommonJS

Đây là điều cơ bản và dễ thực hiện nhất để ứng dụng của bạn có thể được tree shake một cách hiệu quả. Code javascript có hai loại định dạng phổ biến là CommonJS và ESModule. Mọi người chỉ cần nhớ rằng: **các bundle không thể tree shake nếu code có định dạng là CommonJS**.

Để tree shake diễn ra, các bundler như Webpack, RollupJS hay ESBuild phải biết cấu trúc ứng dụng của bạn tại thời điểm build (build time). Cấu trúc đó được gọi là dependecy graph, nó giúp bundler nhận biết những thành phần nào trong ứng dụng phụ thuộc vào những thành phần khác để từ đó biết được những thành phần dư thừa.

Code JS dưới định dạng CommonJS không đáp ứng được điều này do nó có thể import các thành phần khác tại runtime, trong các scope khác nhau như branching scope, block scope,... Điều này làm cho bundle không thể nhận biết chính xác những đoạn code nào nên loại bỏ hay cần được giữ lại.

ESModule là định dạng không cho phép developer import module tại runtime, tức là developer sẽ chỉ được import module tường minh tại module scope.

## 2. Tránh tạo ra các side-effect nếu như nó không thật sự cần thiết

Một đối tượng (operation hay function) được gọi là có side-effect nếu nó tác động lên một trạng thái bên ngoài scope của nó. Ví dụ như bạn viết một hàm như sau

```javascript
window.foo = "foo";

function bar() {
  window.foo = "bar";
}
```

Như vậy, hàm `bar` được coi là tồn tại side effect. Lấy ví dụ khác cụ thể như sau:

```javascript
window.foo = "foo";

function bar() {
  return "bar";
}

window.foo = bar();
```

Mặc dù `window.foo` không được dùng ở đâu trong ứng dụng (ít nhất là tại build time) nhưng webpack sẽ nhận thức đó là 1 side-effect (nó có thể được dùng tại runtime do window có thể truy cập sau này tại runtime) và nó sẽ bundle cả hàm `bar` cũng các dependecies của nó và file kết quả.

Ngoài ra, nếu các bạn viết một thư viện nào nó, để đánh dấu rằng nó không có bất kì side effect nào, nhớ thêm trường `"sideEffects": false` vào package.json để bundler có thể biết.

## 3. Tránh sử dụng class

Bundler chỉ nhận biết bạn sử dụng thành phần nào đó thông qua câu lệnh import ở đầu các module. Còn các thành phần của 1 class có thể được sử dụng hoặc không tại runtime nên chúng không thể tree shake bởi các bundler.

## 4. Tránh sử dụng nhiều phiên bản của cùng 1 thư viện

Giả sử mình có 1 ứng dụng sau:

```json
{
  "name": "libA",
  "dependencies": {
    "swr": "^0.3.9"
  }
}
```

```json
{
  "name": "app",
  "dependencies": {
    "libA": "^1.0.0",
    "swr": "^1.1.2"
  }
}
```

Nếu sử dụng như vậy, bundler sẽ bundle cả hai phiên bản `swr: 0.3.9` và `swr: 1.1.2` trong khi thật sự điều này là không cần thiết đối với ứng dụng của bạn.

Một ví dụ khác liên quan đến việc resolution của yarn berry với cơ chế Play'n Plug

```json
{
  "name": "swr",
  "version": "1.1.2",
  "peerDependencies": {
    "react": "*"
  }
}
```

```json
{
  "name": "libA",
  "dependencies": {
    "swr": "1.1.2",
    "react": "^16.9.14"
  }
}
```

```json
{
  "name": "app",
  "dependencies": {
    "swr": "1.1.2",
    "react": "^17.0.2"
  }
}
```

Tuy `swr` có cùng version là `1.1.2` nhưng bạn vẫn sẽ thấy trong bundle có tới hai đoạn code giống hệt nhau

Lúc này bạn có thể xem lí do bằng câu lệnh [`yarn info`](https://yarnpkg.com/cli/info) như sau:

```bash
$ yarn info -AR --virtuals swr
```

```
├─ swr@npm:1.1.2 [0bbaa]
│  ├─ Version: 1.1.2
│  │
│  └─ Peer dependencies
│     └─ react@^16.11.0 || ^17.0.0 → npm:17.0.2
│
└─ swr@npm:1.1.2 [330c3]
   ├─ Version: 1.1.2
   │
   └─ Peer dependencies
      └─ react@^16.11.0 || ^17.0.0 → npm:16.9.14
```

yarn sẽ resolve `swr` cho `libA` và `app` hai virtual package khác nhau (thực chất cả 2 cùng trỏ tới 1 địa chỉ trên disk), do đó, webpack sẽ hiểu đó là hai phiên bản `swr` khác nhau.

## 4. Sử dụng lazy loading khi có thể

Lazy loading giúp giảm kích thước ứng dụng đi khá nhiều do browser sẽ không cần tải hết code của ứng dụng tại 1 thời điểm.

Ví dụ: bạn có 2 component `Homepage` và `Account` cho 2 route `/` và `/account` trong ứng dụng react. Nếu bạn bundle tất cả vào chung 1 file js sẽ gây ra lãng phí vì tại 1 thời điểm, user chỉ vào được 1 route duy nhất nhưng nó phải download cả code của `Homepage` và `Account`.

React cung cấp cho developer hàm [`React.lazy`](https://reactjs.org/docs/code-splitting.html), NextJS có hàm [`dynamic`](https://nextjs.org/docs/advanced-features/dynamic-import) trong module `next/dynamic`.
Với các component khác, bạn có thể chỉ cần builtin function [`import`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import) của JS là đủ.

## 5. Tránh việc viết nhiều component vào cùng 1 file

Giả sử ứng dụng của mình có cấu trúc như sau:

```
src
├── helpers.js
└── pages
   ├── account.js
   └── index.js
```

```jsx
// helpers.js

export function foo() {
  return "foo";
}

export function bar() {
  return "bar";
}
```

```jsx
// pages/account.jsx

import { foo } from "../helpers";

export default function Home() {
  return <div>{foo()}</div>;
}
```

```jsx
// pages/index.jsx

import { bar } from "../helpers";

export default function Account() {
  return <div>{bar()}</div>;
}
```

Ứng dụng của mình có 2 entrypoint và mình sử dụng webpack làm bundler.

Bạn có thể thấy, hai hàm `foo` và `bar` được dùng ở trong toàn bộ ứng dụng. Tuy nhiên, đối với `index.js` thì hàm `bar` là deadcode, với `account.js` thì `foo` là deadcode. Tuy nhiên, webpack vẫn bundle cả 2 hàm vào mỗi đầu ra của cả 2 entrypoint dẫn tới unused js.

Điều này xả ra do tối ưu `usedExports` của webpack nhìn 2 hàm này dưới góc nhìn của toàn bộ ứng dụng chứ không phải theo góc nhìn của từng entrypoint. Do đó, nó sẽ không remove chúng ra khỏi bundle. **Hay nhớ rằng, tối ưu này chỉ remove những đoạn code không được sử dụng ở bất kì đâu trong ứng dụng**.

Để tree shaking được hiệu quả, bạn có thể tách hai hàm này ra thành các file riêng biệt hoặc viết chúng ngay trong file entrypoint, nơi chúng được sử dụng.

## 6. Giữ nguyên cấu trúc source code khi compile nếu đó là thư viện

Việc giữ nguyên cấu trúc sẽ giúp developer dễ dàng hơn trong việc control tree shaking. Đồng thời, nó cũng giúp tránh được các side-effect do quá trình bundle + minimize của bundler.

Trong RollupJS, bạn có thể enable chế độ [`preserveModules`](https://rollupjs.org/guide/en/#outputpreservemodules)

## 7. Hạn chế sử dụng `import * from '...'`

Việc sử dụng `import * from ...` đồng nghĩa với việc bạn nói với bundler rằng bạn sẽ sử dụng toàn bộ component mà thư viện đó cung cấp mặc dù trong thực tế bạn chỉ sử dụng rất ít các component. Việc `import` như vậy là nguyên nhân phổ biến làm kích thước của ứng dụng lớn. Hãy `import` chỉ những gì bạn thật sự sử dụng như

```javascript
import useSWR from "swr";
import useInfinite from "swr/infinite";
```

Vừa rồi là những king nghiệm của mình trong việc loại bỏ deadcode ra khỏi một ứng dụng web. Mình hi vọng bài viết này sẽ giúp ích phần nào cho các bạn trong việc cải thiện chất lượng của ứng dụng web.


Tại Teko, team của mình phát triển một ứng dụng web bán hàng cho nhiều khách hàng như Phong Vũ, VnShop, VinMart, ... Với việc nhiều khách hàng như vậy nên lượng feature để đáp ứng nhu cầu là rất cao, đòi hỏi codebase lớn. Và tất nhiên, bên cạnh phát triển và hoàn thiện tính năng, chúng mình còn phải tối ưu sao cho chúng chạy ổn định và "nhanh".

Một trong những khía cạnh để mình có thể tiếp cận trong việc tối ưu chính là bundle size của sản phẩm. Một trong những công cụ giúp tụi mình phát hiện vấn đề là nhờ một số kĩ thuật đánh giá mà mình có đề cập trong bài viết [trước đây](su-dung-lighthouse-va-react-developer-tools-de-danh-gia-hieu-nang-web.md).

Trước khi tối ưu bundle size, người dùng phải load ít nhất 750kb dữ liệu khi vào trang web. Sau khi tối ưu, con số này giảm còn 340kb.

Trong bài viết này, mình sẽ đi chi tiết hơn về một kĩ thuật giúp giảm bundle size của các ứng dụng web hiện đại được gọi là **tree shaking**. Đồng thời, bài viết này sẽ lấy ví dụ thông qua Webpack, các bundler khác có thể sẽ có cách thức hoạt động hơi khác.

### Tree shaking là gì?

Tree shaking là một thuật ngữ để chỉ việc gỡ bỏ dead code. Các bundle hiện này hỗ trợ tính năng này có thể kể đến như Webpack, Rollup hay ESBuild. Tất nhiên, nó không phải là một tính năng có thể chỉ cần on/off là xong. Để đạt được kì vọng, bạn phải luôn monitor ứng dụng, phát hiện và áp dụng các kĩ thuật để tree shaking hoạt động hiệu quả.

### Tại sao tree shaking lại quan trọng?

Dead code là những đoạn code bị thừa trong artifact. Chúng nên được gỡ bỏ trước khi được deliver tới người dùng. Việc chúng được gỡ bỏ sẽ làm giảm việc downloading, decompressing, parsing và executing code. Từ đó giúp tăng hiêụ năng và trải nghiệm người dùng, giúp ứng dụng của chúng ta "nhanh" hơn.

### Tree shaking hoạt động ra sao?

Khi viết một ứng dụng, chúng ta thường xuyên sử dụng các dependency (hay các library). Do chúng là các thư viện phục vụ cho nhiều người nên chúng sẽ cung cấp tối đa các feature mà nó có. Điều này dẫn tới việc có những feature chúng ta không cần tới nhưng chúng vẫn được bundle vào artifact bởi các bundler như Webpack.

Bằng việc tạo ra một dependency graph, các bundler sẽ biết những đoạn code nào là dư thừa và sẽ được gỡ bỏ trong quá trình minification.

Để các bundler biết được đoạn code nào thừa, các thư viện phải được cấu trúc sao cho chúng hỗ trợ được tree shaking khi bundler chạy qua chúng. Đây là mấu chốt của vấn đề mà trong phần sau của bài viết mình sẽ đi chi tiết hơn.

### Làm sao để kiểm tra một thư viện thực sự có thể tree shake?

Cách đơn giản nhất là bạn có thể bundle ứng dụng của bạn khi sử dụng thư viện đó và sau đó kiểm tra output của nó. Nếu nó chứa những đoạn code không sử dụng, đồng nghĩa với việc thư viện đó có khả năng không thể tree shake được.

Có hai điều bạn cần lưu ý là:

- Tree shaking chỉ xaỷ ra ở code application, không phải ở code library. Vì chỉ ở application, bundler mới biết đâu là đoạn code được sử dụng.
- Thư viện nên đảm bảo khả năng tree shake cho bundler sau này.

<Image
  src="/images/simple-export-module-graph.svg"
  title="Nguồn: https://blog.theodo.com"
/>

Trong hình trên, khi tree shaking hoạt động, hàm **getUserPhoneNumber** sẽ bị gỡ khỏi bundle file.

OK, giờ chúng ta sẽ tới phần: **Làm sao để viết một thư viện có khả năng tree shaking?**

### Luôn sử dụng ES module giúp bundler có thể phát hiện dead code

Có rất nhiều format trong Javascript code nhưng phổ biến và hay gặp nhất là CommonJS (CJS) và ECMA Script Modules (ESM). Đây là hai hệ thống module phổ biến của JS trong đó, CJS được sử dụng phổ biến bởi NodeJS. ESM được hỗ trợ trong các bản sau ES6 và sau này cũng được hỗ trợ bởi NodeJS nhưng không phổ biến như CJS.

Vấn đề ở đây là: có thể import/export module ở bất kì đâu trong CJS còn ESM thì luôn phải import/export ở module scope.

Việc import/export quá linh động trong CJS làm cho code của chúng ta khó đoán. Mình có thể lấy ví dụ như sau:

```javascript
// lib.js

module.exports = {
  foo: () => console.log("Foo")
}

// app.js

if (conditions) {
  const { foo } = require("./lib.js");
  ...
}
```

Bundler sẽ không biết hàm **foo** được sử dụng hay không tại thời điểm bundle và do đó nó không thể tree shake. **Việc có thể import/export ở bất kì đâu của CJS sẽ làm bundle không thể phát hiện được những đoạn code không sử dụng**. Mặc định, tính năng tree-shaking trong các bundler sẽ không hỗ trợ đối với các thư viện có format CJS.

```javascript
// lib.js

export function foo {
  console.log("Foo");
}

// app.js

import { foo } from "./lib.js";
```

Ngược lại, ESM có cơ chế rõ ràng trong việc import/export. Bạn chỉ có thể thực hiện import/export ở module scope nên bundler có thể thấy rõ ràng module của bạn đang sử dụng những module nào, tại thời điểm bundle.

Hiện nay, đa số các thư viện JS sẽ hỗ trợ đồng thời cả 2 format ESM và CJS. Trong file **package.json**, entrypoint dành cho ESM là **module**, CJS sẽ là **main**.

```json
{
  "main": "dist/index.cjs",
  "module": "dist/index.ejs"
}
```

<Image
  src="/images/esmodules-module-graph.svg"
  title="Nguồn: https://blog.theodo.com"
  height={400}
/>

Với graph ở trên, hàm **getUserAccout** là một unused export nên bundler có thể sẽ gỡ bỏ **userAccount.js** file ra khỏi bundle. Điều này chưa chắc đã đúng, cùng tìm hiểu ở phần sau nhé :smile:

Tóm lại, ở phần này, bạn cần nắm được:

- ESM là điều kiện cần có để tree-shaking có thể hoạt động
- Hãy đảm bảo thư viện mà bạn cung cấp hỗ trợ ESM
- Chắc chắn thư viện mà bạn sử dụng hỗ trợ ESM khi có thể hoặc bạn sẽ không thể tree-shake :smile:

### Sử dụng side-effect optimization nếu có thể

Trong Webpack có hai loại tối ưu:

- **usedExports**: phát hiện những export module được sử dụng hoặc không được sử dụng ở bất kì đâu
- **sideEffects**: bỏ qua những module mà ở đó không có bất kì export nào được sử dụng và free side-effect.

Như ở ví dụ trong phần trước, nếu loại bỏ hoàn toàn **userAccount.js**, rất có thể ứng dụng của bạn sẽ hoạt động sai kì vọng vì trong file đó, có những đoạn code tác động lên các biến global như DOM hay window. Trường hợp phổ biến nhất là các hàm polyfill. Bên cạnh đó, không ít thư viện dùng tính năng import css cũng dẫn tới tình trạng side-effect.

Chúng ta cần lưu ý: side-effect chỉ được sử dụng nếu thư viện đó free side-effect.
Các bundler như Webpack hay Rollup mặc định sẽ hiểu thư viện của bạn side-effect hoàn toàn.
Nếu chúng ta đảm bảo thư viện của mình là hoàn toàn free side-effect thì có thể set **sideEffects** trong package.json là **false**. Khi này, các bundler sẽ thực hiện side-effect optimization.

Trong vài trường hợp, chúng ta không muốn áp dụng side-effect optimization lên một vài file (chẳng hạn như các file css), chúng ta có thể liệt kê nó trong sideEffects như sau:

```json
{
  "sideEffects": ["dist/style.css"]
}
```

Như vậy, ta có thể thấy sideEffect hoạt động hiệu quả hơn khi nó sẽ bỏ qua toàn bộ module/file và subtree.

Để hiểu hơn về 2 tối ưu này, bạn cần nhớ rằng:

- sideEffects bỏ qua toàn bộ những module được import nếu không có bất kì nội dung nào của nó được sử dụng.
- usedExports gỡ bỏ hoàn toàn những export không được sử dụng ở bất kì module nào.

Side effect sẽ không thực sự hiệu quả nếu module không được chia đủ nhỏ và phần sau mình sẽ nói rõ hơn ý này.

Tóm lại, ở phần này, các bạn cần nắm những ý sau:

- tree shaking có 2 phần: **used exports** và **side effects**
- Side efffect hiệu quả hơn việc chỉ sử dụng **used exports**
- Đảm bảo thư viện của bạn phải free side-effect trước khi dùng tối ưu này

### Chia code thành các module nhỏ nhất có thể để tạo điều kiện cho tối ưu side-effect

Việc các bundler như Webpack, Rollup hay ESBuild sẽ gom tất cả các file vào làm 1 file duy nhất. Ở khía cạnh tree-shaking, tối ưu side-effect sẽ không thể xảy ra và chẳng có module nào được loại bỏ.

Hãy cùng xét ví dụ sau:

```javascript
import { isNil } from "lodash";

const checkExistance = (variable) => !isNil(variable);

const userAccount = {
  name: "user account",
};

const getUserAccount = () => {
  return userAccount;
};

const getUserPhoneNumber = () => "***********";

const getUserName = () => "John Doe";

export { checkExistance, getUserName, getUserPhoneNumber, getUserAccount };
```

Khi Webpack bundle, mặc dù **checkExistance** không được sử dụng nhưng **lodash** vẫn được bundle do Webpack không thể tree-shaking CJS (format của lodash).

Nhưng may mắn là trong Rollup, bạn có thể cấu hình **preserveModules: true** nếu muốn giữ nguyên cấu trúc của thư viện và khi đó, lodash sẽ không được import do tối ưu side-effect sẽ cắt bỏ toàn bộ subtree của **checkExistance**

<Image
  src="/images/split-modules-cjs-module-graph.svg"
  title="Nguồn: https://blog.theodo.com"
  height={400}
/>

### Code split và việc chia nhỏ code

Giả sử chúng ta có 1 thư viện với 3 file như sau:

```javascript
// user-library/src/userAccount.js
export const userAccount = {
  name: "user account",
};
```

```javascript
// user-library/src/userPhoneNumber.js
export const userPhoneNumber = {
  number: "***********",
};
```

```javascript
// user-library/src/index.js
import { userAccount } from "./userAccount";
import { userPhoneNumber } from "./userPhoneNumber";

const getUserName = () => "John Doe";

export { userAccount, getUserName, userPhoneNumber };
```

Và code của application chúng ta sử dụng chúng như sau:

```javascript
// user-app/src/userService1.js
import { userAccount } from "user-library";

export const logUserAccount = () => {
  console.log(userAccount);
};
```

```javascript
// user-app/src/userService2.js
import { userPhoneNumber } from "user-library";

export const logUserPhoneNumber = () => {
  console.log(userPhoneNumber);
};
```

```javascript
// user-app/src/index.js
const main = async () => {
  const { logUserPhoneNumber } = await import("./userService2");
  const { logUserAccount } = await import("./userService1");

  logUserAccount();
  logUserPhoneNumber();
};

main();
```

<Image
  src="/images/code-splitting-without-preserving-module-structure-graph.svg"
  title="Nguồn: https://blog.theodo.com"
  height={400}
/>

Trong trường hợp nếu chỉ sử dụng **usedExports** thì nó không thể phát hiện module nào nên được gỡ bỏ vì phương pháp này chỉ hoạt động ở module scope. Do đó, mặc dù **serviceAccount2.js** không sử dụng **userAccount** nhưng nó vẫn không được gán là unused do nó được dùng trong **serviceAccount1.js**

Vậy chúng ta cần lưu ý ở đây: **Webpack không thể tree shake được các exported module trong các chunk độc lập nếu chỉ dùng phương pháp usedExports**.

Nhưng nếu chúng ta sử dụng phương pháp **side-effect**, nó có thể cắt bỏ toàn bộ nhánh **userAccount.js** khi ở **serviceAccount2.js** và cắt **userPhoneNumber.js** khi ở **serviceAccount1.js**.

Một cách dễ hiểu để phân biệt hai phương pháp này là: Nếu ta coi toàn bộ dependencies là một cái cây thì phương pháp **usedExports** sẽ nhìn từ lá lên trên gốc để quyết định việc có nên cắt bỏ chiếc lá đó hay không. Còn **side-effect** sẽ nhìn từ trên xuống để quyết định cắt bỏ toàn bộ subtree đó hay không.

<Image
  src="/images/code-splitting-with-preserving-module-structure-graph.svg"
  title="Nguồn: https://blog.theodo.com"
  height={400}
/>

Tóm lại phần này chúng ta cần nhớ rằng: nếu trên cây, những chiếc lá càng nhỏ, khớp nối càng lỏng lẻo thì việc rung cây để cho lá rụng sẽ dễ hơn những chiếc lá lớn và có khớp nối chắc.

Điều này ám chỉ những chiếc lá là module và code được chia vào các module nhỏ (lá bé) và free side-effect (khớp nối lỏng lẻo) thì càng dễ dàng cho việc tree-shaking.

Vậy tóm lại qua bài viết này, các bạn cần nhớ được những ý sau:

- luôn sử dụng những thư viện hỗ trợ chuẩn ESM khi có thể, nếu bạn thấy một đoạn code nào đó không thể tree-shaking, hãy kiểm tra lại format của nó trước tiên
- Giữ cho code free side-effect
- Chia code logic vào các module đủ nhỏ để dễ dàng cho việc tree-shaking
- Sử dụng split code khi có thể, luôn luôn giữ cấu trúc code riêng lẻ khi viết thư viện

Tất cả những điều trên sẽ giúp bạn có một thư viện dễ dàng tree-shaking và ứng dụng của bạn sẽ tối ưu về bundle size nhất có thể.


Làm sao chúng ta có thể trả lời câu hỏi: **Website này có hiệu năng cao hay thấp, nhanh hay chậm?** hay **Website này có tồn tại những vấn đề gì cần được khắc phục?**.

Để trả lời cho câu hỏi này, chúng ta cần phải đo các chỉ số về hiệu năng, SEO,... của ứng dụng đó.

Có nhiều cách để đo các chỉ số trên và trong bài viết này mình sẽ sử dụng [Google Lighthouse](https://developers.google.com/web/tools/lighthouse/) và [React Developer Tools
](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi) để đo lường chất lượng cũng như phát hiện những vấn đề mà website của chúng ta có thể đang gặp phải.

## 1. Lighthouse

Google Lighthouse là công cụ được tích hợp sẵn trong Google Chrome. Để mở nó, bạn nhấn tổ hợp phím **Ctrl + Shift + I** (hoặc **Optional + Command + J** trên MacOS) để truy cập DevTools, sau đó chọn tab **Lighthouse**

<Image
  src="/images/lighthouse-1.png"
  title="Màn hình Lighthouse trên Google Chrome"
  height={200}
/>

Có 2 phần chính bạn cần chú ý trên Lighthouse là **Categorise** và **Device**. **Categories** là những loại chỉ số mà bạn cần đo, ở đây mình chọn các chỉ số liên quan đến hiệu năng - Performance. Tiếp theo, chọn loại thiết bị mà bạn muốn đo, ở đây mình chọn Desktop.

Tiếp tục nhấn **Generate report** và chờ kết quả trả ra :smile:

Trong bài viết này, mình tập trung vào phần **Performance** vì đó là phần quan trọng nhất để đánh giá một website tốt hay dở tệ.

### Điểm tổng quan

<Image
  src="/images/lighthouse-2.png"
  title="Điểm hiệu năng trung bình và điểm của từng chỉ số"
/>

Bạn có thể thấy trong hình, điểm trung bình về hiệu năng là 40. Điểm số này được tính dựa trên điểm các chỉ số khác về hiệu năng, mỗi chỉ số khác nhau sẽ có các trọng số khác nhau. Các chỉ số có màu đỏ là những thứ chúng ta cần khắc phục, nên quan tâm đến những chỉ số màu vàng và những chỉ số màu xanh là những chỉ số tốt chúng ta cần duy trì.

Ở đây có thể thấy website này đang khá tệ do:

- thời gian block cao - [Total Block Time](https://web.dev/tbt/): 0.5s
- thời gian cần để lượng lớn các phần tử hiển thị trên viewport lớn - [Largest Contentful Paint](https://web.dev/lcp/): 2.5s
- thời gian nội dung được hiển thị trực quan khi trang đang được tải lớn - [Speed Index](https://web.dev/speed-index/): 3.3s
- mức độ ổn định của trang, được đo bằng sự sai khác nhau về vị trí các phần tử trong những lần render - [Cumulative Layout Shift](https://web.dev/cls/)

Bạn có thể tìm hiểu thêm về các metric ở đây: [https://web.dev/metrics/](https://web.dev/metrics/)

Lưu ý: điểm của các chỉ số này chỉ là tương đối ngay tại thời điểm đo. Có thể lần đo ngay sau khi network khoẻ hay máy tính của bạn khoẻ hơn, kết quả đo được sẽ tốt lên.

### Những chỉ số có thể cải thiện

<Image src="/images/lighthouse-3.png" title="Những chỉ số có thể cải thiện" />

Lighthouse đưa ra một viễn cảnh nơi website của bạn có thể đạt được như sau:

- Thời gian server phản hồi có thể cải thiện 0.88s
- Bạn có thể cắt bỏ những đoạn JS thừa để giảm thời gian load 0.6s

Thời gian server phản hồi có thể đo chính xác hơn bằng cách đo thời gian từ thời điểm request đến lúc nhận được byte đầu tiên từ server (Time To First Byte). Bạn có thể sử dụng [wrk](https://github.com/magiskboy/wrk) để đo trên nhiều request cho kết quả khách quan nhất.

Nói chung đây chỉ là những dự đoán của Lighthouse và nó còn tuỳ thuộc vào ứng dụng của bạn nữa nhé :smile:

### Chẩn đoán những vấn đề hiện tại

<Image
  src="/images/lighthouse-4.png"
  title="Nguyên nhân (có thể) cần khắc phục"
/>

Ở đây mình thấy có 2 vấn đề quan trọng là thời gian main thread bị block quá dài và lượng JS thừa làm thời gian xử li kéo dài 2.3s.

Ngoài ra, bạn cũng nên kết hợp sử dụng những công cụ khác của DevTools để có thêm nhiều thông tin hơn trong quá trình đo lường.

Vậy là mình đã giới thiệu sơ qua về Lighthouse để đo lượng hiệu năng của website. Với công cụ này, bạn có thể đánh giá dễ dàng với bất kì website nào bạn muốn.

## 2. React Developer Tools

React Developer Tools là công cụ cho phép bạn debug ứng dụng ReactJS một cách dễ dàng. Nó là một extension trên nhiều trình duyệt. Trong bài viết này, mình sử dụng nó trên Google Chrome.

Để có thể sử dụng, ứng dụng của bạn phải chạy trong component **Profiler** của ReactJS: [https://reactjs.org/docs/profiler.html](https://reactjs.org/docs/profiler.html).

Sau khi load trang, bạn mở Chrome DevTools như phần trên rồi chọn tab **Profiler** như hình

<Image
  src="/images/react-developer-tools-1.png"
  title="React Developer Tools"
/>

Để bắt đầu recording, bạn click vào biểu tượng reload góc trên bên trái. Cơ bản, website sẽ reload và được record lại, sau khi thấy website được load hết, bạn click vào biểu tượng stop màu đỏ góc trên bên trái để dừng việc record và hiển thị kết quả đo lường như hình dưới

Ở đây mình chọn **Flamegraph** cho bài viết này, các bạn có thể tham khảo thêm **Ranked** trên google nhé :smile:

<Image
  src="/images/react-developer-tools-2.png"
  title="Thời gian render của từng component dưới dạng Flamegraph"
/>

Để hiểu rõ hơn về biểu đồ này, mình sẽ giải thích sơ qua về quá trình render của React.

Trong 1 lần render, React sẽ render component thành DOM Node (phase **render**) và đem đi so sánh với DOM Node hiện tại. Nếu có sự khác biệt, DOM Node đó sẽ được thay thế bằng giá trị mới (phase **commit**) ngược lại sẽ bỏ qua. Từ đó suy ra, số lần render lớn hơn hoặc bằng số lần commit.

Chúng ta có thể thấy phần bên trái là biểu đồ về phân bố thời gian cho 1 lần app được commit.
Phần bên phải là thông tin chi tiết về lần commit đó của cả app bao gồm thời điểm commit và thời gian render.

Ngoài ra, góc trên bên phải có 1 barchart. Mỗi cột trong barchart đại diện cho thời gian render của commit đó. Trong hình có thể thấy có 5 lần commit có thời gian render khá dài.

<Image
  src="/images/react-developer-tools-4.png"
  title="Tổng quan các lần commit của app"
  height={80}
/>

Nhìn hình trên, chúng ta thấy số lần commit là 60 và biểu đồ hiện tại là commit đầu tiên.

Khi click vào từng component sẽ hiển thị số lần render của component đó.

<Image
  src="/images/react-developer-tools-3.png"
  title="Chi tiết về render Layout component"
/>

Như trong hình bạn có thể thấy, component cha ở trên, các component con đứng ngang hàng với nhau và ở dưới component cha.

Thời gian render component cha là tổng thời gian render các component con và thời gian render chính nó.

Khi tối ưu render, bạn sẽ nhìn lên barchart và click vào những thanh cao nhất hoặc màu vàng vì đó là những lần commit có thời gian render cao, cần tối ưu.

## 3. Kết bài

Sau bài viết này, các bạn đã có thêm những công cụ hữu ích để có thể đưa ra đánh giá về 1 website có hiệu năng cao hay thấp, đặc biệt là có cái nhìn chi tiết hơn về ứng dụng web nói chung và ứng dụng React nói riêng để từ đó đưa ra những quyết định nên tối ưu ở đâu và như thế nào.


Để hiểu rõ hơn về context trong Flask, chúng ta cũng tìm hiểu xem một web khi viết bằng Python sẽ hoạt động ra sao.

### 1. [WSGI](https://wsgi.readthedocs.io/en/latest/what.html)

Theo [PEP 333](https://www.python.org/dev/peps/pep-0333/), một ứng dụng web khi cài đặt về cơ bản sẽ một hàm với 2 tham số

- `environment`: một `dict` chứa toàn bộ dữ liệu client gửi đến server, nói các khác, đây chính là gói tin HTTP request đã được parse
- `start_response`: một hàm nhận vào status code và danh sách các header, những cái này sẽ được ghi vào phần đầu của gói tin HTTP response

Hàm sau khi xử lí sẽ trả về một iterable của các byte dữ liệu, cái này sẽ được dùng để ghi vào phần body trong gói tin HTTP response.

Khi chạy bất kì một WSGI server nào như gunicorn, uwsgi hay mod_wsgi của Apache, các webserver đó sẽ fork một thread và dùng hàm này để xử lí một request.

Chẳng hạn như này:

```python
# code application
def app(environment, start_response):
	start_response('200 OK', [('Content-Type', 'plain/text')])
	return b'Hello world'

# code webserver
def request_handle(wsgi_app, http_request):
	http_response = BytesIO()

	def start_response(status_code, headers):
		nonlocal http_response
		...

	environment = parse_http_request(http_request)
	body_message = wsgi_app(environment, start_response)
	http_response.write(body_message)
	# send http_response to the client

thread = Thread(target=handle, args(app, http_request,), daemon=True)
thread.start()
```

Vậy ta có thể thấy rằng, environment chính là một context. Handler của chúng ta nhận đầu vào là environment(http request) nên mọi xử lí sẽ phải phụ thuộc vào context này.

Cụ thể, trong flask, `environment` được parse tiếp thành `flask.request` object.

### 2. Vấn đề của Django và các web framework khác

Khi bạn làm việc với Django hay các python web framework khác, bạn có thể thấy rằng nếu chúng ta muốn sử dụng dữ liệu từ request, bắt buộc chúng ta phải truyền top-down biến request xuống từng hàm mà mình muốn sử dụng

Chẳng hạn thế này

```python
def nest_nest_function(request):
	...

def nest_function(request):
	# chả dùng request những vẫn cần phải truyền vào để cho con nó dùng
	nest_nest_function(request)

def index(request):
	# chả dùng request những vẫn cần phải truyền vào để cho con nó dùng
	nest_function(request)
```

Vì đây là backend nên trường hợp này khá hiếm xảy ra và số lượng các hàm lồng nhau cũng không nhiều. Nhưng đó là trường hợp thường xuyên xảy ra trong frontend, đặc biệt là React. Và React cũng giải quyết vấn đề này giống cách mà Flask đã làm.

### 3. Flask proxy

Như bạn thấy ở trên, các request sẽ được isolate trong các thread riêng biệt với context của nó là environment và nó hoàn toàn có thể trở thành một giá trị global trong thread đó.

Ngược lại, trong process scope bao gồm nhiều thread, các environment này không được phép dùng lẫn của nhau và chúng ta nên thắc mắc

**Tại sao khi dùng `flask.request`, tôi có thể gọi nó ở mọi nơi (process scope) mà không bị nhầm lẫn các environment?.**

Vâng, tất nhiên, `flask.request` hay một vài thứ khác tương tự không phải là một object bình thường, chúng là các proxy có behavior để phân biệt nó đang được gọi ở thread nào để có thể lựa chọn context sao cho phù hợp.

OK, nghe có vẻ rất kì diệu nhưng thật ra rất đơn giản!

Mọi chuyện thật đơn giản nếu thread của chúng ta có một cái tên! Vâng chính xác, mỗi một thread khi được fork sẽ có một định danh (id) và nó có thể được lấy ra bằng hàm `threading.get_ident()` chẳng hạn.

Và nếu chúng ta có một `dict` với key là id của thread và value là giá trị của context thì sao nhỉ, chẳng hạn như thế này

```python
global_container = {}

def set_context(value):
	global global_container

	tid = threading.get_ident()
	global_container[tid] = value

def get_context():
	global global_container

	tid = threading.get_ident()
	if tid not in global_container:
		raise RuntimeError("Working outside of application context.")
	return global_container.get(tid)

def nest_function():
	ctx = get_context()
	print(f'In nest function, thread {threading.get_ident()}: {initial_context}')

def handle():
	initial_context = random.random()
	print(f'In handle function, thread {threading.get_ident()}: {initial_context}')
	set_context(initial_context)
	nest_function()

t1 = threading.Thread(target=handle)
t2 = threading.Thread(target=handle)

t1.start()
t2.start()
```

Bằng cách này, khi chúng ta gọi các proxy trong các thread xác định, nó sẽ lấy id của thread đó và lookup trong một global mapping (`global_container` chẳng hạn) để tìm giá trị phù hợp.

Vậy các bạn thử đoán xem trong ví dụ ở phần 1, chúng ta nên set environment ở đâu để nó trở thành context của một thread?

Để biết thêm về cài đặt chi tiết trong Flask, các bạn có thể tìm hiểu về một vài class cũng như những package sau

- [`werkzeug.local.LocalStack`](https://github.com/pallets/werkzeug/blob/master/src/werkzeug/local.py#L170)
- [`werkzeug.local.LocalProxy`](https://github.com/pallets/werkzeug/blob/master/src/werkzeug/local.py#L467)
- [`flask.globals`](https://github.com/pallets/flask/blob/master/src/flask/globals.py)
- [`flask.ctx`](https://github.com/pallets/flask/blob/master/src/flask/ctx.py)

Ngoài request, flask còn có application context chứa application hiện tại khi chúng ta gọi `flask.g` hay `flask.current_app`.

### 4. Ứng dụng của Flask proxy

Flask cũng cho phép chúng ta có thể hoàn toàn tự tạo một context cho riêng mình:

Xử lí ở thread khác

```python
@app.route('/')
def index():
    @copy_current_request_context
    def do_some_work():
        # do some work here, it can access flask.request or
        # flask.session like you would otherwise in the view function.
        ...
    gevent.spawn(do_some_work)
    return 'Regular response'
```

Hay xử lí ở process (thread) khác

```python
app = Flask(__name__)

with app.request_context(envỉonment):
	do_something()
```

Thiết kế này cũng được các extension của flask tuân thủ như Flask-Login, Flask-Admin hay Flask-Celery...

Đến đây, bạn đã có thể nắm được một trong những khái niệm quan trọng trong Flask và có thể sử dụng nó một các đúng cách, tránh các lỗi ngớ ngẩn trong quá trình phát triển.

Hẹn gặp lại các bạn ở bài viết sau, bye bye.


Cú pháp của Python rất sáng sủa và dễ học, chính vì thế có rất nhiều thư viện ở nhiều lĩnh vực được cài đặt bằng Python, hoặc ít nhất cũng có interface là Python như:

- Tensorflow, PyTorch, Theano cho machine learning
- Numpy, SciPy cho tính toán khoa học
- Spark, Pandas cho việc xử lí dữ liệu
- Docker cho containerize
- Django, Flask, FastAPI, Tornado cho phát triển web

Trong bài viết này, mình muốn tập trung vào những thứ hay ho của một web framework - Flask, một framework được cài đặt thuần bằng Python và có được sự hưởng ứng của nhiều người.

### 1. Đơn giản và khả năng mở rộng

Thật sự, Flask là một framework web cực kì nhỏ gọn (như tác giả nói rằng Flask là một micro web framework) so với những đàn anh của nó như Django hay Tornado. Vậy Flask có những gì

- URL routing
- Template engine
- Các high level class
- Testing module
- Commandline tool

Flask không bắt bạn phải làm theo những gì được coi là tiêu chuẩn của nó (tất nhiên vẫn cần có những pattern riêng cho việc này nhưng nó không quá phức tạp) như các framework khác, đặc biệt là Django trong Python.

Nếu bạn cần deploy một model machine learning, nhiêu đó là quá đủ.

Ứng dụng của bạn phức tạp hơn? Flask có 1 giải pháp - extension

Flask có thể được cộng đồng mở rộng bằng cách phát triển các module tách biệt cho nó, cực kì linh hoạt.

Bạn cần tương tác với database, Flask-SQLAlchemy giúp bạn điều này.

Bạn muốn có một hệ thống quản lí dữ liệu như Django, Flask-Admin có thể là lựa chọn hay đấy.

Bạn cần các chức năng authenticate và authorization cho các request, Flask-Login giúp bạn điều đó.

Bạn cần phát triển các RestfulAPI nhanh chóng và thuận tiện, Flask-Connexion sẽ giúp bạn.

Bạn có thể build bất kì một hệ thống web backend nào dựa trên Flask, tất nhiên sự đơn giản của framework cũng đồng nghĩa với việc bạn phải động não nhiều hơn.

### 2. Cấu trúc đơn giả và hiệu quả

Bạn muốn có một backend, đây là những thứ bạn cần với Flask

```python
# main.py

from flask import Flask

app = Flask(__name__)

@app.route('/')
def homepage():
	return 'Hello world'
```

và bạn có thể chạy nó

```sh
$ FLASK_APP=main:app flask run
* Serving Flask app "main:app"
* Environment: production
   WARNING: This is a development server. Do not use it in a production deployment.
   Use a production WSGI server instead.
* Debug mode: off
* Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)
```

Sự đơn giản mà Flask có được cũng nhờ cú pháp đơn giản của Python. Để định nghĩa một router, bạn đơn giản viết một hàm và wrap nó bằng decorator trong Python.

Decorator là một design pattern hiệu quả, bạn có thể xem thêm nó [ở đây](https://en.wikipedia.org/wiki/Decorator_pattern)

Bằng cách này, các lập trình viên có thể thoả sức viết thêm các modifier cho các router như Flask-Login, Flask-Cache.

Đơn giản là các library đó sẽ viết thêm các decorator để người dùng có thể sử dụng cho bất kì router nào họ muốn, thật quá đơn giản.

### 3. Flask tương thích với đa số các Python web server

Flask được implement dựa trên [WSGI](https://wsgi.readthedocs.io/en/latest/what.html) nên nó có thể chạy dễ dàng trên các web server như gunicorn, uvicorn hay hypercorn. Thậm chí, từ xa xưa, Apache cũng có một module cho wsgi là `mod_wsgi`.

### 4. Context

Một điều thú vị nữa mà Flask đem lại có lẽ là khái niệm về `context`.

Nếu bạn nào từng làm Django hẳn sẽ gặp những trường hợp như bạn phải pass cái biến `request` qua 3, 4 hàm lồng nhau, trên thực tế nó không chỉ đem lại một cấu trúc code rối rắm mà còn làm mất tính đồng nhất khó kiểm soát.

Flask đi sau và tất nhiên nó có giải pháp khắc phục chuyện này - `context`.

Như bạn biết, khi có 2 request (2 `context` khác nhau) gửi đến app của bạn, app của bạn cơ bản là fork ra 2 thread khác nhau để xử lí 2 request đó.

Flask có một proxy có thể phân biệt request của từng thread là `flask.request`.

Khi bạn gọi `flask.request`, Flask app sẽ tìm đúng request mà bạn sở hữu và trả về một `Request` object, object này mang toàn bộ thông tin request của client gửi đến server.

```python
@app.route('/books')
def create_book():
	print(id(flask.request))
	...
```

Khi có 2 request đến đồng thời, `flask.request` sẽ có trỏ đến 2 `Request` object khác nhau tuỳ vào việc nó được gọi trong thread nào. Vâng, nó thật là kì diệu.

Chi tiết cụ thể tại sao Flask có thể làm được việc này mình sẽ nói trong bài viết sau, khi nói về thread local.

Bạn cũng có thể thấy khái niệm `context` này được sử dụng trong [ReactJS](https://reactjs.org/docs/context.html) để giải quyết vấn đề tương tự.

Ngoài [request context](https://flask.palletsprojects.com/en/1.1.x/reqcontext/), flask còn có [application context](https://flask.palletsprojects.com/en/1.1.x/appcontext/), các bạn có thể tham khảo tài liệu của Flask để biết thêm cách dùng của nó.

### 5. Testing

Testing luôn là một vấn đề khó khăn đối với đa số các bạn, trong đó có cả mình 😆. Điều đó càng trở nên kinh dị nếu như framework mà bạn chọn không hỗ trợ tốt unit testing. Thật may mắn, Flask làm việc này cực kì tốt (so với đa số các web framework trong Python 😀).

Khi bạn viết một app trong Flask, về cơ bản là bạn tạo ra một `Flask` object với hàng tá các router trong đó.

Vậy việc test app chính là việc test các hàm router trong cái app này. Vậy làm sao để test các hàm đó khi nó đang nằm trong app, thậm chí, có thế hàm đó đang được decorate bởi một đống các hàm khác?

Flask giúp chúng ta điều này bằng cách cung cấp cho bạn một `TestClient` object, cái đó đóng vai trò như là một client thực sự.

Để tạo được object này, bạn chỉ cần gọi phương thức `test_client` trong `Flask` object

Giả sử, backend của bạn có một api truyền lên tên một người và trả về lời chào người đó, bạn có thể làm như sau:

```python
app = Flask(__name__)

@app.route('/say/<name>', methods=['GET'])
def say_hello(name):
	return f'Hello, {name}'

client = app.test_client()

response = client.get('/say/Thanh')

assert response.data == b'Hello, Thanh'
```

OK, đó là những điều mình cảm thấy Flask thật tuyệt vời để mình có thể phát triển một webservice trong Python. Bạn thì sao, cho mình ý kiến của các bạn trong phần comment bên dưới nhé, bye bye.


Giả sử, mình có project Django như sau:

```sh
── app
│   ├── admin.py
│   ├── apps.py
│   ├── __init__.py
│   ├── migrations
│   ├── models.py
│   ├── static
│   ├── templates
│   ├── tests.py
│   ├── urls.py
│   └── views.py
├── db.sqlite3
├── demo
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
└── manage.py
```

Để tắt chế độ debug trong Django, các bạn sẽ sửa biến DEBUG trong file settings.py như sau

```python
DEBUG = False if .getenv('DEBUG', '0') == 0 else True
```

OK, như vậy tưởng như xong =)). Nhưng không, khi mở trình duyệt và vào trang web của mình, các bạn sẽ thấy html vẫn được render trong khi url của các static file lại báo lỗi 404???

Mặc định, Django trong chế độ non debug sẽ không chịu trách nhiệm việc serve các static file nên khi tắt chế độ debug, trình duyệt sẽ không tải được các file ảnh, css, js, …

Để khắc phục vấn đề này, mình sẽ để thằng Django render template trong khi đó, Nginx sẽ đóng vai trò là reversed proxy và serve static file

Đầu tiên, mình sẽ quy định url của static file khi Django render template và đường dẫn static file trên host machine. Các config này nên quy định trong demo/settings.py

```python
STATIC_URL = '/static/'
STATIC_ROOT = '/var/demo/static'
```

Tiếp theo, mình sẽ config urlpatterns để mỗi khi template engine của Django render html sẽ render đúng url của static file mà mình quy định. Trong demo/urls.py

```python
from django.contrib.staticfiles.urls import static
from django.conf import settings

urlpatterns += static(
    prefix=getattr(settings, 'STATIC_URL'),
    document_root=getattr(settings, 'STATIC_ROOT')
)
```

OK, vậy là mình đã config xong đối với Django, giờ sẽ config Nginx để serve đúng chỗ của static file, ở đây là /var/demo/static . Mình tạo file /etc/nginx/conf.d/demo.conf, với nội dung như sau:

```
server {
    listen 80;
    server_name demo;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }

    location /static {
        alias /var/demo/static;
    }
}
```

Sau khi config xong, mình chạy lệnh sau trong thư mục project của Django:

```sh
$ ./manage.py collectstatic
```

Các static file ở các app mà project inject vào sẽ được gom vào STATIC_ROOT. Bây giờ, Nginx chỉ việc serve các file đó thôi ✌️

Các bạn có thể lấy repo này về test thử, https://github.com/magiskboy/django-app-deployment.

Ngoài các static file, các bạn cũng có thể áp dụng cách này đối với các file được người dùng từ client upload lên server.


Web development

Tại sao FastAPI lại nhanh?

Optimize web performance

Tree Shaking cho ứng dụng web

Tree Shaking

Sử dụng Lighthouse và React Developer Tools để đánh giá hiệu năng web

Flask Context và những điều cần biết

Flask có gì hay!

Serve static file in Django