Trang web chính thức của doanh nghiệp khi được cải tiến sẽ dành rất nhiều thời gian cho phần nhìn nhận đầu trang, nhưng lại xếp đặt các công cụ thống kê, dịch vụ khách hàng, pixel, A/B, chat và SDK bản đồ vào phần đầu trang theo kiểu “treo lên trước đã rồi tính sau”. Google web.dev trong bài viết “Hiệu suất JavaScript của bên thứ ba” đã nêu rõ: các tập lệnh bên thứ ba không chỉ làm chậm trang mà còn ảnh hưởng đến quyền riêng tư, bảo mật và hành vi của trang; vì chúng nằm ngoài chu kỳ phát hành của bạn, nên việc khắc phục sự cố càng trở nên khó khăn. Các tập lệnh đồng bộ sẽ chặn quá trình phân tích tài liệu; nếu máy chủ nguồn bên thứ ba gặp sự cố, trang có thể phải chờ đợi cho đến khi yêu cầu hết thời hạn, và bài kiểm tra sự cố đơn điểm WebPageTest được web.dev trích dẫn ước tính khoảng thời gian này từ 10 đến 80 giây. Đối với các trang web B2B cần thu thập khách hàng tiềm năng, điều này còn gây tổn hại đến tỷ lệ chuyển đổi hơn cả việc thiếu hai bức ảnh sản phẩm.
I. Trước tiên hãy xử lý kho dữ liệu, sau đó mới bàn đến các kỹ thuật tối ưu hóa
Lời khuyên đầu tiên của web.dev không phải là sửa mã mà là quản lý: lựa chọn nhà cung cấp có lượng mã nguồn nhỏ hơn, thiết lập ngân sách hiệu suất cho bên thứ ba, không nên đồng thời gắn hai hệ thống quản lý thẻ hoặc hai hệ thống thống kê, thường xuyên kiểm toán và xóa bỏ những pixel không có người quản lý. Nhiều trang web doanh nghiệp cùng lúc tồn tại cả Google Analytics cũ, nền tảng phân tích mới, pixel quảng cáo do phòng kinh doanh tự ý thêm vào và dịch vụ khách hàng trực tuyến đã hết hạn; mỗi loại đều xây dựng khung, thiết lập kết nối riêng, đồng thời có chiến lược lưu trữ cache vô cùng kém. Về chiến lược tải, ngoại trừ các tập lệnh cần thiết cho quá trình render quan trọng, tất cả đều nên sử dụng async hoặc defer; web.dev lấy ví dụ, sau khi The Telegraph chuyển các tập lệnh bao gồm quảng cáo và thống kê sang chế độ defer, thời gian tải quảng cáo trung bình nhanh hơn khoảng 4 giây. Đối với các nguồn nhất định sẽ sử dụng, preconnect còn tiết kiệm được một vòng handshake TLS so với chỉ thực hiện pre-resolve DNS.
1.1 Trang marketing và trang biểu mẫu không nên dùng chung một bộ quy tắc bảo mật
OWASP trong thảo luận về chuỗi cung ứng phía trước nhấn mạnh: cùng một đoạn mã phân tích, khi được gắn trên trang kể chuyện thương hiệu và khi được gắn trên trang gửi thông tin liên hệ, rủi ro hoàn toàn khác nhau. Sự kiện năm 2025 khi các gói như chalk, debug bị chiếm đoạt, với tổng lượt tải xuống khoảng 2,6 tỷ lần, cho thấy rằng việc mất quyền kiểm soát tài khoản của nhà bảo trì có thể lan truyền dọc theo sơ đồ phụ thuộc. Ngay cả khi trang web chính thức không trực tiếp đóng gói các thư viện này qua npm, chỉ cần sử dụng thẻ tự động cập nhật hoặc địa chỉ “phiên bản mới nhất” trên CDN, bề mặt tấn công vẫn tồn tại.
II. CSP nên sử dụng số ngẫu nhiên thay vì mở rộng danh sách trắng vô hạn
Hướng dẫn triển khai CSP của MDN xếp chiến lược nghiêm ngặt dựa trên nonce hoặc hàm băm lên trước chiến lược dựa trên danh sách trắng tên miền. Danh sách trắng càng ngày càng dài, cuối cùng lại đưa cả những miền không an toàn vào, chẳng khác nào không có chiến lược nào cả. strict-dynamic được dùng để giải quyết vấn đề “tập lệnh được tin cậy ở đoạn đầu tiên lại kéo theo các tập lệnh con”, tránh tình trạng đưa cả nửa mạng internet vào script-src. Còn connect-src thì giới hạn nơi các tập lệnh có thể gửi dữ liệu — đây chính là chìa khóa để ngăn chặn việc mã thống kê bị chiếm đoạt mang theo trường biểu mẫu. Tập lệnh nội tuyến không thể được cố định bằng SRI, chỉ có thể dựa vào nonce thay đổi theo từng phản hồi. Chỉ những thư viện tĩnh, được cố định phiên bản mới phù hợp với SRI.
| Mặt điều khiển | Giải quyết vấn đề gì | Gợi ý triển khai trang web chính thức |
|---|---|---|
| Kho dữ liệu và ngân sách | Nhà cung cấp trùng lặp, pixel không có người quản lý | Định kỳ hàng quý nêu tên người chịu trách nhiệm, nếu vượt ngân sách sẽ bị gỡ khỏi hệ thống |
| Phương thức tải | Chặn render, thời gian chờ đơn điểm quá lâu | Mặc định là defer, dịch vụ khách hàng và pixel được hoãn đến sau khi tương tác |
| CSP nonce + strict-dynamic | XSS và việc chèn tập lệnh tùy tiện | Trước tiên áp dụng Report-Only, sau đó mới bắt buộc đối với trang biểu mẫu |
| connect-src / Permissions-Policy | Việc truyền dữ liệu và lạm dụng khả năng của trình duyệt | Trang biểu mẫu cấm sử dụng clipboard, camera và các tính năng không liên quan |
| SRI và cố định phiên bản | CDN bị thay thế file | Cấm các thư viện công cộng “latest” không có hàm băm |
III. Việc cải tiến nên bắt đầu từ ngân sách tập lệnh, chứ không phải từ bản phác thảo hình ảnh
Core Web Vitals đã được bàn luận rất nhiều, nhưng vị trí khiến trang web doanh nghiệp thực sự bị giảm điểm thường là bên thứ ba chứ không phải CSS của chính mình. web.dev còn nhắc nhở: việc thiết lập kết nối tới nguồn bên thứ ba vốn đã tốn kém, HTTPS còn phải qua DNS, chuyển hướng và nhiều lần trao đổi; cùng một trang kéo nhiều nguồn, chẳng khác nào đặt màn hình đầu tiên vào tay nhà cung cấp chậm nhất. Khi XYN Tech làm trang web chính thức, họ coi danh sách thẻ như một hạng mục giao hàng ngang tầm với cấu trúc chuyên mục: mỗi tập lệnh đều ghi rõ mục đích sử dụng, tên miền xuất dữ liệu, có xuất hiện trên trang biểu mẫu hay không, và liệu trang có thể vẫn nộp đơn khi thất bại hay không. Trang chứa biểu mẫu tư vấn mặc định không tải quảng cáo và các pixel không cần thiết; thành phần chat được chèn vào sau khi người dùng nhấp chuột, nhằm tránh phó thác vận mệnh màn hình đầu tiên cho tính khả dụng của nhà cung cấp dịch vụ khách hàng. Permissions-Policy có thể tắt quyền truy cập clipboard, camera, USB của iframe bên thứ ba, điều này đặc biệt hữu ích đối với các trang có chức năng tải file hoặc trình diễn trực tuyến.
- Dùng công cụ dành cho nhà phát triển liệt kê tất cả các nguồn bên thứ ba, đánh dấu các chức năng trùng lặp.
- Thiết lập ngân sách tập lệnh riêng cho trang chủ và trang liên hệ (tính bằng kilobyte và thời gian chặn luồng chính).
- Triển khai cổng báo cáo CSP, trước tiên xem xét lỗi báo sai trong một tuần rồi mới áp dụng bắt buộc.
- Trong hợp đồng yêu cầu nhân viên marketing khi bổ sung pixel phải thông qua quy trình thay đổi, không được tự ý chỉnh sửa mẫu.
Trình quản lý thẻ thường bị coi là cánh cửa hậu “sau này muốn thêm pixel không cần tìm dev”. Đối với đội ngũ bảo mật, nó giống như giao quyền phát hành tập lệnh cho bộ phận marketing. Điều kiện chấp nhận được là: chỉ tài khoản được kiểm soát mới được phép phát hành, mỗi lần phát hành đều có sự khác biệt, container sản xuất mặc định chặn các thẻ chưa được phê duyệt. Nếu không, CSP vừa siết chặt, trình quản lý thẻ lại đưa bất kỳ tập lệnh nào trở lại. Quản lý tập lệnh bên thứ ba không có chỗ cho phô trương, mà là tái xác lập quyền “ai có thể thực thi mã dưới tên miền của chúng ta”. Lần cải tiến trang web tiếp theo, nếu chỉ đánh giá phần hình ảnh, xin vui lòng kèm thêm ảnh chụp bảng điều khiển mạng vào hồ sơ thẩm định: những thanh yêu cầu bên thứ ba với màu sắc khác nhau chính là tiếng ồn nền chung của chuyển đổi và an ninh. Trước tiên hãy xóa bỏ những cái không có người quản lý, rồi mới bàn đến việc có nên thay thế bằng một trung tâm marketing nặng ký hơn hay không.