javascript - page - jQuery Optimization/Best Practices
jquery id value (6)
Bueno ensillar vaqueros, porque este va a ser largo. He pasado la mañana revisando algunos de mis códigos anteriores y me pregunto sobre las mejores prácticas y la optimización. Para evitar un carril subjetivo de bajada, solo publicaré algunos ejemplos con algunas preguntas que con suerte serán fáciles de responder. Trataré de mantener los ejemplos muy simples para facilitar la respuesta y disminuir la probabilidad de errores. Aquí vamos:
1) Asignación frente a llamadas jQuery
Entiendo que, al acceder a los selectores, generalmente se considera mejor asignar un selector a una variable en lugar de hacer la misma llamada más de una vez, p. Ej.
$(''div#apples'').hide();
$(''div#apples'').show();
vs.
var oranges = $(''div#oranges'');
oranges.show();
oranges.hide();
¿Se aplica esta misma regla cuando se hace referencia a jQuery''s $(this) ? Ex. Un simple script para hacer clic en algunos datos en una tabla y personalizar el enlace.
$(''tr td'').each( function() {
var colNum = $(this).index();
var rowNum = $(this).parent().index();
$(this).wrap(''<a href="example.com/hello.html?column='' + colNum + ''&row='' + rowNum +''">'');
})
vs.
$(''tr td'').each( function() {
var self = $(this);
var colNum = self.index()
var rowNum = self.parent().index()
self.wrap(''<a href="example.com/hello.html?column='' + colNum + ''&row='' + rowNum +''">'');
});
2) this vs $(this)
Ok, este es algo que me he preguntado durante mucho tiempo, pero parece que no puedo encontrar ninguna información al respecto. Disculpe mi ignorancia ¿Cuándo tiene sentido llamar a vanilla js this en oposición a jQuery wrapped $(this) ? Tengo understanding que -
$(''button'').click(function() {
alert(''Button clicked: '' + $(this).attr(''id''));
});
Es mucho menos eficiente que acceder al atributo DOM del vainilla de this objeto como el siguiente:
$(''button'').click(function() {
alert(''Button clicked: '' + this.id);
});
Entiendo lo que está sucediendo allí, me pregunto si hay una regla de oro para decidir qué usar.
3) ¿Más especificidad es siempre mejor?
Este es bastante simple, ¿SIEMPRE es beneficioso ser más específico con nuestros selectores? Es fácil ver que $(''.rowStripeClass'') sería mucho más lento que $(''#tableDiv.rowStripeClass'') , pero, ¿dónde dibujamos la línea? ¿Es más rápido aún $(''body div#tableDiv table tbody tr.rowStripeClass'') ? Cualquier entrada sería apreciada!
Si has llegado hasta aquí, ¡gracias por echar un vistazo! Si no lo has hecho,: p
1) Asignación frente a llamadas jQuery
¿Se aplica esta misma regla cuando se hace referencia a jQuery''s $ (this)?
Si, absolutamente. Una llamada a la función $ crea un nuevo objeto jQuery y con él viene la sobrecarga asociada. Múltiples llamadas a $ con el mismo selector crearán un nuevo objeto cada vez.
2) esto vs $ (esto)
Yo diría que saber la diferencia es importante porque a veces es crucial que no envuelva sus objetos con jQuery. En la mayoría de los casos, no desearía hacer una optimización prematura y solo para mantener las cosas consistentes, siempre envuélvalas con $ (this), y preferiblemente en caché en una variable. Sin embargo, considere este ejemplo extremo de una lista desordenada <ul> que contiene un millón de <li> elementos:
$("#someList li").each(function() {
var id = $(this).attr(''id'');
});
Se crearán un millón de objetos nuevos que incurrirán en una importante penalización de rendimiento, cuando podrías haberlo hecho sin crear ningún objeto nuevo. Para atributos y propiedades que son consistentes en todos los navegadores, puede acceder a ellos directamente sin ajustarlos en jQuery. Sin embargo, si lo hace, trate de limitarlo a los casos en los que se tratan muchos elementos.
3) ¿Más especificidad es siempre mejor?
No siempre. En su mayoría depende de los navegadores, y de nuevo no vale la pena profundizar en micro-optimizaciones a menos que sepa con certeza que algo se está ejecutando con bastante lentitud en su aplicación. Por ejemplo:
$("#someElement") vs $("#someElement", "#elementsContainer")
Puede parecer que, dado que también proporcionamos un contexto al buscar un elemento por id, la segunda consulta será más rápida, pero es lo contrario. La primera consulta se traduce en una llamada directa al getElementById(..) nativo getElementById(..) mientras que la segunda no lo hace debido al selector de contexto.
Además, algunos navegadores pueden proporcionar una interfaz para acceder a los elementos por nombre de clase utilizando getElementsByClassName y jQuery podría usarlo para esos navegadores para obtener resultados más rápidos, en cuyo caso se proporciona un selector más específico como:
$("#someElement.theClass")
en realidad podría ser un obstáculo que simplemente escribir:
$(".theClass")
Artículo de blog de 2013 sobre las mejores prácticas de jQuery
Respuestas actualizadas sobre su pregunta y aún más sobre las mejores prácticas de jQuery para aplicar hoy en día, este artículo trata sobre temas interesantes que son realmente útiles y que tal vez quiera leer.
Se trata de los temas que se preguntan aquí y aún más: la función animada, jQuery promete, las mejores formas de importar jQuery, jQuery events etc. ¡Esperamos que sea útil para usted!
Este blog no está muy fechado, pero proporciona algunas respuestas a sus preguntas y también brinda más información sobre la aceleración de su sitio al usar jquery: http://www.artzstudio.com/2009/04/jquery-performance-rules/
Uno de mis favoritos es el número seis, que establece limitar la manipulación DOM. Siempre es malo hacer un .append en un bucle for ya que cada vez que se agrega al DOM, que es una operación costosa.
Hasta tus preguntas:
- El almacenamiento en caché del objeto jQuery debería producir el mejor rendimiento. Evitará búsquedas DOM que es lo que puede ser lento cuando se realiza muchas veces. Puede beneficiarse del encadenamiento de jQuery: a veces no hay necesidad de una variable local.
- Lo mismo ocurre con $ (esto) cuando se trata de un elemento DOM. A pesar de que esta es la forma más rápida de obtener un objeto jQuery, es aún más lento que el almacenamiento en caché. Si el elemento DOM vainilla sería suficiente, entonces no llame a jQuery en absoluto. El ejemplo con el atributo id es excelente: prefiera this.id than $ (this) .attr (''id) si no va a necesitar $ (this)
- Los selectores más específicos disminuirán el tiempo de búsqueda de DOM de hecho. Sin embargo, sí hay una línea para dibujar: haga que los selectores sean más específicos solo si está 100% seguro de que esto mejoraría el rendimiento de una manera notable.
Intentaré responder de la manera más concisa posible:
Guardar en caché cuando se usa con frecuencia, especialmente en una situación de bucle, ejecutar el mismo código para obtener el mismo resultado nunca es bueno para el rendimiento, almacenarlo en caché.
Úselo cuando solo necesite un elemento DOM y
$(this)cuando necesite los métodos jQuery (que de otro modo no estarían disponibles), su ejemplo dethis.idvs$(this).attr("id")es perfecto , algunos ejemplos más comunes:- Use
this.checkedlugar de$(this).is('':checked'') - Use
$.data(this, ''thing'')lugar de$(this).data(''thing'') - Cualquier otro caso donde la creación de un objeto jQuery no es útil básicamente.
- Use
Depender de un selector de ID es preferible para el rendimiento ... ¿qué tan específico necesita ser? Eso depende completamente, en resumen: sea tan específico como necesite ser .
Las únicas situaciones que debes tener en cuenta son los bucles y los eventos . Porque cada acción que hagas en uno de estos se realizará en cada iteración o en cada evento.
Asignación frente a llamadas jQuery
Tu ejemplo no es el mejor. El lugar donde debe guardar las referencias a los objetos jQuery son los que se utilizan en bucles o eventos , o que son resultados de consultas complejas .
esto vs $ (esto)
Nuevamente, en situaciones críticas de rendimiento, la cruda dom es mejor. Aparte de eso, debes elegir cuál es más corto o más legible . Sorpresa, sorpresa, no siempre es jQuery.
¿La especificidad es siempre mejor?
Hay más tipos de especificidad que las personas suelen confundir. Uno de ellos es inútil, por ejemplo, un nombre de etiqueta para una id. De
tag#idselección detag#id, será más lento que una simple identificación. Pero hay otro tipo en el que será un gran beneficio ser específico. Ahora este tipo depende del navegador, porque los modernos se sacrificarán por los antiguos, pero vale la pena el intercambio. Esto sucede cuando se especifica unatagpara unaclasstag.class. En IE 6-7 será significativamente más rápido que una.classsimple, porque sizzle puede hacer uso de la función rápidadocument.getElementsByTagName. Ahora otro tipo es cuando especifica demasiados ancestros . Esto ralentizará las cosas en cada navegador. Esto se debe a que el selector se ejecuta de derecha a izquierda. La regla a tener en cuenta: siempre sea el selector más a la derecha tan específico como sea posible .