Khách mở link tour từ quảng cáo trên điện thoại. Màn hình đen, vòng tròn quay. Năm giây, mười giây. Họ bấm quay lại trước khi kịp thấy căn hộ mẫu hay sảnh khách sạn mà doanh nghiệp đã đầu tư chụp kỹ lưỡng.
Đây là tình huống chúng tôi thường gặp khi được mời “xem giúp vì sao tour chậm”. Ảnh không có lỗi, thiết bị chụp không có lỗi. Vấn đề nằm ở hai khâu ít ai để ý: ảnh được xuất ra web theo cấu trúc nào, và các file đó được đặt ở đâu.
Muốn tối ưu tốc độ tải virtual tour, cần xử lý cả hai khâu đó. Bài này đi qua từng khâu theo đúng thứ tự một tour đến tay người xem: từ ảnh panorama gốc, qua cubemap, multiresolution, định dạng nén, đến hosting, CDN và cách kiểm thử. Mục tiêu là để chủ dự án hiểu đủ để đặt yêu cầu đúng, và đội kỹ thuật có checklist để làm.
Vì sao phải tối ưu tốc độ tải virtual tour
Một panorama 16K có kích thước 16.384 × 8.192 px, tức khoảng 134 megapixel. Ở dạng JPEG chất lượng cao, một file như vậy thường nặng hàng chục MB. Nếu trình xem tải nguyên file này cho mỗi cảnh, người xem trên mạng di động phải chờ toàn bộ file về máy rồi mới thấy hình.
Dung lượng tải về mới chỉ là một nửa vấn đề. Để hiển thị, trình duyệt phải giải nén ảnh vào bộ nhớ. Ảnh 134 megapixel ở dạng điểm ảnh chưa nén (4 byte mỗi điểm) chiếm khoảng 512 MB. Con số này vượt xa mức một tab trình duyệt trên nhiều điện thoại phổ thông được phép dùng, nên trang có thể bị tải lại hoặc đóng đột ngột.
Thêm một giới hạn phần cứng: WebGL, công nghệ mà trình xem 360 dùng để vẽ hình, chỉ nhận texture có cạnh tối đa theo khả năng của GPU. Trên nhiều thiết bị di động, nhất là máy đời cũ hoặc phổ thông, giới hạn đó thấp hơn cạnh 16.384 px của panorama 16K. Khi đó ảnh nguyên khối không thể đưa thẳng lên GPU mà phải bị thu nhỏ, nghĩa là người xem vừa chờ lâu vừa không được xem ở độ nét đã chụp.
Vì vậy, hạ độ phân giải không phải lời giải. Một panorama 8K hay 16K có lý do tồn tại: người xem cần zoom để đọc biển tên, nhìn vân gỗ, soi chi tiết hoa văn. Lời giải là để người xem chỉ tải phần họ đang nhìn, ở độ nét họ đang cần.
Cubemap: chiếu hình cầu lên 6 mặt lập phương
Ảnh 360 sau khi ghép thường ở dạng equirectangular: một hình chữ nhật tỷ lệ 2:1, giống tấm bản đồ thế giới trải phẳng. Định dạng này tiện để lưu và chỉnh sửa, nhưng có nhược điểm lớn khi đưa lên web: vùng trần và sàn (hai cực) bị kéo giãn rất mạnh. Hàng điểm ảnh trên cùng của file thực chất chỉ mô tả một điểm duy nhất trên đỉnh đầu.
Kết quả là một phần đáng kể dung lượng file bị dùng để mô tả những vùng ít thông tin, trong khi việc chia nhỏ ảnh theo vùng nhìn lại khó vì mỗi vùng méo một kiểu.
Cubemap giải quyết việc này bằng cách chiếu hình cầu lên 6 mặt của một khối lập phương bao quanh người xem: trước, sau, trái, phải, trên, dưới. Mỗi mặt là một ảnh vuông có góc nhìn 90 độ, độ méo đồng đều hơn nhiều so với equirectangular.
Mỗi mặt là một ảnh vuông bình thường
Các mặt cube giống ảnh chụp bằng ống kính góc rộng thông thường, nên dễ cắt thành ô vuông đều nhau và dễ nén.
Bớt lãng phí ở trần và sàn
Hai mặt trên và dưới có mật độ điểm ảnh tương đương bốn mặt bên, không còn dải kéo giãn ở hai cực như equirectangular.
Hợp với cách GPU vẽ hình
WebGL có sẵn kiểu texture dạng khối lập phương, và trình xem chỉ cần vẽ 6 mặt phẳng thay vì một mặt cầu nhiều đa giác.
Với panorama 16K, mỗi mặt cube có cạnh khoảng 5.200 px (lấy chiều rộng 16.384 chia cho π). Đây là con số cơ sở để tính số tile và số file ở phần sau.
Multiresolution hoạt động thế nào
Multiresolution (đa phân giải) là cách đóng gói một cảnh thành nhiều mức độ nét, mỗi mức lại chia thành nhiều ô nhỏ gọi là tile. Trình xem chỉ tải ô nào cần, ở mức nào cần, vào lúc cần. Quy trình diễn ra theo bốn bước.
Hiện ngay một ảnh preview rất nhẹ
Mỗi cảnh có một bản preview độ phân giải thấp, dung lượng nhỏ, tải gần như tức thì. Người xem thấy hình ngay khi mở tour thay vì màn hình đen, dù ảnh còn hơi mờ.
Dựng tháp nhiều mức phân giải
Mặt cube được thu nhỏ dần, mỗi mức bằng khoảng một nửa mức trên. Ví dụ với cảnh 16K: khoảng 5.200 px, rồi 2.600 px, 1.300 px, 650 px và nhỏ hơn. Mức thấp dùng khi nhìn toàn cảnh, mức cao chỉ dùng khi zoom sát.
Cắt mỗi mức thành tile khoảng 512 px
Ở mỗi mức, từng mặt cube được chia thành lưới ô vuông. Mức cao nhất của cảnh 16K có khoảng 11 × 11 ô mỗi mặt. Tuỳ phần mềm, mỗi ô có thể thêm vài pixel chồng mép để tránh lộ đường nối khi hiển thị.
Chỉ tải tile nằm trong khung nhìn
Trình xem tính xem người dùng đang nhìn hướng nào, zoom bao nhiêu, rồi chỉ tải các ô thuộc vùng đó ở mức phù hợp. Phía sau lưng hay trên trần mà người xem chưa quay tới thì chưa tải. Khi xoay hoặc zoom, các ô mới được tải bổ sung.
Nhờ cơ chế này, dữ liệu ban đầu của một cảnh chỉ còn là preview cộng vài chục ô ở mức thấp, thay vì toàn bộ ảnh gốc. Bộ nhớ trên máy cũng nhẹ hơn vì trình xem chỉ giữ những ô đang dùng và giải phóng ô đã khuất khi cần.
Lợi ích thứ hai ít được nhắc tới: zoom tốt hơn. Với ảnh nguyên khối đã bị thu nhỏ để vừa giới hạn GPU, zoom sát chỉ thấy hình vỡ. Với multiresolution, zoom sát kéo về ô ở mức cao nhất, đúng độ nét đã chụp.
| Tiêu chí | Tải ảnh nguyên khối | Multiresolution + tile |
|---|---|---|
| Dữ liệu trước khi thấy hình | Toàn bộ file của cảnh | Preview nhẹ và vài ô ở mức thấp |
| Cảm giác khi mở | Chờ màn hình tải | Thấy hình gần như ngay, nét dần lên |
| Zoom sát | Dễ vỡ hình nếu ảnh bị thu nhỏ cho vừa GPU | Tải ô mức cao, giữ đúng độ nét đã chụp |
| Bộ nhớ trên điện thoại | Phải giải nén cả ảnh | Chỉ giữ các ô đang hiển thị |
| Số file trên máy chủ | Ít file, mỗi file lớn | Rất nhiều file nhỏ |
Dòng cuối của bảng là cái giá phải trả. Multiresolution đổi một file lớn thành rất nhiều file nhỏ, và chính điều này quyết định bạn nên đặt tour ở đâu.
Vì sao lại là 512 px
Kích thước tile là bài toán cân bằng. Tile nhỏ (256 px) giúp tải đúng vùng nhìn hơn nhưng sinh ra gấp bốn lần số file và số request. Tile lớn (1.024 px) giảm số request nhưng mỗi ô nặng hơn, và một phần lớn ô bị tải về dù nằm ngoài khung nhìn.
512 px là mức mặc định phổ biến của các trình xem 360 thông dụng vì nó cân bằng tốt hai yếu tố này trên mạng di động hiện nay. Đó là một lựa chọn thực tế, không phải quy luật bất di bất dịch. Với dự án đặc thù, đội kỹ thuật có thể thử mức khác và đo lại.
WebP và JPEG dự phòng
Sau khi đã chia nhỏ ảnh, bước tiếp theo là làm từng ô nhẹ hơn. Theo nghiên cứu nén do Google công bố khi giới thiệu định dạng WebP, ảnh WebP có dung lượng nhỏ hơn JPEG khoảng 25–34% ở cùng mức chất lượng cảm nhận. Với một tour có hàng nghìn tile, mức giảm này cộng dồn thành chênh lệch rõ rệt về thời gian tải và băng thông.
Về tương thích, Chrome, Edge, Firefox đã hỗ trợ WebP từ lâu, còn Safari hỗ trợ từ phiên bản 14 (iOS 14 và macOS Big Sur, năm 2020). Thiết bị còn chạy iOS cũ hơn ngày càng ít, nhưng nếu tour phục vụ nhóm người xem đặc thù, chẳng hạn máy tính bảng cũ đặt ở quầy lễ tân, nên chuẩn bị bộ tile JPEG dự phòng.
Mức chất lượng nén nên chọn bằng mắt, không chọn theo con số chung. Cách làm thực tế: xuất thử một cảnh khó (nhiều chữ, vân gỗ, vùng trời chuyển màu) ở vài mức chất lượng, mở ở mức zoom cao nhất và so với ảnh gốc. Chọn mức thấp nhất mà chưa thấy vệt nén ở vùng trời, viền chữ hay mép kim loại.
Cấu hình xuất trong Pano2VR
Pano2VR là phần mềm 360VR dùng để dựng và xuất tour HTML5 (xem thêm bài Pano2VR là gì). Tên mục có thể khác nhau giữa các phiên bản, nhưng các thông số cần kiểm tra khi xuất cho web gồm:
Bật multiresolution
Chọn kiểu xuất multiresolution cho tất cả các cảnh, kể cả cảnh nhỏ. Một cảnh quên bật sẽ là điểm nghẽn của cả tour.
Tile size khoảng 512 px
Giữ mặc định quanh 512 px trừ khi có lý do đo được để đổi.
Số mức phân giải
Để phần mềm tự tính các mức giảm một nửa, đảm bảo mức cao nhất khớp với độ phân giải thật của ảnh gốc, không phóng to giả.
Định dạng WebP
Chọn WebP cho tile. Chỉ xuất thêm JPEG khi đối tượng xem có thiết bị cũ.
Chất lượng nén
Thử trên cảnh khó, chọn bằng mắt ở mức zoom cao nhất như phần trên.
Preview và ảnh đại diện cảnh
Kiểm tra mỗi cảnh có preview nhẹ để người xem thấy hình ngay khi chuyển cảnh.
Ngoài thông số ảnh, hãy để ý những thứ đi kèm. Video nền, âm thanh và ảnh trong popup hotspot thường nặng hơn tile rất nhiều. Một video giới thiệu tự tải ở cảnh đầu có thể làm mất toàn bộ lợi ích của multiresolution. Nguyên tắc là nội dung phụ chỉ tải khi người xem bấm mở. Cách tổ chức hotspot gọn nhẹ có trong bài hotspot trong virtual tour.
Một tour có bao nhiêu file?
Đây là câu hỏi quyết định chuyện hosting, và có thể ước tính bằng phép tính đơn giản. Lấy ví dụ một cảnh 16K, tile 512 px:
- Mức cao nhất: mặt cube khoảng 5.200 px, tức khoảng 11 × 11 = 121 ô mỗi mặt, nhân 6 mặt được khoảng 726 ô.
- Mức tiếp theo (khoảng 2.600 px): 6 × 6 = 36 ô mỗi mặt, tổng 216 ô.
- Mức khoảng 1.300 px: 3 × 3 = 9 ô mỗi mặt, tổng 54 ô.
- Các mức nhỏ hơn và preview: vài chục file.
Cộng lại, một cảnh 16K sinh ra khoảng một nghìn file. Cảnh 8K có cạnh mặt cube bằng một nửa, nên số ô ở mức cao nhất chỉ còn khoảng một phần tư, tổng cộng cỡ vài trăm file mỗi cảnh.
Nhân với số cảnh, một tour vài chục điểm chụp dễ dàng có hàng chục nghìn file. Nếu có bộ JPEG dự phòng, con số nhân đôi. Mỗi lần người xem xoay góc nhìn, trình duyệt có thể gửi hàng chục request tới máy chủ trong vài giây.
Đặc thù “rất nhiều file nhỏ, rất nhiều request đồng thời” này khác hẳn một website thông thường, và là lý do hosting cho tour cần được chọn riêng.
Lưu trữ ở đâu: shared hosting, S3 + CloudFront hay Cloudflare R2 + CDN
Cách nhiều doanh nghiệp làm theo thói quen là tải cả thư mục tour lên cùng hosting với website WordPress. Cách này chạy được khi ít người xem, nhưng bộc lộ ba rủi ro khi tour bắt đầu được dùng thật.
Cạn tài nguyên máy chủ
Shared hosting giới hạn CPU, RAM và số tiến trình đồng thời. Khi nhiều người cùng xoay tour trong một đợt quảng cáo hay mở bán, request tile chiếm hết tài nguyên và kéo chậm cả website chính.
Chạm giới hạn số file (inode)
Nhiều gói hosting giới hạn tổng số file trong tài khoản. Một tour hàng chục nghìn file có thể ăn gần hết hạn mức đó, khiến việc sao lưu, cập nhật plugin hay tải ảnh mới cho website gặp lỗi.
Xa người xem
Một máy chủ đặt ở một nơi phải phục vụ người xem ở mọi nơi. Mỗi tile phải đi hết quãng đường đó, và độ trễ cộng dồn qua hàng chục request.
Giải pháp chung là tách tour ra object storage (kho lưu trữ file dạng đối tượng, không giới hạn số file theo kiểu inode) và đặt CDN phía trước. CDN giữ bản sao tile tại các máy chủ biên gần người xem, nên lần xem thứ hai trở đi trong cùng khu vực không còn phải về tận máy chủ gốc.
Hai lựa chọn phổ biến là Amazon S3 kết hợp CloudFront, và Cloudflare R2 kết hợp CDN của Cloudflare. Bảng dưới so sánh ở mức nguyên tắc; giá và điều khoản thay đổi theo thời gian, cần kiểm tra trên trang chính thức của nhà cung cấp tại thời điểm triển khai.
| Tiêu chí | Shared hosting | Amazon S3 + CloudFront | Cloudflare R2 + CDN |
|---|---|---|---|
| Phù hợp với hàng chục nghìn file nhỏ | Kém, vướng giới hạn inode | Tốt | Tốt |
| Chịu nhiều người xem cùng lúc | Kém, dùng chung tài nguyên với website | Tốt nhờ CDN | Tốt nhờ CDN |
| Phí băng thông tải ra (egress) | Thường gộp trong gói, có thể bị giới hạn | Có tính phí theo lượng dữ liệu | Không tính phí egress |
| Phí thao tác (request) | Không tách riêng | Có, theo số request | Có, chia nhóm thao tác ghi (Class A) và đọc (Class B) |
| Ảnh hưởng tới website chính | Trực tiếp | Không | Không |
| Độ phức tạp thiết lập | Thấp | Trung bình đến cao | Trung bình |
Với tour 360, nơi dữ liệu tải ra lớn hơn nhiều so với dữ liệu lưu trữ, việc R2 không tính phí egress là lợi thế đáng kể. Nhưng không nên hiểu thành “chi phí bằng 0”: R2 vẫn tính phí lưu trữ và phí thao tác (Class A cho ghi, Class B cho đọc, mỗi nhóm có hạn mức miễn phí hằng tháng), và một tour nhiều tile tạo ra rất nhiều thao tác đọc. Cấu hình cache tốt ở CDN giúp giảm số lần request phải về tận kho gốc.
Một lưu ý về tốc độ: CDN có máy chủ biên ở nhiều nơi, nhưng request của người xem tại Việt Nam được phục vụ từ máy chủ nào còn phụ thuộc định tuyến của nhà mạng và gói dịch vụ. Đừng mặc định “có CDN là nhanh”; hãy đo thực tế từ vài nhà mạng trong nước.
Tính chi phí băng thông đúng cách
Nhiều tài liệu đưa ra con số chi phí rất lớn hoặc rất nhỏ mà không kèm cách tính. Cách đánh giá đúng là tự tính theo dự án của mình bằng một công thức đơn giản:
Dữ liệu tải ra mỗi tháng = số lượt xem × dung lượng trung bình mỗi lượt xem
Rồi nhân dữ liệu tải ra với đơn giá egress của nhà cung cấp (nếu có), cộng phí thao tác và phí lưu trữ. Đừng quên trừ hạn mức miễn phí: AWS có hạn mức egress miễn phí hằng tháng, còn R2 có hạn mức thao tác miễn phí. Với lưu lượng nhỏ, hai phần này có thể làm thay đổi kết quả so sánh.
Ví dụ minh hoạ, với giả định dễ tính: 50.000 lượt xem mỗi tháng, mỗi lượt trung bình tải khoảng 20 MB tile. Dữ liệu tải ra là 50.000 × 20 MB, tức khoảng 1 TB mỗi tháng. Từ con số 1 TB này, bạn tra bảng giá hiện hành của từng nhà cung cấp để so sánh, thay vì tin vào một con số chung chung.
Để có “dung lượng trung bình mỗi lượt xem” sát thực tế, hãy mở tour bằng Chrome DevTools, tab Network, rồi xem như một khách bình thường: vào 4–5 cảnh, xoay vài vòng, zoom vài chỗ. Tổng dữ liệu ghi nhận được là cơ sở tốt hơn mọi ước đoán. Nếu đã có công cụ đo lượt xem, kết hợp thêm số cảnh trung bình mỗi phiên để hiệu chỉnh.
Bài toán ngân sách tổng thể cho một dự án tour, gồm cả sản xuất và vận hành, được phân tích trong bài chi phí làm VR tour 360.
Triển khai tour trên Cloudflare R2
Tour xuất từ Pano2VR là một gói HTML5 tĩnh gồm trang HTML, file cấu hình, script và thư mục tile. Gói này đặt được trên bất kỳ hạ tầng phục vụ file tĩnh nào. Dưới đây là quy trình bốn bước khi dùng R2.
Tạo bucket và gắn tên miền riêng
Tạo bucket R2, sau đó kết nối với một tên miền phụ của doanh nghiệp, ví dụ tour.tencongty.com (tên miền cần được quản lý DNS trên Cloudflare). Tên miền riêng giúp đi qua CDN và cache của Cloudflare. Đường dẫn dạng r2.dev mặc định chỉ nên dùng để thử, không dùng cho bản chạy thật vì bị giới hạn tốc độ.
Đồng bộ dữ liệu bằng rclone hoặc S3 API
R2 tương thích S3 API, nên có thể dùng rclone để đẩy cả thư mục tour với nhiều luồng song song. Kiểm tra kiểu nội dung (Content-Type) của file sau khi tải lên, đặc biệt là
image/webpcho tile, vì sai kiểu có thể khiến trình duyệt không hiển thị hoặc không cache.Đặt Cache-Control và CORS
Tile là file tĩnh, có thể cache rất lâu, ví dụ
Cache-Control: public, max-age=31536000, immutable. Riêng trang HTML và file cấu hình tour nên cache ngắn để bản cập nhật hiện ra nhanh. Nếu trang chứa tour và kho tile ở hai tên miền khác nhau, cần khai báo CORS cho đúng tên miền trang, vì WebGL chỉ dùng được ảnh khác nguồn khi máy chủ cho phép.Hạn chế nhúng trộm
Bật hotlink protection hoặc tạo quy tắc WAF kiểm tra Referer để chỉ cho phép tên miền của bạn tải tile. Muốn ngăn trang khác nhúng nguyên tour bằng iframe, đặt header
Content-Security-Policy: frame-ancestorsliệt kê các tên miền được phép nhúng.
Hai điểm hay bị bỏ sót khi vận hành lâu dài:
- Cache lâu đi kèm đổi tên khi cập nhật.
Nếu tile được cache một năm mà bạn xuất lại cảnh với cùng tên file, người xem cũ có thể vẫn thấy ảnh cũ. Cách an toàn là xuất bản cập nhật vào thư mục phiên bản mới (ví dụ/v2/
) rồi trỏ trang tour sang đó, hoặc xoá cache CDN có chủ đích. - Đừng dùng công cụ chống bot cho file tĩnh.
Các công cụ thử thách người dùng như Cloudflare Turnstile được thiết kế cho form, không phải để bảo vệ tile ảnh. Với tile, Referer, WAF và CSP là đúng công cụ.
Khi tour đã chạy trên tên miền riêng, việc đưa vào website chỉ còn là nhúng iframe. Mã nhúng chuẩn, cách tải khi người xem bấm (facade) và cách giữ Core Web Vitals có trong bài nhúng virtual tour vào WordPress.
Kiểm thử trước khi bàn giao
Một tour được tối ưu đúng phải được kiểm chứng bằng đo đạc, không bằng cảm giác trên máy văn phòng có mạng cáp quang. Bộ kiểm thử tối thiểu gồm:
Giả lập mạng chậm
Mở Chrome DevTools, tab Network, chọn chế độ giả lập mạng chậm (ví dụ Slow 4G hoặc 3G) và tắt cache. Mở tour từ đầu: cảnh đầu tiên phải hiện preview nhanh, không có màn hình đen kéo dài.
Đọc danh sách request
Lọc theo ảnh, kiểm tra tile tải ở định dạng WebP, kích thước khoảng 512 px, và chỉ tải khi xoay tới. Nếu thấy một file vài chục MB, đó là cảnh quên bật multiresolution hoặc một video tự tải.
Kiểm tra header
Bấm vào một tile, xem
Cache-Control,Content-Typevà header cho biết phản hồi đến từ cache CDN hay về tận kho gốc. Tải lại lần hai để xác nhận cache hoạt động.Xoay và zoom trên điện thoại thật
Dùng ít nhất một iPhone và một Android tầm trung, đã có vài năm sử dụng. Xoay nhanh, zoom sát, chuyển liên tục qua nhiều cảnh trong vài phút để xem tour có bị giật, nóng máy hay tải lại trang không.
Đo từ nhiều mạng
Thử bằng 4G của vài nhà mạng trong nước và wifi thông thường, vì định tuyến CDN có thể khác nhau.
Một hiểu lầm phổ biến là dùng điểm PageSpeed Insights để đánh giá tốc độ tour. PageSpeed đo trang web chứa tour, không đo trải nghiệm xoay và zoom bên trong. Điểm đó vẫn quan trọng cho SEO của trang mẹ, nhưng là bài toán riêng, giải bằng cách nhúng đúng chứ không bằng tối ưu tile. Cơ chế tổng thể giữa trang web và tour được giải thích trong bài virtual tour 360 hoạt động trên website như thế nào.
Tour 360 của bạn đang tải chậm?
Gửi cho 360VR đường link tour và website đang nhúng tour. Đội kỹ thuật sẽ xem cách tour đang được xuất và phân phối, chỉ ra điểm nghẽn chính và đề xuất hướng tối ưu phù hợp với hạ tầng hiện có của bạn.
Câu hỏi thường gặp
Vì sao tile thường là 512 px mà không phải 256 hay 1.024 px?
Đây là điểm cân bằng giữa số request và dung lượng mỗi ô. Ô 256 px sinh ra nhiều file và nhiều request hơn hẳn, còn ô 1.024 px khiến trình duyệt tải về nhiều vùng nằm ngoài khung nhìn. 512 px là mặc định phổ biến, nhưng vẫn có thể điều chỉnh nếu đo thấy hiệu quả hơn ở dự án cụ thể.
iPhone cũ có xem được tour dùng tile WebP không?
Safari hỗ trợ WebP từ iOS 14, nên hầu hết iPhone đang dùng đều xem được. Nếu tour phục vụ thiết bị rất cũ, ví dụ máy tính bảng đặt cố định tại quầy, nên xuất thêm bộ JPEG dự phòng hoặc kiểm tra trực tiếp trên thiết bị đó trước khi chốt.
Công ty có máy chủ riêng, có nên đặt tour trên đó không?
Được, nếu có người quản trị và đường truyền đủ mạnh. Tuy vậy, nên đặt một CDN phía trước máy chủ đó để phần lớn request tile được phục vụ từ cache, giảm tải cho máy chủ nội bộ và rút ngắn quãng đường tới người xem ở xa.
Tour đặt trên R2 có nhúng vào website WordPress được không?
Được. Tour chạy tại tên miền riêng như tour.tencongty.com, website chỉ cần nhúng bằng iframe hoặc mở trong popup. Cần cấu hình frame-ancestors phía tour cho phép tên miền website, và nếu website có CSP thì thêm tên miền tour vào frame-src.
Nhúng tour có làm chậm website chính không?
Nếu nhúng iframe tải ngay khi mở trang, tour sẽ tranh băng thông và tài nguyên với nội dung chính. Cách nên dùng là hiển thị ảnh bìa và chỉ tải tour khi người xem bấm hoặc cuộn tới. Khi tour đặt ở hạ tầng riêng, lượt xem tour cũng không chiếm tài nguyên của hosting website.
Bao nhiêu MB cho mỗi lượt xem là ổn?
Không có con số chung, vì còn tuỳ số cảnh người xem đi qua và mức họ zoom. Tiêu chí thực tế hơn là cảnh đầu tiên hiện hình nhanh trên mạng di động, dữ liệu chỉ tăng khi người xem thực sự xoay, zoom hoặc chuyển cảnh, và không có file lớn nào tự tải mà người xem chưa yêu cầu.
Đã có multiresolution rồi thì còn cần CDN không?
Có. Multiresolution giảm lượng dữ liệu cần tải, còn CDN rút ngắn quãng đường và gánh số lượng request lớn. Hai lớp này giải hai vấn đề khác nhau, nên một tour vận hành tốt thường cần cả hai.
