กลยุทธ์ในการย้ายข้อมูลเว็บไซต์จากการใช้สตริง User Agent ไปยังคำแนะนำไคลเอ็นต์ User Agent ใหม่
สตริง User-Agent เป็นแพลตฟอร์มการเก็บลายนิ้วมือแบบแพสซีฟที่สำคัญในเบราว์เซอร์ รวมถึงประมวลผลได้ยาก อย่างไรก็ตาม การรวบรวมและประมวลผลข้อมูล User Agent นั้นมาจากเหตุผลที่ถูกต้องทุกแบบ ดังนั้นสิ่งที่จำเป็นคือเส้นทางสู่โซลูชันที่ดีกว่า คำแนะนำสำหรับไคลเอ็นต์ User Agent เป็นทั้งวิธีที่ชัดเจนสำหรับการประกาศความจำเป็นของข้อมูล User Agent และวิธีแสดงผลข้อมูลในรูปแบบที่ใช้งานง่าย
บทความนี้จะอธิบายเกี่ยวกับการตรวจสอบการเข้าถึงข้อมูล User Agent และการย้ายข้อมูลการใช้สตริง User Agent ไปยังคำแนะนำ Client-Agent
ตรวจสอบการรวบรวมและการใช้ข้อมูล User Agent
คุณควรเข้าใจเหตุผลที่คุณเก็บรวบรวมข้อมูลนั้นอยู่เสมอ เช่นเดียวกับการรวบรวมข้อมูลทุกรูปแบบ ขั้นตอนแรก ไม่ว่าคุณจะดำเนินการใดๆ หรือไม่ก็ตาม คือการทำความเข้าใจตำแหน่งและเหตุผลที่คุณใช้ข้อมูล User Agent
หากไม่ทราบว่ามีการใช้ข้อมูล User Agent หรือไม่ ให้ลองค้นหาโค้ดส่วนหน้าเพื่อใช้ navigator.userAgent
และโค้ดแบ็กเอนด์เพื่อใช้ส่วนหัว HTTP ของ User-Agent
นอกจากนี้ คุณควรตรวจสอบโค้ดส่วนหน้าเพื่อใช้ฟีเจอร์ที่เลิกใช้งานแล้ว เช่น navigator.platform
และ navigator.appVersion
จากมุมมองที่ใช้งานได้ ให้นึกถึงส่วนใดก็ได้ในโค้ดที่คุณกำลังบันทึกหรือประมวลผล
- ชื่อหรือเวอร์ชันของเบราว์เซอร์
- ชื่อหรือเวอร์ชันของระบบปฏิบัติการ
- ยี่ห้อหรือรุ่นของอุปกรณ์
- ประเภท CPU, สถาปัตยกรรม หรืออัตราบิต (เช่น 64 บิต)
เป็นไปได้ว่าคุณอาจกำลังใช้ไลบรารีหรือบริการของบุคคลที่สามเพื่อประมวลผล User Agent ในกรณีนี้ ให้ตรวจสอบว่ามีการอัปเดตเพื่อรองรับคำแนะนำของไคลเอ็นต์ User Agent หรือไม่
คุณใช้เฉพาะข้อมูล User Agent พื้นฐานใช่ไหม
ชุดคำแนะนำเริ่มต้นของไคลเอ็นต์ User Agent ประกอบด้วย
Sec-CH-UA
: ชื่อเบราว์เซอร์และเวอร์ชันหลัก/เวอร์ชันสำคัญSec-CH-UA-Mobile
: ค่าบูลีนที่ระบุอุปกรณ์เคลื่อนที่Sec-CH-UA-Platform
: ชื่อระบบปฏิบัติการ- โปรดทราบว่าการอัปเดตนี้เป็นไปตามข้อกำหนด และจะแสดงใน Chrome และเบราว์เซอร์อื่นๆ ที่ใช้ Chromium ในเร็วๆ นี้
สตริง User Agent เวอร์ชันที่ลดลงที่เสนอมาจะยังรักษาข้อมูลพื้นฐานนี้ไว้ด้วยวิธีที่เข้ากันได้แบบย้อนหลัง ตัวอย่างเช่น สตริงจะมี Chrome/90.0.0.0
แทนที่จะเป็น Chrome/90.0.4430.85
หากคุณตรวจสอบเฉพาะสตริง User Agent เพื่อหาชื่อเบราว์เซอร์ เวอร์ชันหลัก หรือระบบปฏิบัติการ โค้ดของคุณจะยังทำงานต่อไปแม้จะมีโอกาสเห็นคำเตือนการเลิกใช้งาน
แม้ว่าคุณจะสามารถย้ายข้อมูลไปยัง User-Agent Client Hints ได้ แต่อาจมีข้อจำกัดด้านทรัพยากรหรือโค้ดเดิมที่ป้องกันปัญหานี้ การลดข้อมูลในสตริง User Agent ด้วยวิธีที่เข้ากันได้แบบย้อนหลังนี้มีไว้เพื่อให้มั่นใจว่าแม้ว่าโค้ดที่มีอยู่จะได้รับข้อมูลที่มีรายละเอียดน้อยลง แต่โค้ดควรจะยังคงมีฟังก์ชันการทำงานพื้นฐานอยู่
กลยุทธ์: JavaScript API ฝั่งไคลเอ็นต์แบบออนดีมานด์
หากตอนนี้คุณใช้ navigator.userAgent
อยู่ คุณควรเปลี่ยนไปใช้ navigator.userAgentData
ก่อน แล้วกลับไปแยกวิเคราะห์สตริง User Agent
if (navigator.userAgentData) {
// use new hints
} else {
// fall back to user-agent string parsing
}
หากต้องการตรวจหาอุปกรณ์เคลื่อนที่หรือเดสก์ท็อป ให้ใช้ค่าบูลีน mobile
ต่อไปนี้
const isMobile = navigator.userAgentData.mobile;
userAgentData.brands
เป็นอาร์เรย์ของออบเจ็กต์ที่มีพร็อพเพอร์ตี้ brand
และ version
ซึ่งเบราว์เซอร์แสดงรายการความเข้ากันได้กับแบรนด์เหล่านั้นได้ คุณเข้าถึงโมดูลนี้ในรูปแบบอาร์เรย์ได้โดยตรง หรือคุณอาจต้องใช้การเรียก some()
เพื่อตรวจสอบว่ามีรายการที่เฉพาะเจาะจงหรือไม่
function isCompatible(item) {
// In real life you most likely have more complex rules here
return ['Chromium', 'Google Chrome', 'NewBrowser'].includes(item.brand);
}
if (navigator.userAgentData.brands.some(isCompatible)) {
// browser reports as compatible
}
หากต้องการค่า User Agent ที่มีเอนโทรปีสูงค่าใดค่าหนึ่งต่อไปนี้ คุณจะต้องระบุค่าดังกล่าวและตรวจสอบผลลัพธ์ใน Promise
ที่แสดงผล ดังนี้
navigator.userAgentData.getHighEntropyValues(['model'])
.then(ua => {
// requested hints available as attributes
const model = ua.model
});
คุณยังอาจต้องการใช้กลยุทธ์นี้หากต้องการเปลี่ยนจากการประมวลผลฝั่งเซิร์ฟเวอร์ไปเป็นการประมวลผลฝั่งไคลเอ็นต์ เนื่องจาก JavaScript API ไม่จำเป็นต้องเข้าถึงส่วนหัวของคำขอ HTTP จึงสามารถขอค่า User Agent ได้ทุกเมื่อ
กลยุทธ์: ส่วนหัวฝั่งเซิร์ฟเวอร์แบบคงที่
หากใช้ส่วนหัวของคำขอ User-Agent
บนเซิร์ฟเวอร์และความต้องการข้อมูลนั้นมีความสอดคล้องกันทั่วทั้งเว็บไซต์ คุณอาจระบุคำแนะนำสำหรับไคลเอ็นต์ที่ต้องการเป็นชุดแบบคงที่ในคำตอบได้ ซึ่งเป็นวิธีที่ค่อนข้างง่ายเนื่องจากโดยทั่วไปแล้วคุณต้องกำหนดค่าในตำแหน่งเดียวเท่านั้น เช่น อาจอยู่ในการกำหนดค่าเว็บเซิร์ฟเวอร์หากคุณเพิ่มส่วนหัวไว้ที่นั่น การกำหนดค่าโฮสติ้ง หรือการกำหนดค่าระดับบนสุดของเฟรมเวิร์กหรือแพลตฟอร์มที่คุณใช้สำหรับเว็บไซต์
ลองใช้กลยุทธ์นี้หากคุณกำลังเปลี่ยนรูปแบบหรือปรับแต่งคำตอบที่แสดงตามข้อมูล User Agent
เบราว์เซอร์หรือไคลเอ็นต์อื่นๆ อาจเลือกให้คำแนะนำที่เป็นค่าเริ่มต้นที่แตกต่างกัน ดังนั้น แนวทางปฏิบัติที่ดีคือการระบุทุกอย่างที่คุณต้องการ แม้ว่าโดยทั่วไปจะมีคำแนะนำให้โดยค่าเริ่มต้นก็ตาม
ตัวอย่างเช่น ค่าเริ่มต้นปัจจุบันสำหรับ Chrome จะแสดงเป็นดังนี้
⬇️ ส่วนหัวการตอบกลับ
Accept-CH: Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA
หากต้องการได้รับรุ่นอุปกรณ์ด้วยการตอบกลับด้วย ให้ส่งข้อมูลต่อไปนี้
⬇️ ส่วนหัวการตอบกลับ
Accept-CH: Sec-CH-UA-Mobile, Sec-CH-UA-Model, Sec-CH-UA-Platform, Sec-CH-UA
เมื่อประมวลผลในฝั่งเซิร์ฟเวอร์ คุณควรตรวจสอบว่าได้ส่งส่วนหัว Sec-CH-UA
ที่ต้องการแล้วหรือไม่ จากนั้นสำรองไปยังการแยกวิเคราะห์ส่วนหัว User-Agent
หากไม่พร้อมใช้งาน
กลยุทธ์: การให้คําแนะนําเกี่ยวกับคําขอข้ามต้นทาง
หากคุณขอทรัพยากรย่อยแบบข้ามต้นทางหรือแบบข้ามเว็บไซต์ที่กำหนดให้ต้องส่งคำแนะนำของไคลเอ็นต์ User Agent ในคำขอ คุณต้องระบุคำแนะนำที่ต้องการให้ชัดเจนโดยใช้นโยบายสิทธิ์
ตัวอย่างเช่น สมมติว่า https://blog.site
โฮสต์ทรัพยากรใน https://cdn.site
ซึ่งสามารถแสดงผลทรัพยากรที่เพิ่มประสิทธิภาพสำหรับอุปกรณ์หนึ่งๆ ได้
https://blog.site
ขอคำแนะนำจาก Sec-CH-UA-Model
ได้ แต่ต้องมอบสิทธิ์ดังกล่าวให้กับ https://cdn.site
อย่างชัดแจ้งโดยใช้ส่วนหัว Permissions-Policy
รายการคำแนะนำที่ควบคุมโดยนโยบายจะอยู่ในฉบับร่างของคำแนะนำลูกค้า
⬇️ คำตอบจาก blog.site
ที่มอบสิทธิ์คำแนะนำ
Accept-CH: Sec-CH-UA-Model
Permissions-Policy: ch-ua-model=(self "https://cdn.site")
⬆️ ขอทรัพยากรย่อยใน cdn.site
รวมคำแนะนำที่มอบสิทธิ์มา
Sec-CH-UA-Model: "Pixel 5"
คุณระบุคำใบ้ได้หลายรายการสำหรับต้นทางหลายแห่ง ไม่ใช่เฉพาะจากช่วง ch-ua
ดังนี้
⬇️ คำตอบจาก blog.site
ที่มอบสิทธิ์หลายคำแนะนำให้ต้นทางหลายแห่ง
Accept-CH: Sec-CH-UA-Model, DPR
Permissions-Policy: ch-ua-model=(self "https://cdn.site"),
ch-dpr=(self "https://cdn.site" "https://img.site")
กลยุทธ์: การมอบสิทธิ์ให้กับ iframe
iframe แบบข้ามต้นทางทำงานในลักษณะเดียวกับทรัพยากรแบบข้ามต้นทาง แต่คุณระบุคำแนะนำที่ต้องการมอบสิทธิ์ในแอตทริบิวต์ allow
⬇️ คำตอบจาก blog.site
Accept-CH: Sec-CH-UA-Model
↪️ HTML สำหรับ blog.site
<iframe src="https://widget.site" allow="ch-ua-model"></iframe>
⬆️ ขอ widget.site
Sec-CH-UA-Model: "Pixel 5"
แอตทริบิวต์ allow
ใน iframe จะลบล้างส่วนหัว Accept-CH
ที่ widget.site
อาจส่งตัวเอง ดังนั้นโปรดตรวจสอบว่าคุณได้ระบุทุกอย่างที่เว็บไซต์ใน iframe ต้องการแล้ว
กลยุทธ์: คำแนะนำฝั่งเซิร์ฟเวอร์แบบไดนามิก
หากคุณมีส่วนที่เจาะจงของเส้นทางของผู้ใช้ซึ่งต้องการคำแนะนำที่หลากหลายมากกว่าส่วนอื่นๆ ในเว็บไซต์ คุณอาจเลือกขอคำแนะนำแบบออนดีมานด์แทนการเลือกคำแนะนำแบบตายตัวทั้งเว็บไซต์ วิธีนี้มีความซับซ้อนในการจัดการกว่า แต่ถ้าคุณตั้งค่าส่วนหัวที่แตกต่างกันในแต่ละเส้นทางไว้แล้ว ก็อาจเป็นไปได้
สิ่งสำคัญที่ต้องจำไว้คือ ส่วนหัว Accept-CH
แต่ละอินสแตนซ์จะเขียนทับชุดที่มีอยู่ได้อย่างมีประสิทธิภาพ ดังนั้น ถ้าคุณตั้งค่าส่วนหัวแบบไดนามิก แต่ละหน้าจะต้องขอคำแนะนำครบชุด
ตัวอย่างเช่น คุณอาจมีส่วนหนึ่งในเว็บไซต์ที่ต้องการให้แสดงไอคอนและการควบคุมที่ตรงกับระบบปฏิบัติการของผู้ใช้ ในกรณีนี้ คุณอาจต้องดึง Sec-CH-UA-Platform-Version
เพิ่มเติมเพื่อแสดงทรัพยากรย่อยที่เหมาะสม
⬇️ ส่วนหัวการตอบกลับสำหรับ /blog
Accept-CH: Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA
⬇️ ส่วนหัวการตอบกลับสำหรับ /app
Accept-CH: Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA-Platform-Version, Sec-CH-UA
กลยุทธ์: ต้องมีคำแนะนำฝั่งเซิร์ฟเวอร์ในคำขอแรก
อาจมีบางกรณีที่คุณต้องการคำแนะนำมากกว่าชุดเริ่มต้นของคำขอแรก แต่วิธีนี้อาจพบไม่บ่อยนัก ดังนั้นอย่าลืมตรวจสอบเหตุผล
คำขอแรกหมายถึงคำขอระดับบนสุดลำดับแรกสำหรับต้นทางที่ส่งในเซสชันการท่องเว็บ ชุดคำแนะนำเริ่มต้นประกอบด้วยชื่อเบราว์เซอร์พร้อมเวอร์ชันหลัก แพลตฟอร์ม และตัวบ่งชี้อุปกรณ์เคลื่อนที่ คำถามที่ต้องถามก็คือ คุณต้องการข้อมูลแบบขยายในการโหลดหน้าเว็บเริ่มต้นไหม
สำหรับคำแนะนำเพิ่มเติมเกี่ยวกับคำขอแรกจะมี 2 ตัวเลือก วิธีแรก คุณสามารถใช้ส่วนหัว Critical-CH
การดำเนินการนี้จะใช้รูปแบบเดียวกับ Accept-CH
แต่แจ้งเบราว์เซอร์ว่าควรลองส่งคำขออีกครั้งทันทีหากมีการส่งคำขอแรกโดยไม่มีคำแนะนำสำคัญ
⬆️ คำขอเริ่มต้น
[With default headers]
⬇️ ส่วนหัวการตอบกลับ
Accept-CH: Sec-CH-UA-Model
Critical-CH: Sec-CH-UA-Model
🔃 เบราว์เซอร์จะส่งคำขอเริ่มต้นอีกครั้งพร้อมส่วนหัวเพิ่มเติม
[With default headers + …]
Sec-CH-UA-Model: Pixel 5
ซึ่งจะทำให้เกิดค่าใช้จ่ายในการลองใหม่ในคำขอแรก แต่ค่าใช้จ่ายในการติดตั้งใช้งานค่อนข้างต่ำ ส่งส่วนหัวเพิ่มเติมแล้ว เบราว์เซอร์จะจัดการส่วนที่เหลือให้
สำหรับสถานการณ์ที่คุณต้องการคำแนะนำเพิ่มเติมจริงๆ เกี่ยวกับการโหลดหน้าเว็บครั้งแรก ข้อเสนอความน่าเชื่อถือของคำแนะนำไคลเอ็นต์จะแสดงเส้นทางเพื่อระบุคำแนะนำในการตั้งค่าระดับการเชื่อมต่อ ซึ่งทำให้การใช้ส่วนขยาย Application-Layer Protocol Settings(ALPS) เป็น TLS 1.3 เพื่อเปิดใช้การให้คำแนะนำล่วงหน้าในการเชื่อมต่อ HTTP/2 และ HTTP/3 ซึ่งยังอยู่ในช่วงเริ่มต้น แต่หากคุณจัดการ TLS และการตั้งค่าการเชื่อมต่อด้วยตนเองอย่างจริงจัง นี่จะเป็นโอกาสอันดีที่คุณจะมีส่วนร่วม
กลยุทธ์: การสนับสนุนเดิม
คุณอาจมีโค้ดเดิมหรือโค้ดของบุคคลที่สามในเว็บไซต์ที่อาศัย navigator.userAgent
รวมถึงส่วนของสตริง User Agent ที่จะถูกลดขนาดลง ในระยะยาวคุณควรวางแผนที่จะเปลี่ยนไปใช้การโทร navigator.userAgentData
ที่เทียบเท่ากัน แต่คุณมีวิธีแก้ปัญหาชั่วคราว
การเติมเงิน UA-CH เป็นไลบรารีขนาดเล็กที่ให้คุณเขียนทับ navigator.userAgent
ด้วยสตริงใหม่ที่สร้างขึ้นจากค่า navigator.userAgentData
ที่ขอได้
ตัวอย่างเช่น โค้ดนี้จะสร้างสตริง User Agent ที่มีคำแนะนำ "model" เพิ่มเข้ามา
import { overrideUserAgentUsingClientHints } from './uach-retrofill.js';
overrideUserAgentUsingClientHints(['model'])
.then(() => { console.log(navigator.userAgent); });
สตริงที่ได้จะแสดงรูปแบบ Pixel 5
แต่ยังคงแสดง 92.0.0.0
ที่ลดลง เนื่องจากไม่มีการขอคำแนะนำ uaFullVersion
Mozilla/5.0 (Linux; Android 10.0; Pixel 5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.0.0 Mobile Safari/537.36
การสนับสนุนเพิ่มเติม
หากกลยุทธ์เหล่านี้ไม่ครอบคลุมกรณีการใช้งานของคุณ โปรดเริ่มแลกเปลี่ยนความเห็นในที่เก็บ privacy-sandbox-dev-support แล้วเราจะสำรวจปัญหาของคุณไปด้วยกัน
รูปภาพโดย Ricardo Rocha ใน Unsplash