Smashing Podcast Episodio 34 con Harry Roberts: ¿Cuál es el estado del rendimiento web?

En este episodio, estamos hablando de rendimiento web. ¿Cómo es el panorama del rendimiento en 2021? Hablé con el experto Harry Roberts para averiguarlo.

Mostrar notas

Harry está organizando un taller de clase magistral de rendimiento web con Smashing en mayo de 2021. En el momento de la publicación, todavía hay grandes descuentos disponibles para los primeros.

• harry en twitter
• Sitio de consultoría de Harry CSS Wizardry
• Curso en video Todo lo que he hecho para hacer que CSS Wizardry Fast incluya un 15% de descuento
• Libro electrónico de Preguntas para Consultores que incluye un 15 % de descuento
• Guía de Web.dev para Web Vitals
• El batidor de huevos OXO GoodGrips favorito de Drew

Actualización semanal

• Tendencias de diseño web 2021: el informe escrito por Suzanne Scacca
• Uso de aplicaciones Grommet In React escritas por Fortune Ikechi
• Cómo construir una API Node.js para Ethereum Blockchain escrito por John Agbanusi
• Cómo mejoramos el rendimiento de SmashingMag escrito por Vitaly Friedman
• Cuándo decir no a los proyectos independientes escrito por Becca Kennedy

Transcripción

Drew McLellan: es un ingeniero consultor independiente de rendimiento web de Leeds en el Reino Unido. En su función, ayuda a algunas de las organizaciones más grandes y respetadas del mundo a brindar experiencias más rápidas y confiables a sus clientes. Es un experto en desarrollo de Google invitado, un experto en desarrollo de medios de Cloudinary, un desarrollador galardonado y un orador internacional. Entonces, sabemos que sabe lo que hace en lo que respecta al rendimiento web, pero ¿sabías que tiene 14 brazos y siete piernas? Mis amigos de Smashing, denle la bienvenida a Harry Roberts. Hola Harry, ¿cómo estás?

Harry Roberts: Oye, estoy genial, muchas gracias. Evidentemente los 14 brazos, las siete piernas… siguen planteando sus problemas habituales. Imposible comprar pantalones.

Drew: Y bicicletas.

harry: si Pues yo tengo tres bicicletas y media.

Drew: Así que quería hablarles hoy, lamentablemente no sobre bicicletas, aunque eso sería divertido en sí mismo. Quería hablarte sobre el rendimiento web. Es un tema que personalmente me apasiona mucho, pero es una de esas áreas en las que me preocupo, cuando pierdo la vista y me involucro en algún otro tipo de trabajo y luego vuelvo a hacer un poco de trabajo de actuación, Me preocupa que el conocimiento con el que estoy trabajando se desactualice muy rápido... ¿El rendimiento web es tan rápido en estos días como lo percibo?

Harry: Esto es... Ni siquiera estoy diciendo esto para ser amable contigo, es una buena pregunta porque últimamente he estado pensando mucho en esto y diría que hay dos mitades. Una cosa que trataría de decirles a los clientes es que en realidad no se mueve tan rápido. Principalmente porque, y este es el fragmento que siempre uso, puedes apostar por el navegador. A los navegadores no se les permite cambiar fundamentalmente la forma en que funcionan porque, por supuesto, hay dos décadas de legado que deben mantener. Entonces, en general, si apuesta por el navegador y sabe cómo funcionan esos componentes internos, y TCP/IP que nunca cambia... Ciertas cosas que están bastante grabadas en piedra, lo que significa que las mejores prácticas, en general, siempre serán mejores prácticas en lo que se refiere a los fundamentos.

Harry: Donde se pone más interesante es... Lo que veo cada vez más es que nos estamos arrinconando cuando se trata de problemas de velocidad del sitio. Así que en realidad creamos muchos problemas para nosotros mismos. Entonces, lo que eso significa de manera realista es el rendimiento... es el poste de la portería en movimiento, supongo. Cuanto más cambia el paisaje o la topografía de la web, y la forma en que se construye y la forma en que trabajamos, nos planteamos nuevos desafíos. Por lo tanto, la llegada de hacer mucho más trabajo en el cliente plantea problemas de rendimiento diferentes a los que estaríamos resolviendo hace cinco años, pero esos problemas de rendimiento aún pertenecen a las partes internas del navegador que, en general, no han cambiado en cinco años. Así que mucho depende... Y diría que definitivamente hay dos aspectos claros... Animo a mis clientes a que se apoyen en el navegador, se apoyen en los estándares, porque no se pueden cambiar simplemente, los postes de la portería realmente no se mueven. . Pero, por supuesto, eso debe fusionarse con prácticas de desarrollo más modernas y, quizás, un poco más interesantes. Así que mantén tu... Bueno, iba a decir "Un pie en ambos campos", pero con mis siete pies, tendría que... cuatro y tres.

Drew: Mencionaste que los fundamentos no cambian y cosas como TCP/IP no cambian. Una de las cosas que sí cambió en... Digo "años recientes", esto probablemente esté retrocediendo un poco ahora, pero es HTTP en el sentido de que teníamos este protocolo HTTP establecido para la comunicación entre clientes y servidores, y eso cambió y luego tenemos H2 que es entonces todo binario y diferente. Y eso cambió mucho el… Fue por razones de rendimiento, fue para quitar algunas de las limitaciones existentes, pero eso fue un cambio y la forma en que teníamos que optimizar para ese protocolo cambió. ¿Eso ahora es estable? O va a cambiar de nuevo, o…

Harry: Entonces, una cosa sobre la que me gustaría aprender más es la segunda mitad de la pregunta, el cambio de nuevo. Necesito investigar más sobre QUIC y H3, pero está demasiado lejos para que sea útil para mis clientes. Cuando se trata de H2, las cosas han cambiado bastante, pero realmente creo que H2 es una gran promesa falsa y creo que se pasó de la raya, lo cual es notable teniendo en cuenta que se lanzó H1... Y me refiero a 1.1, fue en 1997, así que tenemos mucho tiempo para trabajar en H2.

Harry: Supongo que el beneficio principal son los desarrolladores web que lo entienden o perciben que ahora es ilimitado en las solicitudes de vuelo. Entonces, en lugar de seis solicitudes enviadas y/o seis en tránsito a la vez, potencialmente ilimitadas, infinitas. Sin embargo, trae problemas realmente interesantes porque... es bastante difícil de describir sin ayudas visuales, pero aún tiene la misma cantidad de ancho de banda disponible, ya sea que esté ejecutando H1 o H2, el protocolo no hace que su conexión sea más rápida. Por lo tanto, es muy posible que pueda inundar la red solicitando 24 archivos a la vez, pero no tiene suficiente ancho de banda para eso. Por lo tanto, en realidad no se vuelve más rápido porque solo puede administrar, quizás, una fracción de eso a la vez.

Harry: Y también lo que tienes que pensar es cómo responden los archivos. Y este es otro consejo profesional que reviso en talleres de clientes, etc. Las personas verán una cascada H2 y verán que, en lugar de las seis solicitudes de envío tradicionales, es posible que vean 24. Enviar 24 solicitudes en realidad no es tan útil. Lo que es útil es cuando se devuelven esas respuestas. Y lo que notará es que puede enviar 24 solicitudes, por lo que el lado izquierdo de su cascada se ve realmente agradable y empinado, pero todas regresan de manera secuencial bastante escalonada porque necesita limitar la cantidad de ancho de banda para que no puede cumplir con todas las respuestas al mismo tiempo.

Harry: Bueno, la otra cosa es que si cumplieras con todas las respuestas al mismo tiempo, estarías intercalando respuestas. Entonces obtienes el primer 10% de cada archivo y el siguiente 20%... El 20% de un archivo JavaScript es inútil. JavaScript no se puede utilizar hasta que haya llegado el 100 %. Entonces, lo que verá es, de hecho, la forma en que se manifiesta una cascada H2 cuando observa la respuesta... De todos modos, se parece mucho más a H1, está mucho más escalonada. Entonces, H2, creo que fue sobrevendido, o tal vez a los ingenieros no se les hizo creer que hay límites sobre cuán efectivo podría ser. Debido a que verá personas fragmentando demasiado sus activos y es posible que tengan veinte... mantengamos el número 24. En lugar de tener dos archivos JS grandes, es posible que tenga 24 paquetes pequeños. Seguirán regresando bastante secuencialmente. No llegarán todos al mismo tiempo porque no te has hecho magia con más ancho de banda.

Harry: Y el otro problema es que cada solicitud tiene una latencia constante. Entonces, digamos que está solicitando dos archivos grandes y es un viaje de ida y vuelta de cien milisegundos y una descarga de 250 milisegundos, eso es dos veces 250 milisegundos. Si multiplica hasta 24 solicitudes, todavía tiene una latencia constante, que hemos decidido 100 milisegundos, por lo que ahora tiene 2400 milisegundos de latencia y 24 veces... en lugar de 250 milisegundos de descarga, digamos que son 25 milisegundos de descarga, en realidad, lleva más tiempo porque la latencia se mantiene constante y simplemente multiplica esa latencia por más solicitudes. Así que veré clientes que habrán leído que H2 es esta varita mágica. Se fragmentarán... ¡Oh! No pudieron simplificar el proceso de desarrollo, no necesitamos agrupar o concatenar, etcétera, etcétera. Y, en última instancia, terminará más lento porque ha logrado distribuir sus solicitudes, lo cual era la promesa, pero su latencia se mantiene constante, por lo que en realidad tiene n veces más latencia en el navegador. Como dije, es realmente difícil, probablemente inútil tratar de explicar eso sin imágenes, pero es notable cómo se manifiesta H2 en comparación con lo que la gente espera que pueda hacer.

