|
|
|
|
|
by llarsson
2066 days ago
|
|
So the natural progression here is that only big sites with their own CDN solution will be fast? And for most people and companies that will mean "rely on a large service to actual host your content for you", because they are not operating their own CDN. Because speed matters when it comes to search ranking. So they are then beholden to major platforms such as Google to host sites for them from a global cache? Similar to what AMP does, but for all kinds of content? Hmm. |
|
No, not at all. This change gets rid of global caches.
A) Your site caches will still work, they just won't be shared across sites. A cold-cache load of Gmail will go through the exact same process as the cold-cache load of your site, and subsequent loads of both sites will be just as fast.
B) If your site's initial load time on a cold cache is unacceptable, you are already making an engineering mistake and you need to cut back on the Javascript.
C) Most large sites are already choosing to bundle their own libraries or serve them from dedicated CDNs instead of trying to coordinate with each other to make sure the same resource location is used across multiple websites.
D) Even in a theoretical world these changes were going to make the web a lot slower (and reminder, that world doesn't exist), the risk of library domination in that world would be larger than the risk of website domination. Imagine a world where you write a competitor to JQuery that's just as good, maybe even smaller and more efficient, but nobody uses it because "we have to use the popular library that's likely to be already in the user's cache."
While we're on the subject of D, the fact that nobody says that -- that we don't see smaller JS libraries thrown aside in favor of libraries/versions that are more likely to be already cached -- is strong evidence that your site sharing a JQuery cache with someone like Google or the NYT is not an important performance concern.