იზომე ორივე ლაბორატორიული და ველის მონაცემებით — ისინი სხვადასხვა კითხვას პასუხობენ. Lighthouse არის ლაბორატორია (სინთეზური, გამეორებადი, debug-ისთვის); RUM არის ველი (რეალური მომხმარებლები, ჭეშმარიტებისთვის). თუ მხოლოდ ერთს ენდობი, არასწორ რამეს ოპტიმიზირებ.
| ლაბორატორია (Lighthouse) | ველი / RUM |
|---|
| წყარო | ერთი სინთეზური გაშვება, ფიქსირებული მოწყობილობა/ქსელი | რეალური ვიზიტები, ყველა მოწყობილობა/ქსელი |
| კარგია | debug-ისთვის, CI regression gate-ებისთვის, გამეორებადი | რას ნამდვილად განიცდიან მომხმარებლები |
| INP | ვერ იზომება (რეალური ინტერაქციები არ არის) | იზომება მთელი ვიზიტის განმავლობაში |
| სისუსტე | არ ასახავს შენს რეალურ ტრაფიკს | ხმაურიანი, მოცულობა სჭირდება, უფრო რთული debug |
Lighthouse უშვებს ერთ throttle-ულ ჩატვირთვას სუფთა მანქანაზე — შესანიშნავია პრობლემის რეპროდუცირებისთვის, უსარგებლო შენი p75-ის ცოდნისთვის. განსაკუთრებით INP მხოლოდ ველში შეიძლება დაფიქსირდეს, რადგან მას რეალური ინტერაქციები სჭირდება სესიის განმავლობაში.
import { onLCP, onCLS, onINP } from "web-vitals";
function send(metric) {
// Attribution build tells you WHICH element/interaction caused it
navigator.sendBeacon("/rum", JSON.stringify({
name: metric.name, value: metric.value, id: metric.id,
}));
}
onLCP(send); onCLS(send); onINP(send); // report each metric as it finalizes
ეს არის იგივე მეთოდოლოგია, რასაც Google-ის CrUX (Chrome User Experience Report), რომელიც Search რანჟირებას კვებავს — CrUX არის რეალური მომხმარებლის p75, არა ლაბორატორია.
senior სიგნალი არის ცოდნა, რომ ლაბორატორია ≠ ველი, რომ რანჟირება ველის p75-ს იყენებს და რომ INP მხოლოდ ველშია რეალური. Lighthouse ქულის ოპტიმიზაცია, სანამ რეალური p75 ცუდი რჩება, კლასიკური ხაფანგია, რომლის გამოსავლენადაც არის ეს კითხვა შედგენილი.
IT გასაუბრების კითხვების ბიბლიოთეკა დეტალური პასუხებით — Junior-დან Senior-მდე.
შემოწირულობა