Scelta di selettori efficienti in base alla complessità computazionale

Question

Considerati i dettagli di elaborazione CSS, in particolare RTL matching e selector efficiency, in che modo i selettori dovrebbero essere scritti puramente dal punto di vista delle prestazioni del motore di rendering?

Questo dovrebbe riguardare aspetti generali e includere l'utilizzo o l'evitamento di pseudo-classi, pseudo-elementi e selettori di relazione.

Answer 1

In fase di esecuzione, un documento HTML viene analizzato in un albero DOM contenente elementi N con una profondità media D. C'è anche un totale di S regole CSS nei fogli di stile applicati.

1. stili Elementi sono applicati singolarmente significato v'è una relazione diretta tra N e complessità generale. Degno di nota, questo può essere in qualche modo compensato dalla logica del browser come la cache di riferimento e gli stili di riciclaggio da elementi identici. Ad esempio, le seguenti voci di elenco avranno le stesse CSS applicate (supponendo che non pseudo-classi come :nth-child vengono applicati):

   <ul class="sample"> 
       <li>one</li> 
       <li>two</li> 
       <li>three</li> 
   </ul> 
   

2. selettori sono abbinati destra a sinistra per singoli norma di ammissibilità - cioè se la chiave più a destra non corrisponde a un particolare elemento, non è necessario elaborare ulteriormente il selettore e viene scartato. Ciò significa che la chiave più adatta dovrebbe corrispondere al minor numero possibile di elementi. Sotto, il descrittore p corrisponderà più elementi compresi i punti fuori del contenitore di destinazione (che, ovviamente, non avrà applica la regola, ma ancora provocherà più iterazioni di ammissibilità controllo per quel particolare selettore):

   .custom-container p {} 
   .container .custom-paragraph {} 
   

3. Selettori di relazioni: Il selettore di discendenti richiede fino a D elementi da iterare su. Ad esempio, l'abbinamento corretto con .container .content può richiedere solo un passaggio se gli elementi si trovano in una relazione padre-figlio, ma l'albero DOM dovrà essere spostato fino a html prima che un elemento possa essere confermato in una mancata corrispondenza e la regola venga scartata in modo sicuro . Questo vale anche per i selettori discendenti incatenati, con alcune indennità.

   D'altra parte, un selettore > bambino, un + adiacente selettore o :first-child richiedono ancora un ulteriore elemento da valutare ma hanno solo una profondità implicita di uno e non potrà mai richiedere ulteriore attraversamento di alberi.

4. La behavior definition di pseudo-elementi come :before e :after implica che non fanno parte del paradigma RTL. La logica è che non ci sono pseudo elementi di per sé fino a quando una regola non impone che venga inserita prima o dopo il contenuto di un elemento (che a sua volta richiede una manipolazione DOM extra ma non è necessario alcun calcolo aggiuntivo per corrispondere al selettore stesso).

5. Non sono riuscito a trovare alcuna informazione su pseudo-classi come :nth-child() o :disabled. La verifica di uno stato di un elemento richiederebbe un calcolo aggiuntivo, ma dal punto di vista dell'analisi delle regole sarebbe opportuno escluderli dall'elaborazione RTL.

Dato queste relazioni, complessità computazionale O(N*D*S) deve essere abbassata principalmente minimizzando la profondità di selettori CSS e indirizzamento punto 2. Ciò si tradurrà in miglioramenti quantificabili più forti rispetto alla riduzione al minimo del numero di regole CSS o di elementi HTML da solo^

I selettori superficiali, preferibilmente su un livello, vengono elaborati più rapidamente. Questo è preso ad un livello completamente nuovo da parte di Google (a livello di codice, non a mano!), Per esempio, raramente v'è un selettore a tre tasti e la maggior parte delle regole nei risultati di ricerca sembrano

#gb {} 
#gbz, #gbg {} 
#gbz {} 
#gbg {} 
#gbs {} 
.gbto #gbs {} 
#gbx3, #gbx4 {} 
#gbx3 {} 
#gbx4 {} 
/*...*/ 

^- mentre questo è vero dal punto di vista delle prestazioni motore di rendering, ci sono sempre altri fattori quali il traffico aereo e DOM analisi ecc

Fonti: 12345