Activitate de înregistrare cu API-ul Web Beacon

API-ul Beacon este un API web bazat pe JavaScript pentru a trimite cantități mici de date de la browser la serverul web fără a aștepta un răspuns. În acest articol, vom analiza pentru ce poate fi util, ce îl face diferit de tehnicile familiare precum XMLHTTPRequest („Ajax”) și cum puteți începe să îl utilizați.

Dacă știți de ce doriți să utilizați deja Beacon, nu ezitați să treceți direct la secțiunea Noțiuni introductive.

Pentru ce este API-ul Beacon?

API-ul Beacon este folosit pentru a trimite cantități mici de date către un server fără a aștepta un răspuns . Ultima parte este critică și este cheia pentru care Beacon este atât de util - codul nostru nici măcar nu ajunge să vadă un răspuns, chiar dacă serverul trimite unul. Beacon-urile sunt special pentru trimiterea datelor și apoi uitarea de ele. Nu așteptăm un răspuns și nu primim un răspuns.

Gândește-te la asta ca la o carte poștală trimisă acasă când ești în vacanță. Puneți o cantitate mică de date pe el (un pic de „Mi-ar plăcea să fiți aici” și „Vremea a fost minunată”), le puneți în cutia poștală și nu vă așteptați la un răspuns. Nimeni nu trimite o carte poștală care să spună „Da, chiar mi-aș dori să fiu acolo, mulțumesc foarte mult!”

Pentru site-urile și aplicațiile moderne, există o serie de cazuri de utilizare care se încadrează foarte bine în acest model de trimitere și uitare.

Statistici de urmărire și date de analiză

Primul caz de utilizare care vine în minte pentru majoritatea oamenilor este analiza. Soluțiile mari, cum ar fi Google Analytics, ar putea oferi o imagine de ansamblu bună asupra lucrurilor precum vizitele în pagină, dar dacă am dori ceva mai personalizat? Am putea scrie ceva JavaScript pentru a urmări ceea ce se întâmplă într-o pagină (poate cum interacționează un utilizator cu o componentă, cât de departe a derulat sau ce articole au fost afișate înainte de a urma un CTA), dar apoi trebuie să trimitem acele date către server atunci când utilizatorul părăsește pagina. Beacon este perfect pentru asta, deoarece doar înregistrăm datele și nu avem nevoie de un răspuns.

Nu există niciun motiv pentru care să nu putem acoperi și felul de sarcini banale deseori gestionate de Google Analytics, raportând despre utilizatorul însuși și capacitatea dispozitivului și browserului său. Dacă utilizatorul are o sesiune conectată, puteți chiar lega acele statistici înapoi la o persoană cunoscută. Indiferent de datele pe care le adunați, le puteți trimite înapoi la server cu Beacon.

Depanare și înregistrare

O altă aplicație utilă pentru acest comportament este înregistrarea informațiilor din codul JavaScript. Imaginați-vă că aveți o componentă interactivă complexă pe pagina dvs. care funcționează perfect pentru toate testele dvs., dar ocazional eșuează în producție. Știți că eșuează, dar nu puteți vedea eroarea pentru a începe depanarea. Dacă puteți detecta o eroare în codul propriu-zis, puteți colecta diagnostice și puteți utiliza Beacon pentru a trimite totul înapoi pentru înregistrare.

De fapt, orice sarcină de înregistrare poate fi efectuată în mod util folosind Beacon, fie crearea de puncte de salvare într-un joc, colectarea de informații despre utilizarea caracteristicilor sau înregistrarea rezultatelor unui test multivariat. Dacă este ceva ce se întâmplă în browser despre care doriți să știe serverul, atunci Beacon este probabil un candidat.

Nu putem deja să facem asta?

Știu la ce te gândești. Nimic din toate astea nu este nou, nu-i așa? Am reușit să comunicăm de la browser la server folosind XMLHTTPRequest de mai bine de un deceniu. Mai recent, avem și API-ul Fetch, care face cam același lucru cu o interfață mai modernă bazată pe promisiuni. Având în vedere asta, de ce avem nevoie de API-ul Beacon?

Cheia aici este că, deoarece nu primim un răspuns, browserul poate pune în coadă cererea și o poate trimite fără a bloca execuția oricărui alt cod. În ceea ce privește browserul, nu contează dacă codul nostru încă rulează sau nu, sau unde trebuie să ajungă execuția scriptului, deoarece nu există nimic de returnat, poate doar să execute în fundal trimiterea cererii HTTP până când este convenabil să Trimite-l.

Acest lucru ar putea însemna să așteptați până când sarcina procesorului este mai mică sau până când rețeaua este liberă sau chiar să o trimiteți imediat dacă se poate. Important este că browserul pune în coadă semnalizatorul și returnează imediat controlul. Nu reține lucrurile în timp ce farul trimite.

Pentru a înțelege de ce este o problemă importantă, trebuie să ne uităm la cum și când sunt emise aceste tipuri de solicitări din codul nostru. Luați exemplul nostru de script de înregistrare a analizelor. Codul nostru poate stabili cât timp petrec utilizatorii pe o pagină, așa că devine esențial ca datele să fie trimise înapoi la server în ultimul moment posibil. Când utilizatorul pleacă să părăsească o pagină, dorim să oprim cronometrarea și să trimitem datele înapoi acasă.

De obicei, ați folosi fie evenimentul de unload , fie evenimentul beforeunload de descărcare pentru a executa înregistrarea. Acestea sunt declanșate atunci când utilizatorul face ceva de genul urmăririi unui link de pe pagină pentru a naviga. Problema aici este că codul care rulează pe unul dintre evenimentele de unload poate bloca execuția și poate întârzia descărcarea paginii. Dacă descărcarea paginii este întârziată, atunci încărcarea paginii următoare este, de asemenea, întârziată, astfel încât experiența se simte cu adevărat lentă.

Rețineți cât de lente pot fi solicitările HTTP. Dacă vă gândiți la performanță, de obicei, unul dintre factorii principali pe care încercați să-i reduceți este solicitările HTTP suplimentare, deoarece accesul în rețea și obținerea unui răspuns poate fi foarte lent. Ultimul lucru pe care vrei să-l faci este să pui acea lentoare între activarea unui link și începerea solicitării pentru pagina următoare.

Beacon ocolește acest lucru punând cererea în coadă fără blocare, returnând imediat controlul înapoi la scriptul tău. Browserul se ocupă apoi să trimită cererea în fundal fără blocare. Acest lucru face totul mult mai rapid, ceea ce face utilizatorii mai fericiți și ne permite cu toții să ne păstrăm locurile de muncă.

Noțiuni de bază

Deci înțelegem ce este Beacon și de ce l-am putea folosi, așa că haideți să începem cu un cod. Elementele de bază nu ar putea fi mai simple:

 let result = navigator.sendBeacon(url, data);

Rezultatul este boolean, true dacă browserul a acceptat și a pus cererea în coadă și false dacă a existat o problemă în a face acest lucru.

Folosind navigator.sendBeacon()

navigator.sendBeacon ia doi parametri. Prima este adresa URL la care să faceți cererea. Solicitarea este efectuată ca HTTP POST, trimițând orice date furnizate în al doilea parametru.

Parametrul de date poate fi într-unul din mai multe formate, toate dacă sunt preluate direct din API-ul Fetch. Acesta poate fi un Blob , un BufferSource , FormData sau URLSearchParams - practic oricare dintre tipurile de corp utilizate la efectuarea unei cereri cu Fetch.

Îmi place să folosesc FormData pentru datele cheie-valoare de bază, deoarece este simplu și ușor de citit.

 // URL to send the data to let url = '/api/my-endpoint'; // Create a new FormData and add a key/value pair let data = new FormData(); data.append('hello', 'world'); let result = navigator.sendBeacon(url, data); if (result) { console.log('Successfully queued!'); } else { console.log('Failure.'); }

Suport pentru browser

Suportul în browsere pentru Beacon este foarte bun, singurele excepții notabile fiind Internet Explorer (funcționează în Edge) și Opera Mini. Pentru cele mai multe utilizări, ar trebui să fie bine, dar merită testat pentru asistență înainte de a încerca să utilizați navigator.sendBeacon .

Este ușor de făcut:

 if (navigator.sendBeacon) { // Beacon code } else { // No Beacon. Maybe fall back to XHR? }

Dacă Beacon nu este disponibil și solicitarea dvs. este importantă, puteți reveni la o metodă de blocare, cum ar fi XHR. În funcție de public și de scop, ați putea alege să nu vă deranjați.

Un exemplu: timp de înregistrare pe o pagină

Pentru a vedea acest lucru în practică, să creăm un sistem de bază pentru a stabili cât timp rămâne un utilizator pe o pagină. Când pagina se încarcă, vom nota ora, iar când utilizatorul părăsește pagina, vom trimite ora de începere și ora curentă către server.

Deoarece ne pasă doar de timpul petrecut (nu de ora reală a zilei), putem folosi performance.now() pentru a obține un marcaj temporal de bază pe măsură ce pagina se încarcă:

 let startTime = performance.now();

Dacă ne încheiem conectarea într-o funcție, o putem apela atunci când pagina se descarcă.

 let logVisit = function() { // Test that we have support if (!navigator.sendBeacon) return true; // URL to send the data to, eg let url = '/api/log-visit'; // Data to send let data = new FormData(); data.append('start', startTime); data.append('end', performance.now()); data.append('url', document.URL); // Let's go! navigator.sendBeacon(url, data); };

În cele din urmă, trebuie să apelăm această funcție atunci când utilizatorul părăsește pagina. Primul meu instinct a fost să folosesc evenimentul de unload , dar Safari pe un Mac pare să blocheze solicitarea cu un avertisment de securitate, așa că înainte de beforeunload funcționează foarte bine pentru noi aici.

 window.addEventListener('beforeunload', logVisit);

Când pagina se descarcă (sau, chiar înainte de a se face) funcția noastră logVisit() va fi apelată și, cu condiția ca browserul să accepte API-ul Beacon, va fi trimis farul nostru.

(Rețineți că, dacă nu există suport pentru Beacon, revenim true și pretindem că totul a funcționat excelent. Dacă returnați false , evenimentul ar fi anulat și ar opri descărcarea paginii. Ar fi regretabil.)

Considerații la urmărire

Întrucât multe dintre utilizările potențiale ale Beacon se învârt în jurul urmăririi activității, cred că ar fi neglijent să nu menționăm responsabilitățile sociale și legale pe care le avem ca dezvoltatori atunci când înregistrăm și urmărim activitatea care ar putea fi legată de utilizatori.

GDPR

Ne putem gândi la recentele legi europene GDPR ca fiind legate de e-mail, dar, desigur, legislația se referă la stocarea oricărui tip de date personale. Dacă știți cine sunt utilizatorii dvs. și le puteți identifica sesiunile, atunci ar trebui să verificați ce activitate înregistrați și cum se leagă aceasta de politicile dvs.

Adesea, nu trebuie să urmărim atât de multe date pe cât ne spun instinctele dezvoltatorii. Poate fi mai bine să nu stocați în mod deliberat informații care ar identifica un utilizator, iar apoi vă reduceți probabilitatea de a greși lucrurile.

DNT: Nu urmăriți

Pe lângă cerințele legale, majoritatea browserelor au o setare pentru a permite utilizatorului să-și exprime dorința de a nu fi urmărit. Do Not Track trimite un antet HTTP cu cererea care arată astfel:

 DNT: 1

Dacă înregistrați date care pot urmări un anumit utilizator și utilizatorul trimite un antet DNT pozitiv, atunci cel mai bine ar fi să urmați dorințele utilizatorului și să anonimizați datele respective sau să nu le urmăriți deloc.

În PHP, de exemplu, puteți testa foarte ușor acest antet astfel:

 if (!empty($_SERVER['HTTP_DNT'])) { // User does not wish to be tracked ... }

În concluzie

API-ul Beacon este o modalitate cu adevărat utilă de a trimite date dintr-o pagină înapoi către server, în special într-un context de înregistrare. Suportul pentru browser este foarte larg și vă permite să înregistrați fără probleme datele fără a afecta negativ experiența de navigare a utilizatorului și performanța site-ului dvs. Natura neblocante a solicitărilor înseamnă că performanța este mult mai rapidă decât alternative precum XHR și Fetch.

Dacă doriți să citiți mai multe despre API-ul Beacon, următoarele site-uri merită să vă uitați.

• „Specificația W3C Beacon”, recomandarea candidatului W3C
• „Documentația MDN Beacon”, documente web MDN, Mozilla
• „Informații de asistență pentru browser”, caniuse.com