 Bienvenidas, bienvenidos a la charla de la siesta, habéis elegido la sala correcta para echarles la siesta y hoy vamos a hablar de cachear, os voy a poner un ejemplo, no es este tipo de cacheo precisamente, soy Javier Casares, me podéis encontrar en JavierCasez.com, tengo una web que hablo de temas de sistemas relacionados con WordPress que es o WPcSatmin y habitualmente me podéis encontrar en la red social donde estoy más habituado que es Twitter, o sea ahí me encontráis y una de las cosas que suelo hacer o en las que más me podéis situar dentro de la comunidad de WordPress es que soy uno de los cuatro team reps mundiales del equipo de hosting, de ahí la charla de hoy, hablar con conocimiento. ¿Qué hacemos en el equipo de hosting? pues básicamente somos un poco el punto intermedio entre el software, entre WordPress y todas las empresas de hosting que hay, como muchas de las que hay aquí fuera, pues tenemos cierta relación con ellas para que, por ejemplo, ahora que hay todo el problemilla de el PHP, que si 7.4, que si 8.0 y tal, pues un poco estamos intermediando entre el equipo de core y el equipo de, bueno las empresas de hosting. Varias cosas importantes, en general me vais a escuchar decir muchas cosas, no me hagáis caso en casi ninguna de ellas, obviamente todo está basado en mi experiencia, es muy probable que si hacéis las cosas que digo se rompan vuestras webs y es probable que diga alguna barbaridad, que a lo mejor luego hay que quitar de los vídeos, por lo tanto, espero, espero contenerme, sí, espero contenerme, ya está, es que si no empiezo ya y no. Esto es un poco la, la agenda, vamos a ver un poco qué es el web performance para situar un poco de qué va esto, aparte de las caches, os voy a hablar un poco de herramientas de medir para medir temas de web performance y un poco cómo medir todo lo que os explicaré después, os voy a explicar cómo medir, obviamente, si no de qué van a servir las herramientas, os voy a explicar un poco las diferentes partes de WordPress, seguramente ya la sabéis pero bueno, voy a enfocarlas luego con el tema de las caches, vamos a hablar un poco de servidores de hosting y demás, o sea, diferentes opciones o cosas importantes que tenéis que saber de vuestro hosting, qué luego van a servir para cachear y para acabar os voy a así explicar qué se puede cachear y cómo se hace, vale, luego veremos un par de datos, intentaba cortarlo mucho, hay muchas diapos, voy a ir rápido, vale, si alguien, bueno, habrá preguntas, espero, pero bueno, ¿qué es el web performance? Básicamente, web performance optimization o WPO tiene tres palabras, web en general, espero que sepáis lo que es, performance es rendimiento, o sea, mejorar lo que tenéis y optimization es optimizar, o sea, al final estamos redundando porque rendimiento y optimizar en el fondo son las dos cosas un poco lo mismo. En todos los libros que veáis o cuando se hacen referencia, sobre todos los de la fantástica marca de libros que saca animales en las portadas, utiliza el guepardo como animal de referencia para el tema de web performance, básicamente porque es el animal en principio más rápido sobre la tierra, habría, es dudable porque seguramente, bueno, sobre tierra sí, por iba a decir mosquito, mosca y demás que seguramente van bastante más rápidos. Otra cosa importante a tener en cuenta es la diferencia entre SEO y web performance, no es lo mismo, van de la mano, en el SEO lo que busca es la optimización de los contenidos y el web performance lo que busca es la optimización de el contenedor, del sitio web, del HTML, es un poco las dos cosas, por lo tanto, cuando tú haces SEO on page, o sea, optimizas tu contenido y haces WPO, haces todo el contenedor, pues obviamente si tienes el contenedor y el contenido tienes la respuesta al éxito. En herramientas para medir, básicamente hay tres, la primera y la que siempre tenéis a mano es, hacéis F12 en los navegadores, creo que en todos el F12 funciona, sale una cosa por debajo normalmente, que son las herramientas de administrador del webmaster y allí tenéis diferentes herramientas que os pueden servir para performance, yo por ejemplo de todas esas herramientas, la que más uso, en este caso por mi trabajo, es la pestaña de network, que es donde sale el waterfall, sale todas las peticiones, todo lo que hace con un poco los tiempos y demás, hay otra gente que seguro que usa más otras pestañas, estoy convencidísimo. Y dos de las herramientas que a mí me gustan desde el punto de vista externo, por diferentes razones, cada herramienta hay que interpretarla, una es web page test, es la primera herramienta que salió de la gente que se inventó el web performance, gente que trabajaba en Yahoo, que lo gastaba en Google y demás, y de esa herramienta acabó saliendo el page speed y todo eso, tenéis la herramienta que seguramente es la que todo el mundo conoce y la que todo el mundo ve números, círculos y ahí tengo un 94, eso no sirve para absolutamente nada, hay que interpretar muy bien lo que dice esa herramienta, por eso me gusta más la otra, la del web page test, porque en realidad no te da como cifras tan claras, te da los datos y tú tienes que reinterpretar esos datos, entonces tienes ya que hacer el ejercicio, que a mí me digas 94, me sirve de poco, esta imagen no sé qué, o el código de Google Analyst y valento, vale, y yo qué crees que haga, si es culpa de Google que vaya lento, no mía, valento es, ese tipo de cosas con la otra herramienta no pasan, qué es lo que hay que medir, o qué cosas se pueden medir, la principal desde el punto de vista de web performance y la que tratamos más la gente que se dedica a hosting es el time to first byte, vale, esto es como el punto de referencia, si esto ya va mal, ya lo que venga después ya os da igual, porque hasta que no arregléis esto lo de atrás da absolutamente igual, el time to first byte puede ser dos cosas, el cuando os dé la cifra, si es más alta, vale, normalmente da 0,1, 0,2, 0,3, a veces da dos segundos, dices algo raro debe estar pasando aquí, pues puede pasar dos cosas, una es que sea culpa del servidor que está mal configurado y la otra es que haya algo dentro del código de la web que hace que se bloquee, entonces a veces normalmente cuando esta cifra es alta, todo el mundo dice es culpa del hosting, no, no es siempre culpa del hosting, a veces es un plugin que está ahí, que no se cachea, que pasa una serie de cosas, hace cuello de botella y lo hace antes de poder enviarte la información, vale, entonces tener eso muy presente, esto es un poco tirar a mi lado, ya lo sé, pero es lo que hay. Luego tenemos el don content load, que básicamente es el tiempo que se que tarda en cargar toda la página, el first content full pane, que es el punto donde realmente está el cuello de botella o el menos el primero, luego eso claro va cambiando, porque cuando las reglas te aparece otro, hasta que normalmente siempre hay un punto de esos y luego tenéis el TTI, que es el tiempo en el que pasa desde que el usuario digamos ha escrito la URL y ha pulsado intro o ha pulsado en Google en el enlace, hasta que realmente el usuario puede utilizar la página, vale, yo de todos estos puntos me voy a centrar sobre todo en el primero, vale, el resto suelen tener mucho que ver con los temas, con las plantillas, con el frontal, con los plugins, con todo lo que hay CSS, Javascript, entonces claro yo esa parte que no es del hosting me puedo hacer relativamente poco desde el hosting, pero bueno ahora veremos que hay más datos aparte de estos cuatro, hay como 15 o 20, me voy a centrar en estos cuatro que son como el ABC, pero que sepáis que hay muchos más, otra cosa importante de estas herramientas que hay que tener muy presentes, estas herramientas analizan página a página, no todo el sitio y eso es un error, ¿por qué? porque si tú te descargas un, yo qué sé, el jQuery.js cuando haces el análisis de la siguiente página ese fichero en realidad ya lo tenías cargado porque a lo mejor la escarga en la página principal, entonces no contextualizan estas herramientas y eso es un problema desde el punto de vista de medir, pero bueno sabiéndolo te tienes que aplicar el cuento, ejemplo el código Google Analytics, lo cargas una vez y luego ya no da error, pero el PageSpeed siempre te da el error partes de WordPress, así que voy rápido, luego frenaré un poco, es que quiero no, no quiero quedarme sin tiempo. WordPress tiene varias partes, la principal, el Zip, el que nos bajamos, y per conocido, que básicamente es el software, dentro del Zip que tenemos, tenemos ficheros PHP, tenemos HTML, tenemos Javascript, tenemos CSS, tenemos alguna imagen, iconos, tal y otra de las cosas que viene, no al uso, no te viene la base de datos, pero te viene la posibilidad de crear la base de datos, la base de datos por ahora está, ahora entendéis por qué, voy a dejar caer otra, voy a hacer un spoiler, pero bueno, espero que me perdone Ana, la base de datos normalmente se utiliza MySQL y MariaDB, o MariaDB, y este es uno de los primeros puntos a optimizar, ¿por qué? Porque las bases de datos son un servidor aparte, o sea, dentro de la máquina, vale, cuando hablamos de la web, tenemos diferentes partes, o sea, tenemos el servidor web, que es lo que hace que la web se sirva, tenemos PHP, que es otro servicio, otro servidor que hay por detrás, que es el que ejecuta el código, tenemos la base de datos, que es en la herramienta, el servidor, donde se almacena la información y cada una de estas partes se puede optimizar, la base de datos, en este caso, se suele usar MariaDB o MySQL y, dejo aquí ya caer un poco todo, se está trabajando para que WordPress trabaje con otro tipo de bases de datos, una de ellas es SQLite, que no es un servidor al uso, no es una cosa que hay aquí a instalar, es un pequeño fichero de texto que se puede almacenar, donde se puede almacenar toda la información en el propio hostil, vale, entonces no hace falta eso y los que vengáis a Work on Torreloadones, el, si no me equivoco y espero no hacerlo, el 11 y el 12 de marzo en Torreloadones, Madrid, podréis asistir a una gran charla que voy a dar sobre esto. No es público, pero bueno, estamos en Petit Comité y que me perdonean, allá digo. Más cosas, el PHP es el lenguaje con el que está programado WordPress, como lenguaje que es, se puede optimizar, porque a veces pues hay programadores buenos, hay programadores malos y por eso WordPress va evolucionando, pues si no tendríamos una versión desde hace 10 años, inmutable, sería perfecta, cosa que no pasa. Este obviamente es otro punto a optimizar, si el código se puede optimizar, también podremos llegar a cachearlo y hacer una serie de cosas. Más cosas en las que está compuesto WordPress, los ficheros estáticos, vale, tenemos CSS, tenemos JavaScript que vienen ahí en las carpetas del UWP Includes y todo esto, incluso otra cosa más, que es los medias que vais subiendo, o sea vosotros subís una imagen y eso ya se queda ahí, por lo tanto es un contenido en principio estático y como contenido que está, como ficheros que son, se puede optimizar, por lo tanto lo tenemos ahí. Esto es lo que es WordPress, vale, ya te vamos cogiendo partes, tenemos las herramientas, tenemos que es WordPress, ahora vamos a ver la parte, digamos que nosotros no tenemos tanto control, que es la que nos dan los hosting, la parte del WordPress, nosotros tenemos acceso al código, es código abierto, por lo tanto podemos hacer lo que nos dé la gana, pero luego tenemos la parte de donde se tiene que ejecutar WordPress. En este lado está el servidor web, que como decía es la capa que hay entre el usuario y el propio WordPress, está ahí en medio y es el que pinta por pantalla, es el que hace que en el navegador se pinte por pantalla. Normalmente los más conocidos son Apache Enginx o Lightspeed, en Inginx es como un poco el más raro porque no es tan fácil de configurar y seguramente el 90% de las webs que tenéis siempre están o con Apache o con Lightspeed, esto es un tema. Luego tenemos como decía antes el PHP, el software que ejecuta realmente WordPress. Esto lo he tenido que actualizar, esto cada vez que doy una charla, lo tengo que poner al día, porque hay dramas, entonces ahora mismo esto es a día de hoy, mañana cambiará, seguramente este miércoles puede que cambie porque tenemos reunión y vete a saber qué pasa, pero ahora mismo cualquier cosa que sea menor de PHP 7.3 no hay que usarlo, o sea si tenéis cualquier web que sea menor de 7.3 empezada preocuparos de actualizar, tenemos el otro extremo que es WordPress ahora mismo, no, repito, no es compatible con PHP 8, pero yo lo he puesto y funciona, sí funciona, o sea funciona parcialmente, funciona el 95% del código, el problema es que ese 5% de código que no va te puede hacer reventar absolutamente todo, entonces ahora mismo es un proyecto que hay para arreglar, no creo que antes de las 6.2, porque no da tiempo, que es dentro de dos meses cuando va a salir, el 28 de marzo si no me equivoco, y seguramente de cara a WordPress 6.3 sí que va a haber como un equipo muy focalizado intentar poner al día todo el tema de PHP 8, entonces qué es lo que nos queda PHP 7.4, pero ya está caducado, sí está caducado, pero se sigue manteniendo, es decir una cosa es que PHP.net la fundación no le desoporte pero todas las empresas de hosting dedican mucho y hay muchos repos y muchos sitios donde se va manteniendo, PHP 7.4 sí es seguro, por mucho que os digan que no, sí es seguro, se puede seguir utilizando, os lo dice la persona que toma la decisión de revisar precisamente eso. Luego tenemos la parte de la base de datos, lo que os decía antes, dentro del hosting para que hoy en día funcione WordPress necesitamos o MySQL 8, por favor nada de las anteriores, todavía se puede usar 5 o 7, sí no MySQL 8, intentar siempre que sea la última versión, y MariaDB 16, porque la 16 y no la 19 que ya existe, sí y la 17 y la 8 y la 9, la 16 es la última versión estable, la 7, la 8 y la 9, lo digo por si alguien se pone a hacer experimentos, está bien experimentos sí, pero en producción no, porque son versiones cortas de desarrollo de alguna prueba que están haciendo, entonces hoy en día estas son las dos versiones que hay que utilizar y WordPress es 100% compatible con esto, y ahora empieza la charla, esto es lo que se ha contado, es para contextualizar lo que voy a explicar ahora, vale, entonces ahora diréis, vale, ahora lo entiendo todo, entonces ¿Por qué una charla exclusivamente de cachés? La cachés es el gran desconocido de WordPress y es la varita mágica para hacer que WordPress funcione bien, o sea, normalmente cuando tú te instalas WordPress va bien, empiezas a meterle plugins, empieza a ir regular, le empiezas a meter un tema que no toca, y entonces ya empieza a ir mal y dices, vale, hosti, pues si hace 10 minutos funcionaba súper rápido, sí pasa una cosa que es que cuanto más crece más cosas se tienen que ejecutar, más código, más llamadas a la base de datos, entonces necesitamos intentar que, por ejemplo, si yo voy a visitar la página principal y dentro de dos minutos viene otra persona y va a la página principal y yo no he metido ningún contenido nuevo porque tengo que recalcular la página principal, si la página principal que he visto yo y dentro de 5 minutos va a ser exactamente la misma, entonces voy a crear una caché, es una copia temporal que dejo en algún sitio y vamos a tener diferentes capas de caché, obviamente, si os acabo de decir que hay muchas partes, pues vamos a intentar optimizar cada una de esas partes y cada una tiene pros y contras y cosas que vuestros hosti no nos casos os dejarán y otros que no y demás. La primera, la más fácil, la de abajo, una que en realidad no depende de WordPress, esta es casi obligatoria porque precisamente no depende de WordPress y normalmente los hosting la llevan activada por defecto y entonces es el momento ese de es que acabo de subir un fichero por FTP y no veo qué pasa en nada. Sigo viendo lo viejo, sí, efectivamente, porque pasa esto. ¿Qué es lo que pasa? Que el código de PHP, que es lo que estamos diciendo, que WordPress está construido, programado con eso se va ejecutando y normalmente los servidores para que no se esté ejecutando todo el rato lo que hacen es guardarlo como en memoria. Un ejemplo para los un poco programadores, hay un tipo de cosa que se puede hacer en el código que es un include, que es coger código de un cacho de un sitio y lo metes dentro del principal, entonces para no tener que estar repitiendo el mismo código, haces esa llamada. La caché lo que hace es, yo tengo la página principal y tengo tres includes y luego ejecuto cosas, pues esos tres includes me lo prefabrico, me lo dejo ya guardadito aquí y me creo solo un único fichero en vez de tener que estar llamando a diferentes sitios. Un ejemplo, hace más cosas, pero creo que es bastante claro. Entonces, este tipo de caché la ejecuta el propio PHP no depende de WordPress, por lo tanto hay que decirle a WordPress de alguna manera que, por ejemplo, cuando yo subo un plugin nuevo, como cambio el contenido del plugin, tengo que decirle al PHP que eso ha cambiado porque si no subo el plugin nuevo y sigo viendo el código del viejo. Ya digo, esto suele venir activado por defecto en casi todos los hostings. Preguntarle a vuestro hosting, abrirse un ticket y les decir, oye, el opcache está activado por defecto en mi sitio, si os dicen, sí, tenéis que instalar este plugin. Os bajáis el opcache, publicaremos luego, bueno, la mandaré, pero la web de la WorkCam estará publicada, pero bueno, buscáis esto. Os he dejado el iconito para que cuando vayáis a buscarlo digáis, este es el que quiere Javi que instalemos. Este funciona muy bien, está bien, lo activáis y a partir de ahí cada vez que actualizáis WordPress, actualizáis un plugin, actualizáis un tema, él lo que hará es decirle a PHP, oye, se han cambiado cosas, borra toda la cache y regenerala para utilizar el código nuevo, ¿vale? Esto hace que vaya un pelín más rápido, no vais a notar una muda, pero funciona bastante bien, esto hay que usarlo siempre. ¿Cómo se instala con esto? No voy a entrar al detalle, pero básicamente la última línea veis que pone opcache.enable igual a uno, esto es lo que el hosting suele tener activado por defecto, ¿vale? Si los que desarrolléis lo ponéis a cero, sobre todo las máquinas de desarrollo, ponen lo a cero porque si no es lo típico de pasa de, hosties, que estoy poniendo esto, que no, que le doy f5 y esto no cambia y es porque tenéis esto. Entonces en las máquinas de desarrollo lo desactiváis porque si no es una locura, ¿vale? Y más si actualicéis por FTP. Y aquí está la configuración, ¿vale? Dos detalles de la configuración, por si alguien le interesa. El tamaño de la memoria, ¿cuánta memoria usa Wordpress en general, en este caso está puesto, 128 megas, y ¿cuántos ficheros tiene Wordpress para poder cachear todos esos ficheros? Entonces, obviamente no hay 10.000 ficheros en Wordpress, ¿vale? Pero bueno, está bien tener esa cifra porque si añadimos plugins o ya nos cuento unos bucomers y o hastital que son, que tienen 20.000 ficheros, no 20.000, pero tienen miles, entonces entrarían aquí. Lo que os decía, en play, sepanel y demás, viene, tenéis que mirar que esté o no está activado por defecto, ¿vale? De veres. Esto es un clásico mío, yo en todas mis charlas siempre dejo de veres. Entonces cuando lleguéis a casa, ostia Javi, lo que ha dicho, qué tal, pues aquí tenéis. Siguiente parte, la base de datos. Esta es la otra que os he dicho, que claro, ¿qué pasa con la base de datos? Lo que os decía antes, entrais en la página principal, tenemos el listado de las 10 últimas noticias que he publicado del post, ¿vale? Los 10. Dentro de 5 minutos, si no cambio eso, siguen estando los mismos 10. Dentro de 3 días, dentro de 3 meses, dentro de un año, porque soy tan perro que no he actualizado mi blog y esto es real, sigue habiendo las mismas cosas en la página principal. Que sentido tiene que cada vez que alguien visita la página principal, incluyendo Google, se tenga que ir a la base de datos, calcular todo, buscar el cacho de aquí, de acá, no tiene ningún sentido. Si siempre vas a mostrar exactamente lo mismo. Entonces, ¿qué es lo que se hace? Se utiliza un sitio apartado, en este caso Wordpress de serie tiene dos, Memcachet y Redis, o Redis, en este caso, yo personalmente prefiero Redis, y es donde se almacena temporalmente esa información. Normalmente lo que suelen llevar es tiempos de caches, es decir, guárdamelo una hora y dentro de una hora, si nadie ha tocado nada, lo regeneras, ¿vale? Por si acaso. Entonces, siempre tienes como eso, le puedes poner el tiempo que quieras. Con esto ¿qué haces? Esto es muy interesante, sobre todo, sobre todo, esto es casi obligatorio. Si tenéis más de 10.000 usuarios en Wordpress, alguien tiene más de 10.000 usuarios en Wordpress, esa es la cifra, para que os hagáis una idea, en que Wordpress considera que una web es grande. O sea, cuando preguntéis, ¿mi web es grande? ¿Cuántos usuarios tienes? ¿Tienes más de 10.000? Si no tienes más de 10.000, no es grande, es pequeña. Para mí, grande empieza a ser a partir de los mil. A partir de los mil empieza a hacer cosas raras, ¿vale? Pero bueno, según la comunidad, es 10.000, no les voy a discutir. Otra cosa importante, los que utilicéis e-commerce, e-commerce, por ejemplo, cada vez que se guarda algo en el carrito, eso se guarda en algún sitio. No está yeterio, porque cuando te vas y vuelves, eso puede seguir en el carrito. Y eso se almacena, por norma general, en la base de datos. ¿Qué pasa? Que la base de datos, como hemos visto antes o estamos viendo, es lenta. ¿Por qué? Porque hay que hacer el cálculo, el matching de todo. Ay, esta IP de este usuario con esta cookie tiene esto en el carrito y tengo que calcularlo. Y se va la base de datos. La base de datos no es tan óptima como una cache. Y entonces, si tú tienes activada la cacheta de objetos, esos carritos temporales, en vez de guardarse la base de datos donde realmente está la información importante, la de cobrar las facturas, lo dejas ahí temporal. ¿Por qué? Porque si un carrito se elimina porque ha petado la cache, tampoco pasa nada. No es extremadamente grave, no es, ¿vale? Para eso, en este caso, como os decía, yo personalmente recomiendo Redis, ¿vale? Es mi preferencia, porque se guardan cosas en disco, más que memoria. Y utilizo este plugin. ¿Por qué este plugin? Porque el tío que programa este plugin es el mismo tío que la comunidad programa el core. Entonces, claro, si el tío que hace las funciones de WordPress, que hablan de cache, te hace un plugin, ostia, es que es el tío que sabe todo. Entonces, no voy a usar otra cosa que no sea la de este tío. Entonces, este plugin, que es el Redis Object Cache, este icono vibra. O sea, aquí no, porque está en una imagen fija, pero si lo miráis en la web veréis que hace como un view, view, view. ¿Vale? Esto es lo que hay que instalar. ¿Cómo se instala? Bueno, esto para los programadores y los de sistemas, pero básicamente instalas el servidor de Redis, instalas el conector de PHP para que pueda guardar las cosas en Redis y ya está. Se pueden activar cosas en la cache, bueno, hay unos ficheros, unas historias tal, pero bueno, te vas al plugin, le vas a activar y eso rugería. Cosas importantes de la cache como sistema de almacenamiento, eso tiene un tamaño, obviamente, no vas a empezar ahí, porque si no, petaría. En el caso de WordPress, yo normalmente sueno, bueno, 512 es como grande, ¿vale? Normalmente se suele llenar 128 o así, pero bueno, si queréis ir un poco extras, podéis meterle 512 de memoria y lo que hay que indicarle son un poco dos elementos. ¿Qué pasa cuando se llena la cache? ¿Cómo se vacía? En este caso, por defecto, yo lo digo, lo más viejo, lo vas borrando y lo más nuevo, lo dejas, pero lo que más lógica tiene, pues hay cosas muy surrealistas de combinatorias y luego está cuántas personas se pueden conectar o cuántas conexiones puedes tener. Entonces, ese número, por ejemplo, varía mucho, dependiendo del tamaño del hosting y no es lo mismo, una web de un blog que unicomes, pues obviamente unicomes necesita estar ejecutando muchas cosas. Cosas un poco dudosas. Claro, los que tengáis hosting compartido, las cache son un cubo que está ahí al acceso de cualquiera, porque no tienen usuario y contraseña. No es del todo cierto, pero hacésme caso. Básicamente es eso. Entonces, ¿qué pasa? Si tú lo tienes en un hosting compartido y tienes 300 clientes que no se conocen entre ellos, alguien un poco listo podría acceder a la información de los otros. Entonces, normalmente los hosting compartidos no se suele instalar este tipo de caches. Hay empresas de hosting que tienen sus plugins de cache de optimización que lo que hacen es configurarse a su manera esto para tenerlo separado y tenerlo diferenciado para cada cliente. Entonces, de esa forma, que no sea que, oye, es que mi hosting es una mierda, pues no lo tienen. Normalmente dan servicios para tenerlo. Los más conocidos lo tienen y los que sabéis un poco, ya sabéis de qué estoy hablando. Y una de las últimas, la cache de web y de página. Lo que se estaba diciendo, si yo entro hoy a mi web y no he publicado nada nuevo, ¿para qué voy a estar haciendo llamadas a sitios? Sí, voló de hace un rato y ya está, así total, el que venga después, o Google, o quien sea, ya le sirve. Entonces, cosas que se pueden hacer, lo que normalmente se almacena, esta es la típica cache de, ay, me instalo un plugin de cache, es esta, ¿vale? De todo lo que se ha explicado, esta es una de las partes, ¿vale? Que es la típica, pues el WPoverCache, el W3Cache, el Rocket, el no sé qué, ¿vale? Un montón, yo utilizo esta, ahora se explicaré por qué. Básicamente, ¿qué es lo que hace este sistema? Este sistema dice, ¿vale? Yo visito la página, o por ejemplo, Google visita la página, que es el mejor crauleador que hay a nivel de generar caches, pues como está todo el día navegando por tu web, es un usuario y te va generando las caches. Entonces, cuando viene un usuario real, pum, te la enseña el momento, porque Google ya la visitaba antes. Lo que hace es, tú entras en la web, cargas todo el código, y dice, ah, pues mira, ahora que ya lo tengo, como si fuérais al navegador y dijais, guardad como. Y entonces, lo que hace es, lo guarda en el disco. Entonces, en el WP content, si os fijáis o entrais alguna vez por FTP, veréis que se crea una carpeta misteriosamente que nadie sabe de cómo apareció, que se llama cache. Y dentro de esa carpeta, empiezan a ver miles y miles y miles de ficheros. Cada fichero de esos corresponde a una de las páginas de vuestro sitio. ¿Cuál es la ventaja de esto? Que, si está todo muy bien configurado, cuando el usuario entra a la web, en vez de ir al WordPress, el enginx, el Apache o lo que sea, directamente se va a buscar si alguien ya ha visitado esa página antes. Entonces, como eso es un HTML y no pasa por el PHP, no pasa por base de datos, eso se sirve rápido. O sea, estamos hablando como tener una web en el año 97, que se hacía con el HTML, la subías por FTP y está ahí. Entonces, obviamente, los plugins lo que hacen es controlar que esa página cacheada esté actualizada. Es decir, si tú actualizas un post nuevo, se va hacia parte de la cache. Si haces algún cambio, pues obviamente se tiene que eliminar. Y, por seguridad, normalmente se le dice, cada cuánto tiempo se elimina. ¿Por qué? Porque, a lo mejor, falla algo. Pero dices, mira, oye, cada hora, si no hay una versión nueva, la generas otra vez, aunque ya existiera el fichero. Me lo vuelves a generar, aunque sea el mismo contenido. Entonces, un usuario bringa y el resto, ¿no? Entonces, a un usuario, le irá lenta la web, pero a 3,000, ¿no? Entonces, bueno, esto es como lo del tranvía, ese de que dejo mato a 1 o mato a 5. Esto es un poco lo mismo. Pues que uno se fastidie y el resto bien. En general, ya digo, se activa el plugin. En el caso de Apache o de Lightspeed, no suele hacer falta configuración o en el propio plugin os dice, oye, tienes que darle al botón este para meter este código aquí. No sé, da igual, le das ahí y va. En el caso de Inginx, no. En el caso de Inginx, hay que coger un código y lo tienes que meter tú porque hay que hacer cosas. ¿Qué es lo que se mete en el código de Inginx? Esto. ¿Qué pone aquí? Muchas cosas. Básicamente, no lo voy a explicar. No es la hora para explicar esto. El objetivo es un poco lo que os decía, que el usuario visita la página, si está en el disco, se sirve del disco, y si no, se genera. Se establece el tiempo mínimo de vida, ¿vale? Esto en general, en todas las caches suele pasar. En el op cache suelen ser 60 segundos para que veáis, tampoco es que sea una cosa, un minuto. En el Redis, creo que por defecto es una hora. Y creo que, por ejemplo, el super cache y WordPress en general, por defecto, lleva media hora, o sea, no estamos hablando. Yo, por ejemplo, la del super cache, le pongo un día. Total, si no cambio nada, se sirva lo mismo. Es que tampoco tiene nada. Y si falla algo, le vas a vaciar el cache, la regenere y ya está. Lo que os decía, en cualquier caso, cuando vosotros trabajáis otra cosa, el panel de administración no se cachea. Con el op cache sí, pero con el resto no. Bueno, no, miento. Con el Redis sí, porque, por ejemplo, si os vais a la lista de todos los usuarios o de los posts o tal, hay una pequeña parte que se indexa. Voy muy mal de tiempo. Más cosas, cosas que se pueden cachear. En este caso, en el lado del navegador. Por ejemplo, si os bajáis el logo de mi web, cuando vais a la siguiente página, ¿para qué lo vais a volver a pedir? Si es el mismo logo, la misma URL y en el mismo todo. Tú le puedes configurar al Apache, al Enginx, al servidor web, que toda la información, todas las imágenes, todos los CSS, algunos Javascripts, lo que venga en Ghana, lo decís. Oye, cuando se lo descargue el usuario, si eso no ha cambiado, sigo utilizándolo. Pero sigo utilizándolo dentro de un año. Si la imagen es la misma, a mí la de un año ya me sirve, ¿vale? Por eso, de tanto en tanto, hay que vaciar el historial del navegador y toda esta mierda, porque se queda toda esta mierda. Vuestra de vuestro WordPress hay guardada en el navegador. Y lo hay que el crome va lento. Sí, sí, es culpa tuya. Más cosas, bueno, básicamente es eso. Otra cosa importante, esto sí que es importante. Por norma general, si no ha cambiado nada y los navegadores siguen igual, WordPress tiene una pequeña mala manía, que es que a todos los CSS, Javascripts y demás, después les pone interrogante v igual y el número de la versión del WordPress, ¿vale? Pues las 6.1.1. Con esto que pasa, que todas las URL que llevan parámetros, sobre todo los CSS, Javascripts y demás, si llevan un parámetro, no se cachean en el navegador. Entonces hay que intentar eliminar eso. Hay opciones, hay funciones y hay sistemas dentro de WordPress para quitar eso. Y hay plugins que te permiten hacer inventos raros como juntar un montón de CSS en un sitio. Entonces, en vez de hacer 10 llamadas, haces una, te lo llevas todo y al final, haces lo mismo. Os dejo aquí cosas. ¿Cómo se haría en nginx? Es esto, más esto, más, sí, ahí es un poco, ¿vale? Para cada cosa ya veis los tipos de ficheros que hay. Imágenes, audios, vídeos, documentos, o sea, prácticamente todo lo que no puede cambiar, porque se sube por FTP, pues no sería una opción. Para ir acabando, otras caches, esto ya es que os suene, ¿eh? No voy a entrar. CDNs, esto es algo que a veces los venden. Básicamente es que todo esto que os estoy explicando, en realidad, no lo tenéis vosotros, se guarda en otro sitio del mundo por ahí, que no sabéis, y además no se guarda en uno. Se guarda en todo el planeta. A lo mejor está vuestra web, en vuestro logo, en 20 sitios del planeta, en Turquía, ¿y qué hacen Turquías? Y no vienen los turcos a navegar por mi web. Vale, sí, paso. Otra cosa importante, antes decía, no se puede utilizar la cacheta de objetos, porque los hosting compartidos, claro, el Redis es un servicio para toda la máquina. ¿Hay alguna alternativa? Sí, la hay, no es la más óptima, pero acabo de explicaros que la cacheta de página se puede guardar en disco, porque la cacheta de objetos no la guardamos en disco. Entonces, cada objeto lo convertimos a un fichero y la información está ahí. Como el disco, sí que es para ti solo, lo tienes. Para eso está el... Sí, ya estaba donde tocaba. El docket cache. Este plugin lo que hace es que toda la cacheta de objetos la guarda en ficheros de texto como la cacheta de página. Vale, entonces, es una muy buena alternativa, sobre todo los que estéis en hosting compartidos, ¿vale? Y el proveedor de hosting nos dé una solución de por sí. Otra cosa importante, que se puede cachear las traducciones. Nadie piensa en esto, pero las traducciones no dejan de ser textos que cada vez que alguien entra, se tienen que leer de un fichero, buscar, analizar, pues también se pueden cachear. Esto es de, además, creo que es de un... Bueno, he dejado la URL, porque es bastante complejo de configurar. No es un plugin que instala y funciona. Tienes que bajarlo, meterlo en los MEU plugins y hacer una serie de cosas. Y ahí los tenéis. Y os dejo algunos datos, ¿vale? Un par de tablas. Básicamente, bueno, es un... Un poco el test como lo he hecho. Es un servidor recién instalado. Creé 2500 POS para hacer las pruebas. Y en una primera visita. Estos son los tiempos, ¿vale? Ahí están un poco las capas de cache o con las capas de cache que se han ido utilizando. Ya veis que activando algunas capas, como la del PHP o en el caso de la cache de página, fijaos que el WordPress sin cache, tal y como viene, tardaba 1,8 segundos y activando las diferentes capas, tarda 0,1. ¿Vale? ¿La pena activar las capas de cache? ¿Ha valido la pena venir a esta charla? ¿Vale? Y en el caso de la siguiente visita, en la que, por ejemplo, el logo ya está cacheado, los CSS, hay un montón de cosas que ya se han ejecutado, pasa lo mismo. Una página que tardaba en cargar 0,6, ahora tarda 0,08. Entonces, es muy interesante trabajar esto muy bien. Sobre todo ya digo a los que tenéis y comerci de más. Y antes de irme, el 11 de febrero en Granada hacemos una jacatón, ¿vale? Con WordPress para preparar una serie de plugins y tal para ayudar a protectoras de animales. Si alguien quiere bajar a Granada expresamente, que baje, estaremos ahí abierto y tal. Y quien no, seguramente haremos el evento híbrido. Podéis conectar y tal. O sea, será un poco colaborativo y demás. Como todavía no tenemos acabado la web y tal, y estoy ahí un poco viendo qué, me seguís por Twitter, los que me tal. Y ahí yo seré un poco chapa. Y los que estéis acostumbrados a escuchar mi voz por los podcasts, más chapa seré todavía. Y nada, ya está. Consultorio gratis. Preguntas. No te quejarás, 40 minutos de reloj. Spectáculo. Bueno, ¿alguien se ha quedado con ganas de preguntar algo a Javi? Venga, despertadela si está. Que hay que cambiar de sal. Venga, vamos, vamos. Hola. Hola. Al final, duda tonta, ¿cuántos plugins hay que instalar solo para la cache? Tres. Vale, vale. Tres. De todas formas, sí, esto es un clásico de, ostia, tres plugins. Mano sé qué. Sí, pero tiene mucho sentido. Porque ninguno de estos tres plugins afecta al frontal, ¿vale? Y normalmente ninguno de los tres se ejecuta de forma sincrona, ¿vale? Es decir, obviamente, si subís un plugin, en ese momento se vacía la cache. Es decir, se ejecutan las cosas. Según vosotros, vais ejecutando cosas. Entonces, el tiempo es milisegundos de acciones que hacéis vosotros, ¿vale? Entonces, en general, son plugins que están ahí y son, además, los tres que he puesto son muy livianos. Hay que hacerlo. ¿Has dicho que luego dirías por qué el plugin que usas, perdón? El Super Cache, ¿vale? Básicamente por una razón. Es el de automática, ¿vale? No, pero tiene un sentido. No sé si conocéis Meneame.net, los más mayores del lugar lo conoceréis. Uno de los creadores de Meneame es Roberto Gajir. Y él es el creador de WP Cache. Y WP Super Cache está basado en ese plugin. Es decir, WP Super Cache está basado en tecnología española. Fue el primer plugin de Cache que hubo para WordPress cuando casi ni existían los plugins. O sea, era una cosa que tenías que subir por FTP de una carpeta y hacer unos milagros. Y entonces, con eso se cacheaba. Os hablo de WordPress 2.0, para atrás. Os hablo de, sí, 2005, 2007. Vale, entonces este plugin es la evolución de esa tecnología española. Entonces, por eso también es un poco tributo a, joder, ya que hicimos algo bien aquí. Pues, pues, venga. Más preguntas, más cosas. Venga, por aquí. Una pregunta. Pregunta, micro, micro ahí. Ahí está pagado. Ahí que me salgo del plano. Me pierdo mucho con el tema del Cache, pero hace poco he hecho algunos cambios para que el comercio electrónico que estoy desarrollando vaya más de prisa y parece que va más de prisa. Todos los cambios que he hecho pasan por el hosting que yo utilizo, que dicen, ellos aseguran que con esos cambios, pues va el Cache, pues va estupendamente. Entonces, de todo lo que has hablado, hay algo que yo deba instalar, que no dependa. O sea, que mi hosting, si lo está haciendo bien, yo, o sea, ellos no se encargan de eso. Me he explicado. Te he entendido. Perdón. No, no, no, no. No, sí, ya te digo que tengo este tipo de preguntas llegan siempre. A ver, a nivel de hosting, lo que hay que preguntar, sobre todo el principal, porque no depende absolutamente de ti, es el del PHP, el op Cache. Entonces, eso sí que es preguntarles, es decirles, oye, el op Cache está activo o no está activo? Entonces, si no está activo, activadmelo. Y entonces, te instalas el plugin S. Y si está activo y no tenéis ese plugin, lo activa. O sea, instaláis el plugin y ya está. Eso, ya digo, no depende tanto de vosotros. El resto, sí. El tema de si no queréis liaros mucho, yo me iría al extremo. El todo el tema de Cache de objetos y demás, dejarlo ahí aparcado, yo os vais a la Cache de página. Con eso avanzáis. El Cache de objetos no me suena de nada, pero lo del main cache me suena. Vale. Y esto lo trabajan. Dicen ellos que lo otimizan. Por eso te pregunto, sí. Entonces, sí que tienes que preguntarles qué plugin tienes que instalar, será suyo seguramente, para que realmente puedas aprovechar esa tecnología. Es decir, el hosting te da las tecnologías, pero luego tienes que decirle al WordPress que se vaya conectando a las diferentes tecnologías. Entonces, ese es un poco lo que hay que saber. Si tú vas a utilitar la Cache de página, como es local tuya, no necesitas nada. La instalas y ya está. Por eso es el clásico. Me voy a instalar el plugin de Cache. Y el realidad es la del Cache de página. Pero con eso ya avanzas mucho. El resto ya es, sobre todo, ya digo, la gente que utilicéis e-commerce, tirad mucho de Cache de objetos. Un inciso. Si os vais al saludo del sitio, al herramienta saludo del sitio, desde WordPress 6.1 o 6.0 a lo mejor, vienen avisos de relacionados con el tema de la Cache. Entonces, el propio sistema es capaz de detectar qué plugins tenéis, cuántos usuarios hay, cuántos productos hay y demás. Y, entonces, os pueden avisar de, deberíais de utilizar esta capa de Cache o talentos. Un punto de inicio para empezar a ver cosas es, os vais a herramienta salud del sitio, entrais ahí, veis los errores o avisos o las cosas que os de, os recomiendo que le deis a ver todos, porque normalmente los oculta y veis buscando los que tengan relación con Cache. Deberían de aparecer dos o tres avisos, normalmente, para bien y para mal, porque son las dos, tres cosas que se analizan. No sé qué da una, que iban a preguntar por ahí. Creo que no tenemos tiempo, se la preocupa si no fuera. Bueno, ahora en serio, muchas gracias. Nada. Hasta la próxima.