Drew: ¿Todavía hay beneficio en ese proceso de fragmentación en el sentido de que, está bien, obtener todo el lote todavía toma la misma cantidad de tiempo, pero para cuando obtienes el 100% del primero 24, puedes comenzar a trabajar en eso y puedes comience a ejecutarlo antes de que termine el 24.

Harry: Oh, hombre, otra gran pregunta. Entonces, absolutamente, si las cosas van correctamente y se manifiestan en una respuesta más parecida a H1, la idea sería que el archivo uno devuelva primero, dos, tres, cuatro, y luego puedan ejecutarse en el orden en que llegan. Entonces, en realidad puede acortar el tiempo agregado asegurándose de que las cosas lleguen al mismo tiempo. Si observamos una página web en lugar de una cascada y observa que las solicitudes están intercaladas, son malas noticias. Porque como dije, el 10% de un archivo JavaScript es inútil.

Harry: Si el servidor hace su trabajo correctamente y envía, envía, envía, envía, envía, entonces será más rápido. Y luego, los beneficios colaterales de su estrategia de almacenamiento en caché pueden ser más granulares. Tan realmente molesto sería actualizar el tamaño de fuente en su widget de selección de fecha. En el mundo H1, debe almacenar en caché quizás 200 kilovatios del amplio CSS de su sitio. Mientras que ahora, solo almacena en caché el busto datepicker.css. Así que tenemos beneficios secundarios como ese, que definitivamente son muy valiosos.

Drew: Supongo que, en el escenario en el que mágicamente obtuviste todas tus solicitudes a la vez, eso obviamente atascaría al cliente, ¿no es así?

Harry: Sí, potencialmente. Y luego, lo que sucedería en realidad es que el cliente tendría que hacer una gran cantidad de programación de recursos, por lo que terminaría con una cascada donde todas sus respuestas regresan al mismo tiempo, entonces tendría una brecha bastante grande entre el última respuesta que llega y su capacidad de ejecución. Entonces, idealmente, cuando hablamos de JavaScript, desearía que el navegador los solicite todos en el orden de solicitud, básicamente el orden en que los definió, el servidor los devuelva en el orden correcto para que el navegador pueda ejecutar ellos en el orden correcto. Porque, como usted dice, si todos regresaron al mismo tiempo, solo tiene un JavaScript masivo para ejecutar a la vez, pero aún debe programarse. Por lo tanto, podría tener dudas de hasta un segundo entre la llegada de un archivo y su utilidad. Entonces, en realidad, H1... Supongo que, idealmente, lo que busca es la programación de solicitudes H2, respuestas de estilo H1, para que las cosas puedan ser útiles a medida que llegan.

Drew: Así que básicamente estás buscando una cascada de respuesta que parezca que puedes deslizarte por ella.

Harry: Sí, exactamente.

Drew: Pero no necesitarías un paracaídas.

harry: si Y es realmente difícil... Creo que decirlo en voz alta suena muy trivial, pero dada la forma en que se vendió H2, lo encuentro bastante... no desafiante porque hace que mi cliente suene... tonto... pero es algo difícil de explicar. para ellos... si piensas en cómo funciona H1, no fue tan malo. Y si recibimos respuestas que se ven así y "Oh, sí, ahora puedo verlo". He tenido que enseñar esto a los ingenieros de rendimiento antes. Gente que hace lo que hago. He tenido que enseñar a los ingenieros de rendimiento que no nos importa demasiado cuándo se realizan las solicitudes, realmente nos importa cuándo las respuestas se vuelven útiles.

Drew: Una de las razones por las que las cosas parecen avanzar con bastante rapidez, especialmente en los últimos cinco años, es que el rendimiento es un tema importante para Google. Y cuando Google pone peso detrás de algo como esto, gana tracción. Sin embargo, esencialmente, el rendimiento es un aspecto de la experiencia del usuario, ¿no es así?

Harry: Oh, quiero decir... este es un muy buen podcast, estaba pensando en esto hace media hora, te prometo que estaba pensando en esto hace media hora. El rendimiento es accesibilidad aplicada. Estás garantizando o aumentando las posibilidades de que alguien pueda acceder a tu contenido y creo que la accesibilidad siempre es solo... Oh, son los lectores de pantalla, ¿verdad? Es gente sin vista. Las decisiones de construir un sitio web en lugar de una aplicación... las decisiones son acceder más a una audiencia. Entonces, sí, el rendimiento es accesibilidad aplicada, que es, por lo tanto, la experiencia del usuario. Y esa experiencia de usuario podría reducirse a "¿Podría alguien experimentar su sitio?" punto final. O podría ser “¿Fue agradable esa experiencia? Cuando hice clic en un botón, ¿respondió de manera oportuna?”. Así que estoy 100% de acuerdo y creo que esa es una de las razones por las que Google le da importancia, porque afecta la experiencia del usuario y si alguien va a confiar en los resultados de búsqueda, queremos intentar darle a esa persona un sitio que no van a odiar.

Drew: Y es... todo lo que piensas, todos los beneficios que piensas, la experiencia del usuario, cosas como una mayor participación, definitivamente es cierto, ¿no? No hay nada que aleje al usuario de un sitio más rápidamente que una experiencia lenta. Es tan frustrante, ¿no? Usar un sitio en el que sabes que tal vez la navegación no es tan clara y si haces clic en un enlace y piensas "¿Es esto lo que quiero? ¿No lo es?" Y solo el costo de hacer ese clic, solo esperar, y luego tienes que hacer clic en el botón Atrás y luego esperar, y es simplemente... te das por vencido.

Harry: Sí, y tiene sentido. Si vas al supermercado y ves que está absolutamente repleto de gente, harás lo mínimo. No vas a gastar mucho dinero allí, es como "Oh, solo necesito leche", dentro y fuera. Mientras que si es una buena experiencia, tienes "Oh, bueno, mientras estoy aquí veré si... Oh, sí, tienen esto... Oh, lo cocinaré mañana por la noche" o lo que sea. Creo que aún, tres décadas después de la web, incluso las personas que construyen para la web luchan porque es intangible. Luchan por pensar realmente que lo que te molestaría en una tienda real te molestaría en línea, y lo hace, y las estadísticas muestran que así es.

Drew: Creo que en los primeros días, estoy pensando en finales de los 90, mostrando mi edad aquí, cuando estábamos creando sitios web, pensábamos mucho en el rendimiento, pero pensábamos en el rendimiento desde el punto de vista de las conexiones que la gente estaba usando eran tan lentos. Estamos hablando de acceso telefónico, módems, líneas telefónicas, módems de 28K, 56K, y hubo una tendencia en un punto con imágenes de estilo que cada línea de la imagen se borraría con un color sólido para dar esto... si puedes imaginarlo como mirar a través de una persiana veneciana la imagen. E hicimos eso porque ayudó con la compresión. Porque cada dos líneas el algoritmo de compresión podría-

Harry: colapsar en un puntero.

Drew: Sí. Y así ha reducido significativamente el tamaño de su imagen sin dejar de ser capaz de obtener... Y se convirtió en un elemento de diseño. Todo el mundo lo estaba haciendo. Creo que quizás Jeffrey Zeldman fue uno de los primeros en ser pionero en ese enfoque. Pero lo que estábamos pensando allí era principalmente qué tan rápido podríamos hacer las cosas por el cable. No para la experiencia del usuario, porque no estábamos pensando en... Quiero decir, supongo que fue la experiencia del usuario porque, esencialmente, no queríamos que la gente abandonara nuestros sitios. Pero estábamos pensando en no optimizar las cosas para que fueran realmente rápidas sino en tratar de evitar que fueran realmente lentas, si eso tiene sentido.

harry: si, si

Drew: Y luego, creo que a medida que las velocidades como las líneas ADSL se hicieron más frecuentes, dejamos de pensar en esos términos y comenzamos a no pensar en eso en absoluto. Y ahora estamos en una situación en la que usamos dispositivos móviles y tienen conexiones restringidas y quizás CPU más lentas y tenemos que pensarlo nuevamente, pero esta vez en términos de obtener una ventaja. Además del lado de la experiencia del usuario, puede tener beneficios comerciales reales en términos de costos y capacidad de obtener ganancias. ¿no es así?

Harry: Sí, tremendamente. Quiero decir, no estoy seguro de cómo expresarlo. No me tiro en el pie aquí, pero una cosa que trato de enfatizar a los clientes es que la velocidad del sitio le dará una ventaja competitiva, pero es solo una cosa que podría darle alguna ventaja competitiva. Si tiene un producto que nadie quiere comprar, no importa qué tan rápido sea su sitio. E igualmente, si alguien realmente quiere el sitio web más rápido del mundo, debe eliminar sus imágenes, eliminar su CSS, eliminar su JavaScript y luego ver cuántos productos dice, porque le garantizo que la velocidad del sitio no fue el factor. Pero los estudios han demostrado que hay enormes beneficios de ser rápido, del orden de millones. Estoy trabajando con un cliente mientras hablamos. Calculamos para ellos que si podían renderizar una página dada un segundo más rápido, o mejor dicho, su mayor contenido de pintura era un segundo más rápido, valdría 1,8 millones al año, lo cual es... un gran número.

Drew: Eso casi pagaría tu tarifa.

harry: hola! Sí, casi. Les dije: “Miren, después de dos años todo esto habrá valido la pena. Estarás en el punto de equilibrio”. Deseo. Pero sí, el aspecto de cara al cliente... lo siento, el aspecto de cara al cliente de si tienes un sitio de E-Com, van a gastar más dinero. Si es un editor, leerán más de un artículo o verán más minutos de contenido, o lo que sea que haga, ese es su KPI que mide. Podría estar en el sitio Smashing, podría ser que no rebotaron, en realidad hicieron clic en algunos artículos más porque lo hicimos realmente fácil y rápido. Y luego los sitios más rápidos son más baratos de ejecutar. Si tiene ordenada su estrategia de almacenamiento en caché, mantendrá a las personas alejadas de sus servidores. Si optimiza sus activos, cualquier cosa que tenga que venir de su servidor pesará mucho menos. Mucho más barato de ejecutar.

