Bien, aquí está nuestro problema. Los encantadores usuarios de Wistia pueden poner tantos videos como quieran en una página. A menudo, estos videos están ocultos en pestañas o se abren en ventanas emergentes, pero todos existen en la página cuando se carga. Por un lado, queremos que los videos se reproduzcan lo más rápido posible, lo que significa usar algún tipo de precarga antes de reproducirlos. Por otro lado, queremos minimizar el uso innecesario de ancho de banda para nuestros clientes. Por encima de todo, los videos deberían funcionar.
Para resumir, queremos usar preload=”metadata” en nuestros videos HTML5 donde tenga sentido. Pero Google Chrome tiene una variedad de reglas mal documentadas que complican esto:
- Si tiene dos o más elementos
Ambos casos se manifiestan como un mensaje persistente de “Cargando…” que nunca desaparece. Eso es extremadamente frustrante para los visitantes que intentan ver su video.
El problema de “primero en jugar gana” no es un gran problema. Normalmente, no desea que el mismo video aparezca varias veces en su página y se reproduzca al mismo tiempo. Exige un poco de limpieza para evitar dejar huérfana una transmisión y, por lo tanto, bloquear una nueva con el mismo src, pero hacerlo es bastante sencillo. Para nosotros, significa encontrar videos de Wistia que no están realmente en el DOM, establecer el src del video en una cadena en blanco, llamar a load() y finalmente destruir el elemento. Dado que hacemos un seguimiento de las incrustaciones de Wistia en la página, esa es una solución manejable.
El problema menos sencillo es el n. ° 2, donde intentamos precargar un montón de videos simultáneamente. Nuestras opciones aquí son:
- Intente precargar todo y, si el almacenamiento en búfer se bloquea en uno, cierre esa transmisión. Haga que nuestros videos estén al tanto de otros videos en la página para que puedan coordinarse y mantenerse por debajo del límite de concurrencia.
Con la primera opción, si funciona, está muy bien. Pero en mis pruebas, fue muy difícil liberar flujos una vez que se cargaron previamente. Además, tiene un problema con el espacio libre. Es decir, sí, se precargarán todos los vídeos que puedan precargarse. Sin embargo, si intenta reproducir transmisiones nuevas, ya estamos al máximo de simultaneidad, por lo que volverán a encontrar el problema original y se cargarán para siempre. Un problema más: ignora la posibilidad de cualquier transmisión de audio/video que no sea de Wistia en la página, lo cual es presuntuoso en el mejor de los casos.
Pensando en la segunda opción, en realidad es un poco trivial de implementar si está configurando todos sus elementos
Pero nuestro problema en Wistia, y con muchos otros hosts de video, es que nuestro tipo de inserción más común es un iframe, lo que nos impide consultar fácilmente el DOM para otros videos. Para aquellos de ustedes que no están familiarizados con los iframes, son como pequeños documentos aislados en su página. No pueden saber fácilmente qué hay en la página principal o qué hay en otros marcos de esa página.
Podría decir, hey, agregue algo de JavaScript a la página principal para que pueda hacer el trabajo pesado y establezca una opción de precarga a través del src de cada iframe. Y eso también funcionaría. Pero uno de los propósitos principales de las incrustaciones de iframe es evitar la necesidad de JavaScript en la página principal. ¿Asi que que hacemos?
Si queremos jugar con reglas de origen cruzado y evitar todo tipo de advertencias desagradables en la consola (lo hacemos), solo tenemos una herramienta a nuestra disposición: postMessage. Si podemos usar postMessage para que todos los iframes de Wistia en la página conozcan todos los demás marcos de Wistia, entonces podemos configurar de manera inteligente el atributo de precarga.
Esto es lo que hicimos. Cuando se carga un iframe…
- Se anuncia a sí mismo generando un guid y usando postMessage para enviarlo a todos los demás iframes en la página principal. Le dice a cada iframe ya existente que se anuncie en el nuevo iframe. Los iframes existentes se envían al nuevo iframe con su guid en un mensaje como wistia-iframe-myguid.
Siempre que cada iframe esté escuchando ese evento, puede mantener una lista de los iframes de los que ha tenido noticias. Usando esa lista, puede determinar si debe precargarse o no. Por ejemplo, nuestra lógica dice que no precargue si hay más de dos iframes detectados en la página. Aquí hay una condición de carrera: debido a que los iframes se cargan de forma asincrónica, es posible que existan dos, no se vean a tiempo y ambos activen la precarga. Un tercero aparece un poco más tarde, ve a los otros dos y no se precarga. Consideramos que este comportamiento es aceptable, incluso deseable, ya que nos gustaría que los videos que se cargan más cerca de la parte superior del DOM sean los que precargan.
Una desventaja obvia de este enfoque es que siempre enviamos N^2 (es decir, N al cuadrado) mensajes, donde N es el número de iframes en la página. Afortunadamente, la gente no suele poner cientos de iframes en sus páginas. Pero para esos casos extremos, simplemente podemos limitar la cantidad de iframes que miramos y, si detectamos muchos, no precargarlos. ¡Más vale prevenir que lamentar! Creo que hay formas de sortear este problema de N^2, pero lo dejaré como ejercicio para el futuro.
TLDR: Cuando todo lo que tienes es un martillo, convierte todo en un clavo. postMessage es el martillo de iframes.
