Controlul vitezei de reacție a site-ului

Controlul vitezei de reacție a site-ului

Această problemă este cunoscută de foarte mult timp, iar producătorii au încercat să o lupte. Microsoft a oferit un atribut de amânare pentru eticheta de script. Cu acest atribut, dezvoltatorul poate promite browser-ului că în acest script document.write nu va fi folosit. Cu toate acestea, suportul său pentru diferite browsere este lame. Pe Internet despre el diferite opinii, dar în funcție de sentimentele mele, guru-ul este sfătuit să nu se bazeze pe el.







O altă opțiune posibilă în această situație este să cacheți cumva pe pagină și, după încărcarea scripturilor, să procesați memoria cache.

Pe aceasta voi termina pagina de redare. Să începem inițializarea scripturilor.

Punctul principal pe care vreau să transmit în această secțiune este simplu: în timpul paginii de inițializare ar trebui să efectueze acțiunile minime necesare.

Necesitatea poate fi înțeleasă destul de larg. În primul rând, voi da câteva exemple de neînțelegeri, voi da "sfaturi dăunătoare".

Cel mai obișnuit caz este de a procesa mai multe elemente la momentul încărcării. De exemplu, închideți toate legăturile de pe dispozitivul de gestionare a paginilor. Sau treceți prin nodurile de text și aplicați fiecărei tipografii. Cu primul este legat inextricabil de al doilea: crește cantitatea de reflow pentru pagină prin toate mijloacele. Va fi potrivit să plasați dinamic o pictogramă după fiecare legătură, așa cum face SnapShots.com. Un alt exemplu: creați o rezervă de dom-obiecte care pot veni la îndemână. Apoi, dacă este necesar, acestea vor fi pur și simplu afișate, iar codul dvs. va fi neted și matasos.

Iar acum luați serios în considerare sursele de probleme normale de performanță atunci când încărcați o pagină. Cel mai neplăcut lucru pe care trebuia să-l confrunt la această etapă este legătura dintre agenți de manipulare. În versiunea clasică, această acțiune implică recuperarea unei liste de articole ale căror evenimente vor fi procesate și le va pune la dispoziția acestora. Chiar și în acest algoritm simplu există două locuri care pot fi îmbunătățite în mod serios: aceasta este viteza de căutare a elementelor dorite și viteza de procesare a acestora.

Aproximativ un an și jumătate în urmă a existat o mică bibliotecă, probabil chiar o extindere a prototype.js, numită behavior.js. A permis ca mai mulți selectori CSS avansați să fie utilizați pentru a atribui elemente de manipulare elementelor. Adică, a făcut aproape același lucru, pentru care jQuery este acum adesea folosit. Ideea a fost foarte interesantă și convenabilă. Cu toate acestea, în ciuda tuturor frumuseții, această bibliotecă aproape că nu era potrivită pentru utilizare. Principala problemă a fost, ca de obicei, cu browserul iubit popular: atunci când descărca fiecare pagină, aproape a suspendat computerul pentru câteva secunde. Rădăcina răului a intrat în căutarea elementelor.

Această opțiune este utilizarea de agenți de procesare la nivel mondial. Permiteți-mi să vă reamintesc că majoritatea evenimentelor "apar" până la arborele dom la elementul rădăcină. A fost acolo că acestea pot fi detectate și procesate utilizând evenimentele srcElement de proprietate țintă și pentru a identifica sursa evenimentului.







Ce avantaje ne oferă această abordare? În primul rând, scăpăm de necesitatea de a căuta elemente care să le atragă agenți de procesare a evenimentelor, deoarece documentul este mereu la îndemână în obiectul global. În plus, procesăm doar un singur element, nu zeci. Un alt plus, care este rar, dar foarte frumos se manifestă, este procesarea automată a elementelor create chiar dinamic. Imaginați-vă cum ar trebui să acționați fără a utiliza această abordare: fiecare metodă care creează elemente ar trebui să cunoască persoanele care pot fi atârnate de acest element sau să utilizeze soluții arhitecturale complexe. În cazul unui handler global, totul se întâmplă automat.