Harry: La cuestión es que hay un costo para llegar allí. Creo que Scott Jehl probablemente dijo uno de los más... Y lo escuché de él primero, así que voy a asumir que se le ocurrió, pero el dicho es "Es fácil hacer un sitio web rápido pero es difícil hacer un sitio web". rápido". Y eso es tan sucinto. Porque la razón por la que el rendimiento web podría quedar relegado a la lista de cosas por hacer es porque podría decirle a un cliente: "Si hago que su sitio sea un segundo más rápido, ganará 1,8 millones adicionales al año" o puede ser "Si acaba de agregar Apple Pay a su pago, obtendrá cinco millones adicionales". Así que no se trata solo del rendimiento web y no es el factor decisivo, es una parte de una estrategia mucho más grande, especialmente para E-Com en línea. Pero la evidencia es que lo he medido de primera mano con mis clientes minoristas, mis clientes de E-Com. El caso está ahí, tienes toda la razón. Es una ventaja competitiva, le hará ganar más dinero.

Drew: Volviendo al pasado, de nuevo, me refiero a un tiempo pasado, pero personas como Steve Souders fueron algunas de las primeras personas que realmente comenzaron a escribir y hablar sobre el rendimiento web. Y la gente como Steve básicamente decía: "Olvídate de la infraestructura de back-end, donde todas las ganancias están en el navegador, en el front-end, ahí es donde sucede todo lento". ¿Sigue siendo así 15 años después?

harry: si, si Volvió a ejecutar la prueba en ese entonces y ahora, y la brecha en realidad se había ampliado, por lo que en realidad es más costoso sobre el cable. Pero hay un contraataque a eso, que es que si tiene un rendimiento de back-end realmente malo, si sale de la puerta lentamente, no hay mucho que pueda recuperar en el front-end. Tengo un cliente en este momento, su tiempo hasta el primer byte es de 1,5 segundos. Por lo tanto, nunca podemos renderizar más rápido que 1,5 segundos, por lo que será un límite. Todavía podemos recuperar el tiempo en el front-end, pero si tiene un tiempo muy, muy malo para el primer byte, tiene ralentizaciones en el back-end, hay un límite en la rapidez con la que sus esfuerzos de rendimiento en el front-end podrían hacerlo. Pero absolutamente.

Harry: Eso, sin embargo, está cambiando porque... Bueno, no, no está cambiando, supongo, está empeorando. Estamos empujando más hacia el cliente. Solía ​​​​ser un caso de "Su servidor es tan rápido como es, pero luego de eso tenemos un montón de signos de interrogación". porque escucho esto todo el tiempo “Todos nuestros usuarios usan WiFi. Todos tienen máquinas de escritorio porque todos trabajan desde nuestra oficina”. Bueno, no, ahora todos están trabajando desde casa. No puedes elegir. Entonces, ahí es donde vienen todos los signos de interrogación, que es donde ocurren las ralentizaciones, donde realmente no puedes controlarlo. Después de eso, el hecho de que ahora tendemos a poner más en el cliente. Con eso quiero decir, tiempos de ejecución completos en el cliente. Ha movido toda la lógica de su aplicación fuera de un servidor de todos modos, por lo que su tiempo para el primer byte debería ser muy, muy mínimo. Debería ser un caso de enviar algunos paquetes desde un CDM a mi ... pero ha pasado de poder especificar sus propios servidores a esperar que alguien no tenga Netflix ejecutándose en la misma máquina en la que está tratando de ver su sitio web .

Drew: Es un muy buen punto sobre la forma en que diseñamos los sitios y creo que la mejor práctica tradicional siempre ha sido que debes tratar de satisfacer todo tipo de navegadores, todo tipo de velocidades de conexión, todo tipo de tamaños de pantalla, porque no No sé lo que el usuario va a estar esperando. Y, como dijiste, tienes estos escenarios en los que la gente dice "Oh, no, sabemos que todos nuestros usuarios están en su máquina de escritorio emitida por el trabajo, están ejecutando este navegador, es la última versión, están conectados a la LAN". pero luego pasan cosas. Uno de los grandes beneficios de tener aplicaciones web es que podemos hacer cosas como distribuir nuestra fuerza de trabajo de regreso a sus hogares y pueden seguir trabajando, pero eso solo es cierto si la calidad de la ingeniería fue tal que entonces alguien que está girando instalar su máquina doméstica que podría tener IE11 o lo que sea, si la calidad del trabajo está allí, eso realmente significa que la web cumple su potencial para ser un medio verdaderamente accesible.

Drew: Como dices, existe la tendencia de pasar más y más cosas al navegador y, por supuesto, si el navegador es lento, ahí es donde ocurre la lentitud. Tienes que preguntarte “¿Es esta una buena tendencia? ¿Deberíamos estar haciendo esto?” Tengo un sitio en el que pienso particularmente, noté que está casi 100% renderizado por servidor. Hay muy poco JavaScript y es muy rápido. Cada vez que voy a él pienso "Oh, esto es rápido, ¿quién escribió esto?" Y luego me doy cuenta de "Oh, sí, fui yo".

Harry: Eso es porque estás en localhost, no es de extrañar que se sienta rápido. Es su sitio de desarrollo.

Drew: Entonces, mi trabajo diario, estamos construyendo nuestra aplicación de una sola página y sacando cosas del servidor porque el servidor es el cuello de botella en ese caso. ¿Puedes decir que es más eficaz estar en el navegador? ¿O más eficiente para estar en el servidor? ¿Se trata solo de medir y tomar caso por caso?

Harry: Creo que tienes que ser muy, muy, muy consciente de tu contexto y… genuinamente creo que un error es… narcisismo donde la gente piensa “Oh, mi blog merece ser renderizado en el navegador de alguien. Mi blog con una tasa de rebote del 89% necesita su propio tiempo de ejecución en el navegador, porque necesito que las navegaciones posteriores sean rápidas, solo quiero obtener una... básicamente una diferencia de los datos". De todos modos, nadie hará clic en su próximo artículo, amigo, no empuje un tiempo de ejecución por la tubería. Por lo tanto, debe ser muy consciente de su contexto.

Harry: Y sé que... si Jeremy Keith está escuchando esto, probablemente me va a pegar, pero hay, diría, una diferencia entre un sitio web y una aplicación web y la definición de eso es muy, muy turbio Pero si tiene una aplicación de lectura y escritura pesada, algo en lo que está ingresando datos, manipulando datos, etcétera. Básicamente, mi sitio no es una aplicación web, es un sitio web, es de solo lectura, que colocaría firmemente en el campamento de sitios web. Algo así como mi software de contabilidad es una aplicación web, diría que es una aplicación web y estoy preparado para sufrir un poco de costo de tiempo de arranque, porque sé que estaré allí durante 20 minutos, una hora, lo que sea. Entonces, necesita un poco de contexto y, nuevamente, tal vez el narcisismo sea un poco duro, pero necesita tener un verdadero "¿Necesitamos hacer de este periódico una aplicación del lado del cliente?" No, no lo haces. No, no lo haces. La gente tiene activado el bloqueador de anuncios, a la gente no le gustan los sitios de periódicos de todos modos. Probablemente ni siquiera vayan a leer el artículo y despotricar sobre él en Facebook. Simplemente no cree algo así como una aplicación renderizada por el cliente, no es adecuado.

Harry: Así que creo que definitivamente hay un punto en el que ayudaría moverse más hacia el cliente, y ahí es cuando tienes menos sensibilidad a la rotación. Entonces, cualquier tipo de comunicación, por ejemplo, estoy haciendo una auditoría por un momento para un sitio que... Creo que es un sitio de comunicación electrónica, pero está 100% en el cliente. Deshabilitas JavaScript y no ves nada, solo un div id = "aplicación" vacío. E-Com es... eres muy sensible a cualquier problema. Su flujo de pago es incluso sutilmente incorrecto, me voy a otro lado. Es demasiado lento, me voy a otro lado. No tienes el contexto en el que alguien esté dispuesto a dormir en esa aplicación por un tiempo.

Harry: Photoshop. Abro Photoshop y estoy bastante feliz de saber que la pantalla de presentación tardará 45 segundos porque voy a estar allí durante... básicamente, los 45 segundos valen los 45 minutos. Y es tan difícil de definir, por lo que realmente me cuesta convencer a los clientes "Por favor, no hagas esto" porque no puedo simplemente decir "¿Cuánto tiempo crees que tu usuario estará allí?". Y puede enviarlo desde... si su tasa de rebote es del 89 % y no se optimiza para una segunda vista de página. Baja esa tasa de rebote primero. Creo que definitivamente hay una división, pero lo que diría es que la mayoría de la gente cae en el lado equivocado de esa línea. La mayoría de la gente pone cosas en el cliente que no deberían estar allí. CNN, por ejemplo, no puede leer un solo titular en el sitio web de CNN hasta que haya iniciado completamente una aplicación de JavaScript. Lo único que representa el servidor es el encabezado y el pie de página, que es lo único que no le importa a la gente.

Harry: Y siento que eso es solo... No sé cómo llegamos a ese punto. Nunca va a ser la mejor opción. Entregas una página que es efectivamente inútil y luego tiene que decir "Genial, iré a buscar lo que habría sido una aplicación web, pero la ejecutaremos en el navegador, luego iré y pediré un título". , entonces puedes empezar a… oh, te has ido.” Eso realmente, realmente me irrita.

