Por qué los botones Me gusta de Facebook representan el 16% del código promedio de un sitio web

Según los datos recopilados por BuiltWith.com, el 6% de los 10 000 sitios con mayor tráfico cargan contenido de los servidores de Facebook. Para la gran mayoría de ellos, es probable que ese contenido sea el SDK de Javascript de Facebook, un gran bloque de código que se necesita para mostrar funciones como el botón Me gusta (como se ve en muchos sitios de medios) y los widgets de comentarios de Facebook (que también se utilizan en muchos medios importantes). sitios, Buzzfeed entre ellos).

Este código SDK es tan grande que representa aproximadamente el 16% del tamaño total de todo JavaScript en una página web promedio.

Como biblioteca de software de gran tamaño y ampliamente utilizada, el SDK de Facebook es una buena forma de ilustrar algunas de las respuestas a las preguntas: ¿por qué el sitio promedio hoy en día es tan grande? ¿Y cuánto importa realmente el tamaño?

¿Por qué tan grande?

El SDK de Facebook tiene muchas funciones, duplicando muchas de las herramientas que el sitio promedio probablemente ya incluye para el uso de sus propios desarrolladores: métodos para recuperar datos de otros sitios, para determinar qué navegador y dispositivo está usando el usuario para poder apuntar a funciones específicas para ellos y para mostrar elementos de la interfaz de usuario (como cuadros de diálogo y botones de confirmación). Si clasificamos todas las partes del SDK, el desglose se ve así:

De los conjuntos de características, tres se destacan más:

"Canvas" es el sistema de Facebook para aplicaciones que están destinadas a cargarse en Facebook (Facebook hizo un gran esfuerzo en el pasado para alentar a los desarrolladores a crear aplicaciones que vivieran dentro de Facebook; no estoy del todo seguro de cuán ampliamente se usan estas aplicaciones en la actualidad, pero de cualquier manera, un sitio web normal no usa ninguna de las funciones relacionadas con Canvas. El costo de incluirlas en el SDK es bastante marginal: solo el 1.5% del tamaño total.

Después de eso, tenemos compatibilidad con funciones heredadas. Esto refleja el hecho de que una API acumulará múltiples interfaces para manejar las mismas funciones a lo largo del tiempo. Por ejemplo, los desarrolladores pueden escribir código que llame a FB.getLoginStatus () (el enfoque heredado para solicitar el estado de inicio de sesión actual de Facebook del usuario) o Auth.getLoginStatus ()(el nuevo enfoque alentado). La forma de evitar la necesidad de incluir ambos conjuntos de métodos es publicarlos en versiones separadas del SDK, pero Facebook optó por no hacerlo, lo que probablemente simplificará la experiencia para los desarrolladores y maximizará la cantidad de sitios que usan exactamente el mismo archivo ( para aumentar la probabilidad de que el usuario medio ya lo haya descargado). Esta decisión tiene un pequeño costo: aproximadamente el 3,5% del código del SDK es para manejar funciones que están marcadas explícitamente como "heredadas" (y es muy posible que haya muchas más funciones "heredadas" que simplemente no están marcadas explícitamente como tales ).

Más significativamente, el SDK incluye una serie de polyfills y utilidades similares a polyfill, que constituyen más del 15% de su código. Los Polyfills se utilizan para proporcionar funciones que se encuentran en los navegadores más nuevos a los navegadores más antiguos y, a veces, también para proporcionar funciones más nuevas que están por venir pero que aún no se han agregado a ningún navegador. La mayoría de los polyfills incluidos en el SDK de Facebook son para funciones que ya están incluidas en los navegadores utilizados por la gran mayoría de los usuarios de Internet. Solo sirven para que el SDK funcione para el <1% de los usuarios de Internet en todo el mundo que utilizan navegadores antiguos como Internet Explorer 8, que muchos (si no la gran mayoría) de los principales sitios han dejado de admitir.

Del ~ 80% restante del SDK, es un poco más difícil desenredar qué funciones se necesitan para qué propósito. Esto se debe a que está escrito de tal manera que, para usar una función simple como el botón Me gusta, también se debe incluir código que se use solo para comentarios, incrustaciones de video, botones de inicio de sesión y otras funciones no relacionadas. Facebook podría haber optado por distribuir archivos mucho más pequeños para incluir solo funciones individuales como los botones Me gusta, pero tiene el objetivo comercial de alentar a los sitios a utilizar tantas funciones proporcionadas por FB como sea posible.

¿Importa el tamaño?

Debido al uso generalizado del SDK de Facebook y al hecho de que cambia con relativa poca frecuencia, es probable que muchos usuarios ya lo hayan descargado antes de cargar un sitio. De hecho, esta es una gran parte de la razón por la que Facebook distribuiría un archivo tan grande, en lugar de archivos más pequeños para funciones específicas como los botones Me gusta. Y en las conexiones de red de la mayoría de los usuarios, al menos en los países desarrollados, el tiempo que lleva descargar el archivo es mínimo.

Pero independientemente de si el navegador del usuario ya tiene el SDK descargado, todavía hay una sobrecarga involucrada en ejecutar un gran bloque de Javascript, especialmente en dispositivos móviles. En el relativamente nuevo MacBook Pro en el que estoy escribiendo esto, el SDK de Facebook tarda alrededor de 50 ms (1/20 de segundo) en ejecutarse en un sitio como Buzzfeed. No está mal, especialmente cuando se toma en contexto con el resto del código JS, incluido el código relacionado con anuncios que tarda mucho más en ejecutarse, pero sigue siendo un costo no trivial para algo que solo se usa para mostrar comentarios en la parte inferior del página.

En un teléfono inteligente muy nuevo (Google Pixel), el tiempo de ejecución de JS se duplica, ahora ocupando una décima de segundo:

Cuando se mira en contexto, esta es una pequeña fracción del tiempo total de ejecución del código en la página. Pero aumenta la cantidad de tiempo durante el cual desplazarse o interactuar con la página puede ser una experiencia entrecortada y desagradable. Y esto llega a un punto importante: este SDK en particular tiene un costo marginal, pero los sitios web modernos, especialmente los sitios de medios, a menudo incluyen código similar de una gran cantidad de terceros (este ejemplo lo capturé de Gawker antes de que fuera asesinado por un vampiro multimillonario muestra cuántas solicitudes de este tipo puede haber).

Incluso dejando de lado el impacto en la privacidad de enviar cierta información del usuario a cada uno de estos terceros, el costo de todas estas funciones aumenta rápidamente. Cada script de terceros que agrega un sitio tiene un costo, tanto en términos de rendimiento como para ayudar a racionalizar la adición del siguiente fragmento de código de terceros "relativamente inofensivo" más adelante. Además del impacto inmediato en el rendimiento del costo aditivo de todo este código, esto afecta la moral del desarrollador: imagine trabajar durante días para reducir el 10% del tiempo de carga de su propio código, solo para ver un bloque gigante de código de terceros agregado que empequeñece el impacto de ese minucioso esfuerzo. Y luego (si trabaja para un sitio de medios), ver este mismo patrón repetirse una y otra vez cada pocos meses.

¿Deberías incluirlo?

Si necesita usar una función como Comentarios de Facebook, no hay necesidad de cargar el SDK de Facebook. Pero dependiendo de cómo esté estructurado su sitio, es posible que pueda limitar el impacto en el rendimiento del SDK cargándolo solo cuando sea necesario (por ejemplo, una vez que el usuario se haya desplazado hasta el punto en el que los comentarios deberían ser visibles).

Si desea utilizar el botón Me gusta, deténgase y reconsidere. Facebook ya no muestra los Me gusta de una página de manera prominente (o, en la mayoría de los casos, en absoluto) en los cronogramas de los usuarios. Es mejor usar un simple botón o enlace personalizado para compartir y, como beneficio adicional, evitará que Facebook rastree todas las visitas a su página e interfiera con la privacidad de sus usuarios. Los sitios que han eliminado el botón Me gusta no han podido identificar ningún impacto negativo de hacerlo cuando se trata de referencias de tráfico de Facebook.

CORRECCIÓN al título: Originalmente titulé esto “Por qué el 16% del código en un sitio promedio pertenece a Facebook y qué significa eso”. Como algunos señalaron acertadamente, esto implica que un 16% del Javascript en todos los sitios en Internet (o al menos en todos los sitios principales), consiste en el SDK de Javascript de Facebook. Esta no era mi intención y puedo ver cómo me pareció demasiado sensacionalista.

Con suerte, el nuevo título deja más claro que el SDK de Facebook mide el 16% del tamaño del Javascript promedio de un sitio, y ya no implica que representa el 16% del Javascript total del sitio en Internet. Como señala David Gilbertson aquí, la cifra global real sería mucho menor: 0,96%. También plantea un buen punto con respecto al almacenamiento en caché: el SDK de Javascript de Facebook no se almacena en caché de manera óptima, solo se almacena en caché de la manera más ideal durante 20 minutos, después de lo cual el navegador del usuario vuelve a consultar con los servidores de Facebook para verificar que ya tiene la última versión.