 vale pues aquí voy a leer un poquito porque es que lo de Pablo poveda es que es muy a ver el trabajo para vas y responsable de la línea de negocio de proyectos con batch base php vale gestionó un equipo pero es que además le encanta estar en familia y el ruby y además por tomarse una cerveza fresquita así que imagino que esta noche vamos a tomarnos una cerveza fresquita en la parte os dejo con paulo poveda y nos va a hablar de rendimiento perdón bueno quiero pedir perdón si alguna slide sale un poquito desmaquetada que hemos tenido algún problema de última hora pero voy a tirar millas igualmente vale bueno ya me han presentado así que voy a ir rápido en esta parte porque tengo muchas cosas que contar y quiero que me de tiempo a contarlas todas vale ahora mismo trabajo para vas que es una consultora y llevo proyectos php hoy venimos a hablar de de rendimiento y lo que vengo a hablar también es un poco a poner en valor el trabajo que hacen todos los profesionales que se dedican un poco a la parte de optimización web vale simplemente quería mostraros que hay muchísimo trabajo detrás y que cuesta mucho estar al día y que cuesta mucho optimizar las webs vale esto es lo que primero encuentras cuando buscas optimización web en youtube y creo que hay muchísimo más que un vídeo de 12 minutos vale según mozilla el rendimiento de la web es la medición objetiva es decir lo que podemos medir de forma objetiva y la perfección que tiene el usuario del uso de una web cuán rápida va y lo que tarda en ser interactiva con ella vamos a entender un poco rápidamente cómo funciona la petición http que es la unidad mínima de medida que tenemos que tomar empezando por la parte de hosting que tenéis aquí un montón de hostings a los que preguntar luego porque es tan importante la base de nuestra de nuestra web reside ahí luego tenemos una capa de datos donde vamos a ir guardando la persistencia y datos y demás la parte de la aplicación que está el servidor web esta wordpress está la parte de webeckley cualquier software externo va a estar en esa capa y luego ya por último tenemos arriba la parte proxy balanceadores cdn cualquier petición lo primero que hace es resolver un dns enrutamos la petición se procesa la petición se cachea si se puede cachear se prepara una respuesta se vuelve a cachear esa respuesta si lo necesitamos se presenta el documento final y se sirve vale donde más poco vamos a poner los que nos dedicamos a la optimización es en procesar la petición cuán rápido vamos a hacer que esa petición se procese y la parte de presentación cómo vamos a presentar todos los datos que tenemos que darle al usuario todo ese circuito forma el time to face bite o lo que viene a ser lo que tarda la petición y devolverte el primer dato a procesar no voy a entrar mucho en detalle aquí pero sí que es cierto que una de las partes muy importante aquí es el hosting vale y todos los factores que hay detrás a la hora de elegir un hosting por favor los que tengáis dudas acerca de hostin hay profesionales aquí fuera que han venido a patrocinar la warcam y podéis preguntarle todo lo que necesitáis lo mismo a la hora de pros y caché pues bueno al final nos ayuda a incrementar tiempos la parte de seguridad de protocolos a balancear cargas si lo necesitamos a servir respuestas rápidas a través de una cdn vale final lo que intentamos hacer es descargar a nuestro servidor a través de otros servidores que ponemos por delante para que éste no sufra tanto vale luego tenemos aquí una parte importante que después voy a desarrollar en base de ejemplos en la que tenemos que cuidar vale aquí donde instalamos todos los plugins donde tenemos que medir nuestros accesos a base altos controlar la caché reglas de redirecciones integraciones que hacemos todo eso suma a la hora de que nuestra web sea más rápida o más lenta a diferencia del dibujo anterior aquí cuando estamos procesando ya le metemos carga a nuestros servidores vale y luego por último la capa de presentación que aquí es donde hay miles de presentaciones que hablan de lo que debe pesar una web que tiene que pesar poco el peso de las imágenes optimizan las imágenes los número de número de cargas de ccs de javascript minificar ccs js en fin todo este tipo de de jerga técnica que luego indagar en ella la voy a dejar aquí para que podáis luego desde casa con el status slides ir tirando del del hilo porque son factores que pesan muchísimo a la hora de optimizar una una web al final todo nuestro trabajo se basa en pequeños ajustes que vamos a ir haciendo como un monoplaza de un fórmula 1 que si os fijáis casi todos los años el coche parece igual pero tienen muchísimos pequeños ajustes que hace que año tras año el coche gane milésimas o centésimas por vuelta vale pues vamos a ver esto siempre queda guay ponerlo las frases estas al final la medida que vamos a utilizar son los los capéis vale nos van a decir qué tenemos que medir cuál entraba mi web o cuán rápida es la unidad común a todas las web para poder medirlas vale el ejemplo más común que vamos a tener y el que todo conocemos son las core web vajals vale en que google ha conseguido matemáticamente que medir la percepción del usuario y la velocidad de carga de una web vale a través de estos capéis el lcp el fidec lo comentaré y el celeste para medir archiconocidísimas herramientas vale google page speed ping don't yellow lab web page test gt metrics para la capa de aplicación pues ya son un poquito más complejas vale profiler del x de bug el vp cli hay paquetes que te ayudan a hacer profiling cueri monitor que muchos de vosotros si sois desarrolladores puede que la conozcáis y luego hay herramientas que se llaman a me a me aplicación monitoring performance que sirven para medir el rendimiento más profundamente y luego están todas estas herramientas que también las conocí que las a las las ha comentado muchísima gente en muchas ponencias vale tampoco voy a entrar en cada una de ellas pero aquí las tenéis listadas vale y ahora voy a intentar explicar casos de uso reales que me he ido encontrando en mi trayectoria profesional vale lo primero que tenemos que hacer es saber cómo vamos a empezar a medir vale tener una estrategia clara de por dónde voy a meterle mano a un sitio y cómo voy a ir viendo la evolución de lo que de lo que vamos a hacer vale siempre utilizar las mismas herramientas cuando encontréis nuevas herramientas probarlas y si os encaja en vuestra forma de medir introducirlas dentro de vuestra metodología o framework de trabajo que utilicéis vale usala siempre y aprende a utilizarlas sobre todo y seleccionar bien los KPI que necesitáis medir vale por ejemplo lighthouse lighthouse es una herramienta que como bien indica es un faro nos nos va a ir guiando por dónde tenemos que ir para utilizar nuestra web pero no no mide igual en un navegador cron normal en uno incógnito e incluso lighthouse tiene una herramienta clí que la puedes lanzar desde la terminal y tampoco da la misma medida entonces usar siempre lo mismo vale esto es un caso real que nos encontramos hace un año o así año y medio nos llegó un divi con mal rendimiento en la parte frontal tenía buen rendimiento en tiempos de carga la cachilla muy rápida las imágenes optimizadas al 7 tp 2 todo parecía muy bien pero parece que la carga frontal ahí es donde estaba el problema lo que hablamos con el cliente fue trazar una estrategia de medición vamos a tener un punto de partida vamos a hacer una serie de informes una evolución gestionamos muy bien las expectativas con el cliente de hoy puede que esto salga bien o puede que no consigamos la medición que esperas vale estas son las herramientas que utilizamos y desarrollamos un plugin propio y además utilizamos herramientas que ya asisten en el mercado utilizamos la cron de tu que nos ayudó bastante y luego a nivel de métricas pues utilizamos yellow labs y webpages simplemente lo primero que hicimos fue medir y yellow lab la parte frontal nos ayudó bastante a identificar dónde estaba realmente el problema vale divi si lo conocéis carga muchísima parte de ccs creo que un mega o quizá más y el performance inicial pues era este aprendimos a utilizar light house y a ver cuánto pesaban las métricas vale por él nos ayudó los ponderajes a saber bueno dónde debíamos atacar más por ejemplo el total blocking time que pesa 30% me va a ayudar a tener un mejor rendimiento que si le dedico tiempo al fcp o al speed index el primero que hicimos fue bajarle de nodos y de ccs al menú principal para que el dom size fuera muchísimo más pequeño que el que cuando empezamos a optimizar trabajamos la parte de recursos estáticos controlando de forma condicional cuando se cargaba un recurso estático hicimos plantillas por templates a de forma individual vale optimizamos la carga de js y de ccs combinando quitando js que sobraban poniendo asings de fers profundizamos mucho en la optimización de ccs vimos que en divi casi el 80% de las clases que tiene sobran porque no se utilizan entonces encontramos una manera de limpiar esas ccs sin modificar la original vale entonces conseguimos reducir hasta un 86 por ciento el peso de las ccs de vivi eso nos ayudó bastante a mejorar el rendimiento vale porque la hija es muy listo conoce todo lo que se carga en la web a nivel de detalle vale optimizamos la fuente de la iconografía optimizamos las imágenes pasamos formatos de jpeg png a webp y a formatos quizá más más recientes valdizamos leisilot ojito con los tag managers que es los cargan diablo pesan muchísimo te pueden reventar el rendimiento de iba a decir una cosa te pueden reventar el rendimiento de una web vale reducimos el peso utilizando herramientas de compresión optimizando las imágenes utilizando las directivas de caché que nos ofrece el ht acces y como no podíamos modificar las plantillas hicimos un análisis de por dónde había que meterles manos a las plantillas para que otros equipos del proveedor de cliente pues lo hicieran madre y después de todo este trabajo conseguimos pasar de esto aquí que no está mal ese cambio y de un 19 conseguimos pasar un 73 con pixels vale verdad que la medición de los pixels revienta mucho la el rendimiento de la web vale y por ejemplo acordaros del peso del total blocking time que un 30 por ciento vale pasamos de 5 segundos a 130 milisegundos otro problema de rendimiento que tuvimos fue en el back office que a veces también sufre vale que mucha gente se centra en la capa frontal pero cuando tú tienes una web en la que participan 20 editores te tienes que preocupar de que el back office funcione bien vale entonces investigando investigando y esto fue mucho mucho tiempo nos dimos cuenta que había un registro de base de datos que pesaba 10 megas y nos pusimos a comparar con otras bases de datos que teníamos parecidas y aún siendo alto la diferencia era brutal vale entonces conseguimos entender dónde estaba el problema lo solucionamos y resolvimos el cuello y botella el back office para que os hagáis una idea estaba tardando con más de dos minutos y de tres minutos en cargar una página vale era insufferible eso y luego en la parte de comers también por ejemplo un punto de partida de medición puede ser que te puedas comparar para argumentar el trabajo o argumentar un presupuesto compárate con tus competidores dice un ejercicio fácil de comparar mercadona con el corte inglés la parte de supermercados lo comparé con carrefour y con día mercadona hasta años luz de cualquiera de ellos vale en términos de rendimiento pues esto lo podéis hacer fácilmente con webpages desde la parte de comparadores primero conocer WordPress el otro día dice el ejercicio de montarme una arquitectura aquí de todo lo que tiene webpages por dentro como eso pensó lo podéis ver vosotros mismos vale impresionante aprender a utilizar WordPress y ver que podéis optimizar primero antes de ponerle nada encima hacer lo mismo con Google Mers vale Google Mers te carga absolutamente todos estos paquetes bueno pues a la mitad te sobran tenéis que investigar formas de hacer que todo eso no se cargue cuida las extensiones que metes de Google Mers vale no todo vale no podéis meter 25 extensiones vale esto es un ejemplo de un compañero que que tuve que puse un tweet un día que se encontró un proyecto con 58 plugins vale bueno voy a empezar a meter aquí cosas y lo voy a ir solucionando optimizamos muchísimos los pixels de uso de la web esto lo que pasa cuando no tienes optimizadas tus tags tags pixel huellas digitales lo que google analitis google tag manager como le queráis llamar vale es impresionante los tiempos y cómo esto afecta al rendimiento vale elimina distracciones a tus tutuarios o sea interfaces limpias claras sencillas vale acordar de la web de renfe era infumable hasta hace poco y de hecho creo que sigue siendo hace tiempo que no entro pero era infumable comprar un billete monitoriza en el tiempo esta es una captura de una herramienta que estoy trastando últimamente se llama de bug via y la verdad que es bastante potente a nivel de herramienta porque te ayuda a visualizar cosas y entender cosas que están pasando en tu web de una forma bastante sencilla vale hace tiempo hicimos un caso también de rendimiento y usando el profiler de x debú nos dimos cuenta que la lectura de los ficheros pomo era muy lenta el otro día buscando me encontré con con este hilo de github por lo visto siga abierto de febrero del 2014 la lectura de ficheros pomo cuando son muy pesados hace que el tiempo de respuestas incremente cacha al html por ejemplo cacheamos la parte del header la parte del footer y elementos comunes de la página que no que son digamos que cuesta procesarlos porque un header de un de un e-commerce un menú es muy complejo entonces si cacha se echa html luego lo puede servir de forma rápida vale no hace falta procesar ese menú una y otra vez por cada petición vale optimizamos el el ayax como pues utilizando la característica de sortini de warps o incluso a veces ni siquiera cargando work pues porque a veces tirando con queries nativas contra my sequel puedes obtener el mismo resultado vale al final reduces el tf modificamos muchísimas plantillas para hacerlas mucho más simples vale con eso conseguimos reducir cses y js vale hacer el checado en un paso un formulario con muchos menos campos de los que necesitas vale minimizamos el número de reglas de rewrite rules que son las reglas que necesita warps para entender las peticiones que le que le llegan al servidor vale cada cpt genera un montón de reglas si sabéis la si encontréis la forma podéis hacer que esas reglas desaparezcan y la petición se resolverá mucho más rápido el uso de transients que muchas veces creo que esto es el pequeño olvidado de warps y la gente no lo utiliza pero son súper útiles porque son pequeños registros que yo guardo en base a dos con fecha de caducidad que me ayudan a luego poder operar de forma sin crona en la web como por ejemplo enviar un email enviar un email es algo que a lo mejor no toque hace en tiempo real y lo puedo hacer de forma sin crona con un crón detrás o procesar un reporte de un e-commerce pesado vale ese tipo de operaciones hacen que el servidor se descargue también y cuidar muchísimo la base de datos utiliza herramientas es plain de mysql por ejemplo te da información acerca de cuello de botella utilizar query monitor que ofrece muchísima información vale nosotros utilizamos hace muchos años una herramienta se amazabix que es open source y te ayuda a monitorizar los servidores instalas una gente en un servidor y te da información acerca de lo que ocurre métricas de mysql métricas de lecturas y escrituras en discos cpu uso de ram montón y sobre todo controlar lo que vais añadiendo a vuestra web vale es decir si yo tengo un montón de funcionalidades que quiero añadir a mi e-commerce priorizarlas priorizarlas porque cada cosita que vas metiendo suma vale esta es una técnica y bastantes más pero esta es una técnica matriz impactor esfuerzo donde vais colocando cada funcionalidad que queréis ir añadiendo en su cuadrante y vais a ir viendo que bueno que algunas incluso son descartables vale controlar los costes el hostin puede resultar muy caro sobre todo si estáis en la nube y no controláis lo que tenéis en la nube vale y como conclusiones pues bueno esto es lo que pasa cuando tu web va muy lenta y tienes un e-commerce hay tanta competencia que te vuelves casi incompetente salvo que tengas un mega producto y seas único en el internet que a veces cuesta ser y si ya enumeramos beneficios y costes pues bueno la parte de costes pesa menos que la de beneficios así que merece la pena invertir esfuerzo e inversión económica en hacer que tu web vaya mucho más rápido y muchísimas gracias a todos los que habéis aguantado esta chapa de 20 minutos sé si alguien quiere preguntar algo en si hay tiempo de preguntas muchas gracias por todos los hilos que nos has dejado para tirar mucho curró mi pregunta es alguna vez has separado a nivel de infraestructura el backend del front y hay algún motivo para no hacerlo lo puedes hacer con golpes puedes hacer gel es motivo para no hacerlo si tienes una web normal con visitas normales es decir algo sencillo creo que no te merece la pena por todo el coste que pueda haber detrás y porque vas a necesitar seguramente un equipo de desarrolladores para que te lo implementen o utilizar algún servicio que exista que se acaba de hacer modo gel es y tendrás que pagarlo también pero para una web sencilla creo que con un tema de WordPress debería ser suficiente vale pero en teoría no hay problema en separarlo no no pero vas a tener que conocer qué estás haciendo vale las llamadas a las apis el paradigma cambia un poquito no sé si hay otra pregunta yo mezclando hay más dale es que es es es un tema muy técnico es da para para más tiempo disculpa si ha sido muy rápido porque da mucha información agradecido por la cantidad de tips y sobre el y en su caso en el escritorio vendría muy bien es una estrategia bastante buena sobre todo para engañar las herramientas y viene muy bien cuando el usuario hace una acción en el ratón viene muy bien pero cuando nos llevamos esos dispositivos móviles la mejor estrategia siempre va a ser un time out en javascript o hay una alternativa para que es que en la parte de principio no hay el first input de ley en un dipositivo móvil que en la iteración por parte de un ratón si lo mejor siempre es hacer un un time out en javascript o hay alguna alternativa lo primero es reducir la cantidad de javascript que vas a utilizar y así decir y retrasarla sobre todo vale para que la capa de presentación se muestra antes al usuario incluso de ser interactiva la web y sobre todo el lo que va a ver el usuario eso que tenga la menor cantidad de javascript para que sea muchísimo menos dinámico y el usuario interactúe con la web lo más rápido posible con eso vas a hacer que el que el fez input de ley se baje bastante si no hay una interacción en el móvil al final si hay interacción porque el hacer que un botón se muestre por ejemplo si utilizas un builder le va a aplicar cierto javascript ahí lo quieras o no porque al final los builders colocan los elementos muchas veces utilizando javascript cosa que no he entendido nunca pero a veces pasa vale entonces ese tipo de cosas hay que ir puliéndolas para que no ocurran vale entonces si lo haces todo con ceses e html no hay problema gracias muchísimas gracias pasta si a ver si tenéis más preguntas pues podéis pasar ya nos vamos a tomar el relluno vamos al centro cultural y allí pues podéis hablar ya con los ponentes directamente y hacer más preguntas de acuerdo pues podéis dar paso