Sunt în pragul optimizării vitezei site-ului. Am un site care primește note groaznice de la toți suspecții obișnuiți (în special PageSpeed și GT Metrics; arată OK pe instrumentele Pingdom).
Configurația mea este un singur server T3-Medium care rulează Apache și Wordpress, în spatele unui AWS ELB, cu implementare în CloudFront ca CDN.
Primele mele încercări de a îmbunătăți performanța au inclus
- actualizat la mediu (serverul rulează aproximativ 1/2 duzină de site-uri web, dar sunt mici – traficul colectiv în toate acestea este de doar câteva mii de vizite pe zi – cu toate acestea, o instanță „mică” a fost prea lent chiar și la o singură lovitură, din cauza constrângerilor de memorie),
- a instalat pluginul WP Super Cache (am rulat deja în spatele CloudFront, dar am instalat pluginul pentru a stoca în cache paginile în sine)
- S-au adăugat anteturi de control cache la comportamentul CloudFront
- S-au eliminat șirurile de interogare din cheia de cache (acesta nu este un site tradițional de comerț electronic, iar anunțurile Twitter adăugau un șir unic per utilizator, ceea ce, practic, făcea ca fiecare vizualizare a paginii să fie ratată de cache)
Cu toate acestea, chiar și cu asta, performanța implicită este inacceptabilă. Vinovatul pare să fie livrarea (și execuția) javascript-ului. Iată câteva rezultate de la GT Metrics, bazate pe cât de multă intervenție manuală efectuez:
Cache-Miss Cache-Hit Cache-Miss Cache-Hit Cache-Miss Cache-Hit
Default Default Hammer YouTube Hammer Youtube Baros Hammer Baros Hammer
TTFB 1.100 91 75 66 75 72 | 74 74 122 74 54 75 | 76 86 104 86 63 45
FCP 2.200 1.100 4.200 494 519 383 | 1.100 2.700 1.400 710 415 622 | 1.200 1.200 1.200 388 338 256
LCP 3.300 2.000 6.300 1.900 1.700 1.800 | 1.800 3.500 2.000 2.700 881 1.600 | 1.900 2.000 2.500 684 617 490
Încărcare 4.600 3.200 7.600 2.300 3.000 2.700 | 2.900 4.900 2.700 3.100 1.500 2.500 | 2.000 2.000 2.400 766 824 489
TTI 4.700 3.300 7.600 2.500 2.900 3.200 | 3.000 8.000 2.800 3.400 1.700 3.000 | 8.000 6.800 1.200 6.700 6.700 6.400
După cum puteți vedea, dacă nu fac nimic (primele două, subtabele „implicite”), site-ul durează aproape 3 secunde să se încarce cu o accesare în cache și, adesea, la nord de 4, la o pierdere de cache.
Aceasta este cu adevărat rădăcina întrebării. Ce ar trebui să fac de aici? Voi descrie mai jos ceea ce fac acum, dar nu cred că ceea ce voi descrie este o practică standard pe Internet și, în mod clar, Internetul nu suferă, în general, de pe urma acestui tip de performanță. .
Aplicarea unui baros
Nu sunt sigur care dintre aceste valori contează cel mai mult din perspectiva experienței utilizatorului, dar bănuiesc că în cazul meu este LCP și onload (îmi pot imagina că pentru unele site-uri web este TTI, dar în cazul meu nu e nimic de făcut deasupra foldului, deci vechea măsurătoare First CPU Idle ar fi fost grozavă, dacă Lighthouse ar fi raportat-o în continuare).
Ceea ce fac acum este ceea ce am în secțiunea „Sledge Hammer” a tabelului. Am scris un script care elimină toate etichetele javascript src neesențiale și le pune înapoi numai după 5 secunde sau după prima interacțiune a utilizatorului. Puteți vedea rezultatele. Chiar și într-o pierdere a memoriei cache, site-ul se încarcă în aproximativ 2 secunde, iar la o accesare în cache, este cu mult sub 1 secundă (putem ignora numărul TTI, deoarece aceasta este întârzierea mea de 5 secunde și nu afectează mai sus- aspectul pliului sau interactivitatea).
OK, site-ul „funcționează”, dar într-adevăr, nu numai că se pare că nu ar trebui să facă asta în abstract, dar există și niște javascript pe care mi-ar plăcea foarte mult să funcționeze de la început.
Săpând, toate problemele par să fie JavaScript terță parte (adică, lucruri care nu sunt/nu pot fi pe CDN-ul meu). Unele dintre acestea sunt pur și simplu flagrante și mă pot descurca în interior (de exemplu, pot spune oamenilor de marketing: „Folosiți HotJar doar când aveți nevoie, apoi dezactivați-l â adaugă o secundă completă la încărcarea paginii timp"). Dar unele dintre ele sunt doar „standard de internet” – Stripe și Google Analytics adaugă fiecare aproximativ 500 ms între timpul de încărcare și timpul de rulare.
Pot continua să-mi ajustez barosul, așa cum a sugerat Tim în comentarii, dar acest lucru încă nu mi se pare corect. Trebuie să fie ceva ce îmi lipsește în ceea ce privește această configurare și JavaScript (în special terți).
