gratis google georreferenciación example ejemplos javascript jquery dependencies

javascript - georreferenciación - ¿Debería enlazar con la nube de la API de Google para las bibliotecas JS?



google maps javascript api key (9)

Estafa

  • Los usuarios en países embargados por los EE. UU. (P. Ej., Irán) no recibirán una respuesta de Google

Estoy buscando los pros / contras de sacar jQuery y otras bibliotecas JS de la nube de la API de Google en lugar de descargar archivos e implementarlos directamente.

¿Lo que usted dice?

Mi decisión

La probabilidad de que la lib ya esté almacenada en caché en el sistema de los usuarios es el factor primordial para mí, así que voy con un enlace permanente a googleapis.com (por ejemplo, ajax.googleapis.com/ajax/libs/...). Estoy de acuerdo con otros aquí en que la pérdida de acceso a la nube del servidor de Google es una preocupación mínima.


Además de los puntos hechos por otros, señalaré dos contras adicionales:

  • Una solicitud HTTP externa adicional, por lo que, suponiendo que tenga un archivo Javascript propio (casi seguro), eso es dos mínimos en lugar de un mínimo; y
  • En mi humilde opinión porque la carga de jQuery es asíncrona, toda la página puede cargarse antes de que la biblioteca se haya cargado, por lo que los efectos que usted hace en documentos listos a veces se notan visiblemente al usuario cuando se aplican. Creo que esta no es una gran experiencia de usuario.

Creo que lo mejor sería ejecutar pruebas A / B y ver cuál es la latencia para cargar la versión reducida de jquery de los servidores de Google en comparación con su servidor. Con suerte eso pondrá las cosas en perspectiva. Lo más probable es que el servidor de Google sea más rápido, pero en términos de aceptar la responsabilidad del tiempo de inactividad, no hay nada como hospedarlo usted mismo.


He estado observando el rendimiento real del cargador de Google para jQuery, particularmente, y esto es lo que he encontrado:

  1. Los servidores de Google son rápidos y bastante confiables.
  2. Están sirviendo desde un CDN, lo que significa que si tienes muchos usuarios en el extranjero obtendrán tiempos de carga mucho mejores.
  3. No están sirviendo archivos comprimidos. Así que están sirviendo muchos más bytes de los que necesitan.

Si sabes lo que estás haciendo en Apache, Lighttpd o cualquier otro archivo con el que estés publicando, puedes configurar los encabezados de tu caché igual que Google y reducir significativamente la cantidad de datos que tu usuario final tiene que descargar sirviéndolo desde tu propia cuenta servidor. También puede combinar sus scripts en ese punto y reducir sus solicitudes HTTP generales.

En pocas palabras: el rendimiento de Google es bueno, pero no excelente. Si tiene muchos usuarios en el extranjero, entonces Google probablemente sea mejor, si sus usuarios se basan principalmente en los EE. UU. Y su máximo rendimiento es su preocupación, conozca el almacenamiento en caché, Etags, gzipping, etc. y preséntelo usted mismo.


Pros:

  • La conectividad de Google es probablemente mucho mejor que la tuya
  • Es un CDN gratuito (red de distribución de contenido)
  • Su aplicación web puede cargar más rápido, ya que está utilizando un CDN

Contras:

  • Si / cuando necesita optimizar reempacando un subconjunto de esa biblioteca JS de terceros, está solo, y su aplicación web podría cargar más lento

Pros: Es posible que ya esté almacenado en caché en el sistema del usuario. Google tiene grandes tuberías. Usted no paga por el ancho de banda.

Contras: ahora tiene dos formas diferentes de que su sitio deje de estar disponible: una interrupción del servicio en su servidor o una en el servidor de Google.


Pro:

Los Ajaxlibs de Google ofrecen un "control de versión" muy detallado para las bibliotecas incluidas. Puede aplicar una determinada versión (p. Ej., JQuery 1.3.2) o solicitar automáticamente la última versión de una determinada rama (por ejemplo, JQuery 1.3 series -> entregaría actualmente 1.3.2, pero quizás pronto 1.3.3).

Lo último definitivamente tiene beneficios: obtendrá beneficios de correcciones de errores más pequeñas / mejoras de rendimiento sin romper sus scripts / complementos.

El mantenimiento de un repositorio de bibliotecas múltiples por su cuenta puede convertirse en un recurso intensivo.


Los pros son bastante obvios y están en las otras respuestas:

  • ahorras ancho de banda
  • Google es probablemente más confiable que tu servidor
  • probablemente guardado en la memoria caché en la mayoría de los navegadores (¿Alguien tiene estadísticas sobre esto?)

Pero las desventajas pueden ser muy difíciles:

  • Si usa https, obtendrá un error en la mayoría de los navegadores ya que su certificado no es válido para el dominio de Google, solo el suyo. Este es un problema importante para https.

Estafa:

  • Cuando tiene miedo al envenenamiento de DNS, o cuando teme que alguna red inalámbrica pública no sea confiable, las versiones que no son SSL en realidad podrían no ser servidas por Google en absoluto, abriendo la instalación de software malicioso. (Pero: el almacenamiento en caché se establece en un año completo , por lo que aunque muchos navegadores emitirán una solicitud If-Modified-Since para contenido almacenado en caché al actualizar, esto podría ser un problema teórico ya que la mayoría de los usuarios ya habrán guardado en caché los recursos mientras usando otra red)

  • Al tener extremo cuidado de la privacidad de sus visitantes, es posible que no desee que Google registre visitas a su sitio mediante el uso de su CDN. (Bastante teórico también, ya que se aplica la misma nota sobre el almacenamiento en caché).