- El embed `` predeterminado de YouTube, incluso si se agrega solo uno en una página vacía, genera 32 solicitudes y 1.3 MB de transferencia, una carga considerable para una UI de video pequeña
- Si se agregan varios videos, los recursos no se comparten y el peso aumenta linealmente; en las mediciones de Zach Leatherman sube a 2.4 MB con 2 embeds y a 3.6 MB con 3
- Las funciones visibles al inicio son básicamente la imagen de póster, el título y un gran botón de reproducción, por lo que se puede recrear la misma experiencia de forma más ligera con un Web Component como ``
lite-youtube-embed pesa alrededor de 100 KB y comparte recursos entre varios embeds, mejorando velocidad y eficiencia sin perder funcionalidad- Dado el uso extendido de los embeds de YouTube, reducir megabytes de datos por embed se convierte en una optimización real que también baja el consumo eléctrico y las emisiones de carbono
El costo del embed `` predeterminado
- Al seleccionar
Embed en el menú de compartir de YouTube, se entrega HTML basado en ``
- El código predeterminado no incluye
loading="lazy", por lo que incluso videos fuera de pantalla pueden cargarse de inmediato
- Si YouTube agregara solo carga diferida al iframe predeterminado, podría lograr una mejora de rendimiento inmediata
- Para hacer que el iframe sea responsivo y mantenga su proporción original, se puede apuntar directamente al iframe del embed de YouTube con CSS
iframe[src^="https://www.youtube.com/embed/";] {
inline-size: 100%;
block-size: auto;
aspect-ratio: 16 / 9;
}
Mediciones reales y aumento lineal
- Incluso al poner un solo embed de YouTube en una página vacía, el costo de carga resulta alto
-
32 solicitudes
- 1.3 MB de transferencia de datos
- 2.76 segundos de carga con el WiFi del autor
- Zach Leatherman registró que, a medida que aumentan los embeds, los recursos no se comparten y el peso crece linealmente
- 2 embeds: 2.4 MB
- 3 embeds: 3.6 MB
- Actualmente parece que el tamaño aumentó aún más respecto del momento en que Zach lo verificó
La UI que el usuario ve primero es simple
- Los elementos que el usuario encuentra primero en un embed de YouTube son limitados
- La imagen de póster del video
- El título del video
- Un gran botón de reproducción que inicia el video al hacer clic
- Esa UI y ese comportamiento se pueden implementar sin cargar primero todos los recursos del reproductor de YouTube
- Es difícil evaluar la afirmación de que un embed ligero reduce la participación si no se publican la metodología y los datos
- También hubo un caso en el pasado en el que, cuando un ingeniero de YouTube probó una página de video más ligera, el tiempo de carga promedio aumentó
- La página más ligera llegó también a usuarios con dispositivos de bajo rendimiento y conexiones lentas
- El uso por parte de esos nuevos usuarios ahora alcanzables pudo haber hecho que la métrica de tiempo de carga promedio pareciera más lenta
- Si se mira solo el tiempo de carga promedio, se pueden pasar por alto mejoras reales de velocidad a nivel de usuario
Alternativa: Web Component ``
- lite-youtube-embed, creado por Paul Irish, una figura relacionada con performance en Google, es un Web Component que recrea la experiencia del embed predeterminado de forma más ligera
- La descripción del proyecto dice que renderiza como el embed real y es aproximadamente 224 veces más rápido
- La experiencia de usuario es casi igual a la del embed predeterminado de YouTube
- Muestra la imagen de póster
- Muestra el título
- Muestra un gran botón de reproducción
- Reproduce el video al hacer clic
- La diferencia está en el uso de recursos y en la forma de compartirlos
- Embed predeterminado de YouTube: alrededor de 1.3 MB
- ``: alrededor de 100 KB
- Posibilidad de compartir recursos entre varios embeds
- Se obtiene velocidad, eficiencia y protección básica de privacidad sin pérdida de funcionalidad
Forma de uso e implementaciones relacionadas
- Consiste en registrar el Web Component con JavaScript y luego usar el elemento ``
- Se puede instalar vía npm, copiar directamente o enlazar desde un CDN
import "https://esm.sh/lite-youtube-embed";;
- El método recomendado en el README consiste en poner primero el HTML y cargar el script de forma asíncrona para aplicar mejora progresiva
- Para que se vea correctamente incluso antes de que cargue JavaScript, se puede incluir
background-image dentro del HTML
[Play Video: Keynote (Google I/O '18)](https://youtube.com/watch?v=ogfYd705cRs)
- También hay implementaciones y alternativas relacionadas
2 comentarios
lite-youtube-embed - una incrustación de YouTube más rápida
Opiniones de Hacker News
En una plataforma comunitaria de foros detectan los embeds de YouTube y los reemplazan por miniaturas proxy que no cargan nada hasta hacer clic
Que alguien comparta un video de YouTube en un hilo no significa que todos los que abran esa página tengan que descargar más de 1 MB de JavaScript y además dejar que Google rastree su IP
No me preocupa demasiado el rastreo, así que sigo usando directamente las miniaturas que ofrece YouTube
El reproductor de SoundCloud también es pesadísimo
Si haces hotlink de las miniaturas, Google también puede rastrear desde ahí
El autor dijo que no cree en la evidencia de que una versión más ligera reduzca la interacción, pero yo sí veo bastante posible que pase
En el demo del proyecto recomendado lite-youtube-embed están tanto el reproductor ligero como el normal, y la versión ligera tarda visiblemente más en empezar a reproducir el video
Cada vez que el tiempo de carga aumenta 1 milisegundo, la interacción baja, y aquí la diferencia parece de varios cientos de milisegundos
https://paulirish.github.io/lite-youtube-embed/
La lógica de que cada milisegundo importa también aplica a la página web. Si el usuario abandona la página, ni siquiera llegará al video
Además, también puede estar bien que el usuario no quiera ver el video. En lo personal, si hay un resumen en la página, me gusta poder evitar el video
También me molesta el rediseño de YouTube para escritorio, porque usa demasiado espacio para promocionar otros videos en vez del que de verdad fui a ver. Ojalá tuviera menos distracciones
En términos de semáforos, prefiero que el que se me acerca esté en verde a que todos estén en rojo por un rato corto
Si ves cómo actúan realmente las grandes empresas, queda claro que no les preocupa eso, y si para ellas no es importante, tampoco hay razón para que nosotros optimicemos en su lugar
En este caso de uso no es un gran problema, pero en el resto del stack sí hay que cuidar el rendimiento
No sé cómo terminamos retrocediendo tanto, y parece que Google cada vez arruina más cosas que antes funcionaban perfectamente
Puede variar según el entorno: Firefox, una laptop i7-1185G7 de hace unos 2 años, Windows 11, Edge en modo de 32 bits actualizándose todo el tiempo y sin reiniciar por varias semanas
Gran parte de la impresión de lentitud viene del indicador giratorio de carga. Es como anunciar por sí mismo que es lento
El retraso entre hacer clic y que empiece la reproducción sí puede influir, pero para medir eso bien haría falta alguien del tamaño de YouTube
Sobre el rumor de que un embed más ligero reduce la interacción y sobre el lite-youtube-embed propuesto, los usuarios pueden percibir incluso pequeñas diferencias visuales o de comportamiento del reproductor como algo desconocido y poco confiable
El lite-youtube-embed del demo, aunque muestra el título, no ofrece un enlace para ir a la página real de YouTube, así que hasta da una sensación hostil, como si te impidiera llegar al “contenido” original
Claro, esa función se puede agregar fácilmente, pero eso deja ver un problema mayor
Casi nunca reproduzco videos embebidos, pero si lo hiciera, me basta con la experiencia normal de YouTube. Si lo envuelven en otra capa desconocida, me dan menos ganas de hacer clic
La frase de este artículo de que “no se sacrifica nada” es un ejemplo de desarrolladores creyendo que saben cómo usan los usuarios el software. En realidad, siempre son suposiciones
Ojalá hubiera menos videos, menos dependencia de Google en todas partes y menos bloques de JavaScript. Para una web mejor, ojalá no se embebieran videos de YouTube en cualquier lado
https://paulirish.github.io/lite-youtube-embed/
Ahora que lo sé, estaría bien que estos reproductores ligeros también tuvieran ese botón. Aun así, esta implementación no bloquea por completo una forma fácil de obtener el enlace
Puedes acceder a ella si reproduces el video, pero eso va contra el propósito. No quiero reproducir el video, ni esperar a que cargue, pausar y luego apretar el botón de guardar
Ahora solo falta impedir que los blogueros usen embeds de GitHub Gist
Hugo y probablemente otros generadores de sitios estáticos ya traen soporte por defecto para fragmentos de código con resaltado de sintaxis, y los sitios más dinámicos también pueden eliminar la dependencia de servicios de terceros usando highlight.js
Usar un iframe pesado para un fragmento de código pequeño es realmente raro
https://gohugo.io/content-management/syntax-highlighting/
https://highlightjs.org
Aunque a mí no me guste, no tiene sentido “forzar” cambios en un sitio para que encaje con mis gustos
Lo arreglaron en unas semanas, pero me sorprendió que hubiera estado así durante años
Si puedes aprovechar Content Security Policy en la página, puedes bloquear anuncios para reducir el peso total del embed y también mejorar la experiencia de usuario
Más información: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...
Content-Security-PolicyPorque eso desactiva la protección de CSP contra ataques de inyección. Si de verdad hace falta, hay formas más seguras de permitir scripts inline
https://content-security-policy.com/
Siento que a la idea de que “los embeds más ligeros redujeron la interacción” le falta una parte importante
En teoría, si el tiempo de carga mejora, la interacción también debería mejorar. Entonces, si con un embed más ligero la interacción bajó, eso significa que se sacrificó alguna función o comportamiento
Pero este artículo dice que no se sacrificó nada, así que falta algo en la historia
Aquí podría estar pasando algo similar. Gracias a embeds más ligeros, mucha gente pudo cargar el video por primera vez, pero como sus dispositivos o conexiones eran lentos, quizá abandonaron al momento de reproducirlo
Entonces personas que antes ni siquiera lograban cargar por completo el reproductor y no dejaban ningún dato, ahora podrían aparecer como un aumento en la tasa de “abandono de reproducción de video”
Los usuarios tienen expectativas y tolerancias distintas respecto a los tiempos de carga según el objetivo, y la página y el video dentro de ella son objetivos distintos
Además, el tiempo de carga total de la página no siempre está atado al tiempo de carga del embed, y la carga completa de la página puede ocultar el tiempo de carga del contenido
Una métrica más importante que el tiempo de carga del embed podría ser la demora entre el clic y la reproducción
Como solución del lado del usuario para quienes usan uBlock, se pueden usar filtros click2load
Eso sí, como Chrome está migrando a Manifest V3, puede que ya no funcionen. Basta con revisar los filtros de yokoffing/filterlists
https://raw.githubusercontent.com/yokoffing/filterlists/main...
Es el creador de Betterfox y también tiene otros filtros útiles en GitHub
Lo que yo quería era simplemente un enlace normal, así que hace tiempo hice un pequeño user script que reemplazaba los iframes de YouTube en páginas por enlaces
Para ser una implementación sencilla, funciona sorprendentemente bien. Busca iframes
youtube.com/embedyyoutube-nocookie.com/embed, los cambia por enlaceswatch?v=, también conserva la marca de tiempo y, si quieres, incluso puede poner una imagen en miniaturaMe parece rara la parte de “a mayor número de embeds, el peso crece linealmente. Dos son 2.4MB, tres son 3.6MB”
Me pregunto por qué esos recursos no se obtienen desde la caché. Si todo se carga desde
www.youtube.com, por la política del mismo origen deberían poder reutilizarse los recursos cacheados, ¿no?La mejor parte del artículo, para mí, fue cuando cuenta que después de cambiar a una página más ligera, el tiempo promedio de carga de la página en realidad subió
Viéndolo más de cerca, resulta que los usuarios con dispositivos de gama baja o internet lento por fin pudieron usar YouTube de verdad, y como empezaron a usarlo mucho, dio la impresión de que el promedio se había vuelto más lento
Lo impactante es que la velocidad de uso real mejoró relativamente para todos, y que la métrica de velocidad promedio de carga de la página terminó siendo un señuelo sin sentido
Hace tiempo hice una extensión de Firefox que convertía todos los embeds de YouTube en miniaturas y, al hacer clic, abría YouTube
Al principio la hice porque en los teléfonos no había Flash, pero los embeds en Flash eran comunes, y después amplié la extensión para manejar también embeds en iframe
En la mayoría de los casos, abrir el sitio web completo de YouTube o la app daba una mejor experiencia de usuario que una ventanita de embed pequeña
En ese momento la escribí para la nueva API de extensiones de alto nivel, pero me frustró que la compatibilidad entre versiones del navegador no se mantuviera tanto como esperaba, así que no la migré a WebExtension. Este artículo me dan ganas de portarla de nuevo