Harry: Y no es culpa de nadie, creo que es la infancia de este tipo de ecosistema de JavaScript, la exageración que lo rodea, y también, esto va a sonar muy duro pero... Básicamente es una implementación muy ingenua. Claro, Facebook inventó React y lo que sea, les funciona. Nueve de cada 10 veces no estás trabajando a escala de Facebook, 95 de cada 100 veces probablemente no eres el ingeniero de Facebook más inteligente, y eso es muy, muy cruel y suena horrible decirlo, pero solo puedes conseguir... Ninguno de estas cosas son rápidas por defecto. Necesita una implementación muy, muy elegante de estas cosas para que sean correctas.

Harry: Estaba teniendo esta discusión con mi viejo... él era un ingeniero líder en el equipo en el que yo estaba hace 10 años en Sky. Estuve hablando con él el otro día sobre esto y tuvo que trabajar muy duro para hacer que una aplicación renderizada por el cliente fuera rápida, mientras que hacer que una aplicación renderizada por el servidor fuera rápida no es necesario que haga nada. Solo necesitas no hacerlo lento de nuevo. Y siento que hay muchos lentes color de rosa, ingenuidad, marketing... Sueno tan sombrío, tenemos que seguir adelante antes de que realmente empiece a perder gente aquí.

Drew: ¿Crees que tenemos la tendencia, como industria, a centrarnos más en la experiencia del desarrollador que en la experiencia del usuario a veces?

Harry: No como un todo, pero creo que el problema surge en un lugar que esperarías. Si observa la disparidad... No sé si ha visto esto, pero voy a suponer que sí, parece estar muy al tanto, la disparidad entre los datos del archivo HTTP sobre qué marcos y Las bibliotecas de JavaScript se usan de forma salvaje en comparación con la encuesta sobre el estado de JavaScript, si sigue la encuesta sobre el estado de JavaScript, diría "Oh, sí, el 75% de los desarrolladores usan React", mientras que menos del 5% de los sitios usan React. Entonces, siento que, en masa, no creo que sea un problema, pero creo que en las áreas que esperarías, una gran lealtad a un marco, por ejemplo, la experiencia del desarrollador es... evangelizada probablemente antes que el usuario. No creo que se deba pasar por alto la experiencia del desarrollador, es decir, todo tiene un costo de mantenimiento. Tu carro. Hubo una decisión cuando se diseñó que "Bueno, si ocultamos esta clave, esa funcionalidad, de un mecánico, le llevará mucho más tiempo arreglarlo, por lo tanto, no hacemos cosas así". Así que tiene que haber un equilibrio entre ergonomía y facilidad de uso, creo que eso es importante. Creo que centrarse principalmente en la experiencia del desarrollador es desconcertante para mí. No optimices para ti, optimiza para tu cliente, tu cliente te paga, no al revés.

Drew: Entonces, la cámara de eco en línea no es exactamente representativa de la realidad cuando ves a todos diciendo "Oh, deberías estar usando esto, deberías estar haciendo eso", entonces en realidad es solo un porcentaje muy pequeño de personas.

Harry: Correcto, y eso es algo bueno, eso es tranquilizador. La cámara de eco… no es saludable tener ese tipo de monocultivo tal vez, si quieres llamarlo así. Pero también siento que... y lo he visto en mucho de mi propio trabajo, muchos desarrolladores... Como consultor, trabajo con muchas empresas diferentes. Mucha gente está haciendo un trabajo increíble en WordPress. Y WordPress impulsa el 24% de la web. Y siento que podría ser bastante fácil para un desarrollador como ese que trabaja en algo como WordPress o PHP en el backend, código personalizado, lo que sea, sentirse un poco como "Oh, supongo que todos usan React y nosotros no". ” pero en realidad, no. Todo el mundo habla de React, pero sigues con la corriente, sigues con la mayoría. Es bastante tranquilizador encontrar la mayoría silenciosa.

Drew: La tendencia hacia los generadores de sitios estáticos y luego el alojamiento de sitios completamente en una CDN, una especie de enfoque JAMstack, supongo que cuando hablamos de ese tipo de sitios de tipo publicación, en lugar de sitios de tipo software, supongo que es una tendencia realmente saludable. , lo pensarías?

Harry: Me encanta eso, absolutamente. ¿Recuerdas cuando solíamos llamar a SSG "archivo de solapa", verdad?

Drew: Sí.

Harry: Entonces, construí CSS Wizardry en Jekyll cuando Jekyll era llamado un sitio web de archivos flap. But now we service our generator, huge, huge fan of that. There's no disadvantage to it really, you pay maybe a slightly larger up front compute cost of pre-compiling the site but then your compute cost is… well, Cloudflare fronts it, right? It's on a CDN so your application servers are largely shielded from that.

Harry: Anything interactive that does need doing can be done on the client or, if you want to get fancy, what one really nice approach, if you are feeling ambitious, is use Edge Side Includes so you can keep your shopping cart server rendered, but at the edge. You can do stuff like that. Tremendous performance benefits there. Not appropriate for a huge swathe of sites, but, like you say, if we're thinking publishing… an E-Com site it wouldn't work, you need realtime stock levels, you need… search that doesn't just… I don't know you just need far more functionality. But yeah, I think the Smashing site, great example, my site is an example, much smaller than Smashing but yeah, SSG, flap filers, I'm really fond of it.

Drew: Could it work going deeper into the JAMstack approach of shifting everything into the client and building an E-Commerce site? I think the Smashing E-Commerce site is essentially using JavaScript in the client and server APIs to do the actual functionality as service functions or what have you.

Harry: Yeah. I've got to admit, I haven't done any stuff with serverless. But yeah, that hybrid approach works. Perhaps my E-Commerce example was a bit clunky because you could get a hybrid between statically rendering a lot of the stuff, because most things on an E-Com site don't really change. You filter what you can do on the client. Search, a little more difficult, stock levels does need to go back to an API somewhere, but yeah you could do a hybrid for a definite, for an E-Com site.

Drew: Okay, so then it's just down to monitoring all those performance metrics again, really caring about the network, about latency, about all these sorts of things, because you're then leaning on the network a lot more to fetch all those individual bits of data. It hosts a new set of problems.

Harry: Yeah, I mean you kind of… I wouldn't say “Robbing Peter to pay Paul” but you are going to have to keep an eye on other things elsewhere. I've not got fully to the bottom of it, before anyone tweets it at us, but a client recently moved to an E-Commerce client. I worked with them two years ago and that site was already pretty fast. It was built on… I can't remember which E-Com platform, it was .net, hosted on IIS, server rendered, obviously, and it was really fast because of that. It was great and we just wanted to maintain, maybe find a couple of hundred milliseconds here and there, but really good. Half way through last year, they moved to client side React for key pages. PP… product details page, product listing page, and stuff just got marketable slower lower, much slower. To the point they got back in touch needing help again.

Harry: And one of the interesting things I spotted when they were putting a case for “We need to actually revert this”. I was thinking about all the…what's slower, obviously it's slower, how could doing more work ever be faster, blah blah blah. One of their own bullet points in the audit was: based on projections, their yearly hosting costs have gone up by a factor of 10 times. Because all of a sudden they've gone from having one application server and a database to having loads of different gateways, loads of different APIs, loads of different microservers they're calling on. It increased the surface area of their application massively. And the basic reason for this, I'll tell you exactly why this happened. The developer, it was a very small team, the developer who decided “I'm going to use React because it seems like fun” didn't do any business analysis. It was never expected of them to actually put forward a case of how much is it going to cost the dude, how much is it going to return, what's the maintenance cost of this?

Harry: And that's a thing I come up against really frequently in my work and it's never the developer's fault. It's usually because the business keeps financials away from the engineering team. If your engineers don't know the cost or value of their work then they're not informed to make those decisions so this guy was never to know that that was going to be the outcome. But yeah, interestingly, moving to a more microservice-y approach… And this is an outlier, and I'm not going to say that that 10 times figure is typical, it definitely seems atypical, but it's true that there is at least one incident I'm aware of when moving to this approach, because they just had to use more providers. It 10x'ed their… there's your 10 times engineer, increased hosting by 10 times.

Drew: I mean, it's an important point, isn't it? Before starting out down any particular road with architectural changes and things about doing your research and asking the right questions. If you were going to embark on some big changes, say you've got a really old website and you're going to structure it and you want it to be really fast and you're making all your technology choices, I mean it pays, doesn't it, to talk to different people in the business to find out what they want to be doing. What sort of questions should you be asking other people in the business as a web developer or as a performance engineer? Who should you be talking to you and what should you be asking them?

Harry: I've got a really annoying answer to the “Who should you be talking to?” And the answer is everyone should be available to you. And it will depend on the kind of business, but you should be able to speak to marketing “Hey, look, we're using this AB testing tool. How much does that cost as a year and how much do you think it nets as a year?” And that developer should feel comfortable. I'm not saying developers need to change their attitude, what I mean is the company should make the developers able to ask those kind of questions. How much does Optimizely cost as a year? Right, well that seems like a lot, does it make that much in return? Okay, whatever we can make a decision based on that. That's who you should be talking to and then questions you should ask, it should be things like…

Harry: The amount of companies I work will, they won't give their own developers to Google Analytics. How are you meant to build a website if you don't know who you're building it for? So the question should be… I work a lot with E-Com clients so every developer should things like “What is our average order value? What is our conversion rate? What is our revenue, how much do we make?” These things mean that you can at least understand that “Oh, people spend a lot of money on this website and I'm responsible for a big chunk of that and I need to take that responsibility.”

