I asked my friend in UK who has very high speed broadband, to check the page load time
Questo non è il modo giusto per misurare le prestazioni. Non può essere automatizzato, non è una metrica precisa, non può essere riprodotto in modo affidabile ed è intrinsecamente soggettivo. Il modo giusto è:
-
Determina i requisiti non funzionali che specificano il rendimento previsto per il rendering della pagina in condizioni rigorose.
-
Chiedi a te stesso se hai problemi di prestazioni, ad esempio se questi requisiti non funzionali non corrispondono al codice effettivo.
-
Se è in realtà un problema con le prestazioni, esegui un profiler per determinare il collo di bottiglia. La maggior parte dei browser ne ha uno, mostrando i dettagli di ciò che sta realmente accadendo. Se l'elaborazione JavaScript richiede 1 300 ms. e l'elaborazione CSS - 25 ms., non interessa il CSS in questo momento.
-
Se hai trovato, in base ai benchmark e al profiler, che la differenza tra il tempo di rendering previsto (specificato nei requisiti) e il tempo effettivo testato è dovuto ai CSS, quindi utilizzare diverse tecniche per ottimizzare il tuo CSS. La documentazione di Google è un buon inizio.
Ecco un test fatto sulla home page di Programmers.SE. Il profilo del selettore CSS ha impiegato 59 ms. con i seguenti dettagli:
Selector Total Matches Source
―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
.widget_ad_rotator, .widget_adrotate_widgets, .widget_ads [...] 57.6% 0
html, body, div, span, applet, object, iframe, h1, h2, h3 [...] 11.9% 3862 all.css
a:-webkit-any-link 5.1% 913
:focus 3.4% 0
input[type=button], input[type=submit], input[type=reset] [...] 3.4% 4
div 3.4% 2101
.badge:hover 1.7% 0 all.css
a:visited 1.7% 913 all.css
Come puoi vedere, la maggior parte della perdita di prestazioni deriva dal fatto che sto utilizzando un blocco di aggiunta nel mio browser. Questo fa schifo, dal momento che non voglio bloccare gli annunci su Stack Exchange. Ora che ho autorizzato lo Stack Exchange, il tempo del selettore CSS è passato da 59 ms. fino a 23 ms.
Il secondo selettore più costoso è uno globale che assume elementi identificati dai loro nomi di tag. Questo è costoso dato il numero di partite, e probabilmente non c'è nulla che si possa fare per ottimizzarlo, senza essere troppo ferito dalle incoerenze del browser.
I prossimi quattro sono relativi a Webkit, non al CSS scritto per la pagina web.
A partire dal settimo selettore, la percentuale è troppo bassa per preoccuparsi. Quello attuale, .badget:hover
, non è usato, ma rimuoverlo su questa pagina mentre è usato su altri dovrebbe creare codice difficile da mantenere, e in particolare rappresenterebbe un guadagno inferiore a 100 microsecondi.
Dalla mia esperienza (di uno sviluppatore che lavora solo su applicazioni web di piccole e medie dimensioni, e non sulle app a cui si accede migliaia di volte al secondo), ciò di cui si dovrebbe occuparsi è la complessità dei CSS. Selettori come:
body.en-us div#sidePanel.moveable div:first-child input[type=submit]:hover,
*.lang.en-us div#sidePanel.moveable div:first-child input[type=submit]:hover {
color:#59a;
}
sono illeggibili per gli sviluppatori e lenti per i browser. Evitare la caratteristica di insinuarsi nel sito Web e semplificare gli stili in:
#sidePanel .top-submit:hover {
color:#59a;
}
vale la pena. Allo stesso modo:
.style {
background-color: #000000;
background-image: url('im/fade.jpg');
background-repeat: repeat-x;
background-position: top left;
}
da:
.style {
background: #000 url(im/fade.jpg) repeat-x top;
}
non è troppo difficile e in gran parte semplifica la manutenzione (consulta anche la Guida di stile CSS di Google ).
Ma non impiegherei ore a rimuovere il 20% degli stili solo perché non sono usati, per guadagnare qualche millisecondo. Soprattutto quando si utilizza LESS / Sass.