Hoe MousePlayer werk
'n Eenvoudige gids tot ons nasporingsargitektuur, die hantering van skermresolusies oor toestelle en stelselgrense.
1. Waarom ons nie video opneem nie
'n Algemene wanopvatting is dat visuele ontledingshulpmiddels gewone videolêers (soos MP4 of WebM) van 'n besoeker se skerm opneem. Dit sou enorme bandwydte gebruik, u webwerf aansienlik vertraag en vae, onleesbare teks skep.
MousePlayer gebruik eerder 'n liggewig tegnologie bekend as DOM-kiekietelemetrie. Só werk dit op grondvlak:
Die bloudrukkiekie
Wanneer 'n besoeker u bladsy oopmaak, neem ons skrip 'n teksgebaseerde “bloudruk” van u HTML- en stylstruktuur. Dit teken aan waar elemente is sonder om u bladsy se beeld- of videolêers te kopieer; die speler laai beelde tydens herspeling vanaf hul oorspronklike adres. Die uitsondering is canvas-elemente, waarvan die inhoud as beeld oorgedra word (sien hieronder).
Koördinaattelemetrie
Tydens interaksie neem ons 'n stroom gebeure op: muisposisies, roldiepte, klikteikens en blaaiervenstergroottes, asook veranderinge aan die bladsy self en, volgens die instellings, konsoleboodskappe, mislukte of stadige versoeke en laaitydmetings (Web Vitals). Bewegings en klikke is klein; bladsykiekies en -veranderinge kan volgens die bladsy aansienlik groter wees en word saamgepers oorgedra.
Die teaterherspeling
Wanneer u 'n sessie in u kontroleskerm kyk, herskep ons speler die bladsy met die opgeneemde bloudruk en beweeg 'n virtuele wyser intyds daaroor, met kristalhelder teks.
Ontwerp om lig te bly: die skrip laai asinchronies en stuur klein numeriese datapunte in plaas van video, wat sy eie impak klein hou. Wat dit vir u Core Web Vitals beteken, hang van u bladsye, gasheer en die besoeker se netwerk af; meet dit dus op u eie webwerf eerder as om 'n syfer van ons te aanvaar. Geen bepaalde laaispoed word gewaarborg nie – sien afdeling 20 van die diensvoorwaardes.
2. Skermresolusies & mobiele toestelle
Vandag se gebruikers blaai op alles van kompakte slimfone tot ultrawye 4K-rekenaarskerms. Webwerwe skuif, vou en herrangskik hul uitlegte outomaties vir verskillende skermbreedtes — bekend as aanpasbare webontwerp.
Hoe ons by die besoeker se presiese sigbare gebied pas
Om vervorming in herspeling te voorkom, teken MousePlayer die besoeker se presiese afmetings van die sigbare gebied aan (bv. 390x844 vir 'n slimfoon of 1920x1080 vir 'n rekenaarskerm). Wanneer u die teaterspeler oopmaak, skep ons enjin 'n geskaalde afsonderlike omgewing wat die oorspronklike skermverhouding presies weerspieël.
Rekenaar- & skootrekenaarskerms
Op gewone rekenaars neem ons deurlopende muisbeweging en navigasie oor oortjies binne dieselfde blaaiersessie op. Sweefkieslyste verskyn in herspeling wanneer die bladsy sy dokument daarvoor verander; 'n suiwer CSS-sweefeffek is nie in die dokument sigbaar nie en word nie herskep nie.
Slimfone & tablette
Raakskerms het geen swewende muiswyser nie. MousePlayer pas outomaties aan deur tikgebare, veegrolbewegings en oriëntasieveranderings (portret teenoor landskap) op te neem.
Die uitdaging van grootteverandering tydens 'n sessie
As 'n besoeker 'n tablet draai of 'n blaaiervenster tydens 'n sessie vergroot of verklein, verander die webwerfuitleg dinamies. MousePlayer neem hierdie venstergroottegebeure op en pas die afspeeloppervlak naatloos dadelik aan om die interaksiekonteks te behou.
3. Stelsellimiete & tegniese grense
Om gebruikersprivaatheid te respekteer, blaaiersekuriteit te handhaaf en dataverwerking vinnig te hou, werk MousePlayer binne bepaalde tegniese grense:
| Stelselgrens | Hoe MousePlayer dit hanteer |
|---|---|
| iFrames | iframes van dieselfde oorsprong as u bladsy word saam met hul inhoud en interne interaksies opgeneem. Ingebedde inhoud van 'n ander oorsprong (bv. YouTube-spelers, Stripe-betaalvorms) kan weens blaaiersekuriteitsbeleide (Same-Origin Policy) nie intern opgeneem word nie; dit verskyn as plekhouer in herspeling en word nie daar gelaai nie. |
| Sensitiewe invoervelde (PII) | Wagwoord- en betaalvelde word op elke maskeringsvlak op die besoeker se toestel gemasker en volledige maskering van alle vorminvoer is die verstek vir elke webwerf. U sien dat daar getik is, nie wat nie. Twee grense geld: die twee swakker vlakke vereis ons skriftelike goedkeuring en maskering bereik nooit wat u eie bladsy in die dokument druk nie – 'n bevestigingsbladsy met 'n adres is deel van die kiekie. Albei word uiteengesit in die DPA. |
| Canvas- & WebGL-elemente | Canvas-inhoud word as beeld opgeneem: een keer met die bladsykiekie en weer wanneer dit verander, hoogstens ongeveer een keer per sekonde en met 'n groottelimiet. Gladde animasies verskyn dus as 'n reeks rame. Geen beeld word uit gemaskerde areas of canvas-elemente met beelde van 'n ander oorsprong gestuur nie; WebGL-inhoud kan leeg bly. |
| Webkomponente (Shadow DOM) | Oop shadow roots word met hul inhoud opgeneem. Geslote shadow roots is ontoeganklik vir skripte; hul inhoud ontbreek in herspeling. |
| Oordrag & blaaierberging | Data word oor 'n geënkripteerde WebSocket-verbinding (HTTPS/WSS) gestuur. As dit nie gevestig kan word nie, byvoorbeeld weens 'n instaanbediener, gebruik die skrip 'n geënkripteerde HTTP-roete; baie groot bladsykiekies word apart oor HTTPS opgelaai. MousePlayer stel geen koekies nie; dit gebruik die blaaier se plaaslike berging en sessieberging op u webwerf. |
| Onaktiewe AFK-tydperke | As 'n besoeker 'n oortjie oop laat en 20 minute wegloop, bespeur ons enjin onaktiwiteit outomaties en verkort die stil gaping tydens herspeling, sodat u nie tyd op statiese skerms mors nie. |