Harry: Beyond that, other things are hard to put into context, so for me, one of things that I, as a consultant, so this is very different to an engineer in the business, I need to know how sensitive you are to performance. So if a client gives me the average order value, monthly traffic, and their conversion rate, I can work out how much 100 milliseconds, 500 a second will save them a year, or return them, just based on those three numbers I can work out roughly “Well a second's worth 1.8 mil”. It's a lot harder for someone in the business to get all the back information because as a performance engineer it's second nature to me. But if you can work that kind of stuff out, it unlocks a load of doors. Okay, well if a second's work this much to us, I need to make sure that I never lose a second and if I can, gain a second back. And that will inform a lot of things going forward. A lot of these developers are kept quite siloed. “Oh well, you don't need to know about business stuff, just shut up and type”.

Drew: I've heard you say, it is quite a nice soundbite, that nobody wants a faster website.

Harry: Yeah.

Drew: What do you mean by that?

Harry: Well it kind of comes back to, I think I've mentioned it already in the podcast, that if my clients truly wanted the world's fastest website, they would allow me to go in and delete all their JavaScript, all their CSS, all their images. Give that customer a Times New Roman stack.

Harry: But fast for fast sake is… not chasing the wrong thing but you need to know what fast means to you, because, I see it all the time with clients. There's a point at which you can stop. You might find that your customer's only so sensitive to web perf that it might mean that getting a First Contentful Paint from four seconds to two seconds might give you a 10% increase in revenue, but getting from that two to a one, might only give you a 1% increase. It's still twice as fast, but you get minimal gains. So what I need to do with my clients is work out “How sensitive are you? When can we take our foot off the gas?” And also, like I said, towards the top of the show… You need to have a product that people want to buy.

Harry: If people don't want to buy your product, it doesn't matter how quickly you show them it, it'll just disgust them faster, I guess. Is your checkout flow really, really, really seamless on mobile, for example. So there's a number of factors. For me, and my clients, it'll be working out a sweet spot, to also working out “If getting from here to here is going to make you 1.8 mil a year, I can find you that second for a fraction of that cost.” If you want me to get you an additional second on top of that, it's going to get a lot harder. So my cost to you will probably go up, and that won't be an extra 1.8, because it's not lineal, you don't get 1.8 mil for every one second.

Harry: It will tail off at some point. And clients will get to a point where… they'll still be making gains but it might be a case of your engineering effort doubles, meaning your returns halve, you can still be in the green, hopefully it doesn't get more expensive and you're losing money on performance, but there's a point where you need to slow down. And that's usually things that I help clients find out because otherwise they will just keep chasing speed, speed, speed and get a bit blinkered.

Drew: Yeah, it is sort of diminishing returns, isn't it?

Harry: That's what I was look for-

Drew: Sí.

Harry: … diminishing returns, that's exactly it. Si, exacto.

Drew: And in terms of knowing where to focus your effort… Say you've got the bulk of your users, 80% of your users are getting a response within two, three seconds, and then you've got 20% who may be in the long-tail that might end up with responses five, ten seconds. Is it better to focus on that 80% where the work's really hard, or is it better to focus on the 20% that's super slow, where the work might be easier, but it's only 20%. How do you balance those sorts of things?

Harry: Drew, can you write all podcast questions for everyone else? This is so good. Well, a bit of a shout out to Tim Kadlec, he's done great talks on this very topic and he calls it “The Long-Tail of Web Performance” so anyone listening who wants to look at that, Tim's done a lot of good firsthand work there. The 80, 20, let's just take those as good example figures, by the time you're dealing with the 80th percentile, you're definitely in the edge cases. All your crooks and web file data is based around 75th percentile. I think there's a lot of value investing in that top 20th percentile, the worst 20%. Several reasons for this.

Harry: First thing I'm going to start with is one of the most beautiful, succinct soundbites I've ever heard. And the guy who told me it, I can guarantee, did not mean it to be this impactful. I was 15 years old and I was studying product design, GCSE. Finally, a project, it was a bar stool so it was a good sign of things to come. And we were talking about how you design furniture. And my teacher basically said… I don't know if I should… I'm going to say his name, Mr. Brocklesby.

Harry: Infundía respeto, pero era uno de los muchachos, a todos nos gustaba mucho. Pero él era enorme en todas las dimensiones. Más de seis pies de alto, pero solo un muchacho grande. Hombre grande, grande, grande, grande. Y nos dijo: "Si tuviera que diseñar una puerta, ¿la diseñaría para la persona promedio?" Y los cerebros de 15 años dicen: "Bueno, sí, si todos miden aproximadamente 5'9, entonces sí". Él dijo: "Bueno, inmediatamente, Harry no puede usar esa puerta". No diseñas para la persona promedio, diseñas para las extremidades porque quieres que sea útil para la mayoría de las personas. Si diseñabas una silla para la persona promedio, el Sr. Brocklesby no cabría en ella. Así que me enseñó desde muy, muy joven, el diseño de tus extremidades.

Harry: Y donde eso se vuelve realmente interesante en web perf es... Si imaginas una escalera, y levantas la escalera por el bot... Bueno, me acabo de dar cuenta de que mi metáfora podría... Me quedaré con ella y puedes reírte de ella. yo después. Imagina una escalera y la levantas por los peldaños inferiores. Y esa es tu peor experiencia. Eliges el peldaño inferior de la escalera para levantarla. Toda la escalera viene con ella, como una marea creciente hace flotar todos los barcos. La razón por la que la metáfora no funciona es que si levantas una escalera por el peldaño superior, todo se levanta también, es una escalera. Y la metáfora ni siquiera funciona si la convierto en una escalera de cuerda, porque una escalera de cuerda entonces, levantas el peldaño inferior y no pasa nada, pero... mi punto es que si puedes mejorar la experiencia para tu percentil 90, tiene que sube eso para tu percentil 10, ¿verdad?

Harry: Y es por eso que les digo a los clientes que me dirán cosas como "Oh, bueno, la mayoría de nuestros usuarios usan 4G en iPhones", así que está bien, está bien, y comenzamos a probar 3G en Android, como "No, no, la mayoría de nuestros usuarios son iPhones”, está bien… eso significa que su usuario promedio tendrá una mejor experiencia, pero cualquiera que no esté en el percentil 50 simplemente se queda más atrás. Así que ponte el listón bastante alto estableciendo expectativas bastante bajas.

Harry: Lo siento, tengo la mala costumbre de dar respuestas muy largas a preguntas cortas. Pero fue una pregunta fantástica y, para tratar de concluir, estoy 100 % definitivamente de acuerdo contigo en que quieres mirar esa cola larga, quieres mirar ese... tu percentil 80 porque si tomas todas las experiencias en el sitio y observa la mediana, y mejora la mediana, eso significa que lo ha mejorado aún más para las personas que ya estaban bastante satisfechas. El 50% de las personas que son efectivamente ignoradas no es el enfoque correcto. Y sí, siempre vuelve al Sr. Brocklesby diciéndome "No diseñes para la persona promedio porque entonces Harry no puede usar la puerta". Oh, para cualquiera que esté escuchando, mido 193 centímetros, así que soy bastante larguirucho, eso es lo que es.

Drew: Y todos esos brazos y piernas.

harry: si Aquí hay otro bueno también. Mi novia descubrió recientemente la configuración de accesibilidad en iOS... así que todo el mundo tiene su teléfono en silencio, ¿verdad? En realidad, nadie tiene un teléfono que realmente suene, todos lo tienen en silencio. Descubrió que “Oh, ya sabes, puedes configurarlo para que cuando recibas un mensaje, el flash parpadee. Y si toca la parte posterior del teléfono dos veces, hará una captura de pantalla”. Y estas son configuraciones de accesibilidad, están diseñadas para ese percentil 95. Sin embargo, ella es como "Oh, esto es realmente útil".

Harry: Lo mismo con OXO Good Grips. OXO Good Grips, los utensilios de cocina. Tengo un montón de ellos en la cocina. Están diseñados porque la esposa del fundador tenía artritis y quería hacer utensilios más cómodos. Diseñó para el percentil 99, la mayoría de las personas no tienen artritis. Pero al diseñar para el percentil 99, sin darse cuenta, todos los demás dicen: "Oh, Dios mío, ¿por qué no todos los peladores de papas pueden ser tan cómodos?" Y siento que es realmente, realmente... Me gusta sentirme bien o anécdota que me gusta sacar a la luz en este tipo de escenarios. Pero sí, si optimizas para ellos... Bueno, una marea creciente hace flotar todos los barcos y eso, por lo tanto, optimiza la parte final de la gente y vas a capturar muchos clientes aún más felices por encima de eso.

Drew: ¿Tienes el batidor manual OXO Good Grips?

Harry: Yo no. Yo no, ¿es bueno?

Drew: Míralo. Es tan bueno.

Harry: Tengo la cortadora de mandolina OXO Good Grips que me cortó la punta del dedo la semana pasada.

Drew: Sí, no me acercaré a uno de esos.

Harry: Sí, es mi estúpida culpa.

Drew: Otro ejemplo de mi propia experiencia con el catering para esa cola larga es que, en el proyecto en el que estoy trabajando en este momento, esa cola larga está justo al final, tienes personas con el rendimiento más lento, pero si resulta que si observa quiénes son esos clientes, son los clientes más valiosos para el negocio-

Harry: Está bien.

Drew: … porque son las organizaciones más grandes con la mayor cantidad de datos.

Harry: Cierto.

Drew: Entonces, se encuentran con cuellos de botella porque tienen muchos datos para mostrar en una página y esas páginas deben refactorizarse un poco para ayudar en ese caso de uso. Por lo tanto, están teniendo la experiencia más lenta y, cuando se trata de eso, pagan la mayor cantidad de dinero y marcan una diferencia mucho mayor que todas las personas que tienen una experiencia realmente rápida porque son usuarios gratuitos con un pequeña cantidad de datos y todo funciona bien y es rápido.

