 Pablo Llevan el mundo del desarrollo web desde 2006, o sea que es un veterano ya, y el web persegue desde 2011. Es defensor de la P mayúscula, o sea que como ve a alguno que es la web presi en la P mayúscula, tened cuidado. Y le gusta la optimización de los desarrollos y el código intentado, bien intentado. También es organizador del Grupo de Meta de Madrid de WordPress. Hemos participado como organizador, también en las dos ediciones que se han celebrado de Work at Madrid. O sea que está curtido el hombre, tratarlo bien. Actualmente trabaja como WordPress Consultant en Unir y es autor del blog Desarrollo WP. ¿Quién conoce el blog después de WP.com? ¿Avista Pablo? Tengo fans, ¿eh? Yo empezó a agarrar mi madre, ¿no? Desarrollowp.com donde comparte noticias, tutoriales tupcos y consejos sobre WordPress. Así que nada, sin más dilación, me lo dejo con la presentación de Pablo. Un aplauso. Vale, ¿se me lleguen? Vale, pues nada. Soy Pablo Dota, como lo ha hecho Juanca y vengo a hablar de gestión avanzada de assets en WordPress. Como vamos un poco antes funcionaba, ¿está puesto? Sí, ¿no? Ahora, me quedo aquí más cerquita. Como vamos un poco justo al tiempo, porque quiero tratar muchos temas, lo primero que quiero comentar es todo lo que vamos a ver son consejos, buenas prácticas, hay bastantes apartados, en cada uno de ellos he dejado enlaces a información más detallada, ¿vale? Porque no da tiempo a verlo todo y si tenéis cualquier duda voy a estar aquí el resto del día, o sea que es sin problema. Vamos a hablar de la gestión avanzada de assets para mejorar la optimización de carga de la web, porque como todos sabemos la velocidad es importante, ¿no? Las grandes empresas invierten mucho tiempo, recursos, dinero en optimizar los tiempos de carga de su página web. Probablemente deéis oído hablar alguna vez aquello en Amazon pierden 1% cada 100 milisegundos de carga y tal, pues todas esas estadísticas, estos hitos de grandes empresas podéis ver aquí en estos enlaces, o si tenéis curiosidad para que sepáis que eso, que las grandes empresas invierten mucho en este tipo de tareas. ¿Y por qué? Pues porque el ser humano es impaciente, o sea, nos estamos acostumbrando por ejemplo a ver vídeos a 1,25 o a 1,5, o sea, nuestro tiempo es valioso y no nos gusta que una web tarde mucho a encargar. Aquí os pongo un estudio de SpirCur, que habla de que el peso medio de una web son 3 megas y no sé si lo veis muy bien en las finales de la tasa y tal, cada año veis que va creciendo el peso de la web y lo que más pesa en una web son las imágenes que ocupan 50, 60% del peso total, scripts, HTML, CSS, son cosas que podemos optimizar. Luego también quería comentar que la optimización empieza desde el concepto, es decir, la petición HTTP más rápida es aquella que no se hace, o sea, esto es como lo único que no engorda, lo que se queda en el plato, o sea, petición que no veis, petición que os ahorrais. Entonces hay que pensar un poco eso en el concepto desde el diseño, cualquier web recargada con muchos iconos, muchos efectos, eso es más CSS, más JS, por lo tanto pesará más. En cuanto a la optimización, pues aquí se cumplió la regla de paleto, que si no lo conocéis pero significa que el 80% de la optimización consume el 20% del tiempo y el 20% restante consume el 80%. Incluso diría que es un momento de 10, porque se pueden conseguir resultados con muy poco esfuerzo, buenos resultados, pero los últimos milisegundos es donde es difícil. Y si os estés preguntando qué hace un tío intentando abrir un bote, es que no encuentre ninguna imagen mejor para representar el esfuerzo, va a salir bien el chiste. Fultidamente también me imagino que conoceréis herramientas tipo page speed, gtmetrics, spinontools, nos dan un pequeño informe de cómo está el estado de nuestra web. Bueno, no se ve muy bien por el tamaño de la pantalla, pero si os fijáis, por ejemplo, las reglas de gtmetrics, de las nueve que te mide, siete están orientadas a los assets. Los assets son los recursos estáticos, HTML, CSS, JS y son cosas que se pueden optimizar. Entonces, vamos a ir viendo poco a poco cada una de ellas. La primera es habilitar la compresión. Si habilitáis la compresión en vuestra web, podéis reducir el tamaño de las respuestas hasta en un 90%. Aquí a ver si se ve bien. No se ve bien. Bueno, os pongo una tabla con las típicas librerías, como pueden ser jquery, angular, bushtrap. Podemos llegar a reducir hasta en un 90%. El peso de ese fichero, por lo tanto, se transfiere... Ah, mira, bien. Ahora que no lo veo, soy yo. Aplicar la compresión al perfecto. Reducimos el tamaño de fichero, por lo tanto, la transferencia es menor y más rápida. Para hacer esto, mediante una serie de reglas en el HTS, simplemente os dejo aquí, como veis en todas las slides, un enlace a información más detallada, poniendo una regla en el HTS, podemos aplicar la compresión a este tipo de archivos. El siguiente punto es aprovechar el almacenamiento en cache del navegador. Cuando entramos en una web, nos descargamos todo el CSS, JS y las imágenes. Si seguimos navegando en esta web, o volvemos hasta web mañana, y no aplicamos cache del navegador, nos volvemos a descargar todos los recursos. Esto es un proceso lento y costoso, cada vez que hay que hacer una petición, por la vez que cargas un archivo. Si aplicamos cache del navegador, evitaremos a un usuario la segunda vez que entre, o cuando empiezan a navegar, que se descargue los recursos que ya tiene, porque los servirá directamente desde el navegador. Aquí sí que toco en media para atrás, porque no lo veo. Esto es un ejemplo de... No sé si se ve muy bien, pero bueno, indica que ficheros están cargando desde memoria o desde disco. Se cargan, o sea, es cero milisegundos. Se cargan desde la cache del navegador, más rápido de eso. Entonces la ganancia es mucha, aplicando el cache del navegador. ¿Cómo se aplica? Igual que antes, con más reglas que en el HTE Access. Donde se especifica el tiempo de inspiración del tipo de archivo que tú quieras. Por ejemplo, una imagen, tu sobre su imagen no va a meter nada a cambiar. Puedes poner un año de inspiración, pero durante ese año, cada vez que el usuario entre, si la tiene ya en el navegador, se ahorra a descargarla. A no ser que haya borrocache, pero bueno. Siguiente punto, minificar los recursos. ¿Qué se puede minificar? Pues el HTML, el CSS y el JS. Minificar, si no, es el proceso mediante el cual quitamos los espacios, las tabulaciones, los altos de línea de estos archivos. Todos esos son caracteres imprimibles que ocupan espacio. Si eliminamos eso, el archivo pesa menos. Al pesa menos se transferen antes, va más rápido. Aquí he tratado, donde podéis ver ejemplos, de cuando se minifica un recurso de las librerías típicas, tipo, phone, house, bus, trapital. Podemos ganar entre, si es un CSS, entre un 20, 25% y si es un JS, 60, 70% más o menos de reducción. Esa es una cosa considerable. Antes de minificar, lo que podemos hacer también es eliminar cosas que realmente no utilizamos. Por ejemplo, en el HTML, y perdón, se ve muy rápido, Wordpress por defecto cargan muchos etiquetas, muchas clases que a lo mejor no necesitamos, no queremos. Si las eliminamos, es ya peso que nos quitamos de encima. ¿Cómo podemos hacer esto? Con una función tipo esta, podemos remover todas esas etiquetas y para que os hagáis una idea, en una instalación por defecto de Wordpress, con el 2010-20, nos ahorrabiamos las clases, no es mucho, pero cada cosita de estas, es el granito que asuma para optimizar. ¿Qué más podemos eliminar del HTML que en primer Wordpress? Por ejemplo, en las etiquetas body, en las etiquetas section, en los menús, meten un montón de clases que normalmente no utilizamos o a lo mejor utilizamos una. Para saber si estamos en pos, si estamos en la home, para que os hagáis otra idea, en el body, estas clases, postemplate, posible uno, sin el formal de standard has given in magic do. Yo nunca las he utilizado. Es poco, pero estamos hablando de bytes que podemos eliminar. ¿Cómo? Os dejo aquí varias funciones para actuar en los filtros correspondientes y eliminar esas clases, que es HTML que ocupa espacio. Y luego ya, en sí, lo que es el minificar el HTML, lo que hay que hacer, os dejo aquí dos enlaces, uno, a una clase PHP, si desarrolláis temas o plugins a medida y lo queréis integrar, que es bastante sencillita y si no, pues tenéis también un plugin donde podéis activarlo y el se encarga de hacerlo. El siguiente cosa que voy a unificar es el CSS y pasa un poco lo mismo que con HTML. Vamos a intentar de primeras optimizarlo para que pese menos y luego ya lo minifiquaremos. ¿Cómo ponemos optimizar un CSS? Pues por ejemplo, vamos a utilizar el sorghant, eliminar los vendors prefix que ya no se lleva, cuando tengas 0 unidades, no pongas las unidades, utilizar códigos de color cortos. En este ejemplo que veis, es una clase donde se indica el padding top, right, bottom left o utilizando el sorghant de padding. Estos son entre 40 y 50 bytes de mejora. Vuelvo adelante, no es mucho pero es un poquito que te ayuda entonces antes de minificar suyo sería que de primera vez el archivo estuviera optimizado y para minificar en sí os aconsejaría alguna herramienta tipo gulp o grunt que te ayuda a automatizar estas tareas. Aquí os dejo un ejemplo de cómo sería en gulp como veis es muy fácil, simplemente le dices las fuentes que quieres minificar. En este caso voy a poner este ejemplo las con cateno, la minifico y la renombo en un archivo que haré luego en WordPress. Entonces ya tenemos un archivo totalmente optimizado. Con el JS pues pasa un poco lo mismo. Muchas veces por ejemplo cargamos jQuery para tener un efecto del scroll to top este típico. Entonces jQuery pesa 100k y para esa gilipolle hacemos cargado 100k para una cosa que se puede hacer con Javascript en dos líneas. Entonces os dejo aquí un enlace también que dice que lo mismo no necesitáis jQuery porque es un Javascript nativo. Mucha de las cosas que realmente hacemos las podemos hacer sin cargar una librería más ahorrando bastante peso. Aquí os dejo un ejemplo de cosas que se suelen hacer jQuery como sería en Javascript. Como veis la diferencia no es tanta. Y también os dejo un enlace a técnicas o a trucos para optimizar el Javascript y para minificarlo haríamos lo mismo con gulp. En este caso las fuentes que quieres tratar si lo quieres concatenar si lo quieres sublificar lo renombras al poder en un archivo y ese archivo es el que se carga al final. Y con eso pues optimizaríamos la parte de Javascript. El punto quizá más importante y esto le daría para macharla por si sola es el tema de las imágenes. Si os acordáis en las estadísticas que vimos antes representan hasta el 60% del peso de una web. Voy a pasar aquí un poco rápido porque si no nos va a ir de tiempo pero vamos, las imágenes la podemos optimizar en cinco puntos. El primero es el tamaño. El tamaño porque si subimos una imagen más grande realmente el contenedor que tiene en nuestra web estamos cargando peso innecesario sin más. Muchas veces de hecho he visto imágenes de 6.000 píxeles para contenedores que van en 1.024. Entonces, estamos subiendo imágenes de 4.000 que por si solas pesan más que una web. Cuando optimiza una imagen de 1.024 pues estamos hablando de 100 cas como mucho. El siguiente sería optimizarla en resolución lo mismo tanto para poder utilizar alguna herramienta tipo Photoshop para optimizar las imágenes para web. Porque lo humano a menos de mío yo no llego a percibir cuando las optimizas para web la perdió que es asumible. La ganancia que puedes tener es considerable respecto a que se pixela un pelín. Lo notáis mucho sobre todo en degradados pero en una imagen normal no tiene mucha previa. Aquí sí que os dejo algunos enlaces a plugins que os pueden ayudar en esta tarea. Los suyos que la optimizáis antes son un Photoshop o algo así pero luego además lo podéis optimizar con ayuda de algunos de estos plugins. También importante elegir el formato de cuerpo porque por ejemplo por una fotografía jpg es adecuado y si tiene pocos colores si es una buena instrucción de estas o tiene otra ponencia png si utilizáis png para una fotografía probablemente pese hasta 5 o 6 veces más que si fuera jpg entonces tenéis que elegir el formato adecuado también. Si halláis temas o plugins hacer uso también de imágenes responsive esto es muy importante sobre todo cuando alguien os visita desde el móvil porque os va a servir la imagen adecuada en el dispositivo. Si no lo hacéis y calzáis la etiqueta tal cual estaremos haciendo un usuario de móvil de descargarse una imagen mucho más grande de lo que realmente lo va a ver. Tenéis información más detallada de cada punto en cada slide que luego compartiré. Luego también hay esta técnica que es el lazy load que sirve para antes de imprimir el html se cambia el sobre de la imagen en el banco por lo tanto no hace descarga y cuando tú bajas con scroll me deja la script es cuando hace la petición y te sirve la imagen. Es una técnica buena porque muchas veces un usuario entra a tu home y a lo mejor navega directamente y si tú por debajo tienes un scroll con móvil en imágenes le estás haciendo descargarse imágenes que no va a haber. De hecho, una de las cosas que tengo aquí que no se ve porque está debajo de este enlace es que Chrome en las posiciones de los versiones va a hacerlo por el mismo. Ya no hace falta y está en algún proving de lazy load sino que el navegador se va a encargar de hacer el lazy load de imágenes de videos y de iframes en las posiciones. Está en modo beta ahora. Y aquí os dejo una guía súper restensa que no sé si la conocéis que creo que es de Google sobre la optimización de imágenes que partí de la web. Para optimizar la entrada es CSS. Este es otro de los errores que suelen dar estas páginas que hemos comentado antes. ¿Cómo utilizamos el CSS? Google nos dice que cargamos el crítica del CSS en línea y el resto de forma sincrona. Es técnicamente más difícil y más tiempo, pero vamos a ver y vamos a optimizar de otra manera quizá un poco menos agresiva el CSS. Lo primero es el critical. Para esto es el CSS necesario para el primer pantalla o el primer vistazo de tu web. Esto podéis hacerlo a mano aunque es un poco volto o utilizar alguna librería en Google para extraer el CSS y pintarlo en línea. ¿Cómo lo pintamos en línea en WordPress? Nos podemos enganchar y directamente cargar un fichero que habremos tratado previamente con Google. Esto nos cargará el CSS necesario en línea por lo tanto no vas a notar que se cargue la página o la vas a ver instantáneamente. Otro de las cosas que podemos hacer también es dividir nuestro CSS en media queries. Por ejemplo, en bootstrap hay cuatro cortes de media queries 5, 7, 6, 8, 9, 9, 2, 1, 200 queries. Entonces, podéis hacer un CSS para cada media query y cargarlo con la función de WordPress en QueueStyle. En el último parámetro que se llama media, no sé si lo veis pues ahí podéis indicar para qué media query va a ese archivo. De esta manera, cuando se construye el CSS on sólo va a pasear el que te corresponda, el resto no. Entonces, con esto tenéis también una ganancia importante. Esto es un ejemplo de cómo quedaría las fetas link donde va a bajar estilos y como veis, en atributo media indicaría para qué viewport va a ese archivo. Quitar el javascript que bloquea lo que hayan realizado del contenido. Esto aparece cuando tienes javascript en la head cuando no tienes atributo async en el javascript o cuando no tienes atributo de fer. Vale. Para quitar el o enviar el mejor hecho enviar el javascript al footer podemos hacer uso de la función de WordPress en QueueScript el último parámetro se llama infooter, ponerlo a true. Esto es lo que hará es cargar en el hook del footer nuestro javascript. Si tenéis algún tema, algún plugin que lo carga en el head también lo podéis forzar para enviar ese javascript al footer. Pero como veis, cada vez que el HTML se parsea cuando llega un javascript se para, lo descarga lo ejecuta y luego sí que el parseo. Por eso es el bloqueo del contenido que se llama. Podéis también hacer uso de la etiqueta de atributo async actuando sobre un filtro de WordPress que es el scriptloader tag podéis añadir a los javascript este atributo async lo que hace es paralizar la descarga de javascript. Por lo tanto ese bloqueo es menor pero no se asegura la ejecución o no se garantiza el orden de carga. O sea, si tenéis dos Js con diferentes pesos y los pones async se ejecutará primero el que menos pese. Entonces, si tenéis dependencias no es recomendable que utilicéis este atributo. Y el otro atributo es de CER lo que hace es que se descarga asincronamente y se ejecuta al final. Entonces, a mí personalmente depende de cada proyecto de cada web y tal es más recomendable de CER porque si tenéis dependencias aquí sí que se van a respetar. Entonces, para hacer un pequeño resumen cuando cargáis un javascript tenéis que hacer primero la pregunta si, si hay dependencia utilizar el atributo de CER aparte de enviarlo al footer. Si no hay dependencia podéis utilizar el atributo async e incluso si es pequeñito a lo mejor es más de la pena cargálo en línea y os ahorrais la petición. Tengo tres nuevas extras de la primera voy a hablar un poco de los resources de HINDS que son precarados de recursos hay varios tipos como en el final y en el primer render pero os voy a hablar del preload que quizás es el que más impacto tiene en rendimiento y no sé conozco a poca gente que utiliza la técnica pero es algo que os puede dar un buen punto en optimización. Pero luego hago una directiva obligatoria y de alta prioridad esto lo que hace es indicar al navegador que más adelante tengo un recurso que más adelante voy a utilizar entonces lo que hace es empezar a descargar segundo plano y cuando llegue a ese punto o lo tiene descargado o casi vamos. Se puede hacer esto de tres maneras diferentes uno es ponerlo directamente en la HTML con una etiqueta link como veis al principio otro es me ha dejado a script y el tercero que creo que es más recomendable es hacerlo mediante una cabecera HTTP porque esto se ejecuta en un momento más temprano de la ejecución para empezar a descargar antes. Simplemente podemos hacer el agua tipo esto engancharnos al hook de send headers y aquí indicar qué recursos y de qué tipo queremos que el navegador empiece a descargar o sea hacer el preload tampoco es conveniente que lo hagáis para todo pero por ejemplo si tenéis una hoja de estilos común o tenéis un hota de ese común o sea no recomiendo de metáis ahí 20 imágenes y tal sino para cosas que son más generalistas no sé si conocéis audits que es una cosa que se ha puesto en la pestaña del inspector de elementos de Chrome hace unos meses audits os indica de hecho que utilices preload y por ejemplo en este caso que esto es un proyecto real nos dice que podemos ahorrar hasta 1.400.000 segundos o sea casi un segundo y medio haciendo preload de 4 fuentes para que os hagáis una idea que es una imágenes importante lo que haríamos es decir en la etiqueta HTTP que tenemos estas fuentes y cuando llegue al CSS que utilices la fuente ya las tendrá descargadas o casi vamos esto es bastante importante le digo no conozco mucha gente que lo haga pero es un punto muy importante en optimización y como veis vamos a ver si esto funciona se ve bien esto es la inspector de elementos de Chrome lo que es la petición HTTP veis aquí os pone el link el recurso que habéis dicho que queréis hacer preload y este es un script este es un estilo tenéis que indicar de qué tipo es y él ya va a hacer esa descarga en segundo plano antes de que llegue esta es la cara de condicional esto también es bastante importante recordéis al principio de lo que decíamos de menos es más la petición HTTP más rápida es aquella que nos hace muchas veces instalamos por ejemplo un plugin para comentarios como puede ser Discus pero claro Discus no sabe qué página o en qué templates tú vas a poner un comentario entonces te carga todo su CSS y todo su js que es bastante por cierto en toda tu web en general decir en qué páginas queréis que se carguen por ejemplo en el detalle de un post es absoluto cargar lupos en la home a lo mejor que no tenéis comentarios en una página de archivos en una página o incluso en un post que tenga cerrado los comentarios y entonces estamos haciendo los usuarios descargados que no van a utilizar como podemos hacer esto con las conditional tags de WordPress simplemente sabiendo en qué página estamos o quitar de la cola el script de Discus o el js de Discus rastro es aplicable para cualquier plugin o cualquier tema que estoy desarrollando a medida hay un montón de conditional tags para que sepáis en qué momento en qué página estáis y si queréis quitar o añadir también puede ser interesante que si estáis desarrollando un CSS específico para un tipo de página o para un producto concreto pues podréis sólo añadir ese CSS en una página en concreto entonces no estaríamos cargando CSS que no utilizamos en el resto de páginas pues esto ya es y lar muy fino y por último, bueno, hablar también del uso del ACDN evidentemente pues un ACDN la ventaja que tiene es que nos va a servir el contenido estático mucho más rápido y nos lo va a servir el servidor más cercano al punto donde nos encontremos y simplemente lo veis aquí en los ejemplos jQuery, por ejemplo, el que hagamos antes sin cdn viene a tardar 97.000 segundos en este caso y con cdn 14, o sea que estamos hablando de milisegundos, es un pestañón pero si lo hacéis esto con el CSS con las imágenes con tal pues todo suma y al final la velocidad pues se nota así que siempre que podes pues es recomendable también que utilicéis un cdn también por otros temas pero para la optimización pues se nota bastante y al final no creo que me ayude bien y todo, ya hemos acabado muchas gracias Pablo ahora si a alguno tenéis alguna pregunta levantad la mano y vamos pasando los micros tenéis una duda y luego pregunto en serio, no es una coña a ver, con una vida casi existencial con el tema de las imágenes yo ¿veras imágenes? tenemos en si las gif que yo las gif a parte de Twitter para colar gatitos, no dice cualquier cosa después tenemos las jpg y las pnege, pnege en principio supongo que son en centro de transparencia no, por ejemplo y después es cuidado que después están las webpi que esas ya me matan del todo porque no se puede utilizarlas y no es compatible con todos los mediadores que no estoy seguro de hecho no lo puse aquí porque cuando hice la charla el último que leí en cuanto a las webpi es que en Fireforce o en alguna cosa de Fireforce da problemas sí que es cierto que es menos peso que un jpg y que llegará pero creo que a día de hoy no sería recomendable sobre todo cuando todavía hay gente que te dice que no tiene miedo y respecto a lo otro las imágenes es un poco que progreso yo por ejemplo utilizo Photoshop y cuando voy a guardar justo al lado de guardar elijas el formato y te dice cuánto va a pesar la imagen entonces normalmente una fotografía jpg siempre pero cuando es una infografía que a lo mejor son cuatro iconos que son tres colores suele ser menos peso un pnege hay sí que se ensucia y se nota bastante la pérdida pero es un poco que juegues tú a la hora de guardar y a la hora de elegir el formato que veas cuánto pesa cada una pero si tuviera que decirte algo así genérico jpg para imagen pnege para transparencia o pocos colores pero es un poco que lo veas según vas guardar la imagen Hola soy Pau mi pregunta es sobre la cdn la cosa es si jQuery por ejemplo sería mejor usar una cdn propia y cargar la jQuery ahí o usar la propia cdn de jQuery o entiendo que si la tienes propia mejor si has de usar varios recursos tenerla en la tuya si tú contatas una cdn para el resto de recursos utiliza esa si quieres contatar una cdn pues por ejemplo todas las librerías tipo jQuery bushtrap, fundausam tienen su propia cdn incluso google lapis tiene también jQuery si solo quieres eso o mejor dicho si no quieres contatar una cdn porque descarga o lo que sea no te quiero medir en dios este tipo de librerías sí que sería recomendable que al menos lo intentes cargar de cdn propio de hosting que no sea cdn es que si lo tienes tuya propia en el hosting utiliza eso para imágenes y para cds y todo pero si no, si es solo para de hecho yo por ejemplo no su cdn pero yo que sé por qué y jQuery y esta cosa así que las cargoles de google lapis de su cdn para que ¿has experimentado con técnicas ttp2 de precarga de assets? técnicas se van a contar si tenían o sea, en experiencia experimentado, si pero por ejemplo cuando salió a ttp2 hubo como una creencia de que era mejor separar por ejemplo antes de ir a ttp2 lo bueno era concatenar todo en un archivo porque es una petición entonces te ahorras muchas peticiones cuando llegó a ttp2 el hijo se comentaba que lo mejor era que esos archivos no los concatenas que los cargues por separado porque separabilizan las peticiones pero luego experimentos que he hecho no he notado la diferencia incluso he leído bastante información que no hay una ganancia tan brutal como para que te mereja la pena experimentar yo sigo por ejemplo concatenando todo lo único que no concatena es si un script o un cds es para una página en concreto o crítico pero si ese cds es común el yo lo sigo concatenando pero porque no he personalmente no he advertido una mejora significativa y ya tengo ahí un montón de blogs y de estudios que afirman eso, que no hay una mejora significativa como para que te plantes cualquier locura ahora ponés mi amigo Charly no soy muy amigo de instalar muchos plugins en que medida afecta a la velocidad de carga en lo que es la instalar de plugins, se dedicará a lo que has comentado de imágenes para el lazy law o el smash it hay que instalar dichos plugins para poder hacer estas compresiones yo tampoco soy amigo de plugins pero por ejemplo estos hacen una tarea y la hacen desde el back cada vez que sabes subes una imagen la optimizan y de hecho la optimizan contra sus servidores de la revolución optimizada no tiene un impacto en la parte publica de tus usuarios en este caso sí que es recomendable porque yo de los que tengo aquí uso el imajify y tiene varios niveles de compresión y yo me tiene uno que se llama agresivo o así, ahí sí que se nota te da imágenes de 30k pero ahí empiezas a jugar con el tipo de resolución y sí que para este caso yo lo veo como algo útil porque te ayudan realmente a optimizar la imagen y de hecho luego en los tempos de cargar mejoras significativamente de hecho con Photoshop antes trato la imagen la guardo para web con calidad 60 y google page spin no me la pasa me dice que todavía le puedo optimizar 2% más le paso el imajify y ya me lo optimiza gracias 3 cosas muy rápidas una tema vídeo no creo que no hemos hablado tema de vídeo no sé si merecería una charlaparte pero alguna herramienta o algún método efectivo o sencillo la verdad que no de vídeo no tengo ni idea porque no tengo ni idea pero la única idea que tengo realmente es que cuando he subido he comentado ahí en el vídeo siempre con youtube vimeo o sea una plataforma que te lo sirva extremamente porque de hecho nos pasó una vez en un proyecto que pusimos un vídeo de 25 megas era para un cliente gordo que tuvo un pico de visitas brutal y o sea se cayó la web porque no me escapaba de soportar entonces también depende del caso pero yo creo bajo mi opinión que es mejor esa parte derivarla de un tipo vimeo que me refiero sobre todo a vídeo decorativo que es la sentencia del diseño si hay que incluirlo a nivel de o sea a nivel de background a nivel de vanes a nivel de sliders bueno, si igual bueno, iba por aquí segunda y muy rápida va enlazada con esta que es que el diseño escolar en la administración de choia lo has dicho las tendencias del diseño van a intentar cubrir estas densidades de infarto a las pantallas de hoy en día que piden imágenes al cien por cien de cincuenta disparates y hay que lidiar con eso también y a veces puedes escoger y a veces no puedes escoger efectivamente, por eso decía que la optimización empieza en el concepto realmente y te pongo un ejemplo ahora ahora está muy de modo a eso la imagen que cubre una pantalla de 1980 una de las imágenes que persella pesan si el diseño viene impuesto es lo que hay pero que tampoco te pide algo que vuelen pero íbamos al por ejemplo, cuando tenéis un listado de noticias lo típico que sale la imagen pequeña en la foto en Google Prespa las fotos son 10 pero si lo cambias a 8 que no creo que nadie se la aldea y ya estáis evitando cargar los imágenes son pequeños detalles los conceptos pueden ayudar a a optimizar y también digo mucho en el sentido de recargarlo mucho con mucha imagen de fondo con mucho icono, con mucho efecto, todo eso es CSS, CSS que pesa y ya tengo que si el diseño viene impuesto es lo que hay se optimizará hasta donde se pueda pero muchas veces viene impuesto y por último, si tienes alguna opinión sobre el ACDN de Jetpack quizás es una que es muy accesible para todos creo que soy la única persona de España y si hay alguien más que me lo diga que no utiliza Jetpack en mi vida no tengo opinión pensaba que era especializo pero mira, no bueno, bastante de Western por aquí todo el día sabe que si alguno quiere hablar cualquier prima pues