 André Manero es programador dedicado a tiempo completo a contribuir a WordPress Core. Está patrocinado por automático como parte del programa Five for the Future y ha sido nombrado Core Committer deficientemente. Ha colaborado en el desarrollo de funcionalidades del editor de bloques de WordPress como el motor de estilos de bloques o el Zim.json. También ha implementado mejoras de rendimiento que afectan al frontend. En esta charla, André nos viene a explicar cómo utilizar esos bloques estructurados que son invisibles en la web, pero que si los usamos bien, pueden mejorar el rendimiento de la web. Venga, André, explícanos cómo. Muy gracias. Buenas tardes. He venido a hablaros de bloques de rendimiento, desde una perspectiva de bloques. Entonces, primero que quiero decir o recordar más que nada, son los bloques introducidos a 5 anos, WordPress 5.0, o que van a darnos una estructura a un documento HTML que no me ha tiñado. Antes trabajábamos con etiquetas figura y ahora trabajamos con un nivel superior. Trabajamos con imágenes, galerías, etcétera, que siguen estando representados por la etiqueta figura, pero no estemos maneras de identificar esos bloques. Eso veo que o bloque. ¿Por qué es esto importante desde el punto de vista de rendimiento? Bueno, porque los bloques tengan recursos asociados, tengan, por ejemplo, estilos, ¿vale? Y a capacidad de identificar qué bloques hay en una página nos permite enviar o unón o estilos asociados a ese bloque, ¿vale? Pensad que hasta introducción dos temas de bloques, los temas clásicos, tenían una folla de estilos enorme con todo, ¿vale? Entonces, o que os voy a contar ahora, un par de APIs para poder declarar o recursos que un bloque necesita e usa. No block JSON, este, digamos, archivo que define a estructura de un bloque, podéis decir o recursos que tengan asociados y dónde se van a usar. Por ejemplo, quiero que este JavaScript solamente se cargue no fronteéndome un sitio, o quiero que este CSS se cargue únicamente en el editor, ¿vale? Eso va a permitir una mayor granularidad, ¿vale? O hacer esto por defecto en los temas de bloques o que vaya a ocurrir es que estos recursos o bloques únicamente se van a cargar si un bloque está no te oposte. Si tú no te oposte, usas un bloque image, vais a cargar los estilos de image. Si tú no te oposte, no se va a cargar. Vale. Esto va por defecto en los temas de bloques. En los temas clásicos, puede se habilitar. Otra API, en este sentido, es un JSON en un archivo, en lo que tú puedes declarar los estilos de un sitio. Puedes decir cosas como configurar o acor de fondo los sitios globales. Pero también puedes decir, quiero configurar acor de texto de este bloque específico, la lista. Vale. Si usas este API o que vaya a pasar, es lo mismo que con anterior. Que si o te oposte, tenga un bloque lista, van a cargar los recursos de estilos de este bloque si no lo tienen, pues no se van a cargar. Vale. Esto era simplemente un par de ejemplos. Encanto a APIs que tienen que ver con bloques y recursos. Y ahora quiero palabras de rendimiento. O rendimiento en tema muy amplio. O que afecta al rendimiento, es muy variable. Afectan cosas como si o te usuario que está visitando este sitio, tenga una red de boa o cativa. Si tiene un dispositivo nuevo o antiguo. Hay muchísimas cosas. Si o te un sitio está alojado en un alojamiento web, en un servidor potente o no. Vale. Hay cosas que tienen que ver con WordPress. Que WordPress se llama rápido, favorece que otro sitio se llama rápido. Y, o te he contido, evidentemente, también afecta. Es decir, si tú te es un sitio web superoptimizado, un alojamiento estupendo, pero subes imágenes de 100 megas, pues te va a ir lento. Son varias esas partes que afectan al rendimiento. O que busquero favorecer aquí, o que tengan que ver con bloques. Y específicamente, o que como vemos, o rendimiento en core, en WordPress core. Vale. Y hay muchas métricas, una que nos estamos visiando para optimizar el tiempo de carga. Vale. O tiempo de carga. En este caso, usamos una métrica llamada LCP, que he definido por Google. Y, o que falle, medir o tiempo que tarda en cargar, o te he contido, relevante. Vale. Debajo de la charla, he dicho, pues, siempre ligazons, para que, pues, ya desespandir, pues, estos temas los que estuvo a tocar. No me muevo a parar, o que LCP, etcétera. Pero lo que me importa es que sepades que en core usamos o LCP para medir que tanto tarda en cargar tu sitio. Y específicamente, o que facemos mirar LCP de dos maneras. Subdividimolá entre o tiempo que se tarda en procesar la petición en un servidor y o tiempo que se tarda en navegador en pintar toda esa información que se ya envía. Vale. Para esto no hay una métrica, pero simplemente restamos el LCP de TFB, o Time2Festbite. Entonces, ¿qué hacemos? Bueno, pues, para cada cambio de código que tenemos, pull request, integración en Master, Trang, etcétera, comparamos dos temas. Un tema de bloques y un tema clásico. Vale. En este caso, estamos usando 2023 o 2021. Los dos tenen los mesmos contidos. Tenemos un conjunto de datos igual. Vale. Y lo que se está mostrando aquí es unos datos que tenemos, cuando hacemos un cambio de código, saber cómo varían las cosas. Vale. Aquí lo que está reportando es que o tempo del servidor, Time2Festbite, para o tema de bloques o 2023, eran 64 milisegundos y para o clásicos son 59, es decir, un poquito más rápido. Dos datos. No quiero que vos quédese los números exactos, porque esto es una configuración muy específica de entorno de pruebas. Si yo faco esta misma prueba en el computador, van a ser un poco diferentes. ¿Qué o qué importa? ¿Qué relación vas a ir a misma? Vale. Si haces esa prueba en local con la misma configuración y desver que va a ser un poquito más lento, un tema de bloques. ¿Por qué esto? Bueno, un tema de bloques, hay cosas que un tema de clásico, o a mayor no hay, por ejemplo, un tema de bloques, puede tener un simulation. Y hay que leer esos datos, procesarlo. Vale. Un tema de clásico generalmente no lo tenga, hay que podértelo. También es cierto que los temas de bloques le van do usanos disponibles y, entonces, a su optimización puede ser, tenemos que trabajar más en eso. Sin embargo, si ahora nos vamos a las métricas de cliente, vemos que un tema de bloques, o 233, es muy más rápido que un clásico que estamos mediendo. Casi 2 veces más rápido. ¿Por qué eso? Bueno, pues todo ese tiempo que en Servidor pasamos estudando a estructura del tema, similes son plantillas, modelos, etcétera, o que hacemos conseguir enviar únicamente los recursos que POS necesita, o CSS, dos bloques que se usan, etcétera. Vale. Un tema clásico en Sheralt en una follada de estilos que aplica a todo, vale. Y, entonces, simplemente ves que, como reduciendo o recursos asociados a un bloque, pues digamos que va a ser un mejor rendimiento en cliente. Tomando todo esto nos da que un tema de bloques, a pesar de que en Servidor, según estas estadísticas, sigue siendo más rápido en global. A experiencia que tenga un usuario es mucho mejor, vale. Bien. ¿Y por qué hemos contado todo esto? Bueno, no proceso de crear las métricas en Core, es saber qué analizar, nos demos cuenta de un par de cosas muy importantes. La primera es que experiencia de un usuario no siempre están correlacionadas. Tú puedes ser un servidor que tarda un poco más, porque faga más cosas y, al mismo tiempo, una mejor experiencia de usuario, vale. ¿Qué nos pasa aquí con un titulandric? Este es la primera, digamos, conclusión a que llegamos. La segunda es que, como vos decía antes, el rendimiento depende de muchísimas configuraciones. Entonces, ahora imaginad de vos que obosositio usa una caché de página. ¿Qué significa esto? Significa que obosositio, cuando alguien carga un post, carga una versión estática de ese post. No se carga todo que file Wordpress, vale. Entonces, en ese momento, en ese caso de uso, las diferentes configuraciones de Wordpress no importan, porque, o tiempo que tarde, a caché en devolver contido. Da igual, el tema de bloques, temas clásicos, si te des 50 plugins, usted es un. O el tiempo que tarda a caché en devolver contido. Entonces, este escenario, o que es súper importante que un navegador o cliente solamente reciba o que necesite. Solamente reciba o que necesite para que se llamáis rápido en pintarlo. Entonces, a mi única, básica, gran recomendación hay. Si facetes bloques, por favor, usad de asapes existentes, blog.json, cim.json, hashblog, todo lo que podáis, para únicamente enviar o cliente o recursos que se necesitan, o CSS, o JavaScript que necesita, etcétera. Y esto que vos quería decir, voy a estar, oye, a dar lo que voy a hacer en la conferencia. Puedes metodpar por los pasillos. Estaré también a mesa de WordPress.com. Entonces, estoy disponible para hablar de rendimiento, de estilos, o cualquier otra cosa que queráis comentarme. Y nada, simplemente dar muchas gracias por asistirles.