Harry: Esa es una dimensión fascinante, ¿no? De hecho, tuve un impacto similar en el negocio que acabas de describir, pero trabajé con un cliente hace un par de años y su director ejecutivo se puso en contacto porque su sitio era lento. Como, lento, lento, lento. Un tipo muy agradable también, es un tipo muy agradable con los pies en la tierra, pero tiene un mentor, como un verdadero rico. Y tiene el último iPhone, se lo puede permitir. Es multimillonario, pasa gran parte de su tiempo volando entre Australia, de donde es, y Estonia, donde reside ahora.

Harry: Y él está volando en primera clase, por supuesto que sí. Pero significa que la mayor parte de su tiempo en su bonito y brillante iPhone 12 Pro Max lo que sea, lo que sea, lo hace a través del WiFi del avión, lo cual es terrible. Y fue esta yuxtaposición realmente sorprendente en la que él posee el sitio y lo usa mucho, es un sitio que usa. Y lo estaba presionando... Quiero decir, fácilmente, su cliente más rico era su director general. Y está en esta posición extrañamente privilegiada en la que tiene una conexión peor que Joe Public porque está en algún lugar por encima de Singapur en un vuelo de Quantas mientras le vierten champán en el cuello y está luchando. Y esa fue una idea realmente fascinante de que... Ah, sí, porque tienes tu percentil 95 básicamente puede ir en cualquier dirección.

Drew: Sí, es cuando comienzas a optimizar para usar un sitio con una copa de champán en una mano que piensas: "Tal vez estamos empezando a perder un poco el camino".

Harry: Sí, exactamente.

Drew: Hablamos un poco sobre la medición del desempeño y, según mi propia experiencia con el trabajo de desempeño, es realmente esencial medir todo. estás haciendo una diferencia y cuánta diferencia estás haciendo. ¿Cómo deberíamos medir el rendimiento de nuestros sitios? ¿Qué herramientas podemos utilizar y por dónde debemos empezar?

Harry: Oh hombre, otra gran pregunta. Por lo tanto, hay una variedad de respuestas según la cantidad de tiempo, los recursos y la inclinación hacia la fijación de la velocidad del sitio. Entonces, lo que intentaré hacer con el cliente es... Ciertas métricas listas para usar son realmente buenas. Tiempo de carga, ya no te preocupes por eso. Es muy, muy, muy... Quiero decir, es un buen proxy si su tiempo de carga es de 120 segundos. Supongo que no tiene un sitio web muy rápido, pero es demasiado oscuro y no está realmente orientado al cliente. De hecho, creo que los datos vitales son un muy buen paso en la dirección correcta porque miden la experiencia del usuario, pero se basan en información técnica. La pintura con contenido más grande es realmente agradable para la vista, pero las cosas técnicas desbloquean su ruta crítica, se aseguran de que las imágenes principales lleguen rápidamente y se aseguran de que su estrategia de fuente web sea decente. Hay un trasfondo técnico en estas métricas. Esos son realmente buenos listos para usar.

Harry: Sin embargo, si los clientes tienen tiempo, generalmente es tiempo, porque desea capturar los datos pero necesita tiempo para capturarlos realmente. Entonces, lo que trato de hacer con los clientes es decir: “Mira, no podemos trabajar juntos durante los próximos tres meses porque estoy completamente ocupado. Entonces, lo que podemos hacer es configurarlo rápidamente con una prueba gratuita de Speedcurve, configurar algunas métricas personalizadas”, lo que significa que para un cliente editorial, un periódico, estaría midiendo “Qué tan rápido fue el titular de la artículo presentado? ¿Qué tan rápido se procesó la imagen principal del artículo?” Para un cliente de comercio electrónico, quiero medir, porque obviamente estás midiendo cosas como comenzar a renderizar de forma pasiva. Tan pronto como comience a usar cualquier software de monitoreo de rendimiento, estará capturando sus métricas de rendimiento reales de forma gratuita. Entonces, su primera pintura con contenido, la más grande con contenido, etc. Lo que realmente quiero capturar son las cosas que les importan como negocio.

Harry: Entonces, trabajando con un cliente de E-Com en el momento en que podemos correlacionar... Cuanto más rápido se inicie, ¿cuál es la probabilidad de que se agregue al carrito? Si puede mostrarles un producto antes, es más probable que lo compren. Y esto es un gran esfuerzo para configurarlo, este es un tipo de objetivo ambicioso para los clientes que son realmente ambiciosos, pero cualquier cosa que realmente quieras medir, porque como digo, realmente no quieres medir lo que tu más grande Contentful Paint es, ¿quieres medir tus ingresos y eso fue influenciado por Large Contentful Paint? Entonces, el objetivo final, lo último, sería cualquier cosa que verías como un KPI para ese negocio. Podría ser, en los periódicos, ¿hasta dónde se desplazó alguien en el artículo? ¿Y eso se correlaciona de alguna manera con el retraso de la primera entrada? ¿La gente leyó más artículos si CLS era más bajo? Pero luego, antes de que comencemos a hacer métricas personalizadas, creo sinceramente que web vitals es un muy buen lugar para comenzar y también se ha normalizado bastante bien. Se convierte en… no sé cuál es la palabra. El denominador común más bajo, supongo, donde todos en la industria ahora pueden discutir el rendimiento en este campo de juego nivelado.

Harry: Un problema que tengo, y necesito programar una reunión con el equipo de vitals, es que también creo que Lighthouse es genial, pero CLS es el 33 % de web vitals. Tienes LCP, FID, CLS. CLS es el 33% de sus signos vitales. Vitals es lo que normalmente pasa frente a su equipo de marketing, su departamento de análisis, porque aparece en la consola de búsqueda, se menciona en el contexto de las páginas de resultados de búsqueda, en lo que respecta a vitals, tiene una gran ponderación, 33%, un tercio de signos vitales es CLS, es solo el 5 % de nuestra puntuación Lighthouse. Entonces, lo que obtendrá son desarrolladores que construyen alrededor de Lighthouse, porque se puede integrar en las herramientas, es una métrica de laboratorio. Vitals son datos de campo, es ron.

Harry: Así que tienes esta desconexión masiva en la que tu equipo de marketing dice "CLS es realmente malo" y los desarrolladores piensan "Bueno, es el 5 % de la puntuación de Lighthouse que DevTools me está dando, es el 5 % de la puntuación que Lighthouse CLI nos brinda en CircleCI” o lo que sea que esté usando, sin embargo, para el equipo de marketing es el 33% de lo que les importa. Entonces, el problema es una pequeña desconexión porque creo que Lighthouse es muy valioso, pero no sé cómo concilian esa diferencia bastante grande en la que, en los signos vitales, CLS es el 33 % de tu puntaje... bueno, no puntúas porque tú realmente no tengo uno, y Lighthouse es solo el 5%, y son cosas como esas las que aún necesitan resolverse antes de que podamos hacer que esta discusión sea fluida.

Harry: Pero, de nuevo, larga respuesta a una breve pregunta. Vitals es realmente bueno. LCP es una buena métrica de experiencia de usuario que se puede reducir a soluciones técnicas, lo mismo con CLS. Así que creo que es un muy buen punto de partida. Más allá de eso, son métricas personalizadas. Lo que trato de llevar a mis clientes es a un punto en el que realmente no les importa qué tan rápido es su sitio, solo les importa ganar más dinero desde ayer, y si lo hicieron, ¿es porque estaba funcionando rápido? ¿Si hizo menos es porque iba más lento? No quiero que persigan un LCP místico de dos segundos, quiero que persigan el LCP óptimo. Y si eso realmente resulta ser más lento de lo que piensas, entonces lo que sea, está bien.

Drew: Entonces, para el desarrollador web que solo está interesado en... no tiene presupuesto para gastar en herramientas como Speedcurve y otras cosas, obviamente puede ejecutar herramientas como Lighthouse dentro de su navegador, para obtener una buena medición... Son cosas como Google ¿Analytics útil para ese nivel?

Harry: Lo son y se pueden hacer más útiles. Analytics, desde hace muchos años, ha capturado información de rendimiento rudimentaria. Y ese será el tiempo de DNS, TCP y TLS, el tiempo hasta el primer byte, el tiempo de descarga de la página, que es un proxy... bueno, lo que sea, solo el tiempo de descarga y el tiempo de carga de la página. Métricas tan bastante torpes. Pero es un buen punto de partida y, normalmente, cada proyecto que empiezo con un cliente, si no tiene New Relic o Speedcurve o lo que sea, solo digo "Bueno, déjame echar un vistazo a tus análisis" porque puedo menos proxy de la situación desde allí. Y nunca va a ser tan bueno como algo como Speedcurve o New Relic o Dynatrace o lo que sea. Puede enviar métricas personalizadas muy, muy, muy fácilmente a análisis. Si alguien que escucha quiere poder enviar... mi sitio, por ejemplo. Tengo métricas como “¿Qué tan rápido puedes leer el encabezado de uno de mis artículos? ¿En qué momento se representó la imagen de la página Acerca de? ¿En qué momento fue el llamado a la acción que les implora que me contraten? ¿Qué tan pronto se muestra eso en la pantalla? Realmente trivial capturar estos datos y casi tan trivial enviarlos a análisis. Entonces, si alguien quiere ver la fuente en mi sitio, desplácese hacia abajo hasta la etiqueta del cuerpo de cierre y busque el fragmento de análisis, verá lo fácil que es para mí capturar datos personalizados y enviarlos a análisis. Y, en la interfaz de usuario de análisis, no necesita hacer nada. Normalmente, tendría que configurar informes personalizados y extraer los datos y hacerlos presentables. Estos son ciudadanos de primera clase en Google Analytics. Entonces, en el momento en que comienza a capturar análisis personalizados, hay una sección completa del tablero dedicada a ello. No hay configuración, no hay trabajo pesado en GA en sí mismo, por lo que es realmente trivial y, si los clientes tienen un presupuesto real o tal vez quiero mostrarles el poder del monitoreo personalizado, no quiero decir "Oh sí, lo prometo será realmente bueno, ¿puedo tener 24 mil para Speedcurve? Puedo empezar simplemente diciendo “Mira, esto es rudimentario. Veamos las posibilidades aquí, ahora tal vez podamos convencerlo de que actualice a algo como Speedcurve”.

