 Buenas tardes, disculpar este retrasillo del novato en las presentaciones de la ambita. Como comentaban aquí los compañeros, yo soy Luis. No sé muy bien cómo presentarme, así que he puesto un montón de cosas que me gustan, de música, de cine, no sé qué, por supuesto una foto de campo, aprovechando que un otro compañero Jesús me ha traído de viajes desde las vacaciones hasta aquí. Es que en realidad eso no me gusta, soy más de oveja. Pero bueno, eso es, vámonos a ver cómo soy, esto es lo que hago. Como decía antes, un compañero, yo me decino como webmaster a la hora de trabajar, porque también llevo unos poquillos de años aquí haciendo cosas. Recuerdo que es mi primera web, pues igual fue por el año 94 o por ahí. Así que llevo un timpecillo. Ahora mismo estoy trabajando entre bien, que llevo ya unos años ahí dando la lata y haciendo cosas, intentando enseñar también algunas cosas. Y por supuesto aprender de trabajar un equipo súper apañado. Como decía antes, por ahí el tema de venir a una Meetup, una parte de la insistencia de algunos compañeros. En realidad una de las cosas que me motivan siempre de este tipo de historias es que el hecho de tener que prepararme algo para explicarlo, por lo que realmente me obliga a aprender mucho y a fortalecer los conocimientos que ya pudiera tener, pues a sentarlo, a hacer otras pruebas y a aprender otras cosas que quizás no tenía tan trabajada. ¿Por qué el nombre este raro de Word presionado para esta Meetup? Bueno, en ocasiones los proyectos, la vida de los clientes, los negocios, las páginas web que tengamos nosotros mismos que queramos mover, pues tienen cierto requisito y empezamos a escuchar comentarios como todos estos que veis aquí, ya sean de nuestros clientes, de nosotros mismos si es que tenemos nuestro propio proyecto, de nuestros compañeros, del SEO que está trabajando con nosotros o de lo que sea. Entonces, ¿a qué viene esta presión que vamos notando este estrés por qué las web vayan rápidas y todo esto? Bueno, vamos a intentar ubicarlo, ¿vale? ¿Por qué? Porque, a moverse, según la estadística que tenéis por ahí, ya sabéis que ahora mismo más del 43% de todas las web aparentemente están construidas con Word pres, aunque hay algunos zombis por ahí, pero bueno, y dicen que más de un 60% de todas las web construidas con CMS, pues CMS Word pres, ¿vale? ¿Qué ocurre en el tema de la velocidad web y del rendimiento web y todo esto? Bueno, pues que de todas esas web que hay construidas con Word pres, apenas un tercio, bueno, un poco más, casi un tercio de esas webs, según dice Google y este Informe, pues solamente un tercio de esas webs tienen unos buenos valores de core web vital, ¿vale? de los valores de todos los numeritos verdes y todo eso, de velocidad. Solamente un tercio de todas las web en Word pres. Fijaos como según este Informe, tanto Shopify como Wix, que en algunos casos pueden ser competidores de Word pres, en algunos tipos de proyectos, pues hay muchísimas más webs que cumplen con buenos valores de rendimiento según Google, ¿vale? Lo primero que se nos puede ocurrir es la diferencia que hay entre los Word pres que están construidos por ahí y cómo es Shopify o como es Wix. Vale, lógicamente son entones totalmente distintos. Shopify y las capacidades que tiene cualquier usuario de tocar lo que te ofrece Shopify es mucho más limitado que lo que te ofrece Word pres, ¿no? Eso podría ser una de las razones. Y seguimos con que el entorno y te vas por Twitter, te pones a buscar por ahí, quiero que mi web vaya más rápida, quiero que no sé qué, y siempre hay algún experto, siempre hay alguna forma, un mejor método, una buena manera, un post de por aquí, un post de por allí. Pero oye, en realidad, cuando vemos todo esto, pues no lo volvemos locos, y lo que queremos es hacer WPO a saco. Y en esos momentos es cuando yo algunas veces empezó a sentir como el coyote, aparte de que desde pequeñito, siempre ha sido uno de mis personajes preferidos, muchas veces me siento como que el corre camino es la WPO, es el objetivo de velocidad, y él no sé qué y lo que me están pidiendo, y yo nada más que voy por detrás, pegándome la hostiazo cada dos por tres, porque no consigo llegar a no sé qué, porque no consigo llegar a no sé cuánto. Así que, con este tipo de situaciones, pues, ¿qué hace uno? Pues se pone uno mano a la hora, dice, bueno, entonces mi web tiene que ir rápida, contrato un hostia de la leche, le pongo el superplugging que todos usamos, todos conocemos, que lo hace todo maravillosamente bien, y listo, trabajo hecho. Y hasta aquí la chala de hoy. Que avísame si he tardado mucho. Bueno, esto es una forma de hacer las cosas. Lo que pasa es que yo soy de esas personas que a veces pregunto cosas, entonces por preguntar, termino metiéndome en el barro, y por muy alto que soy, el barro me llega al cuello y termino enfangado. Entonces, de revolcarme en ese fango, y de hacer algunas cosillas, no muchas, pero bueno, algunas cosillas que tienen que ver con la velocidad de la web, o voy a contar algunas experiencias, y ya os adelanto que no voy a hablar de caché, no voy a hablar de hosting, no voy a hablar de optimización de imágenes, no voy a hablar de plugins, no voy a hablar nada de eso. Así que voy a hablar de las cosas que, bueno, que yo he estado trabajando en algunos proyectos. Para trabajar en temas de velocidad y de optimización, me gusta tener en cuenta, me gusta tener en presente algunas cosas. La primera para mí, y probablemente viene porque llevo muchos años en esto de la web, es que el HTML es la pieza básica de la web. ¿Qué olvidás, Luis? ¿Por qué digo esto? Porque a los navegadores, lo que saben hacer muy bien es consumir HTML. Están pensados para eso, ¿vale? Esa es su función principal. Otra cosa que para mí hay que tener muy presente, es que la velocidad es relativa. La velocidad es relativa, no es un concepto que todos tengamos la misma percepción de eso, ni lo que una web va rápida para ti, para mí no lo es, porque ahora después veremos. Por ejemplo esto. Entramos en la misma página web, todos, y depender el móvil que tengamos, la velocidad que percibimos va a ser distinta. Aunque los números, después del paje, digan lo que tengan que decir. Pero el mismo móvil va superlento y el de Fran va en carga superrápido, vete tú a saberlo. El dispositivo que tenga cada uno, la CPU de ese dispositivo, etcétera, ¿vale? Todos esos son condicionantes de la experiencia que tenemos cada uno de nosotros cuando estamos navegando por una web, ¿vale? Otra cuestión que me gusta tener presente, que a veces incluso me cuesta explicarla, una cosa es la velocidad y otra cosa es el rendimiento. Son cosas distintas. El rendimiento influye en muchísimos factores. Esos son algunos de ellos, ¿vale? Es la velocidad, es el tiempo que tarda las cosas de ir aquí hasta allí, punto, es la velocidad. El tiempo que tarda las cosas en descargar, el tiempo que tarda algo en verse, el tiempo que tarda algo en tal, eso es velocidad. Pero el rendimiento es mucho más. El rendimiento es un conjunto de factores, un conjunto de criterios que es lo que tenemos que tener en cuenta. Y uno de esos es la velocidad de muchos parámetros distintos, ¿vale? Es distinto de la velocidad. Entonces, sobre este palabra de Core Web Vitals, que a veces no sabe uno si decirlo en español, en inglés o como sabe, tiene presente que estos criterios que puso en marcha Google para evaluar la experiencia del usuario de la web, primero lo ha puesto en marcha Google y segundo, pollo, pues no está mal, se trata de un indicador de calidad. Todos nosotros hemos visto esas siglas repartidas por todas partes. Supongo que... Bueno, creo que tengo por aquí la definición de cada una de ellas. Pero no sé si decirla o no, porque vosotros me digáis, si queréis explicar alguna, o si no, después con los ejemplos vamos detallando cada una, ¿vale? En resumen. En resumen. Ahora mismo, Google está midiendo los principales factores de rendimiento, estos tres de arriba, que es este de aquí, el LCP es cuánto tarda el elemento más grande de esa página, de esa URL concreta, no de un sitio entero, sino de una URL concreta. ¿Cuánto tarda en cargar? Este elemento, el FID, mire, cuánto tiempo tarda en la página en responder a la primera interacción que hace el usuario con la página. Es decir, cuando tú cargas una página cuando haces clic en un link, eso llama una interacción, cuando haces scroll es una interacción, ese tipo de interacciones que hacemos el usuario con la página, por el tiempo que tarda la página desde que ha cargado desde que clicamos un link hasta que la página responde a ese clic, ese es lo que se llama el FID, ¿vale? La primera vez. Y el desplazamiento de maquetación, del procedimiento de elementos, lo que mide es, una vez cargado la página, ¿qué hace la página para recolocarlo al elemento cuando todavía se está cargando? El FID es un criterio que Google va a reemplazar a partir de marzo, o se supone, por otro concepto que tiene que ver con la interacción que hacemos los usuarios con las páginas, que es con el concepto de INP. Lo que Google es que mide todas las interacciones que hacemos cualquier usuario con las URL en cualquier interacción en todas las páginas del sitio y las va almacenando cualquier interacción. Cada vez que clicamos en un link, cada vez que hacemos una búsqueda en un formulario, cada vez que hacemos un scroll, todo eso lo está midiendo Google y de todas esas mediciones, de todas las interacciones que hagamos cada uno de nosotros con las páginas, pues Google sacará un factor ahí porque la página tiene un INP, de no sé cuánto. Es siempre la interacción que hace el usuario con la página. ¿Por qué hace esto Google? Porque dice que creo que era el 90% de los problemas de rendimiento bien dados por la interacción del usuario cuando ya está en la página. ¿No en lo que tardan en llegar? No, sino cuando ya está dentro de la página, pues ese el 90% de los problemas de rendimiento suelen venir de ahí, a día de hoy. Vete tú a saber dentro de un año. Bueno, ladrillo, pues ahí lo tenéis para cuando lo queráis, ¿vale? ¿Cómo tiene Google todo esos valores? Hay pruebas de laboratorio, hay valores que se tienen de pruebas de laboratorio que le llaman y hay otros valores que se tienen de pruebas de campo. Muchos de vosotros conoceréis Lighthouse, la herramienta está de Google y la extensión para hacer mediciones, ¿vale? Es el laboratorio de Google para hacer mediciones. Muchos de nosotros cogemos el Chrome, ponemos Lighthouse ahí en nuestra máquina local, hacemos cosas, nos sale un numerito que son los mismos de PageSpeed y confiamos en que eso sirve, bien. Sirve cuando tienes claro que es lo que tienes que mejorar, ¿vale? Las pruebas de laboratorio, pues son pruebas de laboratorio, ya sabéis siempre por qué significa eso, prueba de laboratorio significa porque es un entorno muy concreto, eres tú solo con tu equipo, con tu CPU, con tal tal. Lo importante y lo importante tiene que ver con las pruebas de campo. La cuestión es ¿Cómo tiene Google esa información de pruebas de campo? Es decir, ¿Cómo tiene Google la información de los usuarios reales que visitan tu web? Pues la obtiene de todo aquello navegador Chrome de usuarios que tengan la sesión iniciada y que tengan activado la compartición de datos con Google, ¿vale? Entonces de esa forma Google va captando que cada URL que visitáis con vuestro Chrome con la sesión iniciada de atrás, cada URL que visitáis pues va captando todos esos factores que vienen descritos en cada una de las fichas de estos criterios, pues que si el tiempo que tarda es en entrar, el tiempo que te tarda es la imagen más grande, el tiempo que te tarda es en click on link, todos esos valores los va midiendo de todos los usuarios que visitan esas URLs, ¿vale? Entonces como veis aquí algunos factores Google obtiene pruebas de laboratorio el lanza Sublighthouse sobre URLs y aparte obtiene datos de campo sobre esas URLs concretas, ¿vale? Aquí tenemos un ejemplo de una URL de una web de brillante de la marca Garrón Esto está obtenido esta línea con una de las herramientas que luego tejo por ahí y bueno veis cómo empezamos a ver esos conceptos que ya nos gusta tener en las URLs y tal y todo ¿Cuánto tarda el servidor? ¿Cuánto tarda en verse la primera imagen después de la carga? ¿Cuánto tarda el elemento más grande de la imagen? ¿Cuánto tarda la página en que sea interactiva? ¿Cuánto son 2,5 segundos en que yo como usuario cuando visito eso con el móvil pueda hacer algo con la página, bien hacer scroll o bien lo que sea, ¿vale? Y todo eso hasta que la página está totalmente completa O sea, un plugin de cookie 14 segundos, ¿vale? Lo interesante de esto para comprender mejor la experiencia que tienen los usuarios y en realidad, o sea, vosotros cuando estéis navegando por la web analizaros vosotros mismos y haceros estas preguntas O sea, cuando yo estoy navegando por la web que quiero entrar, no sé qué, quiero entrar en mi banco de información para irme fin de semana a nosa donde yo entro en la URL que he pinchado, está ocurriendo algo ¿Cuánto metas el móvil? Está aquí la pantalla en blanco, ¿qué pasa? Lo que ahora, lo que cuando ya me ha cargado algo, lo primero que veo me resulta útil, o tengo que seguir esperando a que yo pueda utilizar a que ver algo útil, ¿vale? Entonces, Google con sus core web vital lo que intenta es responder a estas preguntas, ¿de acuerdo? La misma URL y el típico chequeo de PageSpin, ¿vale? Los valores tenéis que tener en cuenta para entender un poquito los valores de esto tenéis que tener en cuenta estas dos casillas de aquí arriba, ¿de acuerdo? Hay muchas veces que, bueno, ahora lo vamos a ver después en otras URLs muchas veces os encontráis con que esa casilla de esta URL no es clicable, no te da información, ¿vale? ¿Por qué? Eso ocurre cuando Google no ha podido capturar visitas suficientes a esa URL. Entonces, como uno puede capturar visitas suficientes en el último mes, en los últimos 28 días de esa URL concreta, entonces no te puede dar información real sobre los usuarios, ¿vale? Lo que se llama real user monitoring que es monitorización real de la experiencia de los usuarios cuando entran en una URL concreta. Entonces, en los valores de core web vital que antes vemos que son así los más claves esta parte de arriba del pagestí, ¿sabéis qué pagestí tiene? Esta parte de arriba, luego otra parte de abajo con los numeritos que siempre no gustaban todos los informes, ¿vale? Los numeritos, bueno. Entonces, esta parte de aquí arriba que es la información que extrae Google de la experiencia real de los usuarios es la que nos va a dar una información más fidedigna de cómo es la experiencia de nuestros usuarios cuando la vengan por la web. Por tanto, es muy posible, como después veremos es muy posible que tenga un típico pagestí que pone 39 y en rojo y, sin embargo, aquí, en vez de poner no superada, así que te pongas superada, ¿vale? Luego lo vamos a ver. Si queréis que me entretengan después contando con más detalles estas cosas, me decís, ¿vale? Otra página web con otro tipo de página web distinta, esta es una página web en un sitio de actividad en Cataluña para salir con niños está infestada de Javascript con anuncios, no infestada de malware pero está infestada, está eapabullante en cuanto a anuncios, ¿vale? ¿Va aparentemente bien? Puede ser, igual empezare a visitarla y os va super bien. Fijaos, como la de brillante de antes que aquí ponía total visual y complete 14 segundos, solamente 3 segundos, ¿vale? Luego veremos cosas sobre ésta. Como, por ejemplo, esto los Javascripts, los Javascripts de anuncios, los inserciones de anuncios de unos y de otros a pesar de que los tiempos de hecho, a pesar de que los tiempos o sea, la página web cargando segundo y en 3 segundos ya está todo cargado pero según Google el inicio de los usuarios realmente es mala. Primero porque es mala porque lo ponen aquí, ¿vale? Pero bueno, Google empieza a decir que hay muchos cambios de visualización y fijaos en el INP el INP que todavía no se trata como un Core Web Vital pero el INP lo que te está diciendo es que cualquier interacción que tú haces con la página te tarda como medio segundo en responder haces click, medio segundo haces scroll, medio segundo pero algo pasa con esa página y esto es de campeonato otra vez, esto es de un editorial luego entraremos además en detalles time to first byte más de dos segundos igual el de hosting tiene algo que ve igual no igual no totalmente cargada ocho segundos pero realmente podemos hacer algo incluso aunque hayan pasado o no, se ha cargado el elemento más grande a los cinco segundos pero podemos hacer algo con la web porque estamos todavía esperando ahí el spinning de Andra Huerta entonces ¿qué pasa aquí? Pues ¿qué pasa aquí? Bueno, lo primero como pasaba antes, esta URL concreta de este libro concreto Google no ha sido visitada lo suficiente por usuarios tiene una web que no tendrá mucha visita en esa URL concreta y entonces no tiene datos reales de esa URL concreta entonces lo que hace es traerte una interpolación de todas las URLs que Google conoce de este sitio cómo se comportan en los distintos parámetros de core web ¿vale? ¿qué vemos aquí? pues que de todas las URLs que Google conoce los usuarios tardan una media de ocho segundos encargar el elemento más grande de esa web el primer elemento que es visible tarda unos seis segundos y tenemos de nuevo medio segundo de integración aproximada en esa página ¿vale? en cada una de las URLs de esa página y bueno, en esta medición en este caso salieron 3,9 segundos de esto hablaremos después de esto cuando lanzamos el test de pagesp sobre una misma URL en el mismo momento salen 4 valores distintos o 17 valores distintos si ponéis 17 ventanas o ni más lanzáis las 17 a la vez probablemente en 15 saldrán valores distintos son elementos variables son elementos variables porque dependen tanto del tema de laboratorio son valores variables porque las pruebas son pruebas de laboratorio que es lanzando Lighthouse en ese momento y pruebas de, las pruebas de campo las pruebas que tiene Google de cada una de las URLs etcétera entonces en el mismo Google hay en alguna de las preguntas frecuentes dice bueno esto es variable y siempre lo va a ser por las razones de las pruebas laboratorias etcétera entonces hay que fijarse tener en cuenta esto lo que quiere decir lo siguiente hay que fijarse en que yo hago una foto del pagesp y cuando tengo esa foto del pagesp empiezo a trabajar a cada vez que lo que puedo hacer pues igual no vale, entonces como ven lo que se deduce de esto es que las tareas de optimización de velocidad son tareas recurrentes iterativas y permanentes otra cosa más que todo esto todo este pagecito, estas pruebas que hacemos tenemos que ponerla en consonancia con lo que tenemos en Google Search Console este es nuestra aliada vale una de las mejores herramientas que podemos tener a nivel se o por supuesto pero a nivel de conocer la web nuestra como es por dentro porque son otros ojos que no son los nuestros los que están viendo esta web y de aquí podemos sacar mucha información en este caso por ejemplo aquí os está diciendo pues que hay de la web está pues 3400 url tienen un malísimo rendimiento y tal y cual entonces ahí hay mucho que trabajar te ayuda mucho a identificar patrones y son las propias herramientas de Google no tiene que depender de la herramienta ni nada un concepto clave que lo dijo el señor Muñoz no hace mucho en Ponte de Edran a Google se le asuda tu página web vale decir en Google lo único que quiere es darle a los usuarios lo único que quiere aparte de canapasta vale darle a los usuarios lo que el quiere darle a los usuarios entonces como siempre como ya sabemos mucho no, Google lo que queremos lo que quiere es que trabajemos para él y que ayudemos a su negocio de acuerdo entonces cuanto más optimicemos nuestras páginas web más estamos ayudando que Google gane más dinero pero bueno ya de camino a ver si ganamos nosotros algo también vale alguna cosilla que queréis preguntar alguna historia alguna movida el TTFB no influye solamente el servidor no influye solamente el servidor el servidor, efectivamente el servidor ha oído un elemento más es que además en un ejemplo después lo vamos a ver es un elemento más de lo que ocurre en donde acá ocurren las cosas pero pues lógicamente pues lo que hayas programado como lo hayas programado qué tipo de consulta al lance qué librería sí, es lo que estás preguntando si solamente influye la calidad del servidor que tenga eso también influye pero tampoco es el único factor es la conjunción de todas las cosas efectivamente y lo que se habla siempre qué pasa con el hosting compartido o no compartido cuántas CPU o esto lo otro vale depende de todas esas cosas pero ¿por qué? porque depende de la aplicación que tú tengas alojada en ese servidor para un webpre puede ser un servidor de la hostia de rápido para otro webpre puede ser un servidor es querosamente lento hay un tipo de servidor que funciona muchas veces que el servidor debe ejercer también que también afecta efectivamente eso también afecta, eso forma parte del time to fire ahora más hay muchos consejos hay muchas recomendaciones por ahí de que cuando quieras de verdad ser óptimo pero óptimo porque también siempre encuentra la diferencia entre lo que es mejorar y lo que es optimizar óptimo es llegar al tope es optimizar DNS por supuesto entra dentro de esa parte de time to fire bueno, algunos casos reales esto era un vídeo que como decía antes me gusta mucho el coyote y el correcamino descubrí que había un tipo que había grabado realmente a un coyote y a un correcamino de verdad pasa que no se ve claro como el pdf lo que tiene bueno, luego lo veis ¿vale? ahí, bueno si hay que entender ha sido ahí está el coyote y el correcamino igual ha dicho un foc paso de optimizar javascript me voy a poner el plugin este bueno pues ya está el correcamino el primer caso que quiero contaros que este concretamente me ocurre recientemente pero en realidad es habitual en muchos bucomers con los que trabajamos y es la lentitud de carga en el backoffice no sé si vosotros lo habéis experimentado alguna vez o lo sentís con vuestros clientes pero para mí que el cliente esté contento significa que el cliente gestione su web de manera tranquila rápida, cómoda sin que haya problemas para eso el backoffice tiene que ir rápido entonces estamos siempre muy centrados en optimizar el front porque el negocio gana dinero pero es que para mantener ese negocio ahí tiene que haber alguien detrás que esté en el backoffice entonces el backoffice a veces es un pequeño olvidado de nuestra vida con WordPress en muchas ocasiones hay que darle más protagonismo porque de hecho en este caso concreto uno de los principales problemas que tenía la web venía dado por una cosa de rendimiento en back venía dada por una cosa que se hizo para el front qué pasa aquí se quiso hacer en el bucombs para mostrar el precio por unidad de los productos porque tiene productos variables entonces se programó una función propia así calculo el precio por unidad de los productos de la ficha de productos y no hace falta ningún plugin pero empezó a pasar esto que hay cliente que es que estoy aquí en el backoffice y esto tarda a mogollón o estoy intentando editar un producto pero me quedo a pantalla en blanco vamos a ver qué pasa entonces como parte de la análisis del backoffice hay muchas cuestiones que afectan al funcionamiento del backoffice muchísimas necesidades de deseo meten una carga brutal los plugins que sirven para las columnas de los listados de productos, los listados de poder algún tipo de min-call los plugins de permalins también hay uno de ellos que meten mucho hook y alguno de esos hook meten varios milisegundos 20, 30, 100 milisegundos en cada una de las peticiones una cosa muy tonta que es el número de elementos por página que pones en los listados de forma predeterminada a WordPress que aparece en 20 pero bueno, cliente quería editar con más comodidad su listado de productos pues se puso 200 bueno y por supuesto otra cosa que afecta al backoffice el código personalizado hay muchas cosas malas la propia plantilla que tú tengas un backoffice con el 23 que es un backoffice con cualquier otro entonces, ¿qué pasa aquí? pues query monitor a saco el plugin query monitor supongo que muchos de vosotros lo conocéis así, las primeras lanzamientos, bueno, ya estamos viendo que cuando pongo mi listado de productos con 200 productos ahí en la página el PHP me tarda casi 3 segundos en general y tengo 90 pico consulta voy a probar qué pasa cuando pongo 20 3 veces 3 veces el tiempo de carga ya empezó a no quedarse colgado ¿vale? ¿vale? ya se podía trabajar ¿pero qué pasa? es una solución al problema pues no y yo como soy de los que les gusta enfangarse pues digo, algo tiene que estar pasando aquí bueno sigo con el query monitor me voy ahí a los ganchos que se usan en las pantallas de administración de productos, veo todos los ganchos que hay no veo ninguna cosa rara ningún hook extraño nada más que de todos los plugins que tal venga seguimos ¿cómo se quedaba la pantalla en blanco? pues eso quiere decir que no está llegando nada navegado pues vamos a ir a los los de servidor y vemos que hay un fatal error que, lógicamente, él quiera lanzar la pantalla en blanco pero el fatal error en realidad no nos está dando la pista de dónde está el problema así tal cual sale entonces hay que mirar un poquito antes ¿qué pasó? Funtio un PHP y nos vendió la línea del Funtio un PHP y dice, ostras, es el código este que hizo para calcular el precio por unidad ¿vale? ¿qué hacemos aquí? bueno pues venga, entonces el precio por unidad como una cosa que sí tiene que ver en el front pues le ponemos eso y ya está ¿el front funciona? sí ¿el back funciona? sí ¿a solución el problema? no no el problema está aquí el problema está en cargar 200 productos que además son productos con variaciones que lo que quiere es calcular el precio mínimo por unidad que tiene ese producto que puedes tener, vete tu sabe cuántas variaciones y hay bucles sobre bucles sobre consultas sobre consultas sobre consultas entonces tocando esta función no aquí sino aquí igual resolves el problema para el back pero por supuesto también para el front y te puedes permitir incluso no poner caches de página si eres valiente ¿vale? entonces bueno aprendizajes de este caso lo hablé con un algún compañero dice, ostras, es que el tema del memory limit si lo he puesto en WordPress esto porque petas y el fatal error es que se lo ha puesto a un giga la memoria digo, sí, bueno, tú puedes poner memory limit de WordPress a un giga pero si el PHP tampoco lo tienes puesto pues te vas a ir petando eso son cosas que se van aprendiendo por supuesto el número de elementos por página sobre todo la programación eficiente ¿vale? cuando hagamos código optemos por hacerlo de forma eficiente a veces merece la pena echarse media orilla más intentando darle una vuelta a todo esto para que las queries sean óptimas para en vez de lanzar una query en cada loop lance una query al principio y luego me tengo los valores y ya luego solamente proceso los valores una vez que lo que sé hay muchas formas de optimizar la promoción de optimizar la promoción es eficiente ¿vale? y de tener en cuenta de que cada cosa que hacemos en la plantilla va para el front pero va para el back también ¿vale? otro caso este caso ya es de front ¿vale? ya dejamos el back mira Luis que es que tenemos unos valores de PHP que son chungo, que son los deseos, que dicen que tal y cuán ¿vale? pero es que yo cargo la web en el mobile y va muy rápida entonces yo no sé qué pasa aquí ¿Algún problema de tener ahí en la web? seguro como en normal en toda la web hay problemas efectivamente la web va rápida pero el page es bien malo hay a veces la forma de enfocar un problema es ese enunciado que te dicen a ti de volver la pregunta y de hecho preguntártelo a ti mismo seguro que la web va rápida seguro que aunque el page es bien muy malo uno se lo pregunta eso y devuelve la pregunta esto era un vídeo que hace es ver cómo carga la web en un mobile mi mobile el otro día con 3G la web cargo super rápido pero cuando empiezas a navegar ves como la imagen tardan en cargarse los vídeos se quedan con un rectángulo negro y no se ve ese tipo de cosas empieza a usar herramientas para ver qué pasa esto es otra de las herramientas el enlace empieza a medir cosas de la home, de la receta navegando por la web porque tampoco a ti lo que te llega del SEO lo que te llega al cliente es la web va muy lenta pero el VPO la optimización de velocidad mejora de velocidad yo no las abordo por web las abordo por URL cuando me fui a la página inicio para ver cómo va el cliente en lo que todo el mundo pone en PageSpeak como va la web rápida en esta web en concreto cuál es su fuente principal de tráfico en este caso la receta vamos a ver la receta vamos a trabajar la receta no vamos a trabajar ni en los pods de blog ni en la home, ni en nada vamos a trabajar la receta entonces empezamos a trabajar la receta ahí tenemos esos casi 10 segundos del expediente que es la suma de tiempo del lcp un montón de cosas fijaos cómo en cada uno de los test que se está haciendo fijaos la captura de pantalla el cls está de puta madre el cls no tengo problema ninguno pero el lcp el fcp hay mucho rojo ahí a ver qué pasa seguimos con la URL importante qué hago, voy a desactivar el plugin de cookie a ver qué pasa no voy a ver el plugin de cookie para un cuñetero javascript y para la ventana que también deseo expreso al cliente los plugins de cookie, faldones hay 20.000 formas de hacerlo deseo expreso es que sea así en modo modal vale está el plugin de cookie ahí ya me ha dado una pista bueno, seguimos y desde hace un tiempo estoy trabajando con ese atributo estoy experimentando con ese atributo no es que lo ponga por defecto en todo pero estoy experimentando con ese atributo ¿por qué empieza a trabajar con eso? bueno, porque vi que el lcp 5.7 aquí ya en esta otra medida es la receta 3.1 cuando quita el plugin de cookie la cuestión es que el lcp era un elemento que estaba retrasando mucho vamos a intentar trabajar el lcp en esta medición tuvo una medición de 2.15 tal y como estaba hecha la web fijaos que hasta unos 3 segundos casi después no aparece el plugin de cookie y después de aplicar el atributo el fetch priority el lcp se reduce pues es casi medio segundo casi medio segundo ¿por qué? porque le estamos diciendo al largador que mira en concreto en esta imagen que es el elemento más grande en esta receta cargame la con prioridad entonces en la etiqueta de imagen le ponemos el atributo y el ya el navegador sabe que esa imagen la tiene que priorizar ahora descargar datos entonces reducimos un poquito el lcp pero ostia, el plugin de cookie sigue dando la data ahí ¿qué pasa? pues digo ¿por qué había el plugin de cookie? a la configuración de plugin de cookie una vez la pantallita, la administración y navegando, navegando por la IPRO y del plugin de cookie veo ese parámetro retardo de inicialización del banner de 1.500 segundo y medio ¿por qué narices tiene que pasar esto? entonces ¿qué pasa? el plugin de cookie estaba configurado no vaya a mostrar ninguna razón pero estaba configurado para que el banner del cookie aparezca un segundo y medio después de que la página se cargue aposta claro ahí te lo recomiendas en fin, ¿ya está? bueno, pues eso, lógicamente se ha modificado han empezado a bajar los tiempos y de hecho estamos en ello todavía trabaja con las fichas de receta un trabajo que está ahora mismo en curso pero a pesar de todos esos valores raros que, o sea, van esos valores cifras en rojo que este viendo en page p en search console no se ve mucho pero bueno, por ahí cero url pobres ¿vale? que, vamos, este informe de search console lo saqué cinco minutos después de haber tomado las capturas de antes, del page p y todo eso entonces, search console me está diciendo que a pesar de esos problemas de lentitud, etcétera Google está considerando que no hay ninguna url con mal rendimiento y esto es una web que tiene visita que no es una web ni nueva, ni nada vale bueno, pues hay que trabajar en la ficha de receta incluso a pesar de lo que dice search console porque, lógicamente, sabemos que la experiencia de usuario en algunos casos es mala que es lo que hay que trabajar de las cosas que no voy a hablar optimizar imágenes, por supuesto optimizar las dimensiones, la calidad, etcétera hay que optimizar la carga de vídeos suelto el que es que? el youtube el youtube el video te refiere a plugin o te refiere a youtube? es mismo youtube bueno, eso es una fiesta optimizar eso es una fiesta por eso viene muy bien, a mí me está viniendo muy bien ese plugin, igual vosotros utiliza y otro que seguro que va bien pero a mí me está viniendo muy bien ese plugin porque con muy poquita carga se conecta rápidamente a la API la captura de pantalla y te muestra la captura de pantalla de la portada del video entonces, pues este plugin te lo sigue y yo estoy contento porque es que lo hace muy bien lo hace muy bien entonces, bueno, también otra de las cosas que estamos trabajando y que vamos a trabajar es search para IoT a punto de lo Andrés que tenemos que trabajar un poquito y otra de las cosas que no he hablado porque en realidad la he probado pero no la he he trabajado como para tener conclusiones que pueda comentar que es el uso de esta propiedad CSS te permite hacer como un lazy load de elementos HTML, no solo de imágenes sino de imaginado, tenéis un ADV que además cargue un montón de contenido dentro pues podéis decir que esa DIV en concreto por ejemplo, el footer de la página que por lo que se está super cargado podéis decir que el footer se cargue en plan lazy load con este tipo de propiedades entonces, qué cosa estamos aprendiendo de este trabajo primero lo que decía antes el trabajo de VPO no es para hacerlo en toda la web, en mi opinión el trabajo de VPO es para hacerlo en las URL que realmente son importantes en tu web y dentro de cada una de esas URL o de cada tipo de URL que queráis optimizar porque no lo mismo optimiza en este caso por una ficha de receta que lo optimiza en la home y después no lo mismo optimiza en una ficha de receta que en una ficha de un POS de la parte de blog, de unas noticias pues te tienes que concentrar en cada uno de los tipos de URL que tenga tu web para sacarle buen partido sobre todo para optimizar los esfuerzos si estamos optimizando VPO vamos a optimizar también el esfuerzo que dedicamos al VPO porque no queremos matar tampoco como cada caña porque luego parte de todo el cliente quiere una web rápida pero tampoco quiere pagar mucho entonces bueno otra conclusión que por supuesto hay que tener claras es que hay millones de herramientas para monitorizar VPO para tomar medidas etc y todas y cada una de ellas van a dar valores distintas ahora es como lo típico de que horas tenéis yo la una y yo la una puesto lo mismo otra cuestión que es súper importante es que hagáis experimentos con dispositivos reales acá hay el móvil que no lo tengo ahora mismo aquí quiero optimizar me han dicho el cliente que trabajes con la web no sé qué ven a mi google, creo, me mi no sé qué mi page, coge tu móvil y navega con tu móvil coges de tu chica o de tu niño navega con ese móvil de cualquier gama y próébalo porque a lo mejor una navegación tan simple como esa te puede dar mucha más información que todos los números del page alguna cosilla bueno, el último caso el del editorial ¿cómo llega esto? vamos a hacer esta web que está en WordPress, no sé qué pero mira es que aparte de que tenía que arreglar un tema de sincronización con un CRP, un CSV no sé qué no sé cuánto venga, es que aquí en esta web todo va más porque la ficha de los libros tarda mucho la ficha de los libros tarda mucho si fijaos en la captura de nuevo un plugin de cookie maravilloso ahí otro plugin de cookie, no es el mismo otro aquí tenemos los de Philkotepulfame Philkotepulfame Paint 2.8 casi 3, ahora como vemos 8 segundos el locking, el tiempo que tarda la página responde 300 milisegundos nos vamos a ser console 998 URL pobres ninguna URL buena está claro que esta buena necesita un repasillo si alguno sabe dupe peor por favor que bueno, esta buena necesita un repasillo te pones en ir a los datos, el ST por supuesto además que lo típico cojo mi móvil navegas en escritorio, va lento ¿por qué va lento? ahora vamos a ver vamos a analizar la web aparte de lanzar las herramientas que ahora la lanzaremos ¿cómo está hecha? bueno, está hecha con el impresa un tema de esos que ya sabéis que se pillan por ahí o un vpbacary bien plugins 44 plugins activos 44 plugins activos y algunos clásicos de... algunos clásicos en mi en mi contexto, igual cada uno tiene otros clásicos o para vosotros no son problemáticos pero en las web que es lo que estoy trabajando se cumplen ciertos patrones sobre plugins que afectan vamos a decir desfavorablemente al rendimiento de las webs, ¿vale? ST campaign espermalins bucomer pero cuando empieza a meterle coleguita al bucomer cada uno de su padre y de su madre tiene cuidado con las unteras eso siempre se ha dicho los feeds de las redes sociales que por alguna razón 2023 muchos clientes siguen queriendo que se ven los feeds de redes sociales en sus páginas web en fin quizá no tiene nadie de serio ni nadie con sentido común otro clásico del rendimiento web, warfans bueno y bueno, este otro lógicamente o clase contra los clásicos, ¿vale? entonces bueno ya está estamos analizando, ¿vale? estamos analizando tenemos nota de todo eso tiene YoAseo bueno, pero hubiera sido Ryan Mazz vale, vamos a analizar, ahora digo en vez de utilizar el página P utilizar web pages otra herramienta que tenéis por ahí para hacer análisis de rendimiento nos dan valores que bueno, si comparáis con la misma URL en otras herramientas recordad, estamos probando la URL de un libro concreto, vale, no es de la Homshin nos ha dicho un libro de una tienda online que vende, etcétera pues time to verify, 3 segundos empieza a renderizar algo a los 5 segundos el primer elemento visible casi 6 segundos cada 10 segundos en pintarse y no es porque estén rojo, ¿no? pero fijaos esto casi 3 segundos de bloqueo es decir, el tiempo que va entre que se carga algo y yo puedo interactuar con la página ¿vale? esto... el tiempo entre que se carga el tiempo que va el blocking time desde que empieza a cargarse la página hasta que tú puedas hacer algo a la página no puedas hacer nada porque está todavía cargando cosas pero la primera cosa ya ha sido cargada lo que pasa es que tú no puedas hacer nada todavía como usuario, ¿vale? no puedes interactuar con ella normalmente eso es cuando está ahí lo que mide mucho es tiempo de CPU de tu dispositivo ¿por qué? porque en navegador cuando lee una página pues tiene que procesar el HTML construir el DOM, aplicarle el CSS aplicar todos los scripts de javascript y todo eso es CPU CPU, CPU, CPU la CPU tiene sus limitaciones con muchas hilos que tengan ¿vale? bueno, esto era un vídeo que si queréis entrar vosotros en la URL podré entrar en editorialcity.com entrar en un libro y os tardará igual 14 segundos encargar la página ¿vale? esto es como ponerse una foto en el campo, ¿sabes? el típico waterfall ¿cuáles son todas las peticiones? por supuesto, aquí estamos viendo el time to fervide como decía Fran antes hay parte de aquí, no me acuerdo lo que coloré pero parte de aquí es resolución DNS y a partir de aquí ya, cuando ha pasado esos dos casi tres segundos cuando llegan las cosas, cuando ya el navegador empieza a procesar cosas y ahí todo lo ha escrito y todo CSS todo eso es bueno guay como cantaba tanto lo del time to fervide pues digo vamos a echarle un vistecillo o time to fervide vamos a recoger datos sobre eso a ver si es problema de hosting o a ver si es problema de la web porque claro, tampoco ningún cliente ni en todo el mundo tiene la posibilidad de que digo tengo un time to fervide de dos segundos me cojo la web, me la cambio el servidor y me toma por saco obviamente las pruebas vengan en otro servido directamente a veces no tienen una esa facilidad entonces pues bueno otra herramienta pero bueno, vamos a echarle el mano de Ludwig Lee que también es uno de los muy buenos amigos me gusta mirar siempre el autoload sabéis que cuando WordPress en cada una de las peticiones que le hace a WordPress cada una de las url, cada una de las cargas que hace ahí WordPress lee la tabla options y de esa tabla options de los cientos miles de registros que pueda haber hay algunas que si o si las carga siempre memoria porque la necesitas y porque los plugins la meten entonces cuanto a menos options con autoload haya ese milisegundo menos van a ser bueno aquí en este caso estaba por debajo del umbral que tiene considerado como un umbral peligroso que son 900 kilobytes de options y ojo no es el número esto no se refiere a los registros que lee de la base de datos WordPress en la opción de la tabla options se refiere a que cuántos kilobytes cuántos bytes de options necesitan macenar WordPress para cada una de las peticiones ¿por qué digo esto? porque sabéis que hay algunos registros, algunos plugins, algunos datos que se guardan en un solo registro de la base de datos de options pero el valor de la opción es json que te puede ocupar 10k pero está en un solo campo de una sola fila de options entonces igual te estás cargando solamente 100 filas de la tabla options pero es que hay un 20 o 30 que cada una de ellas ocupa 3 o 4k entonces por donde puede venir de ello otra cosa que viene bien mirar cuando tenemos bucomers y tenemos muchos plugins de bucomers es el número de crons que están activos ahí hay cientos de crons no sé por qué venga, seguimos mirando el time-to-fair byte uno de los comandos chulos que tiene wppcli el profile si lanzamos el profile stage contra la url del libro para lanzar el profile stage contra la url del libro pues mira lo que vemos aquí vemos que la parte de carga del wordpress al lanzar el stage lo primero que te hace es analizar las tres partes principales que considero wppcli que es la parte, el arranque de wordpress la coherencia principal y todo lo que carga es por parte de la plantilla ya cuando entra la plantilla a trabajar entonces que está moviendo porque la parte de carga de wordpress la va a partir a iniciar para los huevos y aquí ya cuando empieza uno a mirar este comando está lanzado en el propio servidor entra por ssh donde está alojada la web y ahí mismo pongo wpp este comando está trabajando directamente contra wordpress vamos a llamarle con localhost entre comillas entonces ahí estamos descartando tiempos de transferencia de acuerdo vamos a profundizar en esto ya que nos ha saltado estos dos segundos y pico vamos a introducir en el adenoso el wpp profile empezamos a ver aquí todos los hooks que lanza wordpress en ese arranque y empezamos a ver el número de funciones que está llamando cada uno de los hooks fijaos como aquí el hook de plugins de cargar todos los plugins llama 78 callbacks y tarda 600.000 segundos más de 600 el plugin de init 248 funciones tarda muy poquito hay problemas de base de datos aquí igual no igual no entonces bueno vamos a seguir profundizando en eso de los plugins vamos a ver qué pasa con el hook de plugins a ver si encontramos algo entrando en hook de plugins vemos todos los callbacks que todas las funciones que se hacen la llamada a la hora de cargar los plugins contra esa URL de la ficha del libro entonces vemos cosas que hay algunos de ellos que llegan casi a los 100.000 segundos la regla de descuento de bucomers este está el de paypal está en casi 100.000, 70.000 esto también es otra de las cosas que no hago cuando me pongo con esto el lanzamiento me sale la foto y ya con eso me voy a trabajar hago lanzamiento, lanzamiento, lanzamiento hago pruebas, hago lanzamiento voy navegando y a la vez que están navegando y muchas peticiones vuelvo a hacer este lanzamiento entonces voy tomando distintas capturas en distintas condiciones para intentar acotar el problema bueno pues esto va dando información ¿de acuerdo? nos vamos de la parte del servidor vamos a volver a las herramientas de front me empiezo a lanzar otras herramientas para ver otras mediciones y fijaos como en esta ficha del libro en esta url estamos cargando más de dos megas de javascript más de dos megas de javascript para una ficha de un libro en serio hace falta eso para poder comprar un libro te pones a mirar otras herramientas muy únicas para hacer presentaciones como esta algo que te saca uno gráfico muy chulo te pones a mirar el grafo de peticiones que es una forma muy cómoda de ver esa web toda la url externa que tiene entonces bueno pues por supuesto google active campaign sin haber entrado sin haber visto una ecoódica en eso ya puedes ver que está haciendo no sé cuántas llamadas a las fuentes, a fonts de google hace falta cinco fuentes para vender un libro el plugin de me parece que es de chat porque no no lo he puesto aquí porque me afeaba mucho pero hay otra llamada plugin de chat que no está conectada con ninguna que aparecía por ahí abajo digo igual la herramienta tiene que un fallo pero no sé y llamadas ocultas que te usare de donde vienes dos llamadas world time manager remarketing todas esas cositas que sí que hacen falta acordáis que hace un rato vimos el tiempo de bloqueo que eran casi tres segundos, dos con siete todo eso son javascript javascript que son porque si se han puesto porque hacen falta pero bueno igual se puede hacer otra forma no lo sé he coloreado los que me llamaba la atención he coloreado los que son plugin externos o sea los que son javascript externos llamadas peticiones externas y los negros están los que se llaman desde la propia web y están alojados en el propio hosting pero este digo el script campaign este viejo conocido vamos a echar un vistazo a ver si siguen haciendo las cosas así este script de script campaign está alojado en el propio servidor pero cuando miras el código lo que tiene es una llamada al script que están alojado en el script campaign entonces te está generando claro es una llamada interna que te está haciendo las peticiones externas que no vienen en ninguna parte menos que haga este tipo de pruebas dices amigo porque claro es que cuando yo me puse a ver los scripts y no vi ninguna mención a estos de aquí, que era bueno, no vi chiquitillos pero bueno, no vi ninguna mención a estos y bueno, esta en alguna parte tiene que estar y efectivamente estaban aquí metidos en este código de script campaign te analisis sin darle a aceptar la cookie no, perdona no, sí, le había dado a aceptar la cookie no, efectivamente esto es sin aceptar la cookie de verdad efectivamente es que es que efectivamente efectivamente y no lo he mencionado pero es que no está bloqueando cookies no está bloqueando cookies bloquear efectivamente y además en este caso que tiene activado el tracking ya no es que solamente está conectado sino que tiene activado el tracking efectivamente tendrían que volar y eso es otro síntoma es otro síntoma de cómo van las cosas de que no pasan más cosas porque nadie levanta la mano bueno y otro detalle importante que da también la herramienta de web page test es lo que pone aquí abajo el javascript o sea el html que se descarga el navegador después de que la página termina de procesarse esa cantidad de html ha aumentado más de un 8% con respecto a lo que había se ha descargado 100 kb de html cuando ha terminado de procesarse la página en realidad había 108 kb de html que hay que decir eso porque alguno de esos javascript está generando html ahí para algún efecto visual pero que eso influye, que queda bonico pero que se influye en el tiempo de bloqueo y la experiencia de usuario seguimos ya hemos dejado javascript, vamos al css 9000 reglas de css que bueno que no son ni muchas ni pocas, son 9000 pero como me aparece ahí un enrojo pues eso seguro que está mal 9000 reglas de css en algunos proyectos Andrés, verdad que sabemos que es otra regla de css y es una es un desastre es un desastre porque eso efectivamente también influye en cómo el navegador tiene que procesar y el tiempo que tarda en procesar y pintar y todo eso lo típico del proyecto, que va pasando muchos años va pasando por muchas manos, hay que hacer no sé qué cambio pues meto css el uso de mucho import que eso también es una cosa que afecta mucho al rendimiento 11 no 5 como yo al principio creía 11 web fonts, cargándose que bueno entonces que opináis vosotros de todo esto una buena verdad una buena verdad un plugin de css pues eso, una buena, solución número 1 un plugin de css no voy a preguntar cuál, solución numerado por dónde atacaría ahí vosotros alguna idea? no dejar que el cliente ponga plugin voy a darle administrador ya lo creo si por ahí pasan algunas de las cosas de luego es que quiero poner los descuentos para bucomer descuentos para bucomer, este plugin busque que buena pintada no se cuenta el descarga, puh, lo pongo dos días después, la hueva lenta la carga de condición al descarga también la misma atacaría ahí vosotros vale, la hueva de la buena nueva ya lo he dicho este hombre, la va a hacer él ya se la ha ganado 11 fontes y ninguna cargando de local todas cargando externas hostia, el hotting hostia, el hotting o sea que hay trabajo aquí hay trabajo para arreglar la línea de esa rosa que aparece arriba eso bloquea eso bloquea un archivo que no sigue leyendo nada hasta que no se procesa como tengas un timing pero fíjate una cosa Javier, señor Javier, señor Casares fíjate una cosa me he encontrado muchas veces con que estaba alguien trabajando en la web en su entorno local que dice tu bueno me pongo la web me pongo el repositorio y no sé qué para que me descarga la imagen voy a arreglar una cosilla y lo voy probando y te está bloqueando vas viendo que tú puedes hacer tus pruebas estás enfocado en lo tuyo pero sabes que ahí te están apareciendo eso y no le hacen ni caso y no le hacen ni caso a eso por eso nunca he quedado jajaja quiere decir que ese tipo de cosas que sabe uno luego se te olvidan cuando tienes que o no se te olvidan no las tienes tan en cuenta porque las das por hecho es una herramienta por eso para los que quieren ver para los que quieren ver qué más haríais vosotros y cambiarlo de hosting nos llamamos a Pagan que salemos para hacer la web nueva o cambiar de hosting jajaja ahora cogemos nos lo llevamos a Amazon y la web sigue quedando un segundo por supuesto configurar bien el plugin de cookie hay que configurar bien el plugin de cookie si queremos hacer un buen trabajo yo quería preguntar también qué opináis de jQuery la he quitado se usa se usa es como el jQuery se debe usar en el admin para eso se puso o sea el admin ya está en barro de wpi para que se usa en el frontal vale pues jQuery un viejo amigo bueno por mucho trabajo la verdad es que aquí hay mucho trabajo muchas gracias por vuestras aportaciones Andrés espero que hayas tomado nota que esto lo vamos a tener que mirar si bueno esto era para había puesto este ejemplo simplemente para que lo pusiéramos en común si alguno se le curó alguna otra cosa más quitarla quitarla web si hacesla de nuevo quitarlo en facebook hacesla con html esta mañana estaba probando con un compañero estaba con Akillera que me enseña una web con un compañero como hacemos antes la web con html puro y duro Time to fervide 200 milisegundos porque es un hosting de baratico pero bueno 200 milisegundos y bueno pues ya está Time to fervide a la pregunta que hacía ahí antes de afectar solamente el hosting a Time to fervide ya has visto que la movida que tengas en el arranque de WordPress afecta mucho ¿vale? ese carga de bootstrap puede venir dado puede venir dado porque sea un 2100 lo que está donde está al ojo esto o puede venir dado porque tenga mucho procesamiento bueno pues ahí terminando os voy a dejar aquí he notado algunas cosillas de algunas herramientas de las que he estado mostrando aquí otros que no están mostrando estos son algunas herramientas para hacer testeos masivos para montarte tu propia tu propio kit de VPO para que tú te montes tu propio layout tu propia monitorización para hacer monitorización continua sobre las web que trabajas etcétera porque como he comentado alguna ocasión una cosa es que midáis en un momento dado la URL sobre la que vais a trabajar porque vais a trabajar en esa URL concreta pero otra cosa es que la web evoluciona cada sitio tiene una vida y con la vida de cada sitio lo que mediste ayer que iba bien hoy lo mides y ya no va bien entonces la monitorización tiene que ser continua en la medida de lo posible en la medida que el proyecto de clientes te lo permitan y eso es lo que te va a permitir ir mejorando y por supuesto controlar ni el cliente mete cualquier cosa ni ese tipo de historias algunos enlaces algunos sitios que me sirven en el día a día y bueno, recomendaros query monitor para vuestra vida diaria incluso para los que tengáis niños y eso o en query monitor también podéis saber realmente lo que queréis, los que quieren los niños cuando os piden algo y configurar en el Google config también hace profiling eso es eso es para otras charlas para otras charlas si queréis y bueno por recordar y por finalizar algunas conclusiones para ir terminando después de todo esto merece la pena sentirse muy agobiado porque tengo que tener la web muy rápida porque es que tal siempre hay que poner las cosas en contexto una foto de page speed no vale para nada eso también es muy claro entonces pongamos herramientas pongamos conocimiento con respecto a la herramienta es bueno, antes de entrar a la herramienta y tener una cosa que siempre es clara que cuanto más HTML tenga la web más rápida o sea cuanto menos morralla tenga más rabida o sea las herramientas que no llegan ahora hay que aprender a manejarlas pero también hay que entenderlas los conceptos de core webvitas y todo demás bueno algunos son más complicados que otros de entender porque la tecnología a veces es un poco engorrosa pero lo que hay que entender sobre todo es que significan las cifras y ponerlas en contexto, eso es muy importante tener siempre presente la diferencia que hay entre la percepción y la realidad entre lo que os cuento un cliente, lo que os cuento un SEO lo que os dices las herramientas y la realidad de cómo son las cosas la realidad nunca la vaya a conocer podéis conocer algo con el real user monitoring de muchas herramientas, del mismo page speed bueno pues algo podéis tener en cuanto a la experiencia pero tener siempre presente que no todo es cierto recordemos mejorar el rendimiento de WordPress no es solo mejorar el front es mejorar el back porque la gente que maneja el back necesita tener una buena experiencia de usuario también y hacer rendimiento web en una tarea iterativa como acabo de comentar hace un momentito hay que estar midiendo y monitorizando y por supuesto pues como el coyote ser perseverante y por muchas veces que os caigáis por el barranco pues subí otra vez y he empezado otra vez la persecución y listo vale nada más si queréis comentar ahora lo que os venga bien muchas gracias por atender