Gần đây, trong cộng đồng front end, kết xuất phía máy chủ (Server-side Rendering) ngày càng trở nên thu hút hơn nhờ React.
Nhưng đó không phải là giải pháp duy nhất để mang lại trải nghiệm tốc độ siêu nhanh cho người dùng.
Nếu nói đến chỉ số thời gian tính đến byte đầu tiên TTFB (Time-to-first-byte): Pre-rendering cũng là một chiến lược khá tốt.
Vậy sự khác biệt giữa Client-side vs Server-side vs Pre-rendering là gì?
Client-side rendering là gì?
Kể từ khi các framework như Angular, Ember.js và Backbone tồn tại, các lập trình viên front end có xu hướng hiển thị mọi thứ ở phía máy khách. Nhờ có Google và khả năng "đọc" JavaScript, nó hoạt động khá tốt và thậm chí còn thân thiện với SEO.
Với giải pháp Client-side rendering, bạn chuyển hướng yêu cầu đến một tệp HTML duy nhất và máy chủ sẽ phân phối nó mà không có bất kỳ nội dung nào (hoặc với màn hình tải) cho đến khi bạn tìm nạp tất cả JavaScript và để trình duyệt biên dịch mọi thứ trước khi hiển thị nội dung.
Nếu có kết nối internet tốt và đáng tin cậy, nó chạy khá nhanh và hoạt động tốt. Nhưng nó có thể tốt hơn rất nhiều và không khó để làm theo cách đó. Đó là những gì chúng ta sẽ thấy trong các phần sau.
Server-side rendering (SSR) là gì?
Giải pháp Sever-side Rendering (SSR) là điều mà chúng tôi đã từng làm rất nhiều, nhiều năm trước đây, nhưng có xu hướng bỏ quên giải pháp Client-side Rendering.
Với các giải pháp Server-side Rendering, bạn đã xây dựng một trang web — với ngôn ngữ PHP chẳng hạn — máy chủ đã biên dịch mọi thứ, bao gồm dữ liệu và gửi một trang HTML được điền đầy đủ cho máy khách.
Nó nhanh chóng và hiệu quả.
Nhưng… mỗi khi bạn điều hướng đến một route khác, máy chủ phải thực hiện lại công việc: Lấy tệp PHP, biên dịch nó và phân phối HTML, với tất cả CSS và JS trì hoãn tải trang đến vài trăm mili giây hoặc thậm chí cả giây.
Điều gì sẽ xảy ra nếu bạn có thể thực hiện tải trang đầu tiên với giải pháp SSR và sau đó sử dụng một framework để thực hiện định tuyến động với AJAX, chỉ tìm nạp dữ liệu cần thiết?
Đây là lý do tại sao SSR ngày càng nhận được nhiều sự quan tâm trong cộng đồng vì React đã phổ biến vấn đề này bằng một giải pháp dễ sử dụng: Phương thức RenderToString.
Loại ứng dụng web mới này được gọi là universal app hoặc isomorphic app.
Vẫn còn một số tranh cãi về ý nghĩa chính xác của những thuật ngữ này và mối quan hệ giữa chúng, nhưng nhiều người sử dụng chúng thay thế cho nhau.
Dù sao, ưu điểm của giải pháp này là có thể phát triển phía app server-side và client-side với cùng bộ code và mang lại trải nghiệm thực sự nhanh chóng cho người dùng với dữ liệu tùy chỉnh.
Điểm bất lợi là bạn cần phải chạy một máy chủ.
SSR được sử dụng để tìm nạp dữ liệu và điền trước một trang có nội dung tùy chỉnh, tận dụng kết nối internet đáng tin cậy của máy chủ.
Nghĩa là, kết nối internet của chính máy chủ tốt hơn kết nối của người dùng, vì vậy nó có thể tìm nạp trước và tổng hợp dữ liệu trước khi phân phối cho người dùng.
Với dữ liệu được điền sẵn, sử dụng ứng dụng SSR cũng có thể khắc phục sự cố mà ứng dụng do khách hàng kết xuất gặp phải với tính năng chia sẻ mạng xã hội và hệ thống OpenGraph.
Ví dụ: Nếu bạn chỉ có một tệp index.html để phân phối cho khách hàng, họ sẽ chỉ có một loại siêu dữ liệu — rất có thể là siêu dữ liệu trang chủ của bạn. Điều này sẽ không được ngữ cảnh hóa khi bạn muốn chia sẻ một route khác, vì vậy sẽ không có route nào của bạn được hiển thị trên các trang web khác với nội dung người dùng phù hợp của họ (mô tả và hình ảnh xem trước) mà người dùng muốn chia sẻ với mọi người.
Pre-rendering là gì?
Việc bắt buộc phải chạy một máy chủ cho một universal app có thể một trở ngại và có thể quá mức cần thiết đối với một ứng dụng nhỏ. Đây là lý do tại sao Pre-rendering có thể là một sự thay thế thực sự tốt.
Tôi đã phát hiện ra giải pháp này với Preact và CLI của riêng nó cho phép bạn biên dịch tất cả các route được chọn trước để bạn có thể lưu trữ tệp HTML đã được điền đầy đủ vào một máy chủ tĩnh.
Điều này cho phép bạn mang đến trải nghiệm siêu nhanh cho người dùng, nhờ chức năng hydrat hóa Preact / React mà không cần Node.js.
Vấn đề là vì đây không phải là SSR nên bạn không có dữ liệu dành riêng cho người dùng để hiển thị vào thời điểm này — nó chỉ là một tệp tĩnh (và hơi chung chung) được gửi trực tiếp theo yêu cầu đầu tiên.
Vì vậy, nếu bạn có dữ liệu người dùng cụ thể, đây là nơi bạn có thể tích hợp một khung được thiết kế đẹp mắt để cho người dùng thấy dữ liệu của họ đang được gửi đến, để tránh họ chờ đợi thất vọng:
Vẫn có một cách khác: Nhưng để kỹ thuật đó hoạt động, bạn vẫn cần có proxy hoặc thứ gì đó để chuyển hướng người dùng đến đúng tệp.
Tại sao nên sử dụng Pre-rendering?
Với ứng dụng single-page, bạn cần chuyển hướng tất cả các request đến tệp gốc, sau đó khung chuyển hướng người dùng bằng hệ thống định tuyến tích hợp của nó. Vì thế, tải trang đầu tiên luôn là cùng một tệp gốc.
Để giải pháp Pre-rendering hoạt động, bạn cần nói với proxy của mình rằng một số route cần tệp cụ thể và không phải lúc nào cũng là tệp gốc index.html.
Ví dụ: Giả sử bạn có bốn route (/, /about, /jobs và blog) và tất cả chúng đều có bố cục khác nhau. Bạn cần 4 tệp HTML khác nhau để cung cấp khung cho người dùng, sau đó sẽ cho phép React/Preact/ .... thay thế dần nó bằng dữ liệu thực.
Vì vậy, nếu bạn chuyển hướng tất cả các route đó đến tệp root index.html, trang sẽ có cảm giác khó chịu, trục trặc trong quá trình tải, theo đó người dùng sẽ thấy khung của trang sai sai cho đến khi tải xong và thay thế bố cục.
Ví dụ: Người dùng có thể thấy khung trang chủ (đang chờ tải) chỉ có một cột, trong khi họ chờ đợi một trang có cấu trúc như kiểu Pinterest. Điều này sẽ làm mất đi tính nhất quán trong tâm trí người dùng.
Giải pháp là cho proxy của bạn biết rằng mỗi trong 4 route đó cần một tệp cụ thể:
-
https://my-website.com → Redirect đến root index.html file
-
https://my-website.com/about → Redirect đến /about/index.html file
-
https://my-website.com/jobs → Redirect đến /jobs/index.html file
-
https://my-website.com/blog → Redirect đến /blog/index.html file
Đây là lý do tại sao giải pháp này có thể hữu ích cho các ứng dụng nhỏ — Nhưng sẽ đau khổ nếu bạn có vài trăm trang.
Nói một cách chính xác, không bắt buộc phải làm theo cách này — bạn chỉ có thể sử dụng trực tiếp tệp tĩnh.
Ví dụ: https://my-website.com/about/ sẽ hoạt động mà không cần chuyển hướng vì nó sẽ tự động tìm kiếm index.html bên trong thư mục của nó.
Nhưng bạn cần proxy này nếu bạn có url tham số — https: //my-website.com/profile/guillaume sẽ cần chuyển hướng yêu cầu đến /profile/index.html với bố cục riêng của nó, vì profile/guillaume/index.html không tồn tại và sẽ gây ra lỗi 404.
Tóm lại, có ba chế độ xem cơ bản phù hợp với các chiến lược hiển thị được mô tả ở trên: Màn hình tải, khung chờ tải và toàn bộ trang sau khi được hiển thị cuối cùng.
Tùy thuộc vào chiến lược, đôi khi chúng tôi sử dụng cả ba chế độ xem này và đôi khi chúng tôi chuyển thẳng đến một trang được hiển thị đầy đủ.
Chỉ trong một trường hợp sử dụng, chúng tôi buộc phải sử dụng một cách tiếp cận khác:
Chỉ Client-rendering thường là không đủ
Ứng dụng Client-rendering là điều chúng ta nên tránh ngay bây giờ vì chúng ta có thể làm tốt hơn cho người dùng.
Và làm tốt hơn, trong trường hợp này, cũng dễ dàng như giải pháp kết xuất trước. Nó chắc chắn là một cải tiến so với chỉ client-redering và dễ triển khai hơn một ứng dụng hoàn toàn được Server-side rendering.
Một ứng dụng SSR / universal app có thể thực sự mạnh mẽ nếu đó là một ứng dụng lớn với nhiều trang khác nhau. Nó cho phép nội dung của bạn tập trung và có liên quan khi nói chuyện với trình thu thập thông tin xã hội. Điều này có ích cho SEO, bởi hiện tại hiệu suất trang web có ảnh hưởng lớn đến thứ hạng tìm kiếm.
Hãy theo dõi hướng dẫn tiếp theo, nơi tôi sẽ hướng dẫn cách chuyển đổi một SPA thành các phiên bản SSR và SSR được kết xuất trước, đồng thời so sánh hiệu suất của chúng.
Tổng kết
Qua bài viết này hi vọng bạn có thể hiểu được:
Client-side rendering là gì?
Client-side rendering (Kết xuất phía máy khách) cho phép các lập trình viên làm cho trang web của họ được hiển thị hoàn toàn trong trình duyệt bằng JavaScript. Thay vì có một trang HTML khác nhau cho từng route, một trang web được hiển thị phía máy khách sẽ tạo từng route một cách trực tiếp, động ngay trong trình duyệt. Cách tiếp cận này đã phổ biến khi các JS framework giúp bạn dễ dàng thực hiện.
Server-side rendering là gì?
Server-side rendering (Kết xuất phía máy chủ) cho phép các lập trình viên điền trước một trang web với dữ liệu người dùng tùy chỉnh trực tiếp trên máy chủ. Nói chung, thực hiện tất cả các request trong một máy chủ sẽ nhanh hơn so với việc thực hiện thêm các chuyến đi vòng từ trình duyệt đến máy chủ cho chúng. Đây là điều mà các lập trình viên thường làm trước khi kết xuất phía máy khách.
Sự khác biệt giữa Client-side rendering và Server-side rendering?
Kết xuất phía máy khách quản lý định tuyến động mà không cần làm mới trang mỗi khi người dùng yêu cầu một route khác. Nhưng kết xuất phía máy chủ có thể hiển thị một trang được điền đầy đủ trong lần tải đầu tiên cho bất kỳ route nào của trang web, trong khi kết xuất phía máy khách hiển thị một trang trống trước tiên.
Pre-rendering là gì?
Pre-rendering là sự cân bằng giữa Client-side và Server-side rendering. Mỗi trang được kết xuất trước hiển thị một khung mẫu trong khi dữ liệu chờ được load dần bằng các AJAX / XHR request. Khi trang được tìm nạp, định tuyến nội bộ được thực hiện động để tận dụng lợi thế của trang web được hiển thị phía máy khách.
Universal app là gì?
Một Universal app sẽ gửi đến trình duyệt một trang chứa dữ liệu. Sau đó, ứng dụng tải JavaScript của nó và thay thế dần dữ liệu vào trang để có được một ứng dụng được hiển thị hoàn toàn từ phía máy khách. Cách tiếp cận này kết hợp những ưu điểm của các kỹ thuật mới nhất hiện nay.
Toptal
---
HỌC VIỆN ĐÀO TẠO CNTT NIIT - ICT HÀ NỘI
Học Lập trình chất lượng cao (Since 2002). Học thực tế + Tuyển dụng ngay!
Đc: Tầng 3, 25T2, N05, Nguyễn Thị Thập, Cầu Giấy, Hà Nội
SĐT: 02435574074 - 0914939543
Email: hello@niithanoi.edu.vn
Fanpage: https://facebook.com/NIIT.ICT/
#niit #niithanoi #niiticthanoi #hoclaptrinh #khoahoclaptrinh #hoclaptrinhjava #hoclaptrinhphp #java #php #python