Drew: A menudo me he dado cuenta de que mi instinto sobre qué tan rápido debería ser algo, o qué impacto debería tener un cambio, puede ser incorrecto. Haré un cambio y creo que estoy haciendo las cosas más rápido y luego lo mido y en realidad he hecho las cosas más lentas. ¿Soy solo yo siendo basura en web perf?

harry: de nada Tengo un ejemplo muy pertinente de esto. Precarga… una introducción realmente rápida para cualquiera que no haya oído hablar de la precarga, la carga de ciertos activos en la web es intrínsecamente muy lenta y los dos principales candidatos aquí son imágenes de fondo en CSS y fuentes web, porque antes de que pueda descargar una imagen de fondo, tiene para descargar el HTML, que luego descarga el CSS, y luego el CSS dice "Oh, este div en la página de inicio necesita esta imagen de fondo". Por lo tanto, es intrínsecamente muy lento porque tiene todo ese tiempo de CSS en el medio. Con la precarga, puede poner una línea en HTML en la etiqueta principal que diga "Oye, aún no lo sabes, pero créeme, necesitarás esta imagen muy, muy, muy pronto". Por lo tanto, puede colocar una carga previa en el HTML que activa de forma preventiva esta descarga. Cuando el CSS necesita la imagen de fondo, es como "Oh, genial, ya la tenemos, eso es rápido". Y esto se promociona como este Mesías perf web... Aquí está la cosa, y te lo prometo, tuiteé esto la semana pasada y se ha demostrado que tengo razón dos veces desde entonces. La gente escucha sobre la precarga, y la promesa que ofrece, y también está fuertemente impulsada por Lighthouse, en teoría, hace que su sitio sea más rápido. La gente se casa tanto con la idea de la precarga que incluso cuando puedo demostrar que no funciona, no la quitan de nuevo. Porque “No, pero dijo Lighthouse”. Ahora bien, esta es una de esas cosas donde la teoría es sólida. Si tiene que esperar por su fuente web, en lugar de descargarla antes, verá las cosas más rápido. El problema es que, cuando piensas en cómo funciona realmente la web, cualquier página que accedas por primera vez, cualquier dominio nuevo que accedas, tienes una cantidad finita de ancho de banda y el navegador es muy inteligente gastando ese ancho de banda correctamente. Revisará su HTML muy rápidamente y hará una lista de compras. Lo más importante es CSS, luego es jQuery, luego es esto... y luego las siguientes cosas son estas, estas y estas menos prioritarias. Tan pronto como comienzas a cargar tu HTML con precargas, le estás diciendo al navegador “No, no, no, esta ya no es tu lista de compras, amigo, esta es la mía. Tienes que ir a buscar esto. Esa cantidad finita de ancho de banda sigue siendo finita, pero no se gasta en más activos, por lo que todo se vuelve marginalmente más lento. Y tuve que abuchear esto dos veces la semana pasada, y aún así la gente dice: "Sí, pero no, es porque se descarga antes". No, se solicita antes, pero está robando ancho de banda de su CSS. Literalmente puedes ver que tus fuentes web están robando ancho de banda de tu CSS. Así que es una de esas cosas en las que tienes que seguir los números. Lo he hecho antes en un cliente a gran escala. Si estás escuchando esto, has oído hablar de este cliente, y yo insistí bastante en que "No, no, tus etiquetas de cabeza están en el orden incorrecto porque así es como debería ser y necesitas tenerlas en este orden porque teóricamente da pistas en eso…” Incluso en lo que yo era para el cliente sabía que me estaba poniendo en ridículo. Debido a cómo funcionan los navegadores, tiene que ser más rápido. Así que estoy haciendo la estratagema, este cambio... a muchos millones de personas, y se hizo más lento. Se hizo más lento. Y yo sentado allí, insistiendo indignado “No, pero los navegadores funcionan así” es inútil porque no funciona. Y lo revertimos y yo estaba como “¡Lo siento! ¡Todavía te voy a facturar por eso!” Así que no eres tú en absoluto.

Drew: Sigue estos números.

Harry: Sí, exactamente. "De hecho, tengo que cobrarte más, porque pasé tiempo revirtiéndolo, me tomó más tiempo". Pero sí, tienes toda la razón, no eres tú, es una de esas cosas en las que... Lo he hecho un montón de veces en una escala mucho más pequeña, donde estaré como "Bueno, en teoría, esto debe funcionar" y no funciona. 't. Sólo tienes que seguir lo que sucede en el mundo real. Es por eso que ese seguimiento es realmente importante.

Drew: A medida que cambia el panorama y se desarrolla la tecnología, Google implementa nuevas tecnologías que nos ayudan a hacer las cosas más rápido, ¿hay alguna buena manera de mantenernos al día con los cambios? ¿Hay algún recurso que deberíamos considerar para mantener nuestras habilidades actualizadas en lo que respecta al rendimiento web?

Harry: Para abordar rápidamente toda la "creación de Google"... Sé que es un poco irónico, pero me voy a centrar en esto. Supongo que justo al principio, apuesta por el navegador. Cosas como AMP, por ejemplo, son, en el mejor de los casos, una solución a posteriori. No hay reemplazo para construir un sitio rápido, y en el momento en que comienza a usar cosas como AMP, debe aferrarse a esos estándares no estándar, la misericordia del equipo de AMP cambia de opinión. Tuve un cliente que gastó una fortuna en la licencia de una fuente de un proveedor de fuentes de la lista de permitidos de AMP, luego, en algún momento, AMP decidió "Oh, en realidad no, esa fuente proporcionada, vamos a bloquearla ahora". Así que tenía un cliente que invirtió mucho en AMP y este proveedor de fuentes y tuvo que elegir "Bueno, deshacemos todo el trabajo de AMP o simplemente desperdiciamos este gran número al año en la fuente web" bla, bla, bla. Por lo tanto, sería muy cauteloso con cualquiera... Soy un experto en desarrollo de Google, pero no conozco ninguna orden de mordaza... Puedo ser crítico y diría... evite las cosas que son aclamadas como de talla única. -Solución para todos, cosas como AMP.

Harry: Y para hablar con alguien más por un segundo, Cloudflare tiene una cosa llamada Rocket Loader, que es AMP-esque en su esfuerzo. Está diseñado como "Oh, solo active esta cosa en su CDN, hará que su sitio sea más rápido". Y en realidad es solo un reemplazo para construir su sitio correctamente en primer lugar. Entonces… para abordar ese aspecto, trate de mantenerse lo más independiente posible, sepa cómo funcionan los navegadores, lo que significa inmediatamente que Chrome monoculture, está de vuelta en el regazo de Google, pero sepa cómo funcionan los navegadores, apéguese a algunas ideologías fundamentales. Cuando esté construyendo un sitio, mire la página. Ya sea que esté en Figma, Sketch o donde sea, mire el diseño y diga: “Bueno, eso es lo que un usuario quiere ver primero, así que no pondré nada en el camino de eso. No cargaré de forma perezosa esta imagen principal porque es una tontería, ¿por qué haría eso?”. Así que solo piensa en "¿Qué te gustaría que el usuario fuera primero?" En un sitio de E-Com, será la imagen del producto, probablemente la navegación al mismo tiempo, pero las revisiones del producto, las preguntas y respuestas del producto, la carga diferida. Meta eso detrás de JavaScript.

Harry: Ciertas formas fundamentales de trabajar que le servirán sin importar la tecnología sobre la que esté leyendo, que es "Priorizar lo que prioriza su cliente". Trabajar más en eso sería más rápido, así que no ponga las cosas en el camino de eso, sino más cosas tácticas para que las personas estén al tanto, mantenerse al tanto... y de nuevo, directamente a Google, pero web.dev está demostrando ser un recurso fenomenal para los conocimientos agnósticos del marco y de la pila... Así que si quieres aprender sobre vitals, quieres aprender sobre PWA, entonces web.dev es realmente genial.

Harry: En realidad, hay muy pocas publicaciones centradas en el rendimiento. El correo electrónico de Calibre es, creo que su correo electrónico de rendimiento quincenal es simplemente fenomenal, es un muy buen resumen. Esté atento a la plataforma web en general, así que está el Grupo de trabajo de rendimiento, tienen un montón de cosas sobre las propuestas de GitHub. Una vez más, volvamos a Google, pero nadie sabe acerca de este sitio web y su fenomenal: chromestatus.com. Le dice exactamente en qué está trabajando Chrome, cuáles son las señales de otros navegadores, por lo que si desea ver cuál es el trabajo en las sugerencias de prioridad, puede ir y obtener enlaces a todos los rastreadores de errores relevantes. Chrome Status muestra los hitos de cada... "Esto saldrá en MAT8, se lanzó en el 67" o lo que sea, eso es algo muy bueno para los conocimientos técnicos.

Harry: Pero sigo volviendo a esto, y sé que probablemente suene como "El viejo le grita a Cloud", pero me limito a lo básico, casi cada libra o dólar, euro, que he ganado, ha estado enseñando a los clientes. que "Sabes que el navegador ya hace esto, verdad" o "Sabes que esto no podría ser más rápido" y eso suena muy correcto de mi parte... Nunca he ganado un centavo con la venta de tecnología adicional. Todo el dinero que gano se trata de eliminar, restar. Si te encuentras agregando cosas para que tu sitio sea más rápido, estás en la dirección equivocada.

