 Más allá del rendimiento de nuestro hueldo. Así que vamos a acelerar. Muy bien. Muchas gracias, Julián. Venga. Vale, bueno, yo tenía un slide de presentación, pero aquí hay mis redes sociales y eso si alguien quiere, pero ya me han presentado. Entonces, me han presentado, yo quería conocer un poco el público, entonces voy a hacer un pequeño sondeo. ¿Quién de aquí ha estudiado cosas relacionadas con desarrollo, ingeniería, FEP, lo que sea? Vale. ¿Quién de aquí trabaja habitualmente, picando código, ya sea PHP, JavaScript? Vale. ¿Y quién de aquí toca de vez en cuando algo de código, pero no es muy lo suyo? Vale, más o menos. Ok. Vale. Muy bien. Pues vamos a hablar de performance. Vale. Siempre me meto este slide al principio, porque muchas veces el tema de la performance se ve alguna gente como algo friki, algo muy técnico, que no, pues quiero dedicar una semana a mejorar el rendimiento, pues no, eso no da valor a la empresa, no da valor el negocio. Entonces, a mí siempre me gusta poner gente que se toma muy en serio lo de hacer mucho dinero, que se toma muy en serio el rendimiento. Vale. Mi estudio favorito es el de Amazon, que estudiaron que por cada segundo extra para que su site tardaba en cargar, perdían al año 1.6 billones de dólares. Vale. Entonces, la próxima vez que alguien nos diga que el rendimiento no tiene valor de negocio, tenéis la cita, hay más, aquí tenéis un link con un montón de ejemplos. Vale. Pero la cuestión es que es relevante, técnicamente es relevante en términos de negocio. Dicho esto. Plan de la charla. Voy a tratar de hablar un poco de performance backend ¿Vale? ¿De qué no vamos a hablar? No vamos a hablar de recetas prechas. Si vosotros ponéis en Google performance WordPress, salen un montón de artículos muy buenos con recetas que podéis aplicar y van a mejorar el rendimiento de vuestro site. ¿Vale? Le hace elegir un buen hosting, kilos de SiteGround. Les invité a hacer una cuña, no han venido. Luego, pues, minificarte ese JavaScript, usar PHP 7, ObjectCache, todas esas cosas. Son recetas que tenéis que hacer, si os preocupa el rendimiento lo tenéis que hacer, lo está muy bien explicado ¿Vale? Entonces yo no voy a entrar en eso. Yo voy a entrar en explicaros los porqués. Cuando ya habéis hecho eso, todas las cosas de la lista, todo lo que os sale cuando buscáis en Google y sigue yendo lenta la categoría de producto de silla de jardín y tengo que averiguar por qué. ¿Vale? Voy a intentar daros las herramientas para que podáis ver vuestro caso particular donde tenéis los problemas ¿Vale? Entonces aviso que puede que sea un poco teórico, un poco técnico, pero mi objetivo no es que de lo que yo explique salgáis entendiendo lo todo, sino que cojáis las herramientas para luego cuando os encontréis en la situación poder hacer el análisis vosotros mismos ¿Vale? Así que vamos a empezar por el backend. Si alguien se pierde, voy muy rápido en algún punto, no tengáis miedo en levantar la mano y decidirme que repita algo que explica más algo. Volvemos a los noventa. Cliente, internet, servidor, base de datos ¿Vale? Os suena la web 2.0, la web dinámica, todas las historias, pues en ese cambio fue cuando se introdujo la arquitectura de backend que tenemos hoy en día en todos nuestros sites en que básicamente, aparte del cliente que es quien visita nuestra página web, le da nuestra petición, la gestiona un servidor que ejecuta un script PHP, ese script va la base de datos, carga datos, el script los procesa, prepara un HTML y lo manda al cliente. ¿Vale? Y esto es lo que sería el backend ¿Vale? Es muy básico, lo sé, pero el objetivo es tener las cosas claras para no perdernos en el bosque ¿Vale? Entonces, otra obviedad, PHP y MySQL funcionan usando procesador y memoria. Eso es lo que significa que si tenemos un problema de rendimiento de backend puede ser un problema de procesador, de tiempo de procesado o un problema de uso de memoria. Hasta aquí bien ¿No? Perfecto. Lo siguiente, la complejidad de nuestro código. ¿Alguien le suena? Big O. ¿Vale? Big O es una herramienta de análisis teórico de código ¿Vale? Es una tontería, pero queda bien el nombre en inglés y los gráficos ¿Vale? Os lo cuento, es muy sencillo. Básicamente es la forma que tenemos de decir nuestro código cuánto tarda o cuántos recursos necesita para procesar un conjunto de información. Es decir, yo tengo mi script PHP, tengo mi WordPress que está cargando 10 posts. Supongamos que por 10 posts tarda un segundo ¿Vale? Si paso de 10 posts a 100 va a tardar 10 veces más, va a tardar 10 segundos, va a tardar 15, va a tardar 2 ¿Vale? Esa relación entre la cantidad de datos que estamos procesando que habitualmente es un select a la base de datos de qué posts tengo que mostrar para esa categoría por poner un ejemplo, cuánto va a tardar ¿Vale? Y eso depende del código con el que lo procesamos. Si tiene muchos bucles que van dando muchas vueltas haciendo cosas lentas sobre cada post, léase buscar por relacionados. Léase un template que va lento, lo que sea. Pues vamos a ver distintas relaciones ¿Vale? Yo os digo esto directamente no lo vais a usar, pero es una herramienta súper útil para pensar cuando tenemos problemas con nuestro código. Vamos a ver algunos ejemplos. Esto de aquí, es eudocódico ¿Vale? No me digas, no compiladería roscphp. Cargamos 10 posts y tiramos el array, pintando el contenido cada uno de los posts ¿Vale? De acuerdo, esto es lineal. A más post más tarda, por cada post tarda lo mismo porque es esa operación que tarda lo mismo siempre ¿Vale? Entonces veríamos que es ON y identificamos ya los accesos a base de datos que son operaciones y típicamente pueden ir lentas. Siguiente ejemplo, y si en vez de cargar el post y hacer print lo que hago es primero cargarlos y des y luego para cada id, vuelvo a hacer una query a base de datos para cargar el post y luego lo printo. Pues también vuelve a ser lineal, pero ya tenemos dos puntos de acceso a base de datos que hemos pasado de un acceso a base de datos a 11 para 10 posts. Si fueran 100 son 100 un accesos a base de datos. Ojo, siguiente ejemplo, y si en vez de hacer un print del content del post, tira un template aquí. No lo sabemos, ya no es que puede ser bueno o malo, es que no lo sabemos, no tenemos el contexto en ese punto ¿Vale? Seguimos disfrutando de la flexibilidad de WordPress. Ahora añadimos, perdón me he colado un ejemplo, sí, exacto, perdón, ahora luego vamos a la flexibilidad de WordPress. Aquí otro ejemplo que ya no sería ON, sino que sería ON cuadrado, lo que estamos haciendo es para cada post, cogemos los posts relacionados ¿Vale? Entonces ya vemos aquí tenemos un bucle y otro bucle ¿Vale? Entonces aquí ya la complejidad se multiplica, ya no es que sume para cada uno que me tome más a la entrada, sino que ya multiplico, porque tengo dos bucles ¿Vale? Y ahora sí nos vamos a la extensibilidad de WordPress, disculpad. ¿Qué pasa si en vez de hacer el select nosotros tenemos un filtro, tenemos otro filtro, tenemos un do action, pasa que no tenemos ni idea de qué código se está ejecutando ¿Vale? Y ahora me diréis ¿Vale? Esto que te estás poniendo aquí, se taído la olla porque es un ejemplo muy complicado cuando si quieres pintar el contenido pones el primero y lo tienes ¿Vale? Noticias, todos los WordPress del mundo está lleno de cosas así como la última y peores, apatadas, todos sitios, solo uso WordPress Core y BuCommerce que son wow, también ¿Vale? Pero no os espantéis, no os espantéis porque el hecho en sí de tener ese tipo de código no es el problema, el problema viene cuando tenemos cuellos de botella, entonces ese tipo de códigos, ese tipo de situaciones pueden generar códigos de botella, pero depende de nuestro site, de nuestra instalación, de nuestro contenido, de nuestro servidor, donde vamos a tener nuestros cuellos de botella ¿De acuerdo? Y es por eso que nos sirven las recetas prechas, las recetas prechas del principio las tenéis que hacer porque tienen sentido, pero aquí es donde vienen los problemas. Disculpad, no estoy quedando por la gola seca. Dicho eso, siempre viene muy bien citar a Donald Kuhn, que es uno de los padres de la programación moderna, que tiene esa cita súper famoso, non-critical path optimization is the root of all evil. ¿Qué significa? Que si nos podemos optimizar cualquier pieza de código que vemos, eso podríamos hacerlo más rápido, eso podríamos hacerlo más rápido, estamos jodidísimos ¿Vale? Porque en general, cuando andamos a optimizar sin el contexto de nuestra ejecución, la liamos, en general, es una premisa de función en general ¿Vale? Entonces, lo que tenemos que hacer es buscar nuestros cuellos de botella. Y ahora me diréis, claro chico listo, pero como los encuentro, hay dos herramientas ¿Vale? Que sirven para eso. Una del tipo de herramientas se llama monitorización y otro tipo se llama profiling ¿Vale? Y os voy a enseñar unas capturas de una década ¿Vale? Pero básicamente la monitorización, lo que es, es una herramienta que instalamos en nuestro servidor y va agregando información de la ejecución cotidiana de nuestro site ¿Vale? Eso significa pues... Bueno, ahora veremos unos ejemplos, no me alargo. Y luego el profiler no nos da información agregada, pero sí que nos da el detalle de una ejecución, de un call trace que se llama, es decir, desde que un cliente entra por mi index.php y empieza a cargar todo el WordPress, el llamar los hooks, los plugins o sé qué, pues todo el hilo de ejecución que se da, el profiler me permite analizarlo ¿Vale? Entonces son dos tipos de análisis distintos. Con la monitorización vemos en general qué piezas de mi site valentas y con el profiling nos permite ver, cuando identificamos un problema, ir a ver qué partes de código tenemos que tocar ¿Vale? Vamos a ver. Yo os presento un new relic de monitorización, porque es la que uso yo ¿Vale? Yo trabajo con Pantheon IO y viene por defecto. Nos da una información así, una visión general ¿Vale? Esto es interesante, esto es un histograma de mi site, que básicamente lo que significa es la barra hacia arriba, es la cantidad de respuestas que doy por cada tipo de tiempo ¿Vale? En ese gráfico vemos que entre 400 milisegundos y 600 milisegundos tengo un gran volumen de respuestas y que luego de 600 hasta segundo y medio tengo la mayoría de las peticiones que estoy respondiendo ¿Vale? ¿Qué nos va a interesar de aquí? Tenemos un overview de transacciones, pero aquí tenemos un problema con WordPress, que es que al no gestionar las rutas, tal y como gestionar las rutas WordPress ese herramienta no acaba de detectarlo bien, pero bueno nos da un poco de idea si el login es lento, si la página es lenta, si el 404 es lento ¿Vale? Esto de aquí indica cuánto tiempo se está llevando a responder a cada una de esas peticiones, pero lo interesante es esa sección de aquí, tenemos WordPress, Hooks, Plugins y Sims y aquí nos saca la información agregada de cuánto tiempo está cada hook cogiendo del total de tiempo ejecutado que estamos monitorizando, en ese caso el init se lleva un montón de tiempo, luego tengo un Visual Composer aquí, que también se me está comiendo la mayoría del tiempo ¿Vale? Y en términos de Plugins y Sims pues igual, cada plugin y cada sim y vemos aquí el tiempo que consume ¿Vale? Ojo porque aquí por ejemplo arriba de todo está BuCommerce, pues que mi site es un BuCommerce, básicamente tengo un site que vende, entonces es normal, no es malo que este BuCommerce arriba, pero en tercer lugar tengo el BP Retina 2x que me da soporte, imágenes con retina ¿No? Que a lo mejor no debería ser el tercer plugin consumiendo más tiempo en mi site, a lo mejor aquí hay algo que revisar ¿Vale? Es ese tipo de información lo que nos da la monitorización y finalmente también nos da información de base de datos ¿Vale? pero estoy aquí, quien sepa SQL y optimizar queries y tal, pues ya se lo mira. Profiler, el profiler como vemos nos da una información, entra por aquí la petición, esto es mi index PHP, perdón ahí, y el index PHP llama esta, llama esta, esta llama aquí, tu tu tu tu tu tu tu tu, ejecuta y las funciones van devolviendo resultados, tu tu tu tu tu tu tu, y ahí volvemos el HTML ¿Vale? Esto es la ejecución, el call trace de nuestro WordPress, entonces la gracia, tenemos aquí un resumen de dónde se me va el tiempo, y podemos hacer zoom ¿Vale? Entonces por ejemplo aquí vemos muy claro que bucomers init, consume el 47% del tiempo de respuesta. Ese 47%, el 45% es bcloadcard. Y de este 45%, el 43%, 44%, es bucomers geolocation geolocateip. Pues si esa función me está tardando el 44% del tiempo de la respuesta de mi WordPress, seguramente tengo que ir a mirar el código de esa función, ¿no? Ok, tenemos aquí un cuello de botella, ¿vale? Respondiendo a la pregunta inicial. ¿Cómo vamos hasta aquí? ¿Sí? Habló demasiado rápido. Es que hay mucho por decir. Vale, ok, bueno, no se ha marchado nadie. Eso está muy bien. Sí, no, del total, del total, del total, ¿vale? Venga, front-end performance. Aquí es más sencillo, porque no tenemos arquitectura de servidor. Vale, aquí solo tenemos que saber cómo nuestro navegador está procesando lo que le devolvemos, ¿vale? Entonces, ¿qué hace el navegador cuando recibe nuestro HTML? Empieza generando lo que se llama el DOOM, que esto os va a sonar de DOOM ready, esas cosas, ¿vale? Eso significa que nosotros le mandamos un archivo con HTML, que básicamente son tags estructurados, anidados, entonces el navegador lo procesa y genera un árbol, ¿de acuerdo? Entonces empieza por el tag HTML, el tag HTML tiene el body, tiene el head, y va construyendo todo el árbol de nuestra página. Luego, coge los CSS, y hace lo mismo. Hace un árbol de clases, de la herencia encascada, ¿vale? El CSS es hojas de estilo encascada, pues esa cascada se refleja aquí con también un árbol, y para cada hoja del árbol tenemos las propiedades que aplicar. Y luego, ¿qué hace? Coge el DOOM, el CSS DOOM, lo junta y genera lo que se llama el render tree. Y con el render tree empieza a mostrarnos la página, es ahora que sé que tengo que mostrar y cómo tiene que aparecer, lo muestro, pero no es tan fácil. Porque nuestro navegador no tiene toda la información de golpe. Recibe el HTML, y ahí hay mencionados unas imágenes, hay mencionado un JavaScript, un CSS, el JavaScript se ejecuta, ¿vale? Entonces, la red influye en nuestra performance front-end. Primero tenemos el HTML, luego el HTML pide el CSS y el JavaScript, ¿vale? Aquí hay un tiempo muerto, ojo, ahí parece que tendríamos que poder mejorar. Luego lo procesa, luego genera el CSS1, luego ejecuta el JavaScript, luego puede volver a hacer el DOOM porque se ejecuta el JavaScript, ha cambiado algo con lo cual tengo que reconstruir el árbol, etcétera, etcétera, ¿vale? Y es en ese proceso donde se nos va el tiempo, por tanto es ese proceso que hay que optimizar. ¿Qué herramientas tenemos para optimizar eso? ¿Viene eso ya? Sí, ¿vale? ¿Qué herramientas? Lo primero que necesitamos para optimizar es medir, no podemos optimizar sin medir, para el backend ni lo he mencionado porque es el time to first visit, es cuando tarda el servidor en responder. Pero un front-end esto es más complicado, ¿vale? Hay una herramienta, voy a poner los ejemplos de Chrome, ¿vale? Que es el audits, que básicamente esto es como el page speed insights, pero sin ser el page speed insights que va fatal, eso lo tenéis en vuestros navegadores y podéis correr los audits en local, con muchísima más fiabilidad. Entonces os da unas ideas de cosas que mejorar, que esto pues si lo dice hacerlo, y luego os saco unas métricas, ¿vale? Saca 6, yo recomiendo que os fijéis en 3. First print, es decir, cuando el navegador empieza a mostrar contenido, tiempo que tarda el navegador en dejar al usuario interactuar, hacer scroll, hacer click en un link, los hovers, todo eso, y luego el tiempo en que el CPU deja de funcionar, ¿vale? Porque puede pasar que esté renderizando, pero luego tenga cosas que ejecutar y aún está dándole dándole, aún está la página cargando, ¿vale? Entonces es el tiempo en que se determina la carga, por decirlo de alguna forma. Aunque puede ser que el usuario haya visto cosas antes. Audits, siguiente tab, performance. ¿Alguien sabe usar la tab de performance de Chrome? ¿Sabéis por qué? Porque es infumable. Pero a pesar de ser infumable, es de lo mejor que tenemos, chicas. Así que hay que aprender a usarlo. ¿Vale? Voy a dedicar unos minutos a intentar explicarlo. Primero, cosa que nos tenemos que fijar, líneas verticales, ¿vale? Estas son las métricas estas, ¿vale? Entonces, si vemos que esta, por ejemplo, que es el final de la carga, pasa después de que equipase algo y que hay mucho tiempo muerto, tal, ¿vale? Nos va dando información. Luego, arriba, arriba tenemos una historia de tiempo, ¿vale? Desde que he pedido la página, le he dado al intro, al URL o hecho F5, hasta ahora, con lo cual, cuando lo miremos, habrá un cacho de tiempo que nos dará información. Tenemos que hacer zoom, ¿vale? Hacemos zoom aquí. Entonces, de aquí nos saca esa información. Esa información nos tenemos que centrar solo en main. Bueno, solo, a ver, a empezar. Nos tenemos que centrar lo que hay en main. En main hay todas las tareas que va haciendo el navegador. Lo que hemos visto, zoom, CSS zoom, render tree, ¿vale? Pues eso está aquí explicado. Entonces, ¿cómo nos lo muestra? Pues hace tasks y dentro de las tasks pues las distintas tareas que hay, ¿vale? Fijaos que aquí tengo una cosita roja, que no es mi puntero, que nos dice, ojo, que aquí algo la está liando, ¿vale? Entonces, ya es un punto para empezar, ¿vale? Para mirar eso, como veis, a ese nivel de zoom es imposible de asimilar. ¿Vale? A ese nivel de zoom pues vemos una tarea grande, de tareas pequeñas y tiempo muerto. Y podríamos decir que vemos aquí dos lilas cuando las lilas están aquí y la mayoría. Pero no sabemos qué es y cuesta mucho bajar al detalle. Entonces, ¿qué hacemos? Hacemos zoom. Veis aquí que he hecho zoom pequeñito y aquí, ya se puede entender, ya se puede leer, ¿vale? Entonces, por ejemplo, vamos a ver. Aquí tenemos una tarea que está recalculando estilos, ¿vale? ¿Por qué recalcula estilos? ¿Por qué nos puede calcular todos del tirón? ¿Cuántas veces me estás recalculando estilos? Pues eso es una de las cosas que podemos mejorar para que vaya más rápido. Si nuestro proceso, en vez de calcular tres veces los estilos, los calcula 40, que no son números que me está inventando muy locos, son números reales, obviamente va a tardar más. Entonces, tenemos que ir bajando a mirar, ¿vale? ¿Cómo lo hacemos? Clicamos en la tarea y la tarea nos dice en esta task, pasan esas cosas. Entonces, yo voy a ver el recalculate style, ¿vale? El problema en sí no es que se recalcule el estilo, es que algo está haciendo que se tenga que recalcular el estilo. ¿Cómo sé qué tarea, qué cosa está pasando para que tenga que recalcular el estilo? Aquí lo tengo. Veis que pone iniciador y entonces puedo clicar aquí en rebel y me dice, ¿quién está haciendo que esto se vuelva a calcular? Le doy y he pasado de aquí, aquí se ve muy poquito, pero está esta tarea de aquí pequeñita seleccionada, ¿vale? ¿Qué pasa? Veis aquí abajo, dice, en medio de este paseado del HTML tengo una tarea que me schedule style recalculation, una tarea que está generando un, cuando puede recalcular el estilo porque he cambiado algo, ¿vale? Pues vamos a ver qué es lo que está haciendo eso, que línea está provocando que se tenga que recalcular para ver si la podemos optimizar, cambiar lo que sea. Igual que antes, nos vamos aquí a la derecha y tenemos qué línea es la que está generando que se recalcule. Le clicamos aquí y nos lleva a una línea de nuestro HTML. ¿Qué está pasando aquí? Pues nos ha llevado a una línea de JavaScript que seguramente está cambiando alguna clase de algo y cuando está ahí construyendo el DOM y el CSS DOM y cambió una clase, tengo que volver a mirármelo todo con la nueva información, ¿vale? Y ese sería un ejemplo, ¿vale? ¿Se entiende la idea? ¿Qué pasa? Que de esto está llenísimo y de esas hay de mucho tipo, ¿vale? Entonces tenemos que volver al principio de la charla, buscar los collos de botella y optimizar los collos de botella, pero no todos los collos de botella van a ser igual de eficientes en términos de una optimización cuánto tiempo nos va a permitir mejorar y a la vez no es el mismo esfuerzo cambiar un JavaScript de mi CIM que me he hecho yo con jQuery todo feliz que un script de bucomers del carrito, ¿vale? Entonces aquí es donde tenemos que volver a la visión general y decir, ¿vale? Aquella cosica que he visto ahí está aquí y me genera aquí pues un segundo 0.2 segundos y es WordPress Core, ¿vale? Ok, pues es lo mejor. Busco otra cosa para mejorar, ¿vale? Aquí ya es el balance y cuanto queréis bajar al detalle, etcétera, ¿vale? Pero la herramienta es ésta y el procedimiento de análisis es éste. ¿Y alguna duda de esto? Ahora creo que voy mejor de tiempo que me pensaba, alguna duda de esto. Vale, última herramienta que os enseño, ¿vale? Es el Coverage, ¿vale? Coverage no está por defecto en Chrome Tools pero si vais arriba a la derecha, los tres puntitos que es el menú de más podéis añadirlo, ¿vale? Esto se muestra al lado del console y tal. Coverage lo que nos dice es qué porcentaje de nuestros archivos se están usando en la página, ¿vale? Se copla un poco, ¿vale? Qué porcentaje de los archivos se están usando en nuestra página. Aquí vemos, por ejemplo, que tengo Assets en mi CIM, Assets, CSS, App, CSS, que sería como el archivo principal del CIM. Cuarenta cas, treinta y cinco cas sin usar. Hombre, pues a lo mejor si no tengo treinta y cinco cas de CCSU cargando, que se tienen que juntar con el render tree y que a cada vez que se recalcula, si tienen que volver a procesar mi performance sería mejor, ¿no? Ok. Lo mismo. Cosas típicas que os podéis encontrar aquí. Pues mira, tengo los estilos del Carty del Checkout en un archivo aparte, en mi SAS, pero cuando lo compiro lo genero todo del tirón y lo meto en un solo archivo y lo cargo siempre. Ah, muy bien. Bueno, a lo mejor te es práctico, pero está claro que procesar el CSS del Carty del Checkout en páginas no son ni al Carty del Checkout en términos de performance no tiene mucho sentido, ¿vale? Entonces, bueno, con esta herramienta del Coverage, podemos tener información sobre qué estamos cargando, qué nos estamos usando. Si os fijáis aquí, en ese ejemplo, la mayoría de bytes de CSS y JavaScript que está cargando esta página, no se usan en esa página, ¿vale? Entonces, obviamente reducir eso mejora nuestra performance front-end. ¿Vale? Y creo que os he tirado un montón de ideas. Entonces, preguntas, debate, opiniones, insultos, lo que queráis. Venga. Me gusta mucho que me hagas esa pregunta. Pues básicamente, en general, tenemos en nuestro FunctionsPHP un EnqueueScript que está cargando pues nuestro script o nuestro estilo, ¿no? Pues, ¿qué hacemos? En vez de generar un solo archivo y hacer el Enqueue sin contexto, o sea, en nuestro FunctionsPHP y que se ejecute siempre, ¿qué podemos hacer? Cuando compilamos nuestros estilos o los hacemos a mano, aquí cada cual a su gusto, lo generamos en distintos archivos en función del contexto, ¿vale? Es decir, si yo tengo un CSS para las landings, un CSS para los productos y un CSS tal y un CSS común, porque hay cosas que van a ser comunes, no nos olvidemos, pues luego en mi Functions puedo mirar el contexto, por ejemplo, puedo mirar el típico isAdmin, isProduct, is no sé qué, pues si no es Product, no meto los estilos de Product, ¿vale? Y es ese tipo de técnicas que puedes ir sacando, ¿vale? En general lo que se hace cuando partes de tener un CSS todo agregado es, ¿sigues cargando el que tienes ahora como general y vas quitando cosas? Entonces para cada contexto vas quitando. Eso tiene otra ventaja muy importante, que no lo he mencionado, que es que la complejidad de los electores CSS cuanto más complejos son, más tiempo de carga requieren, es decir, si mi selector son cinco clases o un peor idés que son más lentos o Enth, Child, blah, blah, ¿vale? Hay algunos que son más lentos que otros y cuanto más anidemos el CSS U, os recordáis del árbol, cuanto más anidamos más grande es el árbol, cuanto más grande es el árbol más difícil es de procesar, más tiempo requiere. Entonces el hecho de sacar estilos por página nos permite sacar esos electores que siempre ponemos al principio y buscamos un selector del body para que sea producto, no sé qué, pues nos permite gestionar el contexto no en el CSS sino en el PHP, o lo cual tenemos una carga también más liviana, ¿sí? Gracias por la charla y un momento, una duda un poco. ¿Qué lugar, un archivo CSS unificado en el file o varios archivos? Lo digo porque hace poco, el baby, por ejemplo, le comentaba usar un solo archivo, lo que pasa es que cuando vas a usar un archivo para una tienda, para varias páginas distintas pues en este archivo hay un montón de códigos que no se usan en una sola página dividiéndolo en varios archivos pues son más decisiones de CSS-TP. Muy buena pregunta también, vamos a ver, como todo en esta vida hay que encontrar un balance y tienes que analizar tu caso particular. Argumentos a favor de pocos archivos hay varios, el tiempo de carga no te tendría que preocupar tanto porque son peticiones que se hacen en paralelo, ¿vale? Con lo cual, si inician todos al mismo tiempo entonces que sea una o sea n en verdad estás bajando la misma cantidad de bytes si que tienes un margen de error, del tiempo de conexión tal no sé qué pero que tende ser mínimo. Otro argumento es la caché del browser ¿vale? En esas recetas que os he dicho hay una cosa que es configurar los headers de cache, básicamente lo que hace es que el browser cuando tiene un CSS no lo vuelve a descargar siempre, sino que lo rehusa, ya me lo he bajado, me acuerdo, es de la misma referencia no me lo vuelvo a descargar y eso mejora nuestro tiempo en la parte de red no necesariamente en la parte de procesado, entonces tienes que analizar tu red, tus clientes, claro no es lo mismo, si tienes clientes distribuidos por todo el mundo o si tienes un negocio local en Málaga y tienes clientes de Málaga y tienes el servidor en Málaga tienes que ver, tienes que ver, ¿vale? Hay como estos factores y tienes que ir ponderándolos, no es que usar muchos distintos sea mejor y uno sea peor, ni viceversa. Me limito a decir es que cargar mucho CSS, ojo porque implica procesar ese CSS muchas veces, cada vez y eso perjudica perjudica más otra cosa, puede ser, hay que depender del contexto Yo lo que intento es cargar tres archivos, CSS en un máximo y inversiones para poder usar una caché y también si tengo que hacer un cambio pero una vez son nuevas y ya... Aquí lo que yo os diría es, os vais aquí y veis si tenéis un problema de recalculo de estilos o no y habitualmente el problema es de JavaScript en general, ¿vale? Hay que ver el caso venga Blackfyre No lo sé porque no lo pago yo Blackfyre es de pago pero eso es la versión gratuita que te instalas en tu local y yo siempre uso la gratis y me funciona súper bien Vale, te quería preguntar si salas de herramientas alternativas que sean auto, autónomas Todo esto te lo puedes instalar en tu propio servidor Si, no, las dos te las tienes que instalar en tu servidor pero son SAS Tú subes los datos a una plataforma y ahí los consultas La verdad es que yo antes usaba para profiling el XH Proof pero el XH P7 está... bueno, yo no me he clavido con él y me he pasado Blackfyre, va a ser honesto Hay herramientas pero... Pero se va a ser aquí de bus con lo cual no lo puedes tener introducido Cada cual tiene sus limitaciones Yo en ese sentido si tenéis un site, eso importa para sites con bastante tráfico, entonces yo soy muy fan de usar los PAS, platformas de service A mí me gusta el Panzone IO y platformesh y ambos tienen ya las herramientas montadas y tal y la verdad es que tú lo instalas y te meto una varnish por delante tienes redes para el object cache o sea, en plan, si alguien os paga las horas para miraros todo eso, vale es que puede pagar un servicio de ese tipo porque esto es así No te sé decir más, lo siento ¿Alguien más lo digo antes de repetir? Eh, pues dale Yo he usado enginex como proxy de reverso y he usado varnish Ambos van muy bien, o sea, aquí un poco el equipo que tengas, lo que se sienta cómodo También depende bastante de las políticas de invalidación de cache, va a ser muy bien y también de las herramientas que hay que ver con las herramientas de las políticas de invalidación de cache ¿Túal mundo sabe que es un proxy reverso? Vale, un minuto para contarlo, vale Un proxy reverso es cuando nuestro cliente hace un apetición al servidor no lo mandamos directamente al PHP a procesar y generar la página sino que pasa por un sitio intermedio que dice esa página ya me la sé, sí, ya la tengo te la paso sin ejecutar el WordPress y si no la tengo, ejecuto el WordPress, cojo la página la mando quien me la ha pedido y me la quedo para la próxima ¿Vale? ¿Eso lo que hace? Que si tenemos, por ejemplo, mucho tráfico en la front page, estamos sirviendo la front page igual a todo el mundo no tenemos que calcular la front page cada vez, la calculamos una vez al día y solo mandamos el HTML estático ¿Vale? Eso, si tenéis lo mismo alguien que os paga para dedicar horas a mirar eso eso lo tenéis que tener, ¿vale? Entonces el me pregunta entre varias herramientas, entre enginex y varnish para mí depende de qué políticas de invalidación tengas que usar, por ejemplo yo en enginex con bucomers necesito un cache vary que significa que añado un atributo a cada cache y genero una página de producto por cada país porque en cada país voy a tener una currency distinta, voy a tener una moneda distinta y voy a tener unos impuestos distintos con lo cual esas páginas me van a cambiar en función del país entonces necesito que mi proxy reverso guarde una copia distinta de la misma página en función del país yo soy un enginex, uno sefer, uso varnish, por ejemplo depende de esas cosas da igual, da igual, si, si en verdad hay plugins que te lo hacen a mano guardando HTML en un directorio porque hay situaciones en las cuales no puedes cachar toda la página no sé el que uses esitax que es una movida un poco compleja entonces igualmente las páginas que no se pueden cargar con el proxy reverso necesitas cargarla rápida entonces tener un proxy reverso no significa que no tengas que optimizar la performance backend en ocho mil productos, ¿qué tipo de productos? camisetas, zapatos, vale vale no digo porque es un ocho mil con las variaciones de talla y color en 32 mil, aquí hay un problema yo uso bucomers pero los hechos por delante bucomers no está pensado para manejar esos volúmenes esto es así y es una lástima entonces vas a tener problemas seguro en mi experiencia con esos volúmenes, con tienes volumen de contenido el bottleneck está en la base de datos ¿por qué? porque está todo en post y en post meta tienes unas tablas gigantes con unos índices de mySQL generados que no están diseñados para esas tablas gigantes con lo cual la query esta es lenta, o sea cada query a post te puede tardar 1.5 segundos que eso es lo que te mata en ese caso entonces ¿qué hacer en ese caso? optimizar la base de datos, o sea harías todo ese análisis y seguramente te llevaría a que el PHP lento lo que tiene lento es una query a base de datos, entonces pues miras qué queries son y aquí hay que saber ese query para ver el select que está usando en el where, la cláusula where, y ahí hacer índices para esos where, para hacer las queries más rápidas, que van a hacer las queries select más rápidas pero las de update más lentas entonces, ojo también no sé si respondo a tu pregunta, o sea todo eso es válido todo esto es válido pero te avanzo que en ese contexto tu problema va a ser eso, y creo que vale, está ahí yo os diría, si os quedan dudas o tenéis casos particulares, me podéis coger por aquí, ahora hay la merienda o después, o en el afterparty yo hasta el quinto gin tonic, hablo de performance sin problemas gracias