5 ms·

Our site was using hosted libraries, google fonts, and google analytics. All of which seemed to be behind captchas, throwing CORS errors, and 503ing since this

• mholt 9y ago
  Having the same problem here! Glad it wasn't just me...
• ocdtrekkie 9y ago
  Is there a good reason to use these things hosted by a third party source? Libraries are tiny, the fonts can be downloaded from Google Fonts and embedded locally, etc. Even the Google Analytics JS script I presume can be stored and run local. Shouldn't a goal be to mitigate the number of possible failures which can bring down your site by reducing the number of single points of failure?
  • sbov 9y ago
    IIRC Google Fonts aren't easy to download because they vary by user agent.
    • vetinari 9y ago
      You can download zip archive of ttfs using the customize tab on the fonts site. Or go directly to the source, and get the git repo.
  • wil421 9y ago
    One reason is that by linking to external libraries your browser most likely has them cached. At least it was the case a few years ago when I was doing web dev.
    • eric_b 9y ago
      I see this argument a lot but I don't think it's necessarily a good one. If a third party CDN goes down, your site is down. A few extra ms in initial download isn't so bad compared to having your site be completely inaccessible for reasons outside your control.
      • jlgaddis 9y ago
        Then why are these sites down?
      • wil421 9y ago
        Self hosting will probably cause more downtime than if you are using a decent CDN. CDN is just one of many points of failure, I would expect there's a fine balancing act where you could achieve benefits of both.
        • dom0 9y ago
          By definition, if your site is down, you don't need your assets.
          • deleted 9y ago
            [deleted]
      • omni 9y ago
        Why doesn't having the resources cached provide a buffer against short-term outages of the CDN?
        • nleach 9y ago
          The browser still has to make a request to the CDN to get back an HTTP 304. The goal is to avoid downloading a potentially large payload, not be resilient against connectivity issues.
        • hobofan 9y ago
          Because normal Cache-Control is only aimed at reducing the amount of data transferred. With newer immutable Cache-Control[0], a CDN going down wouldn't have an effect if you have the resources cached. [0]: https://hacks.mozilla.org/2017/01/using-immutable-caching-to-speed-up-the-web/ https://hacks.mozilla.org/2017/01/using-immutable-caching-to...
    • Asmod4n 9y ago
      This is most likely never the case, because there are way too many versions of each library.
  • deleted 9y ago
    [deleted]
  • bcherny 9y ago
    2 reasons: 1. If you're still using HTTP 1.x, sharding assets across origins lets the browser load them in parallel (if set up correctly). You can generally load just 6 assets in parallel per origin, and sharding is a way to get around that limit. 2. A library like jQuery is so popular, and is so often served from googles CDN, that chances are a user already has it in their local cache from when they downloaded it on some other site. That said, yes - the downside is more surface area that might go down.
    • dchest 9y ago
      2. A library like jQuery is so popular, and is so often served from googles CDN, that chances are a user already has it in their local cache from when they downloaded it on some other site. Which of these versions do you have cached? 3.2.1, 3.2.0, 3.1.1, 3.1.0, 3.0.0, 2.2.4, 2.2.3, 2.2.2, 2.2.1, 2.2.0, 2.1.4, 2.1.3, 2.1.1, 2.1.0, 2.0.3, 2.0.2, 2.0.1, 2.0.0, 1.12.4, 1.12.3, 1.12.2, 1.12.1, 1.12.0, 1.11.3, 1.11.2, 1.11.1, 1.11.0, 1.10.2, 1.10.1, 1.10.0, 1.9.1, 1.9.0, 1.8.3, 1.8.2, 1.8.1, 1.8.0, 1.7.2, 1.7.1, 1.7.0, 1.6.4, 1.6.3, 1.6.2, 1.6.1, 1.6.0, 1.5.2, 1.5.1, 1.5.0, 1.4.4, 1.4.3, 1.4.2, 1.4.1, 1.4.0, 1.3.2, 1.3.1, 1.3.0, 1.2.6, 1.2.3
      • castis 9y ago
        Asking an annoyed rhetorical question doesn't seem productive to the point you're trying to make here. As an actual answer, it would be variable proportional to the size of the window between releases mentioned here: https://en.wikipedia.org/wiki/JQuery#Release_history https://en.wikipedia.org/wiki/JQuery#Release_history I'm sure a fair amount of people serve jQuery from a local storage. The usefulness that the user might already have it cached is a non-zero point, no matter how insignificant you may think it is.
      • kerkeslager 9y ago
        How many do you need to make this worthwhile? The ratio of cost of storing a library versus the cost of GETing a library is very low, so the chances of already having a library cached can be very low for the EV to be worthwhile. Weighing that against the chance of downtime is a bit more complicated, admittedly.
  • jjlane 9y ago
    Our GA is setup through GTM now, that is why it's not hardcoded into our head. Really the most important gain we get from hosted libraries is caching. Since any user that has hit a google hosted lib, which is pretty widely used and distributed it allows them to access their cached version instead of sending our another request.
  • tregoning 9y ago
    Yes, Google can change the logic for auth, analytics, etc at any time and your local outdated copy will be useless, further I believe it's possible that Google returns different JS depending on the browser that's requesting it in order to keep payloads down and performance high.
• kyrra 9y ago
  For something like jquery, you can host locally and fallback to it if the CDN fails. https://stackoverflow.com/a/1014251 https://stackoverflow.com/a/1014251
  • jjlane 9y ago
    damn, never thought to do this. thanks for the heads up.
  • lamlam 9y ago
    Loading JavaScript libraries synchronously should be avoided if possible, making the above solution not a great one.
    • kyrra 9y ago
      Is there a better/different way to handle this type of fallback?
      • giancarlostoro 9y ago
        Surprised Content-MD5 or a similar spec isn't used by the browser to avoid a web where only Google's hosted solution allows for efficient JS file caching. If you know two files are most likely equal by filename and checksum, you should be able to just reload the cached version, if loading the cached file produces too many errors, try downloading the new one or something, instead of forcing everyone to host it all under the same corp (in this case Google). Oh well.
      • lamlam 9y ago
        Yes. What you should do is use an asynchronous module loader. There are many small standalone ones like loadjs [1]. But the more widely used tools such as webpack also suppprt this as code splitting [2]. In general you want to avoid sync loads of js assets because depending on how the server serving the asset hangs it can cause the webpage to hang as well. For example, if the server responds with a 404 right away then there are no problems. But if the server does not respond and leaves the connection open the browser will just wait the max time. [1] https://github.com/muicss/loadjs/blob/master/README.md https://github.com/muicss/loadjs/blob/master/README.md [2] https://webpack.js.org/guides/code-splitting/ https://webpack.js.org/guides/code-splitting/