Harry: Por ejemplo, no voy a nombrar... la gran empresa de publicidad/motor de búsqueda/navegador en absoluto, no los voy a nombrar, y no voy a nombrar el marco de JavaScript, pero actualmente estoy en discusiones con un marco de JavaScript muy, muy grande y muy popular sobre la eliminación de algo que está dañando activamente u opcionalmente eliminando algo que dañaría el rendimiento de una gran cantidad de sitios web. Y dijeron: "Oh, vamos a conectar..." alguien de esta gran empresa, porque investigaron un poco... y es como "Necesitamos una opción para eliminar esto porque puedes ver aquí, y aquí, y aquí está haciendo que este sitio sea más lento”. Y su solución fue agregar más, como "Oh, pero si haces esto también, entonces puedes eludir eso" y es como "No, no, agregar más para hacer que un sitio sea más rápido debe ser la solución incorrecta". Seguramente puede ver que va en la dirección equivocada si se necesita más código para terminar con un sitio más rápido”.

Harry: Porque fue rápido al principio, y todo lo que agregas es lo que lo hace más lento. Y la idea de agregar más para hacerlo más rápido, aunque… podría manifestarse en un sitio web más rápido, es una forma equivocada de hacerlo. Es una carrera hacia el fondo. Lo siento, me estoy poniendo muy nervioso, se nota que no he despotricado por un tiempo. Entonces esa es la otra cosa, si se encuentra agregando funciones para hacer que un sitio sea más rápido, probablemente se esté dirigiendo en la dirección equivocada, es mucho más efectivo eliminar cosas que agregarlas.

Drew: Ha creado un curso en video llamado "Todo lo que he hecho para hacer que la magia de CSS sea rápida".

Harry: ¡Sí!

Drew: Es un poco diferente de los cursos de video en línea tradicionales, ¿no es así?

harry: lo es Seré honesto, es en parte… No quiero decir pereza de mi parte, pero no quería diseñar un plan de estudios que tenía que ser muy rígido y llevarte de cero a héroe porque el tiempo que implica hacerlo es enorme y tiempo que no sabía si tendría. Entonces, lo que quería era tener material listo para usar, solo proyectarme en la pantalla hablando a través de él para que no comience con "Aquí hay un navegador y así es como funciona", por lo que debe ser al menos consciente de fundamentos web perf, pero son trucos, consejos profesionales y ejemplos de la vida real.

Harry: Y como no necesitaba hacer un plan de estudios completo, pude bajar el precio de golpe. Por lo tanto, no es un gran curso de 10 horas que lo llevará de cero a héroe, es entrar y salir como mejor le parezca. Básicamente, es solo mirar mi sitio, que es un excelente patio de recreo para cosas que son inestables o... es muy poco riesgo para mí experimentar allí. Así que acabo de hacer una serie de videos. Fue muy divertido grabar. Simplemente derribando mi propio sitio y hablando de "Bueno, así es como funciona esto y así es como podrías usarlo".

Drew: Creo que es genial cómo se divide para resolver diferentes problemas. Si quiero obtener más información sobre la optimización de imágenes o lo que sea, puedo pensar: "Bien, ¿qué tiene que decir mi amigo Harry sobre esto?", Me sumerjo en el video sobre imágenes y listo. Es realmente accesible de esa manera, no tienes que sentarte durante horas y horas de cosas, puedes simplemente ir a la parte que quieras y aprender lo que necesitas aprender y luego salir.

Harry: Creo que traté de mantenerlo más... El beneficio de no hacer un currículo rígido es que no necesitas ver un determinado video primero, no hay introducción, es solo "Ve y mira alrededor y mira lo que encuentras interesante". lo que significa que alguien que sufre problemas de LTP es como "Oh, bueno, tengo que sumergirme en esta carpeta aquí" o si sufre problemas de CSS, puede sumergirse en esa carpeta. Obviamente, no tengo estadísticas, pero me imagino que hay una alta tasa de abandono en los cursos, simplemente porque tienes que pasar tres horas de introducción en caso de que te pierdas algo, y es como "Oh, ¿sabes qué? No puedo sigue haciendo esto todos los días” y la gente podría abandonar muchos cursos. Así que mi pensamiento fue sumergirme, no es necesario que hayas visto las tres horas anteriores, puedes ir y encontrar lo que quieras. Y los comentarios han sido muy, muy... De hecho, lo que haré es que aún no existe, pero lo haré inmediatamente después de la llamada, cualquiera que use el código de descuento SMASHING15 obtendrá un 15 % de descuento de eso

Drew: Es casi como si hubieras optimizado el rendimiento del curso en sí, porque puedes ir directamente a la parte que quieras y no tienes que hacer toda la negociación y...

Harry: Sí, sin querer, pero me lo atribuiré.

Drew: Entonces, he estado aprendiendo todo sobre el rendimiento web, ¿qué has estado aprendiendo tú últimamente, Harry?

Harry: Cosas técnicas... no realmente. Tengo mucho en mi lista de "aprender", así que QUIC, H3 tipo de cosas Me gustaría obtener un poco más de conocimiento práctico de eso, pero escribí un libro electrónico durante el primer cierre en el Reino Unido, así que aprendí. cómo hacer E-Books, que fue muy divertido porque son solo HTML y CSS y sé cómo hacerlo, así que fue muy divertido. Aprendí una edición de video muy rudimentaria para el curso, y lo que me gustó de eso no es nada de trabajo conceptual. Obviamente, al aprender un lenguaje de programación, tienes que luchar contra los conceptos, mientras que aprender un libro electrónico era solo flujos de trabajo y... cosas con las que nunca había jugado antes, así que fue interesante de aprender pero no requirió un cambio de carrera. , así que eso fue bastante agradable.

Harry: Y luego, cosas no técnicas... Monto muchas bicicletas, me caigo de muchas bicicletas... y como no he viajado desde marzo pasado, hace casi un año, he estado haciendo mucho más. andar en bicicleta y centrarme mucho más en… mejorar eso. Así que he estado investigando mucho sobre las salidas de potencia y las potencias de umbral funcional, estoy haciendo un programa de entrenamiento en este momento, por lo que constantemente, piernas agotadas constantemente, pero estoy aprendiendo mucho sobre fisiología en torno al ciclismo. No sé por qué, porque no tengo planes de hacer nada más que seguir montando. Ha sido realmente fascinante. Siento que he sido muy afortunado durante los encierros, en plural, pero he logrado mantenerme activo. Mucha gente se perderá cosas simples como un viaje diario a la oficina, una buena oportunidad para estirar las piernas. En el Reino Unido, como sabrás, el ciclismo ha sido muy defendido, así que he estado jugando mucho más para aprender más sobre andar en bicicleta desde un aspecto más fisiológico, lo que significa... no sé, solo ser un nerd sobre otra cosa para variar.

Drew: ¿Quizás no hay tanta diferencia entre la optimización del rendimiento en la web y la optimización del rendimiento en el ciclismo, son todas ganancias marginales, verdad?

Harry: Sí, exactamente. Y la cantidad de gráficos que he estado viendo en la bicicleta... Tengo datos de potencia de la bicicleta, salgo a dar un paseo y vuelvo como "Oh, si tuviera cinco vatios más aquí pero luego ahorrara 10 vatios allí, podría hacer esto, esto y esto más rápido que nunca ”y … he sido un anorak enorme al respecto. Pero sí, tienes razón. ¿Sabes qué? Creo que has dado con algo realmente interesante. Creo que ese tipo de cosas es un buen deporte/pasatiempo para alguien que es un poco obsesivo, a quien le gusta perseguir números. Hay cosas encendidas, quiero decir que sabrás esto, pero, Strava, tienes tus KOM. Empaqué 19 de ellos el año pasado, lo que es, para mí, una cantidad fenomenal. Y casi todo se debe a obsesionarse con los datos disponibles y mirar "Este tipo al que estoy tratando de vencer, estaba haciendo 700 vatios en este punto, si pudiera llegar a 1000 y luego disminuir" y bla, bla, bla … es ser obsesivo. nerd Pero tienes razón, supongo que es algo similar, ¿no? If you could learn where you afford to tweak things from or squeeze last little drops out…

Drew: And you've still got limited bandwidth in both cases. You've got limited energy and you've got limited network connection.

Harry: Exactly, you can't just magic some more bandwidth there.

Drew: If you, the listener, would like to hear more from Harry, you can find him on Twitter, where he's @csswizardty, or go to his website at csswizardry.com where you'll find some fascinating case studies of his work and find out how to hire him to help solve your performance problems. Harry's E-Book, that he mentioned, and video course we'll link up from the show notes. Thanks for joining us today, Harry, do you have any parting words?

Harry: I'm not one for soundbites and motivation quotes but I heard something really, really, really insightful recently. Everyone keeps saying “Oh well we're all in the same boat” and we're not. We're all in the same storm and some people have got better boats than others. Some people are in little dinghies, some people have got mega yachts. Oh, is that a bit dreary to end on… don't worry about Corona, you'll be dead soon anyway!

Drew: Keep hold of your oars and you'll be all right.

harry: si I was on a call last night with some web colleagues and we were talking about this and missing each other a lot. The web is, by default, remote, that's the whole point of the web. But… missing a lot of human connection so, chatting to you for this hour and a bit now has been wonderful, it's been really nice. I don't know what my parting words really are meant to be, I should have prepared something, but I just hope everyone's well, hope everyone's making what they can out of lockdown and people are keeping busy.