Ngược dòng thời gian

Client-side Rendering (CSR)

• Time to Content lâu: Người dùng phải chờ tải và thực thi JavaScript mới thấy nội dung.

• SEO kém: HTML ban đầu không chứa dữ liệu thực, gây khó khăn cho các bot tìm kiếm khi lập chỉ mục.

• Hiệu năng thấp trên thiết bị yếu: Toàn bộ quá trình render được đẩy sang phía client.

Server-side Rendering (SSR)

• Hiển thị sớm hơn: Cải thiện các chỉ số Web Vitals quan trọng như Largest Contentful Paint (LCP).

• SEO tốt: Nội dung đã có sẵn trong HTML ngay từ đầu, dễ dàng cho bot tìm kiếm.

• Hỗ trợ thiết bị yếu: Vì việc render đã được xử lý phía server.

• Tăng tải server: Mỗi yêu cầu cần dựng HTML động, tiêu tốn tài nguyên.

• Hydration vẫn là nút thắt: Sau khi HTML hiển thị, trình duyệt vẫn phải tải và chạy JavaScript để "kích hoạt" ứng dụng, khiến Time to Interactive (TTI) bị kéo dài.

Static Site Generation (SSG) – "Pre-render everything"

• Khó khăn khi nội dung thay đổi thường xuyên: Việc cập nhật nội dung cần build lại, không phù hợp với dữ liệu động.

• Dữ liệu quá lớn: Thời gian build có thể kéo dài, thậm chí không khả thi với hàng ngàn trang động.

Island Architecture: "Chỉ Hydrate Phần Cần Thiết”

• Giảm JS tải về: Giúp trang web nhanh hơn đáng kể, đặc biệt trên các thiết bị yếu.

• Vẫn giữ được tương tác: Nhờ khả năng hydrate từng component riêng lẻ.

Qwik: "Resumability" Thay Thế Hoàn Toàn "Hydration”

• Không cần chạy JS ban đầu: Thời gian tương tác (TTI) gần như tức thì.

• JS được tải dần theo hành vi: Tải cực kỳ nhẹ, mang lại cảm giác mượt mà như ứng dụng native.

Những gì chúng tôi đã làm – và vì sao vẫn chưa đủ?

Tối ưu response time

• Full Page Cache: Tỷ lệ hit cache của các yêu cầu trên hệ thống của chúng tôi khá lớn. Do đó, việc triển khai full page cache đã giúp giảm đáng kể thời gian phản hồi, đồng thời giảm tải tài nguyên cho server vì không phải render lại nhiều.

• Monitor: Chúng tôi theo dõi response time của các yêu cầu trên các công cụ như New Relic. Mục đích của việc này là để nhanh chóng phát hiện ra các yêu cầu có vấn đề, hoặc những bất thường xảy ra mỗi khi chúng tôi phát hành một phiên bản mới.

• Improve API: Từ các chỉ số thu được trên các công cụ giám sát, các API có response time lớn đều được xử lý tối ưu để giảm thời gian phản hồi chung cho toàn bộ yêu cầu.

Preload priority resource

<!-- Preload critical images -->
<link rel="preload" as="image" href="/hero-image.webp">
<link rel="preload" as="font" href="/font.woff2" crossorigin>

<!-- Preload critical CSS -->
<link rel="preload" as="style" href="/critical.css">

• Xác định Component đầu tiên: Dựa trên dữ liệu, chúng tôi xác định rõ component nào sẽ nằm ở vị trí đầu tiên trong nội dung của trang.

• Xác định tài nguyên cần Preload: Sau đó, chúng tôi xác định những component nào có tài nguyên cần preload (ví dụ: hình ảnh chính, video thumbnail...). Các tài nguyên này được đưa vào props của component, và khi component đó được render, quá trình preload sẽ được kích hoạt.

Inline critical CSS

<style>
  /* Critical CSS được inline trực tiếp vào HTML */
  .hero { background: url('/hero.webp'); }
  .nav { position: fixed; top: 0; }
</style>

• Build-time: Chúng tôi đã phát triển một plugin cho Vite để tự động xác định mỗi component cần sử dụng CSS nào. Từ đó, chúng tôi có thể xây dựng một bản đồ (map) chi tiết giữa component và CSS tương ứng mà nó cần. Đồng thời, các CSS dùng chung cho layout tổng thể cũng được đóng gói riêng.

• Run-time: Dựa vào dữ liệu và trạng thái của trang, hệ thống sẽ xác định được layout và các components đang được sử dụng. Từ thông tin này, chúng tôi có thể tự động xây dựng critical CSS (CSS tối thiểu cần thiết để hiển thị phần quan trọng nhất của trang) cho từng trang cụ thể ngay tại thời điểm chạy.

Code Splitting

// Route-based splitting
const ProductPage = lazy(() => import('./ProductPage.vue'));

// Condition-based splitting  
const PaymentModal = lazy(() => 
  import('./PaymentModal.vue').then(module => ({
    default: module.PaymentModal
  }))
);

• Route-based splitting (Chia theo Route/Trang): Kỹ thuật này chia nhỏ mã nguồn theo từng trang hoặc route riêng biệt. Khi người dùng truy cập một trang cụ thể, chỉ mã nguồn cần thiết cho trang đó mới được tải về, giúp giảm đáng kể lượng JavaScript ban đầu.

• Condition-based splitting (Chia theo Điều kiện): Sử dụng dynamic import (import()) để chỉ tải các module hoặc component khi một điều kiện nhất định xảy ra (ví dụ: khi người dùng nhấp vào nút mở modal, chuyển tab, hoặc cuộn đến một phần tử cụ thể). Điều này đảm bảo rằng các đoạn mã không cần thiết cho tương tác ban đầu sẽ không làm chậm quá trình tải trang.

Rewrite library

Island Component

// Island component
// ~/components/islands/ProductReviews.vue
<template>
  <div>
    <div v-for="review in reviews" :key="review.id">
      {{ review.content }}
    </div>
  </div>
</template>

<script setup>
// Component sẽ được render như island
const reviews = ref([]);

onMounted(async () => {
  reviews.value = await $fetch('/api/reviews');
});
</script>

• Giảm đáng kể response time: Server không mất thời gian render runtime cho từng yêu cầu.

• Tiết kiệm chi phí server: Chuyển hầu hết công việc tính toán sang giai đoạn build time.

• Giảm thiểu độ trễ hydrate: HTML tĩnh đã có sẵn, client chỉ cần gắn logic tương tác.

Vượt Qua Giới Hạn Của Hydration: Khám Phá Sức Mạnh Thay Đổi Cuộc Chơi Của Qwik

Sự khác biệt cốt lõi

Serialization: Bí Mật Đằng Sau Resumability

• Không cần tải lại toàn bộ logic: Chỉ tải JavaScript khi người dùng tương tác với một phần cụ thể của trang.

• Tối thiểu hóa JavaScript ban đầu: Ứng dụng trở nên tương tác gần như ngay lập tức.

• Hiệu suất vượt trội: Giảm thời gian chờ đợi so với quá trình hydration thông thường.

<!-- HTML được render từ server với serialized state -->
<div q:id="0" q:host>
  <button 
    q:id="1" 
    onClick$="./chunk-abc123.js#handler_0"
    q:state='{"count": 0}'
  >
    Count: 0
  </button>
</div>

<!-- Qwik loader (~1KB) -->
<script>
  // Đọc serialized state và setup event listeners
  window.qwikLoader = {
    async handleClick(event) {
      const handler = await import('./chunk-abc123.js');
      return handler.default(event);
    }
  }
</script>

So sánh thực tế: React vs Qwik

// pages/counter.tsx
import { useState } from 'react';

export default function Counter() {
  const [count, setCount] = useState(0);
  
  return (
    <div>
      <h1>Count: {count}</h1>
      <button onClick={() => setCount(c => c + 1)}>
        Increment
      </button>
    </div>
  );
}

// Toàn bộ React runtime (~42KB) + component code phải load trước khi trang interactive

import { component$, useSignal } from '@builder.io/qwik';

export default component$(() => {
  const count = useSignal(0);
  
  return (
    <div>
      <h1>Count: {count.value}</h1>
      <button onClick$={() => count.value++}>
        Increment  
      </button>
    </div>
  );
});

Demo Thực Tế: Trang Checkout eCommerce với Qwik

• Nó có rất nhiều các payment methods khác nhau. Ở đó tha hồ SDK để chúng ta “thách thức” Qwik xem điểm nó có cao như lời đồn không. Từ Stripe, Paypal, Google Pay

• Nó cũng rất nhiều các tracking sdk từ Facebook, Tiktok, Pinterest… Mà nói về thế giới SDK của analytics thì có quá nhiều luôn. Xem Qwik nó giải quyết ra sao luôn.

Hạn chế và Trade-offs của Qwik

• Yêu cầu làm quen với cú pháp và triết lý mới: Qwik đòi hỏi người dùng làm quen với khái niệm resumability, một mô hình hoàn toàn khác so với hydration truyền thống. Việc viết code theo cách "hoãn thực thi" (ví dụ: onClick$(), useStore(), useSignal()) có thể gây bỡ ngỡ, đặc biệt với những nhà phát triển đến từ các framework quen thuộc như React hoặc Vue.

• Debug phức tạp hơn: Do logic được phân mảnh và trì hoãn đến runtime, việc debug trong môi trường phát triển hoặc kiểm tra hành vi khi lỗi xảy ra trên client có thể phức tạp hơn. Trong các framework truyền thống, toàn bộ logic đã được tải sẵn, giúp quá trình này dễ dàng hơn.

• Hệ sinh thái tích hợp còn hạn chế: Qwik chưa có hệ sinh thái plugin và component phong phú như React hay Vue. Các công cụ bên ngoài như thư viện form, i18n, hoặc headless UI đôi khi phải được viết lại, hoặc tích hợp thủ công, đòi hỏi nhiều công sức hơn.

• Tối ưu cho Edge/Serverless, nhưng không phù hợp mọi nơi: Qwik phát huy tối đa sức mạnh khi chạy trong môi trường Edge (như Vercel, Cloudflare Workers...). Trong môi trường server truyền thống hoặc các ứng dụng SPA không cần SEO, lợi thế của Qwik có thể giảm đi đáng kể.

• Tuổi đời còn trẻ: Qwik mới được công bố chính thức từ năm 2022 và bản 1.0 chỉ vừa ổn định trong năm 2023. Điều này đồng nghĩa với việc:
• Một số tính năng vẫn đang trong quá trình hoàn thiện.
• Cộng đồng và tài nguyên học tập còn hạn chế.
• Có ít case study sản phẩm lớn được triển khai thực tế, khiến việc dự đoán các vấn đề phát sinh ở quy mô lớn trở nên khó khăn hơn.

Khi Nào Nên Chọn Qwik?

✅ Phù hợp khi:

• Website cần SEO tốt và tốc độ tải nhanh

• Ứng dụng eCommerce, landing page, blog

• Team sẵn sàng học công nghệ mới

• Dự án mới hoặc có thể refactor

❌ Chưa phù hợp khi:

• Cần tích hợp nhiều thư viện React/Vue có sẵn

• Team thiếu thời gian training

• Ứng dụng internal không cần tối ưu quá mức

• Dự án đã stable với framework hiện tại

Kết luận