 Bueno, pues aquí seguimos. La siguiente charla que me toca presentar ahora viene el crax de los crax supremos, el maravilloso Fernando Puente para mí, y sí, ¡Oh, me he dado un begotón que te has dejado Fernando, que lo he todavía visto! Madre mía! Y el que bien tiene esta indigita la ropa, eh. Aquí me aspiramos con el mercadillo. ¡Qué guay! Bueno, voy a presentar a los a Fernando y yo dejo con su charla. Fernando Puente es informático de vocación y profesión, formadora vocacional para anotécnicos y beguiners de comer y beber. Esa es buena, eh. Últimamente estás en modo muy hogareño. Yo te echo de menos en la Workamp, lo he de decir, te echo de menos mucho. Y desde 1996 llevas trabajando en tecnologías de la información Cobble Incluido y desde el 2007 utilizando WordPress en proyectos internacionales para medios de comunicación y comercio electrónico. Para mí ya te digo que es un placer dejaros con este crack y su ponencia sobre mitos y realidades sobre WP en WordPress. Lo de siempre, recordad que al final de la charla en los últimos cinco minutos recojamos vuestras preguntas por el chat de YouTube para luego compartirlas con Fernando Puente. Fernando, ¿todo tú y yo? Muy bien, muchas gracias. Buenas tardes. Bueno, vamos a preparar. Y buenas tardes y bienvenidos de nuevo a esta maravillosa iniciativa de la comunidad que es Work en España. Hasta la fecha pues el mayor evento WordPress organizado en el nivel mundial. Espero que todos os encontreis bien y que estéis disfrutando y disfrutéis de estos acordaros tres más un día de Work and y que saqueis provecho de todo este conocimiento que se comparte y de todo el networking que se va a generar. Y como decía en el título hoy venga a hablar sobre WPO y todo lo relacionado con la optimización de tu sitio web. Tanto de algunos mitos como de muchas realidad. WPO, no? Eso que solemos relacionar con velocidad, presteza, rapidez, eficiencia. A todos los viene a la imagen, la cabeza o nos viene a la cabeza una imagen parecida pues eso, ¿no? A una parada en boxes, ¿no? Parecido a lo que tenemos en la fórmula 1. En este simil sería el piloto nuestro usuario y nosotros somos la escudería y en cierto modo es parecido, ¿no? Perfecta sincronización de todos los elementos y dar servicio en el menor tiempo posible. Aunque la realidad en el día a día, siempre desde un tono jocoso se parece más a esto, ¿no? Porque no todo está siempre tan perfectamente coordinado ni tenemos los mejores recursos ni podemos dar siempre el mismo servicio ni siempre al mismo usuario ni siempre la misma condiciones. Así que al menos prioricemos qué mejorar esa será nuestra estrategia de WPO para nuestro proyecto concreto. Soy Fernando Puente como decía a Charla, como decía a Carla, perdón, soy embajador de marca de GIF, me defino como informático de vacación y de procesión. Desde 1996 trabajando en internet, desde 2007 con plataforma de WordPress y estoy especializado en sitios internacionales de alto tráfico y comercio electrónico. Y en la sesión de hoy pues hablaremos de eso de WPO, ¿no? Unas siglas que tienen un significado para mí mucho más amplio que lo que es velocidad y que me gusta definir como aquellas estrategias y tareas de diseño, de desarrollo, de optimización, de mejora del rendimiento, de gestión de los recursos y herramientas disponibles, de todo ello orientado a que el servicio que da nuestra web o proyecto online sea el óptimo para todos y para cada uno de los usuarios que lo visitan. Y súper importante en cualquier soporte y en cualquier momento, que no siempre es igual. No solo cuando ejecutamos el PageSpeed de turno, sino cuando vienen nuestros usuarios a visitarnos que realmente cuando debemos de dar el mejor servicio. Pero lo que buscamos y buscan nuestros clientes es el Unicorrio Blanco, el famoso mito del 100, con el que posicionaremos mejor, venderemos más y seremos más felices, o suena, ¿verdad? Y probando solo lajon, claro, que es otro de los errores habituales. Pero cómo conseguir esenciado por mucho el 100? Lo primero debería ser leer las recomendaciones de las herramientas de turno que normalmente nos dejan igual. Son muy genéricas o no aplican a nuestro proyecto concreto. Pero realmente lo que deberíamos hacer es preguntarnos qué está afectando al rendimiento de mi página. Es decir, saber por qué tu sitio es rápido o lento y cómo minimizarlo o prevenirlo o tener la suficiente capacidad de análisis para ver que no podemos optimizar más y que nuestro KPI para esa herramienta concreta sea un 80 o un 69. ¿Por qué no? Si tuviéramos que hacer una lista, no acabaríamos. Eso significa que todo lo que me utiliza a mi proyecto web con WordPress acepta el rendimiento. La respuesta es sencilla, sí. O como diría alguno en dos palabras, todo. Desde la lección del dominio, el tipo de hosting, la tecnología empleada, el código que se utiliza, los temas, los plugins, las configuraciones, el software base, las versiones, todo afecta al rendimiento. Ahora bien, en mayor o menor medida. Y es este el ámbito de actuación del WPO, entender esos elementos y priorizar la resolución o mejora de los mismos. Entonces, ¿cuáles son los elementos más importantes? Si yo tuviera que representar de una manera gráfica factores que afectan al rendimiento en grandes bloques, lo haría de esta manera, de abajo arriba, de mayor a menor incidencia en el rendimiento. Quizá alguno les sorprenda que sea el usuario que más peso tiene, algo externo completamente a nosotros. Pero si os paráis a pensar, tanto su conectividad como su localización o el dispositivo usado, van a pesar sobre todo lo demás, sobre el servidor que utilizamos, el diseño lógico visual de nuestro sitio, el código ejecutar o la localización y tipo de nuestro hosting, así como el CMS he utilizado. Espero que vorple, evidentemente. Sobre algunos de ellos, podemos incidir más o menos. Intentaré repasarlos en cierto detalle y que prioricéis sobre todo vuestro trabajo de optimización. Vamos con ellos. Si esto fuera un ranking dentro de un blog, con un buen clickbait de los 20 factores WPO para hacer que tu página abuela y que Google no quiere que sepas actualizado 2020, el primero de sus factores siempre serían las imágenes. Las imágenes son uno de los recursos más fáciles de optimizar y que mejor rendimiento tenemos. ¿Cómo afectan las imágenes dentro de nuestra página? De muchas maneras. En cuanto al tamaño, en cuanto al número, en cuanto a la compresión, en cuanto al tipo, en cuanto al formato, mi recomendación, utilizar sólo los tamaños adecuados para cada diseño, comprimir las imágenes antes de subirlas y utilizar el formato más moderno y optimizado por tanto disponible. Por ejemplo, WP, si tu servidor lo permite. El diseño. Todavía no estoy hablando del tema elegido, sino de nuestro concepto de diseño en función de si es un diseño responsive, si vamos a tener un diseño por dispositivo o no, si vamos a ser simplemente mobile only, si realmente aplicamos un diseño mobile first. ¿Cuál es nuestra estrategia en el about default? Es decir, aquello que pintamos en el primer pantallazo. ¿Si vamos a utilizar o no formatos AMP? Todo eso va a influir muchísimo en nuestro rendimiento. Esa parte de diseño lógico. Luego veremos cómo lo pintamos o no. La Cache, la famosa Cache, ¿no? De servidor, de cliente, de proxy inverso, en un ACDN, de base de datos. Incluso cuando no podemos utilizar la Cache, porque a veces nos pasa, en función de la tipología del proyecto, es posible que no podamos utilizar todas las estrategias que existen alrededor de la Cache. Es otro de los factores que afectan mucho al rendimiento, pero quizá el más difícil de entender y de mejorar, más allá de la Cache del navegador. Algo muy sencillo de implementar, prácticamente con añadir cinco líneas de configuración a nuestro fichero HTA, de configuración del servidor, podemos habilitar esa Cache de navegador y nos va a dar un muy buen rendimiento. Los Escribe terceros, ¿no? La analítica, esos Pixeler de seguimiento, ese mapa de calor para saber por dónde el usuario está brujuleando, ese chat online que activamos, afectan, pero mucho. El propio Escribide Google Analytics es marcado como no optimizado por su propia herramienta de PageSpeed. Algo que muchos lo dicen, es que no lo entiendo. Pues sí, es cierto, es que no está optimizado. Mi recomendación utiliza solo aquellos que sean necesarios en cada página. Por ejemplo, es posible que el chat online o el pixel de seguimiento no lo necesites en todas y cada una de las páginas. A lo mejor solo en aquellas que necesiten de conversión o de ayuda del usuario. Y como veremos más adelante, optimiza la posición y secuencia de la carga en la página. Es decir, en qué momento cargamos esos scripts dentro de la página en cuanto a código y en qué secuencia respecto a otros scripts. Entonces, la publicidad pues acepta el rendimiento. Sí, es uno de los factores que más acepta el rendimiento de las páginas y tu proyecto utiliza estos recursos. Has probado analizar la web de un gran medio online. Verás que es uno de los recursos que más penaliza. Tiene una optimización muy difícil, ya que depende normalmente de la implementación de terceros, con lo cual nos limitaremos casi solo al orden de dónde lo podremos poner. Vamos a penalizar muchísimo más si en ese primer pantallazo que utilizamos para mostrar al usuario nuestra web utilizamos muchos recursos publicitarios. Es decir, un recurso que acepta mucho y de difícil optimización. Nos lo podremos quitar pues como decíamos al principio jocosamente, pues a lo mejor no porque es nuestro medio de subsistir. El time to verify, otro factor importante del que se han oído milion mitos o tiempo que necesita el navegador desde que realiza la solicitud de una página hasta que empieza a recibir el contenido. Y es una mezcla de muchos factores, con lo cual cómo mejorar este time to verify depende, por ejemplo, del ADNS. Depende del tipo de certificado, lo tengamos o no, a día de hoy necesario. Depende de nuestro servidor, donde lo tengamos, el tiempo de respuesta que tengas ese servidor, el tiempo en preparar esa página, la velocidad del cliente para recoger esa respuesta, como veíamos al principio. Muy importante ese recurso que es la velocidad de respuesta del cliente. Y que otros factores o mitos que se mencionan muchas veces no influyen, pues eso se escribe de terceros, porque normalmente se van a ejecutar en lo que se llama un evento JavaScript, que es después de recibir esos bytes, cuando ya se está pintando la página del usuario. Con lo cual, si queremos mejorar, no nos centremos en eso, centrémonos en esa parte de servidor, en esa parte de optimización de esos recursos que metenábamos antes. Antes hablábamos de diseño lógico y de diseño visual, y ahora hablamos de cómo pintarlo. Los llamados temas dentro de WordPress. Mitos aquí? Cientos. Que si abada no, que si divin mejor, que si yo soy del editor clásico, que si yo soy de Gutenberg, o del editor de bloques, que si los constructores dan peor rendimiento. De verdad, podríamos hacer una work-in completa solo con este temario. Técnicamente hablando, el rendimiento en el pintado en nuestra página viene dado por unas cosas muy sencillas, el HTML que está pintando, la regla CSS, es decir, cómo de complicado es ese pintado, y aquellos eventos y recursos de JavaScript que emplea el tema. Por lo tanto, el uso de maquetadores visuales, que añaden eventos y recursos adicionales, siempre tendrá un peor rendimiento, aunque sólo sea por una llamada a adicionales al librería de recursos. Por lo que volvemos a pensar en la balanza entre funcionalidad y pérdida de rendimiento. Son optimizables, sí, algunos de ellos incluso ya lo traen dentro de sus propias funcionalidades, y otros son optimizables con alguna de las estrategias que hemos visto. Por ejemplo, la caché. Y si el tema o el pintado, mejor dicho, es tan importante, ¿habéis probado con una arquitectura sin temas? Sí, sin necesidad de un tema dentro de WordPress, el conocido como Headless CMS. Ya tenéis disponibles varios frameworks o pensores para ello. Desarrollados, por ejemplo, en Riad, con un rendimiento muy, muy bueno en cuanto a pintado, pero en los que muchas veces perdemos toda la experiencia y funcionalidades que nos añaden los plugins dentro de WordPress. Como siempre, una balanza entre mejora del rendimiento y funcionalidad. De momento, nos seguimos quedando con los temas. Los plugins. Los plugins son la forma que tenemos para ampliar la funcionalidad de WordPress, quizá el recurso más potente dentro del ecosistema WordPress, y que nos facilita adaptar WordPress a nuestro proyecto en función de nuestras necesidades, con funcionalidades que por defecto no tiene WordPress, por ejemplo, un formulario de contacto, o por ejemplo, un plugin para mejorar el SEO, o la seguridad, o la caché famosa, o convertirnos en un comercio electrónico. Sí, también podemos convertir nuestro CMS en un comercio electrónico. Los plugins, ¿no? Otro de los grandes mitos. Y famoso número de plugins. ¿Cuántas veces lo habéis oído o escuchado? ¿Y qué hay de verdad sobre ello? Pues en realidad nada. Como podéis ver en este ejemplo de una web, sólo tengo siete plugins activos. Un número bajo para todos esos recomendadores de número de plugins. Quiere decir, entonces, que mi web está optimizada? Pues seguramente no. Y la respuesta es no. Os puedo asegurar que el consumo de recursos de esta web es altísimo. Incluso con solo siete plugins. Así que el mito es que no depende del número, sino de la calidad del código de los plugins, de cómo están desarrollados y cómo están implementados. Eso es lo que realmente va a afectar si se ejecutan en todo así cada una de las peticiones del usuario, cómo de carga de base de datos o cómo de carga de recursos tiene cada uno de esos plugins. Es realmente eso lo que nos va a afectar. Un recurso invisible para todos esos analizadores, pero una estrategia yo diría que de las más potentes en cuanto a optimización de recursos. La carga condicional. O dicho de una manera sencilla. ¿Qué recursos utilizo y tengo que cargar en cada petición de usuario? Y que está muy relacionado con el uso de plugins. Y como veíamos antes, de las posibles llamadas a recursos de terceros. Un ejemplo clásico, el plugin de creación de formularios. ¿Es necesario en todas las páginas? ¿Por qué lo cargamos en todas y cada una de las páginas? Seguramente no. O un plugin de valoraciones de contenido o de compartir en redes sociales. ¿Es necesario en la Jón o en la página de contacto? Seguramente no. Las cookies. ¿Realmente afectan? Sí, pero mínimamente sobre el global de la página. Hablamos de unos pocos bytes que se transiten entre el servidor y el cliente. Y la implementación correcta para anular el uso de cookies en tu proyecto puede ser más costoso que realmente el beneficio que obtienes. E incluso en sitios dinámicos es imposible que nos quitemos ese concepto de cookies. A lo mejor de los recursos estáticos y poco más. Con lo cual optimización difícil no prioricemos. El orden de carga, como veíamos antes, muy importante, fundamental para cómo optimizamos nuestros recursos. Ya tenemos claro todos los recursos que tenemos que cargar en nuestra página. Vamos a ver cómo minimizar el impacto sobre el usuario en función del orden en el que cargamos. Siempre se dice que pongamos arriba los CSS y al final los JavaScript. Bueno, eso es una regla genérica que muchas veces no aplica para todos. Pero sí aplica sobre todo para los recursos de terceros. No los voy a cargar hasta que no sean necesarios. Las precargas. Otro recurso, otra estrategia muy importante. Si ya sé que voy a necesitar, por ejemplo, una fuente de Google, voy a ir indicando al navegador, oye, estate atento, que es posible que me conecte para esto. Y una estrategia fundamental, innecesaria utilizar, sobre todo relacionada con lo que veíamos al principio de las imágenes y de otros recursos, es la carga diferida. ¿Por qué cargar recursos que todavía no está viendo el usuario? Lo habitual. Las imágenes, o iframes o la publicidad. Si el usuario está todavía en la primera pantalla, ¿por qué sigo cargando contenido más abajo de esa primera visualización? Aquí tenemos algo positivo a nuestro favor, que es que ya se están imprezando a implementar a nivel de HTML esa carga diferida en las imágenes. WordPress lo va a traer por defecto dentro de muy poquito y además los navegadores van a implementar dentro de muy poco automáticamente esa carga diferida para algunos de los recursos. Con lo cual es uno de las estrategias que ya podemos empezar a utilizar que se nota muchísimo y que en breve disfrutaremos automáticamente. El uso del ACDN, otro de los famosos recomendados y otro de los famosos mitos, no? Si mis usuarios están en España, ¿para qué voy a utilizar un ACDN? Pues seguramente para liberar recursos de servidor. La ACDN al final nos ayuda a tener nuestros archivos más cerca de los usuarios. Es una red global de contenidos que lo que hace es que el tiempo para recoger el contenido entre el navegador y nuestro servidor se reduzca. ¿Por qué no utilizar un ACDN para descargar de carga a nuestro servidor? Aunque sea dentro de nuestro mismo país, pues hagámoslo. Hagámos también posiblemente una estrategia de solo los contenidos estáticos al ACDN y el rostro a nuestro servidor y se complementa con esa ubicación del servidor, que cada vez va teniendo realmente pues menos peso. Si lo veíamos antes en la pirámide, estaba casi arriba del todo, todo lo relacionado con el con el cpd. ¿Por qué? Porque las redes cada vez son más rápidas, son más eficientes y los servidores cada vez son más eficientes. Antiguamente con redes muy muy lentas y muy pocos centros de datos disponibles, la ubicación de servidor era algo fundamental. A día de hoy es algo pues que no vamos a tener demasiado impacto en nuestro rendimiento. Las fuentes, ¿no? Que bonitas son las web desde la democratización de la Google Fonts. Nuestra web se han ido llenando de maravillosas tipografías, dicho de otro modo, de llamadas a otros recursos. Como veíamos antes es un recurso, así que otra llamada externa. ¿La tengamos en nuestro servidor o la tengamos en Google Font? Mi recomendación, utilizarlas solo si son necesarias, como veíamos antes y lo hemos visto a lo largo de toda la sesión. Donde sean necesarias, en el menor número posible y lo más optimizada en cuanto a pesos y juego de caracteres. ¿Por qué seguís cargando esos caracteres cirílicos y no los usáis? Y una última recomendación, que además mejora mucho el rendimiento es utilizar fuentes con varios pesos. Intentar utilizar fuentes variables. Uno de los grandes olvidados, las redirecciones. Total, si es solo una redirección, ¿no? Famoso 301, el 302, el 307, el 308. Al igual que en la fórmula 1, seguimos hablando de milisegúndole mejora. Todo cuenta y una redirección no necesaria también. Si son redirecciones nuestras, normalmente es fácil de corregir. Si son de terceros, es bastante más complicado. Si podemos corregirla, quitémoslo. Al igual que hablábamos con las imágenes, una de las estrategias más fáciles de implementar son las relacionadas con la compresión y el minify o mal llamado minificado de archivos, ¿no? Esta técnica consiste en reducir y comprimir los archivos de texto. Ojo, he dicho archivos de texto. Es decir, aplicaremos esta técnica a nuestros archivos HTML, CSS, Javascript, fuentes, ficheros Eclipse ML, incluso a nuestras imágenes en formato de SVG, que son también ficheros de texto. No comprimáis los .jpg, los .png, los .gith. Eso ya vienen comprimidos. Mi recomendación, utilizar compresión de archivos desde tu servidor. Es un recurso que requiere muy poquita proceso de servidor y que mejora muchísimo en la parte de cliente. La mayor posible, ahora mismo, sería Broadly con retrocomparatibilidad con GIT y un plugin que aplique minify automáticamente a tus archivos de texto. Si estás utilizando un ACDN ya no es necesario, seguramente ya lo estoy aplicando. Para mí, como pintaba, el segundo grupo de importancia en cuanto a cómo afecta al rendimiento de la página. Mi recomendación, última versión, era de todo el software que utilicemos, sobre todo hablando de PHP, que es el motor de nuestro WordPress. Compartido, dedicado, cloud, híbrido, infraestructura, hay mil tipos de servidor. En este caso, la parte económica tiene un peso fundamental sobre este recurso, pero no todo nos podemos permitir una infraestructura a medida. Tiene, como hemos visto en toda la sesión, importancia sobre el rendimiento, pero en mucha menor medida que, por ejemplo, el software que utilizamos en ese servidor. Podéis poner a competir una carísima infraestructura cloud desactualizada con PHP 5.6 y ninguna optimización de WordPress frente a un hosting compartido barato, pero con las últimas versiones de software y una buena optimización. O sea, seguro que ganará el segundo. Recomendación, el tipo de hosting nos lo va a marcar la necesidad del proyecto. Se puede empezar con algo muy humilde y con un muy buen rendimiento. Relacionado con el servidor también y uno de los factores que WordPress tiene un gran peso, es la base de datos. Ya que hablamos de un CMS que extrae los contenidos de ahí. Recomendaciones, limpieza que nos olvidamos, mantenimiento, orden, tamaño sobre este recurso. Y siempre que sea posible utilizar técnicas de Cache para intentar limitar el uso de la base de datos. Llegamos al final, lo que veíamos en el pico de la pirámide. WordPress influye en el rendimiento también, pero de todo lo que hemos visto, seguramente, sea el recurso que menos influye. Utilizar siempre las últimas versiones, por seguridad y por optimización. Si volvemos al mito, seríamos capaces de conseguirlo con todo esto que hemos visto? Pues seguramente no. Si estaremos más cerca del principio. Pero entonces os preguntaría, ¿esta es la medición que debemos usar? ¿Es fiable? ¿Es lo que buscamos? Para mí no. Al final, todas estas herramientas son recomendaciones y se basan en generalidades de buenas prácticas, que no tienen por qué aplicar a tu proyecto. Por lo que debemos fiarnos un poco y olvidarnos y tratar de convencer a nuestros clientes de no ir hacia Cionicorner Blanco. Os invito a utilizar otras herramientas de medición, como la que incorpora Google Analytics, sobre la experiencia real de vuestros usuarios, donde sacaremos mejores conclusiones. Lo que sí os puedo confirmar es que todas estas buenas prácticas redundarán en un mejor posicionamiento de vuestras páginas. Y una mejor experiencia de vuestros usuarios, que es en realidad, y no invito, lo que busco para mí y para mis clientes. Así que muchas gracias. Ya he traduido aquí entre todas. Eres un crack, Fernando. Interesante la charla. Bueno, no lo he dicho antes al principio, pero hoy es la ponencia número 25 de Fernando, ¿no?, en todas las workouts. Estamos haciendo una celebración y yo por eso tengo 25 preguntas para que me respondas en los tres minutos que tenemos así rápido. Intentaremos estar optimizados. Pregunta de una optimizada. Te voy a pasar alguna pregunta que nos han dejado por aquí. Muy bien. A ver, tenía por aquí de Nadia, que me la he hecho al principio, Nadia, no sé cómo se dice, la pedido, Juma. ¿Qué dice? ¿Cómo podemos saber si a simple vista si un plugin afecta la velocidad de la web, a simple vista? A simple vista, pues, con una sencilla estrategia. Pongo la web con el plugin y la web sin el plugin y hago las dos mediciones. Vale, normalmente, si no podemos hacer eso, a simple vista sería si me añade algún recurso, por ejemplo, una llamada en el HTML o una carga adicional de un recurso. Pero la prueba siempre, en la más sencilla es hago la prueba con el plugin y sin el plugin. Luego, a nivel técnico, hay muchas más estrategias, utilizar analizadores, leerse el código incluso, pero la más fácil de utilizar sería eso. Vale, hay una que me ha parecido interesante, que la he hecho, bueno, ésta de Eric, que decía después, a raíz de lo que decía antes, dice cómo saber qué calidad tiene un plugin, la calidad de un plugin, que es un poco de lo que venía hablando, pero me parece muy interesante una pregunta que nos han puesto ahora de Martín Mayolos, 7, que habla, a ver si no la va a ponen por aquí, que dice, cuando la herramienta de Google despeites nos habla de demasiados elementos, ¿cómo podemos mejorar eso? Eso es el famoso HTML, la complejidad del HTML. Ahí tenemos que ir a tocar el tema en nuestro caso, es el pintado. ¿Cómo ha de complicado? Es el pintado de ese HTML. Normalmente ese error nos suele dar cuando son temas multipropósito, que tienen, por así decirlo, muchísimas variables y la complejidad del tema, pues al final, pues tiene mucho sí, si tienen muchas cosas sanidad, es que lo que hace es ir complicando el domno, el famoso dolor, pero para poder incidir en eso, es el tema el que tenemos que tocar. Vale, y bueno, por último, vamos a otra pregunta que nos deja por aquí, hay mogollón de preguntas, recomiendo a todos y os animo a todos los asistentes ahora que paseis al canal de Zoom, a charlar un poquito con Fernando Puente porque está esto a tope y no nos da para ponerlas todas. Quería hacerla de Pio 7 que dice, que me parece también interesante, ¿qué herramientas de monitoreo en tiempo real usas tú para el tema del WTO? Vale, en tiempo real utilizo New Relic, que es una herramienta que me permite tener tanto visión de la parte de PHP, como de la parte de servidor, como de la parte de base de datos, esa es la que utilizo en mis proyectos, en lo que es el tiempo real, pero al final esto es un compendio de muchas herramientas. Todas las herramientas que utilizamos nos pueden dar un dato muy significativo, igual que hablaba antes de Google Analytics para saber cómo se estaban comportando mis usuarios, hablo de New Relic para saber cómo está la parte interna del servidor, las propias pruebas que yo puedo hacer incluso por línea de comandos del tiempo de ejecución de un script, todas esas herramientas que utilicemos son importantes, ¿vale? De una sola herramienta es muy difícil y es un poco lo que quería dejar como colofón final. Nos saquemos todas las conclusiones de pasar un PHP y automáticamente me dice tal, porque seguramente hay muchas más herramientas. Los propios proveedores de hosting proben de herramientas, algo tan sencillo como el AWWStats nos puede dar información, ¿cuáles son los recursos más remandados? Eso también es información. Bueno, pues nada, Fernando, muchísimas gracias. Gracias a vosotros por el currazo que os habéis pegado y gracias a todo el mundo por asistir hasta WorkOn Online. Nos vemos en la sala de network. Dale para allá y todos los que queráis iros para allá a charlar con Fernando, también recordar que tenéis el otro a la otra sala de Zoom para que paseis a charlar o hablar con los sponsors, no los dejes ahí abandonad ellos, que también ellos han pegado un currazo y sin ellos no estaríamos aquí hoy y mañana y pasado. Así que bueno, Fernando, un beso muy fuerte. Un beso muy fuerte, espero verte muy pronto. Seguro, vamos con la siguiente charla. Muchas gracias a todos, adiós.