Vì sao không phải dự án nào dùng Single Page Application cũng tốt?
Back To BlogsTrong một thời gian dài, Single Page Application (SPA) được xem như một bước tiến lớn của frontend. Các thư viện như ReactJS hay Vue.js giúp việc xây dựng giao diện nhanh hơn và mang lại trải nghiệm mượt mà.
Tuy nhiên, khi đặt SPA vào bối cảnh các website cần SEO, marketing và phân phối nội dung, nhiều vấn đề bắt đầu xuất hiện. Không phải dự án nào cũng phù hợp với cách tiếp cận này.
Khi nội dung không còn hiển thị ngay từ đầu
sequenceDiagram
participant U as User
participant B as Browser
participant S as Server
participant J as JavaScript
rect rgb(230, 245, 255)
U->>B: Truy cập website
B->>S: Request HTML
S-->>B: HTML rỗng
end
rect rgb(255, 235, 235)
B->>J: Load JS bundle
J->>B: Render nội dung
end
Cách SPA hoạt động khiến nội dung không xuất hiện ngay trong HTML ban đầu. Điều này tạo ra một khoảng trống giữa lúc tải trang và lúc nội dung thực sự hiển thị.
Với công cụ tìm kiếm, đây là một rào cản. Bot thường đọc HTML trước, nếu không thấy nội dung, chúng phải chờ JavaScript. Không phải lúc nào quá trình này cũng diễn ra đầy đủ.
Các hệ thống AI hiện nay cũng gặp vấn đề tương tự. Chúng ưu tiên dữ liệu có sẵn, dễ đọc. Nội dung phụ thuộc vào JavaScript thường bị bỏ qua hoặc không được hiểu đúng.
Những giới hạn của ReactJS và Vue.js trong bài toán SEO
flowchart LR
A[User truy cập]:::a --> B[Tải HTML]:::b
B --> C[Tải JS bundle]:::c
C --> D[Execute JS]:::c
D --> E[Render nội dung]:::d
classDef a fill:#d0ebff,stroke:#339af0,color:#000
classDef b fill:#d3f9d8,stroke:#51cf66,color:#000
classDef c fill:#ffe3e3,stroke:#ff6b6b,color:#000
classDef d fill:#fff3bf,stroke:#fcc419,color:#000
Các framework như ReactJS và Vue.js mặc định dựa vào client-side rendering.
Toàn bộ nội dung phụ thuộc vào JavaScript. Khi bundle lớn, thời gian tải tăng lên. Nếu script lỗi hoặc chậm, trải nghiệm bị ảnh hưởng ngay lập tức.
Khi nội dung không có sẵn, khả năng được index và được hiểu bởi công cụ tìm kiếm cũng giảm đi đáng kể.
Để khắc phục những hạn chế này, nhiều dự án phải bổ sung thêm các framework như Next.js hoặc Nuxt.js. Tuy nhiên, điều này cũng đồng nghĩa với việc hệ thống trở nên phức tạp hơn, kéo theo chi phí phát triển và vận hành tăng lên. Việc kết hợp thêm layer server, rendering và routing khiến quá trình bảo trì đòi hỏi nhiều kinh nghiệm hơn, đồng thời nếu không kiểm soát tốt cũng có thể phát sinh thêm các rủi ro về bảo mật.
Hướng đi thực tế hơn: kết hợp nhiều cách render
flowchart TD
A[Request]:::start --> B{Loại trang}:::decision
B -->|SEO / Nội dung| C[SSR / SSG]:::seo
B -->|Tương tác cao| D[CSR]:::csr
C --> E[HTML có sẵn]:::good
D --> F[Render bằng JS]:::normal
classDef start fill:#e7f5ff,stroke:#1c7ed6,color:#000
classDef decision fill:#fff0f6,stroke:#d6336c,color:#000
classDef seo fill:#d3f9d8,stroke:#2f9e44,color:#000
classDef csr fill:#e3fafc,stroke:#1098ad,color:#000
classDef good fill:#fff9db,stroke:#f59f00,color:#000
classDef normal fill:#f1f3f5,stroke:#868e96,color:#000
Thay vì chọn một hướng duy nhất, nhiều hệ thống hiện nay kết hợp nhiều phương pháp. Những trang cần nội dung rõ ràng cho SEO sẽ được render sẵn. Những phần cần tương tác cao sẽ dùng JavaScript.
Cách này giúp cân bằng giữa khả năng hiển thị nội dung và trải nghiệm người dùng.
Cách EzyPlatform tiếp cận
sequenceDiagram
participant U as User
participant S as Server
participant B as Browser
rect rgb(220, 255, 220)
U->>S: Request trang
S-->>U: HTML đầy đủ nội dung
end
rect rgb(235, 235, 255)
B->>B: Hiển thị ngay
B->>B: Tăng cường JS khi cần
end
EzyPlatform không đi theo hướng SPA thuần. Nội dung được render sẵn từ server, đảm bảo khi tải trang, thông tin đã có đầy đủ.
JavaScript chỉ đóng vai trò bổ trợ cho tương tác. Hệ thống không phụ thuộc hoàn toàn vào client-side rendering.
Kiến trúc được chia thành các module nhỏ thay vì một SPA lớn. Điều này giúp giảm độ phức tạp và giữ cho hệ thống dễ mở rộng.
Kết luận
SPA là một lựa chọn mạnh, nhưng không phải là mặc định cho mọi dự án. Khi mục tiêu liên quan đến SEO, marketing hoặc khả năng được các hệ thống AI hiểu và phân phối, việc phụ thuộc hoàn toàn vào JavaScript sẽ trở thành một hạn chế.
Một cách tiếp cận kết hợp, như cách EzyPlatform đang áp dụng, thường phù hợp hơn với các bài toán thực tế, nơi nội dung cần được nhìn thấy, được hiểu và được phân phối rộng rãi.
Young Monkeys - Founder