Da, dezavantajele abordării pot fi atribuite faptului că pentru fiecare acțiune a utilizatorului sunt efectuate mai multe operații. Cu alte cuvinte, sarcina pe procesor este transferată de la inițializarea paginii la clicurile și mișcările mouse-ului. Pentru proiectul dvs., aceasta poate să nu fie decizia corectă, dar cred că este cea mai bună în majoritatea cazurilor.

Folosind astfel de tactici, realizăm că atunci când se încarcă pagina, există într-adevăr un număr minim de acțiuni: mai mulți manipulatori sunt atârnați pe document, asta-i tot.

Teoretic, poți îmbunătăți comportamentul.js sau jQuery în așa fel încât să folosească agenți de manipulare globali, dar până acum nu știu despre astfel de proiecte.

În acest sens, conversația despre inițializare poate fi terminată și se poate trece la rata de reacție a elementelor de pagină. Cele mai frecvente evenimente pentru procesare sunt hover and click. Să începem cu clic.

Există o modalitate foarte simplă de a accelera răspunsul pentru a face clic pe 100-200 milisecunde. Pentru a face acest lucru, pur și simplu utilizați evenimentul "mousedown" în loc de evenimentul clic. Dar, ca de obicei, când câștigăm timp, pierdem altceva. În acest caz, sacrificăm posibilitatea utilizatorilor avansați de a schimba soluția deja după ce au făcut clic pe butonul - în cazul utilizării clicului, ei ar putea să ia mouse-ul în partea laterală. Depinde de dvs. dacă sunteți gata să faceți acest lucru de dragul vitezei.

Imaginați-vă că aveți pe pagină un meniu vertical vertical, construit pe css-hover, și navigați cu mouse-ul deasupra acestuia, ducându-l la butonul "înapoi". Toate elementele de meniu lucrează la rândul lor, iar diferite submeniuri se aprind foarte vizibil pe pagină. E distractiv și asta e rău. Un alt neajuns poate fi ilustrat și cu un meniu drop-down. Aceasta se datorează faptului că acuratețea acțiunilor umane este mică. Și tehnologia trebuie să rezolve această problemă.

Deci, aici este un exemplu primitiv al meniului. Vreau să redeschid noul document creat. După ce am indicat mouse-ul la punctul "Ultim" și am văzut submeniul, mișcarea cea mai naturală pentru mine ar fi să mișc cursorul mouse-ului direct în țintă. Desigur, în cea mai simplă implementare, nu va funcționa pentru mine de îndată ce cursorul este peste elementul "Ieșire", submeniul dispare. Abordarea "corectă" în acest caz este să țineți mouse-ul pe orizontală în submeniu și apoi să îl mutați în jos. Deoarece lățimea meniului principal poate fi mare, iar înălțimea liniei este mică, această sarcină nu este simplă.

Am definit metoda delayedHover () pentru dom-objects. Pe plan intern, utilizează metoda mai generală a funcțiilor getDelayedHandlers (). pe care l-am determinat de asemenea. Mai întâi, luați în considerare o întârziere mai simplă (). Acesta primește trei parametri: obiectul real dom, funcția de manipulare și setările de întârziere. Există într-adevăr câteva linii înăuntru: numim getDelayedHandlers () a funcției de manipulare și îi atribuim metodele de la obiectul dom pentru mouseover / mouseout. Aceste metode se blochează de la declanșare. De exemplu, dacă mouseout se întâmplă imediat după trecerea mouse-ului, mânerul mouseover nu va executa. Și invers.

Luați în considerare modul de realizare a acestui comportament. Metoda getDelayedHandlers () declară două funcții simetrice. Fiecare dintre ele resetează mai întâi timpul de expirare la celălalt și apoi creează timpul de expirare propriu. Prin timeout, funcția principală se numește fie cu adevărat, fie cu falsă.

Și acum - un exemplu de folosire a unei "mișcări lente". Trebuie să arătăm un indiciu pentru un element. Definiți o funcție care, în funcție de parametru, afișează sau ascunde un indiciu. După aceea, sunăm metoda butonului delayedHover. și să-i dați parametrii acestei setări de funcție și de timp. Acum, promptul va apărea cu o întârziere de 200 ms și va dispărea cu o întârziere de 100 ms.







Articole similare

Trimiteți-le prietenilor: