Skip to main content

Tối ưu đúng chỗ: partial reload, deferred & prefetch

Ba kỹ thuật này giải ba bài toán khác nhau:

Partial reload

Server nên lazy-evaluate prop:
Nếu roles là eager expression thay vì closure, DB query vẫn có thể chạy dù client chỉ yêu cầu users.

Deferred prop

analytics ra khỏi critical path của initial render. rescue: true hữu ích nếu panel phụ được phép fail mà không phá toàn page; đừng dùng nó để che lỗi của dữ liệu cốt lõi.

Prefetch

Prefetch phù hợp với destination có xác suất click cao và response không quá nhạy với freshness. Không nên prefetch hàng chục link có response tốn nhiều tài nguyên hoặc dữ liệu chỉ vì API cho phép.

Quy tắc chọn

Đo trước và sau

Theo dõi tối thiểu:
  • TTFB của Inertia request.
  • Query count và query time.
  • Payload JSON size.
  • Thời gian từ navigation đến content usable.
  • Số request do prefetch nhưng user không bao giờ dùng.
Tối ưu đúng nghĩa là giảm critical-path work, không phải bật mọi feature performance cùng lúc.

Đừng trộn ba capability thành một khái niệm “cache”

Ba thứ tối ưu ba điểm khác nhau.

Thiết kế prop boundary trước khi tối ưu

Khó tối ưu:
Dễ tối ưu hơn:
Prop boundary là performance architecture.

Measure query count và payload

Trước/sau optimization nên đo:
Nếu partial reload giảm payload 80% nhưng server vẫn chạy tất cả query tốn nhiều tài nguyên thì tối ưu vẫn chưa hoàn chỉnh.

Freshness budget cho prefetch

Ví dụ Edit Product:
20 giây có thể hợp admin CRUD; nhưng permission/inventory cực nhạy cần TTL khác hoặc không prefetch.

Deferred failure phải degrade gracefully

Primary list vẫn nên usable nếu analytics panel fail:
Đừng để secondary data biến thành single point of failure của page.

Tài liệu chính thức

Nội dung thực chiến trong bài được xây dựng dựa trên API và nguyên lý của Inertia.js v3 Documentation. Khi áp dụng vào dự án, hãy đối chiếu API cụ thể với tài liệu chính thức theo phiên bản bạn đang sử dụng.