2010-11-04 14 views
10

In jQuery ogni volta che incontro qualcosa di simile:CSS e jQuery selettore di velocità

$("div#MyDiv")..... 

Io generalmente dico sviluppatore: "Non preoccupatevi mettere il div davanti #MyDiv, selettori ID sono i più veloci. " Cioè

$("#MyDiv").... 

Ciò è perché quest'ultimo collegare direttamente document.getElementById invece di dover eseguire la scansione del DOM per tutti <div> primi elementi.

La mia domanda è: le stesse regole si applicano ai selettori CSS? Cioè piuttosto che:

div#MyDiv 
{ 
} 

E 'più veloce per avere semplicemente ?:

#MyDiv 
{ 
} 

(mi rendo conto che i selettori CSS sono incredibilmente veloci in ogni caso, quindi in realtà non sarebbe fare una differenza significativa.)

Molte grazie

EDIT

Qualsiasi collegamento o riferimento potrebbe essere utile ai fini di questa discussione. Grazie :-)

+0

Considerare il caso di: $ ("... ..."). Find ("# foo"). Ahia. All'improvviso le affermazioni sono passate attraverso il tetto (non sono consapevole di come questo caso funzionerebbe comunque). Comunque, * le due regole CSS sopra hanno una precedenza diversa * (la forma si è qualificata con il tag sempre leggermente più alto). –

+0

@ pst - Non sono sicuro che io segua. Puoi espandere? –

+0

Considera il caso in cui gli elementi non sono ancora allegati al documento. (Come * fa * jQuery gestire questo? Non correlato alla domanda finale però.) –

risposta

11

direi che è estremamente improbabile che fa alcuna differenza del mondo reale. In teoria, sì, è richiesto un numero inferiore di controlli (poiché lo standard div#foo deve corrispondere a div per corrispondere al selettore, in base a the spec). Ma le probabilità di fare una vera differenza in un'app browser reale? Vicino allo zero

Detto questo, io sempre rabbrividisco quando vedo cose come div#foo in applicazioni HTML. HTML ha solo un attributo di tipo ID (id), quindi non è necessario per l'ulteriore qualifica. Fai in modo che il motore di selezione CSS (del browser o di jQuery) lavori di più per capire cosa intendi, rendi il selettore fragile (se lo div diventa un footer, ad esempio), ecc.e, naturalmente, do lasciati aperti a un'implementazione di selettivamente non riuscendo a riconoscere che può cercare qualcosa per ID e quindi controlla se è un div e così va a cercare tra tutti i div s. (Esiste una tale implementazione? Forse, non si sa mai.) Escludendo alcuni casi limite, mi fa sempre pensare che qualcuno non sappia cosa stanno facendo.

Quindi per me la velocità non è l'argomento principale. L'inutilità è. ;-)

+0

Bene, potresti * avere una pagina con un 'p # pippo' e * un'altra * pagina con un' div # pippo', entrambe le pagine includono lo stesso Javascript, e vuoi solo che lo script si applichi al 'div # foo' ... Non che sia uno script o un markup sensato, ma solo dicendo ...; o) – deceze

+0

@deceze: Assolutamente, quello sarebbe uno dei casi limite di cui stavo parlando. (Un altro essere se si desidera consentire il contenuto utente avanzato abilitato per HTML sulla pagina e modificarlo in modo diverso a seconda che si trattasse di un 'div' o di' span', ecc.) –

2

sì, questo è più veloce a causa della velocità di analisi e perché il browser non deve controllare se l'elemento è anche un <div>. (per alcune regole la differenza di velocità non è percepibile dall'utente)

+0

Quindi ... qualsiasi benchmark? –

+2

http://code.google.com/intl/it-IT/speed/page-speed/docs/rendering.html –

2

Secondo this Mozilla article, fa la differenza, anche se un minuto. (Si noti che mentre questo articolo viene descritto lo styling interfacce utente XUL, il motore di layout Gecko viene utilizzato sia per rendere l'interfaccia utente di Firefox e le pagine Web viene caricato.)

L'ID è destinata ad applicarsi a un singolo elemento nel DOM in ogni caso, quindi il colpo di performance sostenuto dal tentativo di abbinare il nome del tag è completamente inutile, che sia significativo o meno. Per non parlare del fatto che sprecherebbe pochi byte nel tuo foglio di stile.

+0

L'articolo non esegue il backup con alcun dato, però. –

+0

@ T.J. Crowder: Sì, sfortunatamente. Questo è quanto posso trovare per ora. – BoltClock