Tối ưu hoá thẻ và trình quản lý thẻ cho Core Web Vitals.
Thẻ là đoạn mã mã của bên thứ ba được chèn vào một trang web, thường là thông qua một trình quản lý thẻ. Thẻ thường được dùng nhất cho hoạt động tiếp thị và phân tích.
Tác động của thẻ và trình quản lý thẻ đối với hiệu suất rất khác nhau tuỳ theo trang web. Trình quản lý thẻ có thể được so sánh với phong bì: trình quản lý thẻ cung cấp tàu – nhưng việc bạn sử dụng và sử dụng như thế nào là hoàn toàn tuỳ thuộc vào bạn.
Bài viết này thảo luận các kỹ thuật tối ưu hoá thẻ và trình quản lý thẻ cho hiệu suất và Các chỉ số quan trọng về trang web. Mặc dù bài viết này đề cập đến Trình quản lý thẻ của Google, nhiều ý tưởng đã thảo luận cũng có thể áp dụng cho trình quản lý thẻ khác.
Tác động đối với Chỉ số quan trọng chính của trang web
Thông thường, Trình quản lý thẻ có thể tác động gián tiếp đến Chỉ số quan trọng chính của trang web bằng cách sử dụng hết tài nguyên cần thiết để tải nhanh và duy trì khả năng phản hồi của trang. Lượng băng thông có thể được dùng để tải JavaScript của trình quản lý thẻ xuống cho trang web của bạn hoặc cho các lệnh gọi tiếp theo mà tính năng này thực hiện. Thời gian của CPU trên luồng chính có thể được dùng để đánh giá và thực thi JavaScript có trong trình quản lý thẻ và các thẻ.
Nội dung lớn nhất hiển thị (LCP) dễ bị tranh chấp băng thông trong thời gian tải trang quan trọng. Ngoài ra, việc chặn luồng chính có thể làm trễ thời gian kết xuất LCP.
Điểm số tổng hợp về mức thay đổi bố cục (CLS) có thể bị ảnh hưởng do trì hoãn việc tải các tài nguyên quan trọng trước lần hiển thị đầu tiên, hoặc do trình quản lý thẻ chèn nội dung vào trang.
Lượt tương tác với Next Paint (INP) dễ xảy ra tranh chấp CPU trên luồng chính và chúng tôi đã quan sát thấy mối tương quan giữa quy mô của trình quản lý thẻ và điểm INP thấp hơn.
Loại thẻ
Tác động của thẻ đối với hiệu suất sẽ khác nhau tuỳ theo loại thẻ. Nói chung, hình ảnh thẻ ("pixel") là có hiệu suất cao nhất, tiếp theo là mẫu tuỳ chỉnh và cuối cùng là thẻ HTML tuỳ chỉnh. Thẻ nhà cung cấp sẽ khác nhau tuỳ thuộc vào chức năng của thẻ cho phép.
Tuy nhiên, xin lưu ý rằng cách bạn sử dụng thẻ sẽ ảnh hưởng lớn đến hiệu suất của thẻ của bạn. "Pixel" có hiệu suất cao chủ yếu do bản chất của thẻ này áp dụng các hạn chế chặt chẽ về cách sử dụng chúng; thẻ HTML tùy chỉnh không thường sẽ không tốt cho hiệu suất nhưng do mức độ tự do, mang lại cho người dùng, chúng có thể dễ dàng sử dụng sai mục đích theo cách không tốt cho hiệu suất.
Khi xem xét thẻ, hãy lưu ý đến quy mô: tác động của bất kỳ thẻ nào nhưng có thể trở nên quan trọng khi hàng chục hoặc hàng trăm các thẻ được sử dụng trên cùng một trang.
Không phải tập lệnh nào cũng được tải bằng trình quản lý thẻ
Trình quản lý thẻ thường không phải là cơ chế hiệu quả để tải tài nguyên triển khai các khía cạnh trực quan hoặc chức năng tức thì của trải nghiệm người dùng — để ví dụ: thông báo về cookie, hình ảnh chính hoặc tính năng của trang web. Sử dụng trình quản lý thẻ để tải các tài nguyên này thường làm chậm quá trình phân phối. Điều này có hại cho người dùng và cũng có thể tăng các chỉ số như LCP và CLS. Ngoài ra, hãy duy trì xin lưu ý rằng một số người dùng chặn trình quản lý thẻ. Sử dụng trình quản lý thẻ để triển khai trải nghiệm người dùng có thể khiến một số người dùng của bạn không truy cập được trang web.
Hãy cẩn thận với các thẻ HTML tùy chỉnh
HTML tuỳ chỉnh
các thẻ
đã có mặt trong nhiều năm và được sử dụng rất nhiều trên hầu hết các trang web. HTML tùy chỉnh
các thẻ cho phép bạn nhập mã của riêng mình mà không có nhiều hạn chế, bất kể tên,
công dụng chính của thẻ này là thêm các phần tử <script> tuỳ chỉnh vào một trang.
Thẻ HTML tùy chỉnh có thể được sử dụng theo nhiều cách khác nhau và tác động của chúng về hiệu suất khác nhau đáng kể. Khi đo lường hiệu suất của trang web, xin lưu ý rằng hầu hết các công cụ sẽ phân bổ tác động về hiệu suất của thẻ HTML tuỳ chỉnh cho thẻ người quản lý đã chèn thẻ đó—thay vì chính thẻ.
Thẻ HTML tuỳ chỉnh có thể chèn một phần tử vào trang xung quanh. Hành động chèn các phần tử vào trang có thể là nguyên nhân gây ra các vấn đề về hiệu suất và trong một số trường hợp cũng gây ra sự thay đổi bố cục.
- Trong hầu hết các trường hợp, nếu một phần tử được chèn vào trang, trình duyệt phải tính toán lại kích thước và vị trí của từng mục trên trang — quá trình này được gọi là layout. Tác động về hiệu suất của một bố cục là rất nhỏ, nhưng khi tác động xảy ra quá mức có thể trở thành nguồn gây ra các vấn đề về hiệu suất. Tác động của chính sách này hiện tượng này lớn hơn trên các thiết bị cấp thấp hơn và các trang có nhiều Các phần tử DOM.
- Nếu một phần tử trang hiển thị được chèn vào DOM sau thành phần xung quanh đã hiển thị, điều này có thể gây ra thay đổi bố cục. Hiện tượng này không phải là duy nhất đối với người quản lý thẻ, tuy nhiên, vì thẻ thường tải sau các phần khác của trang, thông thường sẽ được chèn vào DOM sau khi trang xung quanh đã được hiển thị.
Cân nhắc sử dụng Mẫu tuỳ chỉnh
Hỗ trợ mẫu tuỳ chỉnh một số hoạt động tương tự như thẻ HTML tuỳ chỉnh nhưng được xây dựng dựa trên hộp cát phiên bản JavaScript cung cấp API dùng cho mục đích sử dụng phổ biến như chèn tập lệnh và chèn pixel. Như chính tên gọi của nó, hai công cụ này cho phép mẫu được tạo, bởi một người dùng thành thạo có thể tạo mẫu này với hiệu suất trong tâm trí. Sau đó, những người dùng ít kỹ thuật hơn có thể sử dụng mẫu. Cách này thường an toàn hơn so với việc cung cấp quyền truy cập HTML tuỳ chỉnh đầy đủ.
Do những hạn chế lớn hơn đối với các mẫu tuỳ chỉnh, các thẻ này ít có khả năng có các vấn đề về hiệu suất hoặc bảo mật; Tuy nhiên, đối với cùng một nên các mẫu tuỳ chỉnh sẽ không dùng được cho mọi trường hợp sử dụng.
Chèn tập lệnh đúng cách
Việc sử dụng trình quản lý thẻ để chèn tập lệnh là một trường hợp sử dụng rất phổ biến. Chiến lược phát hành đĩa đơn
bạn nên sử dụng Mẫu tùy chỉnh và
injectScript
API.
Để biết thông tin về việc sử dụng composeScript API để chuyển đổi một HTML tuỳ chỉnh hiện có hãy xem bài viết Chuyển đổi thẻ.
Nếu bạn phải sử dụng thẻ HTML tuỳ chỉnh, hãy lưu ý một số điều sau:
- Các thư viện và tập lệnh lớn của bên thứ ba phải được tải thông qua thẻ tập lệnh
tải xuống tệp bên ngoài (ví dụ:
<script src="external-scripts.js">), thay vì sao chép-dán trực tiếp vào thẻ. Mặc dù đã ngừng sử dụng thẻ<script>loại bỏ một lượt trọn vòng riêng biệt để tải nội dung của tập lệnh xuống, việc này sẽ làm tăng kích thước vùng chứa và ngăn tập lệnh lưu vào bộ nhớ đệm được tách riêng bởi trình duyệt. - Nhiều nhà cung cấp khuyên bạn nên đặt thẻ
<script>ở đầu<head>. Tuy nhiên, đối với các tập lệnh được tải thông qua trình quản lý thẻ, đề xuất này thường không cần thiết: trong hầu hết các trường hợp, trình duyệt đã hoàn tất phân tích cú pháp<head>trước thời điểm trình quản lý thẻ thực thi.
Sử dụng pixel
Trong một số trường hợp, tập lệnh của bên thứ ba có thể được thay thế bằng hình ảnh hoặc iframe "pixel". So với các hình ảnh tương ứng dựa trên tập lệnh, pixel có thể hỗ trợ ít chức năng hơn, nên thường được coi là triển khai ít được ưu tiên hơn vì của thiết bị đó. Tuy nhiên, khi được sử dụng bên trong trình quản lý thẻ, pixel có thể linh động hơn vì chúng có thể kích hoạt các trình kích hoạt và truyền các biến khác nhau. Chúng phổ biến nhất loại thẻ có hiệu suất cao và an toàn vì không có thực thi JavaScript sau thì hệ thống sẽ kích hoạt. Pixel có kích thước tài nguyên rất nhỏ (dưới 1 KB) và không làm thay đổi bố cục.
Hãy liên hệ với nhà cung cấp bên thứ ba của bạn để biết thêm thông tin về dịch vụ hỗ trợ của họ dành cho
điểm ảnh. Ngoài ra, bạn có thể thử kiểm tra mã của họ để tìm thẻ <noscript>.
Nếu một nhà cung cấp hỗ trợ pixel, họ thường sẽ đưa các pixel vào
Thẻ <noscript>.
Lựa chọn thay thế cho pixel
Pixel trở nên phổ biến vì có thời gian chúng là một trong những chiếc điện thoại rẻ nhất
và đáng tin cậy nhất để đưa ra yêu cầu HTTP trong các trường hợp mà máy chủ
là không phù hợp ( ví dụ: khi gửi dữ liệu đến Analytics
). Chiến lược phát hành đĩa đơn
navigator.sendBeacon()
và fetch()
keepalive
Các API được thiết kế để giải quyết trường hợp sử dụng tương tự này nhưng được cho là đáng tin cậy hơn
pixel.
Không có vấn đề gì khi tiếp tục sử dụng pixel vì pixel được hỗ trợ và có tác động tối thiểu đến hiệu suất. Tuy nhiên, nếu bạn đang xây dựng beacon của riêng mình, bạn nên cân nhắc sử dụng một trong các API này.
sendBeacon()
Chiến lược phát hành đĩa đơn
navigator.sendBeacon()
API được thiết kế để gửi một lượng nhỏ dữ liệu đến máy chủ web trong các tình huống
trong đó phản hồi của máy chủ không quan trọng.
const url = "https://example.com/analytics";
const data = JSON.stringify({
event: "checkout",
time: performance.now()
});
navigator.sendBeacon(url, data);
sendBeacon() có một API bị giới hạn: API này chỉ hỗ trợ việc tạo các yêu cầu POST và có
không hỗ trợ thiết lập tiêu đề tuỳ chỉnh. Đó là
được hỗ trợ bởi tất cả trình duyệt hiện đại.
fetch() keepalive
keepalive
là cờ cho phép Tìm nạp
API sang
để thực hiện các yêu cầu không chặn như báo cáo sự kiện và phân tích. Đó là
được sử dụng bằng cách đưa keepalive: true vào các tham số được truyền đến fetch().
const url = "https://example.com/analytics";
const data = JSON.stringify({
event: "checkout",
time: performance.now()
});
fetch(url, {
method: 'POST',
body: data,
keepalive: true
});
Nếu fetch() keepalive và sendBeacon() có vẻ rất giống nhau, thì đó là do chúng
là thế nào. Trên thực tế, trong các trình duyệt Chromium, sendBeacon() hiện được xây dựng dựa trên fetch()
keepalive.
Khi chọn giữa fetch() keepalive và sendBeacon(), bạn cần lưu ý
hãy cân nhắc các tính năng và khả năng hỗ trợ trình duyệt mà bạn cần. API tìm nạp() là
linh hoạt hơn đáng kể; tuy nhiên, keepalive có ít trình duyệt hơn
hỗ trợ cao hơn sendBeacon().
Tìm hiểu rõ
Thẻ thường được tạo bằng cách làm theo hướng dẫn của nhà cung cấp bên thứ ba. Nếu không rõ mã của nhà cung cấp là gì, hãy cân nhắc việc hỏi một người biết. Việc thu thập ý kiến thứ hai có thể giúp xác định xem thẻ có tiềm năng tạo ra hay không về hiệu suất hoặc bảo mật.
Bạn cũng nên gắn nhãn thẻ có chủ sở hữu trong trình quản lý thẻ. Còn xa quá dễ quên chủ sở hữu thẻ và cũng rất e ngại khi xoá thẻ trong trường hợp không thích!
Điều kiện kích hoạt
Ở cấp độ cao, việc tối ưu hoá thẻ điều kiện kích hoạt thường bao gồm việc đảm bảo không kích hoạt thẻ nhiều hơn mức cần thiết và chọn một điều kiện kích hoạt giúp cân bằng giữa nhu cầu kinh doanh với chi phí hiệu suất.
Bản thân trình kích hoạt là mã JavaScript sẽ tăng kích thước và quá trình thực thi chi phí của trình quản lý thẻ. Mặc dù hầu hết các điều kiện kích hoạt đều nhỏ, nhưng tác động tích luỹ có thể cộng thêm. Ví dụ: việc có nhiều sự kiện nhấp chuột hoặc trình kích hoạt bộ tính giờ có thể đáng kể làm tăng khối lượng công việc của trình quản lý thẻ.
Chọn một sự kiện kích hoạt thích hợp
Tác động của thẻ về hiệu suất là không cố định: nói chung, mức độ tác động mà thẻ kích hoạt thì tác động của thẻ đó càng lớn đối với hiệu suất. Thông thường, các tài nguyên bị hạn chế trong quá trình tải trang ban đầu và do đó tải hoặc thực thi tài nguyên (hoặc thẻ) cụ thể sẽ lấy tài nguyên khỏi một tài nguyên khác.
Mặc dù điều quan trọng là phải chọn điều kiện kích hoạt phù hợp cho tất cả các thẻ, đặc biệt quan trọng đối với những thẻ tải tài nguyên lớn hoặc thực thi thời gian dài các tập lệnh.
Thẻ có thể được kích hoạt trên
Số lượt xem trang
(thường là Page load, trên DOM Ready, vào Window Loaded) hoặc dựa trên một
sự kiện tùy chỉnh. Để tránh ảnh hưởng đến tải trang, bạn nên kích hoạt
các thẻ không cần thiết sau Window Loaded.
Sử dụng sự kiện tuỳ chỉnh
Sự kiện tuỳ chỉnh
cho phép bạn kích hoạt trình kích hoạt để phản hồi các sự kiện trên trang không được đề cập trong
Trình kích hoạt tích hợp trong Trình quản lý thẻ của Google. Ví dụ: nhiều thẻ sử dụng chức năng lượt xem trang
điều kiện kích hoạt; tuy nhiên,
khoảng thời gian từ DOM Ready đến Window Loaded có thể kéo dài trên nhiều
và điều này có thể khiến bạn khó tinh chỉnh khi thẻ kích hoạt. Tuỳ chỉnh
sự kiện sẽ cung cấp giải pháp cho vấn đề này.
Để sử dụng sự kiện tuỳ chỉnh, trước tiên hãy tạo một điều kiện kích hoạt sự kiện tuỳ chỉnh rồi cập nhật thẻ của bạn để sử dụng trình kích hoạt này.
Để kích hoạt trình kích hoạt, hãy đẩy sự kiện tương ứng vào lớp dữ liệu.
// Custom event trigger that fires after 2 seconds
setTimeout(() => {
dataLayer.push({
'event' : 'my-custom-event'
});
}, 2000);
Sử dụng các điều kiện kích hoạt cụ thể
Việc sử dụng các điều kiện kích hoạt cụ thể giúp tránh kích hoạt thẻ một cách không cần thiết. Mặc dù có nhiều cách để áp dụng khái niệm này, nhưng một trong những cách đơn giản nhất những điều hữu ích bạn có thể làm là đảm bảo rằng thẻ chỉ kích hoạt trên những trang thực sự được sử dụng.
Biến tích hợp có thể cũng được kết hợp vào các điều kiện của điều kiện kích hoạt để hạn chế việc kích hoạt thẻ.
Tuy nhiên, xin lưu ý rằng việc có các ngoại lệ hoặc điều kiện kích hoạt phức tạp sẽ cần đến thời gian xử lý trong và ngoài hệ thống, vì vậy đừng biến chúng thành quá phức tạp.
Tải trình quản lý thẻ vào thời điểm thích hợp
Việc điều chỉnh thời điểm mà trình quản lý thẻ tự tải có thể tác động đáng kể đến hiệu suất. Trình kích hoạt không thể kích hoạt cho đến khi chúng được định cấu hình như thế nào sau khi trình quản lý thẻ tải. Mặc dù điều quan trọng là phải chọn những yếu tố kích hoạt phù hợp cho các thẻ riêng lẻ (như đã giải thích ở trên), thử nghiệm thời điểm bạn tải thẻ người quản lý thường có thể có tác động tương đương hoặc lớn hơn nhờ lượt chuyển đổi này sẽ ảnh hưởng đến tất cả các thẻ trên một trang.
Việc tải trình quản lý thẻ sau cũng sẽ thêm một lớp kiểm soát và có thể tránh việc phát sinh trong tương lai các vấn đề về hiệu suất vì điều này sẽ ngăn người dùng trình quản lý thẻ vô tình tải gắn thẻ quá sớm mà không nhận ra tác động của việc này.
Biến
Biến cho phép đọc dữ liệu trên trang. Chúng rất hữu ích trong trình kích hoạt và trong chính thẻ.
Giống như trình kích hoạt, biến dẫn đến việc mã JavaScript được thêm vào trình quản lý thẻ, và do đó có thể gây ra các vấn đề về hiệu suất. Các biến có thể được tích hợp tương đối đơn giản ví dụ: có thể đọc các phần của URL, cookie, lớp dữ liệu hoặc DOM. Hoặc chúng có thể là JavaScript tuỳ chỉnh về cơ bản là không giới hạn chức năng của chúng.
Giữ cho các biến trở nên đơn giản và ở mức tối thiểu vì chúng sẽ cần được đánh giá liên tục do trình quản lý thẻ tạo. Xoá các biến cũ mà không còn sử dụng nữa để giảm cả kích thước của tập lệnh trình quản lý thẻ lẫn thời gian xử lý sử dụng.
Quản lý thẻ
Việc sử dụng thẻ một cách hiệu quả sẽ làm giảm nguy cơ xảy ra các vấn đề về hiệu suất.
Sử dụng lớp dữ liệu
Lớp dữ liệu "chứa tất cả thông tin mà bạn muốn chuyển đến Trình quản lý thẻ của Google". Xem thêm cụ thể, đó là một mảng các đối tượng JavaScript chứa thông tin về trang. Bạn cũng có thể dùng thẻ này để kích hoạt thẻ.
// Contents of the data layer
window.dataLayer = [{
'pageCategory': 'signup',
'visitorType': 'high-value'
}];
// Pushing a variable to the data layer
window.dataLayer.push({'variable_name': 'variable_value'});
// Pushing an event to the data layer
window.dataLayer.push({'event': 'event_name'});
Mặc dù Trình quản lý thẻ của Google có thể được sử dụng mà không cần lớp dữ liệu, nhưng công cụ này thực sự nên dùng. Lớp dữ liệu cung cấp cách thức hợp nhất dữ liệu được tập lệnh bên thứ ba truy cập vào một nơi duy nhất, do đó cung cấp thông tin rõ ràng hơn về việc sử dụng mã. Một trong những lợi ích của giải pháp này là các phép tính biến thừa và thực thi tập lệnh. Sử dụng cả lớp dữ liệu kiểm soát dữ liệu mà các thẻ truy cập, thay vì cung cấp JavaScript đầy đủ quyền truy cập DOM hoặc biến.
Xoá các thẻ trùng lặp và không dùng đến
Thẻ trùng lặp có thể xảy ra khi một thẻ được đưa vào mã đánh dấu HTML của một trang trong bên cạnh việc được chèn thông qua trình quản lý thẻ.
Bạn nên tạm dừng hoặc xoá các thẻ không sử dụng thay vì chặn bằng cách sử dụng một kích hoạt ngoại lệ. Việc tạm dừng hoặc xoá một thẻ sẽ xoá mã khỏi vùng chứa; chặn thì không.
Khi các thẻ không sử dụng bị xoá, điều kiện kích hoạt và biến cũng phải được xem xét để xem có thể xoá bất kỳ nội dung nào trong số đó nếu chỉ có những trình quản lý nội dung đó sử dụng các thẻ.
Sử dụng danh sách cho phép và danh sách từ chối
Danh sách cho phép và từ chối cho phép bạn định cấu hình các quy tắc hạn chế thật chi tiết về thẻ, trình kích hoạt và các biến được phép trên một trang. Tính năng này có thể dùng để giúp thực thi hiệu suất tốt nhất thực tiễn và các chính sách khác.
Các danh sách cho phép và từ chối được định cấu hình thông qua lớp dữ liệu.
window.dataLayer = [{
'gtm.allowlist': ['<id>', '<id>', ...],
'gtm.blocklist': ['customScripts']
}];
Ví dụ: có thể không cho phép bất kỳ thẻ HTML tuỳ chỉnh, JavaScript nào biến hoặc quyền truy cập DOM trực tiếp. Điều này có nghĩa là chỉ pixel và thẻ được xác định trước có thể được sử dụng, với dữ liệu từ lớp dữ liệu. Mặc dù điều này chắc chắn hạn chế, thì việc này có thể giúp triển khai trình quản lý thẻ hiệu quả và an toàn hơn nhiều.
Cân nhắc sử dụng tính năng gắn thẻ phía máy chủ
Việc chuyển sang tính năng gắn thẻ phía máy chủ không phải là một nhiệm vụ đơn giản nhưng rất đáng để thực hiện đang cân nhắc – đặc biệt đối với những trang web lớn muốn có nhiều quyền kiểm soát hơn đối với . Tính năng gắn thẻ phía máy chủ sẽ xoá mã nhà cung cấp khỏi máy khách và cùng với mã đó, giảm tải cho quá trình xử lý từ máy khách đến máy chủ.
Ví dụ: khi sử dụng tính năng gắn thẻ phía máy khách, tính năng gửi dữ liệu đến nhiều số liệu phân tích tài khoản đòi hỏi ứng dụng khởi tạo các yêu cầu riêng biệt cho từng điểm cuối. Ngược lại, với tính năng gắn thẻ phía máy chủ, ứng dụng chỉ đưa ra một yêu cầu duy nhất để vùng chứa phía máy chủ và từ đó, dữ liệu này được chuyển tiếp đến Analytics.
Xin lưu ý rằng tính năng gắn thẻ phía máy chủ chỉ hoạt động với một số thẻ; thiết bị theo dõi khả năng tương thích khác nhau tuỳ thuộc vào nhà cung cấp.
Để biết thêm thông tin, hãy xem Giới thiệu về phía máy chủ gắn thẻ.
Vùng chứa
Trình quản lý thẻ thường cho phép nhiều thực thể hoặc "vùng chứa" trong thiết lập. Nhờ đó, bạn có thể kiểm soát nhiều vùng chứa trong một thẻ tài khoản người quản lý.
Chỉ sử dụng một vùng chứa trên mỗi trang
Sử dụng nhiều vùng chứa trên một trang có thể gây ra các vấn đề quan trọng về hiệu suất khi nó xuất hiện chi phí bổ sung và việc thực thi tập lệnh. Ít nhất, API này sao chép chính mã của thẻ cốt lõi này, vì nó được phân phối như một phần của vùng chứa JavaScript, không được dùng lại giữa các vùng chứa.
Rất hiếm khi có trường hợp sử dụng hiệu quả nhiều vùng chứa. Tuy nhiên, có thể những trường hợp mà việc này có thể diễn ra (nếu được kiểm soát tốt) bao gồm:
- "Tải sớm" nhẹ hơn vùng chứa và nút "tải sau" nặng hơn container, thay vì một vùng chứa lớn.
- Có một vùng chứa bị hạn chế được người dùng ít kỹ thuật sử dụng hơn với vùng chứa các thẻ không thể sử dụng bị hạn chế, nhưng được kiểm soát chặt chẽ hơn trong vùng chứa bị hạn chế.
Nếu bạn phải sử dụng nhiều vùng chứa trên mỗi trang, hãy làm theo Trình quản lý thẻ của Google hướng dẫn thiết lập nhiều vùng chứa.
Dùng vùng chứa riêng nếu cần
Nếu bạn sử dụng một trình quản lý thẻ cho nhiều tài sản (ví dụ: một ứng dụng web và một dành cho thiết bị di động)—số lượng vùng chứa bạn sử dụng có thể giúp ích hoặc ảnh hưởng đến quy trình làm việc của bạn tăng năng suất. Điều này cũng có thể ảnh hưởng đến hiệu suất.
Nói chung, một vùng chứa duy nhất có thể được sử dụng hiệu quả trên nhiều vùng chứa trang web nếu các trang web tương tự nhau về cách sử dụng và cấu trúc. Ví dụ: mặc dù ứng dụng web và ứng dụng di động của thương hiệu nào có thể phục vụ các chức năng tương tự nhau, thì có khả năng ứng dụng sẽ có cấu trúc khác nhau, do đó được quản lý hiệu quả hơn thông qua các vùng chứa riêng biệt.
Việc cố gắng sử dụng lại một vùng chứa quá rộng thường làm tăng mức không cần thiết độ phức tạp và kích thước của vùng chứa bằng cách buộc áp dụng logic phức tạp để quản lý thẻ và trình kích hoạt.
Chú ý đến kích thước vùng chứa
Kích thước của vùng chứa được xác định bởi các thẻ, trình kích hoạt và biến của vùng chứa đó. Mặc dù vùng chứa nhỏ vẫn có thể tác động tiêu cực đến hiệu suất trang, nhưng vùng chứa gần như chắc chắn sẽ hoạt động.
Không được chọn kích thước vùng chứa làm chỉ số làm kim chỉ nam khi tối ưu hoá thẻ sử dụng; tuy nhiên, kích thước vùng chứa lớn thường là dấu hiệu cảnh báo cho biết vùng chứa không được duy trì tốt và có thể bị sử dụng sai mục đích.
Trình quản lý thẻ của Google vùng chứa limit (giới hạn) lên 200 KB và sẽ cảnh báo về kích thước vùng chứa bắt đầu từ 140 KB. Tuy nhiên, hầu hết các trang web nên cố gắng giữ cho vùng chứa của chúng nhỏ hơn nhiều so với tỷ lệ này. Để thì vùng chứa trang web trung bình là khoảng 50 KB.
Để xác định kích thước vùng chứa của bạn, hãy xem kích thước của phản hồi
được trả về bởi https://www.googletagmanager.com/gtag/js?id=YOUR_ID. Chiến dịch này
chứa thư viện Trình quản lý thẻ của Google cùng với nội dung của
vùng chứa. Thư viện Trình quản lý thẻ của Google có kích thước khoảng 33 KB
nén.
Đặt tên cho các phiên bản vùng chứa
Vùng chứa phiên bản là ảnh chụp nhanh nội dung của vùng chứa tại một thời điểm cụ thể. Sử dụng có ý nghĩa và kèm theo một đoạn mô tả ngắn về những thay đổi bên trong có thể rất hữu ích trong việc gỡ lỗi hiệu suất trong tương lai dễ dàng hơn vấn đề.
Quy trình gắn thẻ
Việc quản lý các thay đổi đối với thẻ đóng vai trò quan trọng để đảm bảo thẻ không có tác động tiêu cực đến hiệu suất trang.
Kiểm thử thẻ trước khi triển khai
Việc kiểm tra thẻ trước khi triển khai có thể giúp phát hiện vấn đề (hiệu suất và nếu không) trước khi vận chuyển.
Những điều cần xem xét khi thử nghiệm một thẻ bao gồm:
- Thẻ có hoạt động chính xác không?
- Thẻ này có gây ra bất kỳ thay đổi nào về bố cục không?
- Thẻ có tải tài nguyên nào không? Những tài nguyên này lớn đến mức nào?
- Thẻ có kích hoạt tập lệnh chạy trong thời gian dài không?
Chế độ xem trước
Chế độ xem trước cho phép bạn để thử nghiệm các thay đổi về thẻ trên trang web thực tế của bạn mà không cần phải triển khai chúng cho công khai trước tiên. Chế độ xem trước bao gồm một bảng điều khiển gỡ lỗi cung cấp về thẻ.
Thời gian thực thi của Trình quản lý thẻ của Google sẽ khác (chậm hơn một chút) khi chạy ở chế độ Xem trước do phát sinh thêm mức hao tổn tài nguyên cần thiết để hiển thị trong bảng điều khiển gỡ lỗi. Do đó, việc so sánh các chỉ số đo lường Chỉ số quan trọng của trang web được thu thập ở chế độ xem trước thành dữ liệu được thu thập trong phiên bản chính thức. Tuy nhiên, sự khác biệt này sẽ không ảnh hưởng đến hoạt động thực thi của thẻ chính họ.
Kiểm thử độc lập
Một phương pháp thay thế để kiểm tra thẻ là thiết lập một trang trống chứa vùng chứa có một thẻ duy nhất—thẻ mà bạn đang thử nghiệm. Chế độ thiết lập thử nghiệm này ít thực tế và sẽ không phát hiện được một số vấn đề (ví dụ: liệu thẻ có gây ra bố cục hay không thay đổi)—tuy nhiên, công cụ này có thể giúp bạn dễ dàng tách biệt và đo lường tác động của vào những việc như thực thi tập lệnh. Hãy xem cách Telegraph dùng chế độ này phương pháp tách biệt để cải thiện hiệu suất mã của bên thứ ba.
Theo dõi hiệu suất thẻ
Giám sát trong Trình quản lý thẻ của Google Có thể sử dụng API để thu thập thông tin về việc thực thi thời gian của một thẻ cụ thể. Thông tin này được báo cáo cho điểm cuối của đang chọn.
Để biết thêm thông tin, hãy xem bài viết Cách tạo Trình quản lý thẻ của Google Giám sát.
Yêu cầu phê duyệt các thay đổi về vùng chứa
Mã của bên thứ nhất thường trải qua quá trình xem xét và kiểm thử trước khi triển khai – cũng sẽ xử lý thẻ của bạn như nhau. Thêm hai bước xác minh, yêu cầu quản trị viên phê duyệt đối với các thay đổi về vùng chứa, là một cách để thực hiện này. Ngoài ra, nếu bạn không muốn yêu cầu xác minh hai bước nhưng vẫn muốn theo dõi các thay đổi, bạn có thể thiết lập container thông báo đến nhận thông báo qua email về các sự kiện vùng chứa mà bạn chọn.
Định kỳ kiểm tra việc sử dụng thẻ
Một trong những thách thức khi làm việc với thẻ là thẻ có xu hướng tích luỹ trong thời gian: thẻ được thêm nhưng hiếm khi bị xoá. Việc kiểm tra thẻ định kỳ là để đảo ngược xu hướng này. Tần suất lý tưởng để thực hiện việc này sẽ phụ thuộc vào cách thẻ trên trang web của bạn thường được cập nhật.
Gắn nhãn từng thẻ để chủ sở hữu dễ nhận biết, giúp bạn dễ dàng xác định ai có phản hồi cho thẻ đó và có thể cho biết liệu thẻ đó có còn cần thiết hay không.
Khi kiểm tra thẻ, đừng quên dọn dẹp các điều kiện kích hoạt và biến dưới dạng tốt. Chúng cũng có thể dễ dàng là nguyên nhân gây ra các vấn đề về hiệu suất.
Để biết thêm thông tin, hãy xem phần Giữ tập lệnh của bên thứ ba trong kiểm soát.