Like many other foot-guns, this is still great for novices to get started and learn the ropes without dealing with a lot of production-level problems. In an ideal world, everyone would learn best practices from the start and never create a bug in their code.
But that isn't how humans work, and there needs to be some grease easing the process at the start. So they still serve a function, even if it's not the one that the CDNs imagined at the start.
No need to gatekeep. We can show a bit more empathy to the teens (or older folks) that are trying this for the first time in their life. Compartmentalization of concerns is an important part of pedagogy.
How would anyone learn? I agree when it comes to anything with stakes or deployments to production, but everyone starts somewhere and copy pasting a url from a CDN is one less headache when you’re playing with something totally new.
And that is how we ended with the mess in this article. We are not doing kinder garden here, it is software development. And if one can't grasp idea of files on server (a very basic) then why are you even doing software development? The whole software development process has being watered down to included people who don't really want to do software development. I'm sure if one is passionate about it, they will figure this out.
To my absolute shame, about 15 years ago, I made this comment about a junior dev on my team. That junior dev is now a much better developer than me.
We’re all on a journey in our careers. Those of us with more knowledge and experience can and should help those with less, instead of gatekeeping and lecturing.
Senior SWE here :) I did not know how to install a package ~10 years ago and doing anything with a server was terrifying. Sure glad I never had someone say this to me.
It'd probably be quicker for you to teach them once or twice than for them to change their entire career. People need to learn things before they can do them, it is what it is.
I'd much rather work with someone that just needed to learn a few things I take for granted than someone who decides it's their right to say who's in or out of IT haha. Teach or get out of the way.
I have specific, distinct memories of some things I did when I was starting out as a developer that are so obviously wrong today. But that's because I've got 15-20 years of experience now that I didn't have back then.
Overly sensationalized title, like the author points out as well in the article. Your site will be fast and your users will be safe as long as you use SRI with any content you're adding from a public CDN.
Huh? The advice is clearly written as: if it's beneficial compile your JS and if not host the libraries yourself (especially if you're using a CDN for your own website anyways).
I have never been sure that public CDNs were a win, even back in the day.
The issue is this: many sites would download files from 10+ different domains and a single ‘long-tail’ DNS query, increasingly likely if you have more domains, will cause more delay than you could possibly save by using multiple servers.
There was common knowledge that cdns were great because they would have predownloaded copies on the users cache from other sites. But one group tested it and found that it’s so infrequent that the user has the exact version of jquery from the same cdn that you may as well ignore the chance.
For more than a few years it's been guaranteed that it won't be cached, because caches are now partitioned per-website. The CDN offers no caching advantage at all
And by “more than a few years” you mean “nine years”, in the case of Safari (which is usually somewhere between a third and a half of web traffic depending on your userbase).
In a lot of cases, removing the JS would make the site more functional. Imagine how much nicer online shopping would be if you had mostly-static HTML pages.
Functional for whom? Most websites exist to make money for the people who make them, including news sites. All that crap serves the publisher's functional goals.
Maybe not all but quite a few of them are. On news sites for instance almost everything that gets loaded besides the text of the news item and one or two images are bloat.
An often overlooked issue is TCP congestion window scaling; For HTTP/1.1 it can be beneficial to serve all resources from a single host as you will likely have "hot" (=larger scaled congestion window) tcp connections to that host. In contrast, if you serve resources from 3-4 different hosts, the TCP congestion windows needs to scale up for each inididual host, which takes a couple of round trips before maximum throughput is achieved. However, there is no silver bullet here, whether or not this is faster or slower depends on a myriad of connection/link parameters.
This is actually a pro-CDN argument, as most CDNs use anycast IPs and long-lived DNS entries, so it is more likely that a user will have that DNS entry cached plus the tcp path might be considered already "hot". But again, the myriad of different parameters do not allow for generalized "its always better to do X" statements.
You are absolutely right. But if you i.e. load foo.com/ which is just 10kb of HTML, you have a very good chance that your TCP congestion window is not yet scaled to match your actual path bandwidth, so transferring foo.com/static.js might take longer than from a CDN or a "hot" tcp connection. On the other hand, if you load too many ressources from either foo.com or mycdn.com, you might hit the TCP multiplexing limits (6 TCP connections in browsers) and stall loading. Equally distributing resources across foo.com and mycdn.com will give you 2x6 TCP connections, so a stall is less likely. It really depends on a ton of factors, your network link, the amount of resources and their size, OS parameters etc. So there is no general rule of thumb here.
I was just talking about DNS not this other stuff.
But now that you bring it up, isn't the 6 resources per domain outdated? At least for HTTP2? When I've done performance testing on my site lately it definitely seemed to load more than 6 resources in parallel from one domain but I haven't looked into this topic in a long time (back when it definitely was limited)
Yes, I was explicitly referring to HTTP1/1. With HTTP2, connection multiplexing is baked into the HTTP/2 protocol. But again, whether or not this speeds things is hard to tell without knowing all relevant parameters. There is a reason HTTP/3 uses QUIC over UDP, the main motivation was to put the userspace (i.e. browser) more in control over congestion control and such things (while TCP is always kernel-implementation dependent). And I think we will see lot of different implementations and innovations in this field (just as there is a ton of different TCP congestion window scaling algorithms).
I was refering to a sane default of 6 TCP sockets that some browsers use per host when using HTTP/1.1. I don't think this is standardized, so its just an implementation detail and might vary across browsers and plattforms. Maybe you can even increase this in your browser settings. From a quick glance at the HTTP/2 spec, it seems the actual number of multiplexed steams is configurable per session: https://httpwg.org/specs/rfc7540.html#SettingValues (SETTINGS_MAX_CONCURRENT_STREAMS). Of course, OSes have limits how much outgoing TCP connections you can have (per user, per process, system wide) but I think will be much higher than 1000.
Edit: Firefox by default uses no more than 900 parallel HTTP connections (check your about:config page), and I assume this holds true for all windows/tabs combined - which is plenty.
Not sure how it is now, but back in the days it was a feature to have different hosts, as browsers would only ever open X connections per host. So if you spread your assets over a.example.com, b.example.com etc. it could load faster than if everything came from the same place.
Most websites and web apps spend so much time on server side CPU per page load that offloading a few static requests makes next to no difference. The CDN thing is way down the list of changes you can make to improve performance in most cases.
We are talking about the end user experience in terms of time taken to display the page, of which the largest part for a dynamic page is usually cpu time on the server not minute optimisations of static objects. It's not the lowest hanging fruit.
This just isn't true at all. The amount of time it takes to download, parse, and execute modern JavaScript payloads is usually longer than a page's TTFB. Then there is also the parsing of HTML and CSS and actually painting the page. For "most websites" if cached appropriately then server CPU time is minimal in most cases
>Meanwhile, if your caching reverse-proxy goes down, you have the option to immediately put a different caching service in front of your site, or temporarily serve static content from your servers directly, and get things working again with no code changes or backend deployments required
I think I'd prefer deploying a new CDN link to updating DNS. "No code changes or backend deployments" makes the assumption that DNS is a manual change (not terraform, etc.)
Two of the things that this article calls out are security & privacy. It's worth keeping in mind that you can and should be using SRI when loading remote resources like this, which will go a long way to protect you. And, you can set attributes like referrerpolicy to ensure that privacy is maintained as much as possible.
(cdnjs, that I maintain and is referenced in the article, does both of these by default if you copy a script/link tag from our site.)
(ps, I dislike the name; you don’t encounter the term “subresource” anywhere else in webdev. It’s a “subresource” of the HTML document resource, eyeroll)
Depends what you mean by that precisely. But you can load things from cloudflare's ipfs gateway without doing anything special otherwise. Directly from ipfs - not without extensions.
You could include js-ipfs[0] and fetch all your resources from IPFS without going through a gateway. However, this approach would make the site fully dependent on JavaScript.
A PWA with a Service Worker could perhaps implement its own client-side "gateway", translating public gateway URLs into direct IPFS access. Without the Service Worker (or without JS) it would fall back to using the gateway.
Does an HTTP gateway actually allow you to make peer-to-peer IPFS connections, or does the actual content end up being routed through the gateway? And if so, wouldn't that be equivalent to a traditional CDN from the perspective of a client?
It sounds like we'd need to have browsers implement IPFS protocol support directly for this to be a feasible alternative to centralized CDNs.
With SRI you can't store unique identifiers in the cache since the cached content has to match the hash in the URI. The only real privacy leak would be potentially determining whether certain data was already cached.
While you're correct, it's too little too late. You should assume that everyone effectively don't have a web cache. It's like the effect of Spectre and Meltdown: JS timers are no longer accurate to compensate for them.
The article brought up some good points. If SRI fails, it simply won't load and thus break your site, which isn't a great outcome. And in organizations, the likely hotfix will be to remove SRI. Not to mention you have to keep track of the hash, which could cause breakage when a newer version is used and the devs don't keep that in mind.
To not run code that somebody else may have changed is the whole point. And it does not fail if you test it first. We are talking about billions of requests every day that is served by external CDN providers.
It always annoys me when a site hangs when it tries to load something from fonts.googleapis.com. Developers need to use a system font stack which loads fonts from the system itself instead of remote web fonts. On a fast connection you don’t notice it, but you will notice it on a slow connection, and the majority are on slow connections. Developers need to deliberately use slow connections and see just how responsive their site is. Don’t develop on a hyper fast connection because you assume the site loads super quick and overlook latency issues. I think you can emulate slow connections in browser devtools so there is that.
That's plain wrong. Sure, if you used Monotype's there will be issues (because they're so litigious), but Google Fonts only hosts open-source fonts so there's no reason to just search the correct font and host that instead (unless you somehow manually tweaked the URL to get Product Sans: that's illegal even if you loaded it from Google's CDNs).
It's custom fonts that don't share metrics with built in fonts. If they don't do that the page content jumps around when the fonts load. Custom fonts were a terrible idea, I wish browsers would just drop support for them.
EDIT: Unless there's a way to include metrics outside the font there really isn't a way to prevent reflows when it loads other than blanking the entire page until then.
There is no way that a browser could figure out what the "closest available" system font is, or that one even exists. It's up to the designer to specify the font(s) to be used.
If sites don’t specify image dimensions, the page content jumps around when the images load. Images were a terrible idea, I wish browsers would just drop support for them.
(There are many ways to avoid reflows with font loading, eg font-display: optional)
s/page/font, which is what `font-display: optional` does, sort of. There's a 100ms blank grace period, and if the font's not ready by then it uses the fallback font. (It'll still load, and be ready in cache for the next page visit)
Sorry, no part of your comment is true. This is easily the best option for slow connection/device users, and it comes at the expense of the design.
> The page takes an extra 100ms to load
Nope. Slow connections' floor for first paint is 100ms when using `font-display: optional` – not an additional 100ms. The page is still loading like normal in this period. (If you're already under a 100ms FCP for 3G users, you know all of this already)
> the content will jump by some large amount
`font-display: optional` is literally designed to prevent this from ever occurring. Either the font is ready for first paint in 100ms, or another font is used.
I love the progress bar at the top of that page. It is a better gauge of the required time commitment than the "7 minute read" or by glancing at the scrollbar block size, IMO.
Which browsing contexts still feature the affordance of scrollbar blocksize? I thought UX as a profession had chosen to totally commit to the sin of removing it.
It is a good idea but not an original one: what it's really doing is reinventing the vertical scrollbar, but placing it horizontally, with a bunch of the functionality missing.
Isn't it a shame that OS people have started making scroll bars so hard to see that someone is having to implement a less functional equivalent on-page.
It's not even clear if using Google Fonts is GDPR compliant (since you're leaking the fact that your visitor has visited your website): https://github.com/google/fonts/issues/1495
Even if you do want to use your own hand-picked font on your site, just self host it, or bundle it with something like https://fontsource.org/
Surely you are not processing data in this case though? The client (software) determines whether to make a connection to fonts.google.com. Your website never passed the information to google.
No, that's not how it works. If the website (via js or tags) requests that something is called, than your software calls it and you're responsible. The client only runs your software, in this case, HTML & co.
Though it arguably doesn't get enforced anyways, except for some big corps.
That may be technically correct, but doesn't count in front of a judge. They generally don't care for implementation details but they care for the results. And the result is that you made your visitor talk to google.
Reading the relevant court decision actually showed enough technical understanding by the judge to make a balanced decision.
The reasoning was that as it is so very easy to self host Google fonts and with caching as an argument gone there is actually not enough reason anymore to use the hosted version by Google and transmit PD to Google.
Would the site have used a foundry that didn't offer self hosting the reasoning might have turned out differently if the site owner could have made a strong argument for using this specific font by this foundry.
Judges do not tend to be impressed by technicalities. You're causing the information to be passed to google; the means by which that happens are largely irrelevant.
And also, if the technical line of argument were found meaningful, it could also be used for absurdities: "no, your honor, my website didn't display copyrighted images without a license – it merely gave the visitors' browsers some instructions which they happened to interpret in a way that resulted in them causing some pixels on a screen to light up in a way that somewhat resembles the copyrighted images".
Indeed. And even though I consider myself a technical person through and through, I wouldn't want the law to work like that. We, as humans, are not capable of specifying society's functioning at that precision. We need the fuzziness of humans in the loop.
Neither would I. Though every now and then I wouldn't dislike to be bound to rules that I can evaluate in advance, without having to bet on what a judge's a posteriori interpretation will be.
I agree. But other times I'd also very much dislike being bound by "code" that the democratically elected lawmakers agree is buggy (buggy compared to their and the electorate's intentions).
This is one of the services lawyers who are specialized in the area can provide; they will know the case law around particular rules, etc.
Tax Law is especially interesting here, because you can basically depend on what the IRS has said but there's a chance that even if they said X, the tax court will actually rule Y (in your favor). Sometimes the risk can be worth it (if you made a good-faith effort to comply with a reasonable understanding of the law, and the court rules against you, you just have to pay the tax; even if you were found unreasonable you pay the tax + penalty which often isn't that much).
Many websites also do not provide their JS source code in readable form and state the code's license. They purposefully obfuscate it using uglifiers and then build in things talking to Google into their website. Even the usual "isogram" thingy for GA is not readable. Giving this, I definitely hold the web developer and company responsible.
It's been ruled once already that using Google Fonts is a breach of GDPR [0].
> The disclosure of the user's IP address in the above-mentioned manner and the associated encroachment on the general right of personality is so significant with regard to the loss of control over a personal data to Google, a company that is known to collect data about its users, and the individual discomfort felt by the user as a result, that a claim for damages is justified.
Generally speaking using any public CDN is not GDPR compliant. If you _could_ self host the files, then you can not meet the necessity test required for any of the relevant legal basis in GDPR art 6(1).
Google Fonts and FA are worse, because the personal data is shipped off wholesale to the USA. Neither FA or Google (for fonts) offers a data processing agreement that would make it legal to use.
If developers can't efficiently deliver what designers want, within reason, that's most definitely the the fault of developers collectively, even if it might be a big ask of a single developer without sufficient experience or resources.
> If developers can't efficiently deliver what designers want, within
reason, that's most definitely the the fault of developers
collectively, even if it might be a big ask of a single developer
without sufficient experience or resources.
An interesting take on which part of the dog wags.
In your model, developers seem positioned to serve designers.
Having written a book on design, and practised it, I have to say that
web is very unusual in allowing designers such rein. In other
disciplines, like sound design or product design, the constraints and
requirements of the project come first, and designers need to fit
their work to that.
A very great many web projects I have seen fail went south the moment
"designers" got involved. Designers seems to wield an inappropriate
level of power and influence, and operate without proper technical
supervision, often breaking things or creating unreasonable demands.
I think this misalignment comes from the early days of the web, when
anyone who could write HTML called themself a web designer and took on
an entire site development. Even though post-CGI/database the
server-side roles were better differentiated, the legacy of "aesthetic
driven design" lingers.
I do not want to denigrate web designers, but times have changed and
in my opinion, having a website that "looks great" just isn't that
important these days. I'd much rather use simpler, accessible, secure,
private, content-centred sites.
> who do you think designs the simpler, accessible, secure, private, content-centred sites
That would be the role of a designer who is doing their job properly
and paying attention to the specification for a simple, accessible,
secure, private, and content-centred site.
> (...) having a website that "looks great" just isn't that important these days. I'd much rather use simpler, accessible, secure, private, content-centred sites..
Why exclude aesthetics? There is no need for it. It positively affects usability, just like the other qualities you described.
> It positively affects usability, just like the other qualities you described.
It does indeed. "Aesthetics" in the most accurate sense of the word,
as opposed to orderliness or just "looking right", is about how it
makes us feel. Some people seem particularly sensitive to it and say
they can't use a site or application that feels wrong. I respect that
nuanced choosyness. Indeed I'm sure there's a biological thing going
on, as in the way we select berries to eat or choose partners to mate
with. Hard to introspect parts of our brain say "that's okay" or
"that's off, don't touch". Aesthetics is very real.
But (there's always a but :) ... it should never be put ahead of
functionality. As I see it that's what makes "Design" design, and not
Art. It's blending aesthetics and elegance within a practical value
set. And very often that "requirements set" is given to us designers
by another... a film director, a product manager, an information
architect etc. They say - "Here's what it has to do, (functional
requirement) now go design it (non-functional)".
And what I am saying is that, in Web Design at least, the designers
have gotten the upper hand, and that's partly the fault of developers,
system architects, or project managers for letting themselves get
pushed around like that.
I’ve worked in high-trust environments (read: where public CDNs are noncompliant) and that’s never been an issue. All of these fonts are downloadable and self-hostable.
If you have bad designers then yes, that makes your life harder. But insisting on a custom font doesn’t make that person a bad designer if there’s a valid reason why including it would improve the users’ experiences.
- If the font is part of a brand identity that the user trusts (there’s a reason Times New Roman has Times in it).
- If the font has associations with a particular place or time that you want to imbue your system with.
- If you give the user themselves the ability to select a font that works best for them (for example a font focused on the dyslexia reading experience in an ereader).
I disabled web fonts by default in uBlock Origin. The internet is so much better without them. I selectively enable them for sites I use frequently that have special icon fonts that mess up the interface if they can't load.
Is there a need to use uBlock for this sort of thing? In Firefox, there's a button to allow sites to use their own fonts, in the 'advanced' fonts menu. I don't see any reason why a website should pick it's own fonts.
I go back and forth on allowing it to set background and text colors. Forcing black text on a white background does make some pages pretty ugly, but it does force everything to be readable.
There isn't, except that it makes it possible to selectively enable them on certain sites. They don't bother me for things that I use regularly and already have them cached, like my bank. In fact, without them a lot of UI elements like carets and button icons become junk.
Ah yes, we should entirely limit typographic creativity due to creating slight irritation for the lowest common denominator. Guess we should stick to web safe colours and 90% JPEGs too.
Quite some time ago, I gave up on letting sites set their own fonts. Why allow it? The ones on my system are perfectly usable and familiar -- some sites may pick slightly better ones, others will go for some annoying whimsical bullshit.
Going back and forth on allowing sites to set text/background colors.
Good content doesn't need graphic design tricks to remain interesting.
Developers need to use a system font stack which loads fonts from the system itself instead of remote web fonts.
The default font display setting for Google fonts is 'swap'. Using font-display means the browser will block rendering for a short time, and then use the fallback font if the font hasn't loaded, and then swap in font when it does eventually load.
But, and here's the important bit, the block period for 'font-display: swap' is 0ms. In other words, Google Fonts works how you think it should already so long as the developer has included a fallback system font in the font-family.
I suspect you're attributing a blocking problem to Google Fonts when really it's caused by something else.
> Developers need to use a system font stack which loads fonts from the system itself instead of remote web fonts.
Browsers have always loaded a font from the system over a web font if it has a font of that name.
We could just normalize having a lot more free as in beer fonts installed on the average user's machine.
The unfortunate emphasis there is "average user's machine" as font loading times are already a a deanonymization vector/fingerprinting. Way back in the day IE made a big deal about bundling a group of fonts and calling them "Web Safe" and we need an initiative like that again. Take the Top X fonts from Google Fonts and just bundle them with browsers or operating systems and spread those as widely as possible so that it isn't a useful deanonymization vector.
> Browsers have always loaded a font from the system over a web font if it has a font of that name.
This isn't actually accurate. It's possible for a CSS author to write @font-face rules that behave in this way (by including local(...) sources ahead of remote-font URLs), but that's by no means universal practice.
> Values are separated by commas to indicate that they are alternatives. The browser will select the first font in the list that is installed or that can be downloaded using a @font-face at-rule.
> If the font family name is the same as a font family available in a given user's environment, it effectively hides the underlying font for documents that use the stylesheet.
I've made a few websites. This idea might work for your blog but it doesn't swing with designers. Brand control is everything, and that extends well into typography.
Given the web is about 65% browsed by a Google client, I'm surprised Google Font aren't directly installed into each system fonts on first load.
> There is no single service that can go down [...]
> Each piece of content is loaded entirely independently, [...]
Both of these statements can be true, but in fact, what ends up happening is someone puts their site on a pinning service like Piñata or Infura, and then it's right back to being centralized and trackable. Filecoin helps decentralize who pins, but even then, one ends up using a pretty interface like web3.storage since using the real service is just too much overhead for just pushing a page.
I'm personally a big fan of IPFS, but I'd use it to make an entire site reliable for users who care to self-pin.
>and then it's right back to being centralized and trackable.
I haven't been following IPFS very closely recently, but this doesn't track for me at all.
So people pin some content on a big node.
Once you download it, now it's on YOUR node, and your friend can still get it off you. Your node is just as authoritative as the big one. They disappear and IPFS can carry on.
I remember people criticizing NFT's using IPFS links as "not solving anything" and I was truly truly baffled at why anyone would think that. You could easily hold on to your image on a thumb drive, or absolutely any method of backing content up. If every single copy on the internet got nuked, you could just publish from your usb drive again and suddenly it's back up, available for all to see. More to the point, anyone could do that. So anyone (including you) with even a slight motivation to preserve that data could authoritatively do so.
disclaimer: I do not like NFT's. I don't like them practically, I don't like them abstractly, and I don't like them culturally. It's just this is one criticism thrown at NFTs I don't agree with, IPFS makes this aspect work.
This also strikes me as another "You're Not Google" example. With modern computers, where even the smallest instance currently available on AWS would have been a beefy system when this advice was first diffused into the community, CDNs are probably solving a problem you don't have in 2022. If you have 10MB of static files to serve, and they're decently cached, you're looking at the ability to serve on the order of 50-100 new users per second with very realistic setups nowadays that would still be generally considered "entry level" in the modern environment, while in the meantime consuming almost no resources on the server because serving static files is really easy. And that's just straight off the "main server".
If you've run the numbers, and that's a problem, hey, great, more power to you! There's web sites where that's a problem. But, you know, remember that 100 new users per sec is a scale of nearly 10,000,000 per day. Is that really your scale? There's an awful lot of sites, even busy, productive, and profitable sites, that are looking more at the "1 new user loading a fresh copy of these things per second", if not one per minute.
I remember working with "servers" in the low hundreds of megahertz, on software stacks a lot less optimized than today. Shifting around your static serving could do something then. Today? Choking even a single CPU server's capability to serve static content takes some doing. By the time that's your core problem, you'll know.
(There's still a lot of "best practices" banging around the community from the "low hundreds of megahertz" period of time. At the risk of goring some sacred oxes, I also consider the obsession with total statelessness to date from this era. While one must still be careful with it, judicious application of state in the modern era can be very helpful. It's less panic-inducingly terrifying when I can afford the equivalent of entire servers dedicated to each individual user, where "server" is defined as "a server class machine from the time this advice first percolated out". The software engineering considerations around state are relevant and must be considered, but the solution of "zero! none! never! not any!" is no longer the only viable or best choice.)
While I agree we should not assume a cdn is necessary, as far as user traffic is concerned, not all seconds are created equal. Those pesky users have a habit of making requests at the same time, like they're in cahoots with one another. Whether it's because they're all in the same time zone and they just got home from work, or the clock struck midnight and your fire sale has begun, you don't provision for average qps, you provision for peak qps.
This does not negate your argument, in fact for many use cases doing your own caching could be a better way to meet increased demand (certainly a cheaper way). CDN-related issues can be incredibly difficult to troubleshoot, too, especially without a support contract.
By all means, if You Are Indeed (Some Reasonable Fraction Of) Google, then by all means, take that seriously.
But I can tell you from personal experience I've been asked to produce a "CDN plan" for content access on the order of once a minute during peak hours, and which had no reasonable business case for distributing enough to matter.
I am personally responsible for one system that does need CDN-like capability, because it does serve static files at a rate and a required reliability that a single server can't meet. (We don't use a "real" CDN because for our use case it would be absurdly expensive, but we're keeping an eye on the offerings out there.) So I do know they can exist. But even that system is, in 2022, on the lower end of what you would need such a thing for, and it is serving multi-gigabyte images out on a fairly routine basis to many tens of thousands of consumers (which are automated systems, not humans). That's what it takes to be on the "low end" of blowing out a normal static file server. 15 years ago these systems were a royal pain to maintain, at a much lower level of usage, and non-trivial effort was spent optimizing what they serve. Today, they mostly just hum away doing their job.
> I also consider the obsession with total statelessness to date from this era
People were less obsessed with statelessness back then. There was some push for statelessness (peaking at the time of the 10K problem), but it was much less than now.
I believe the current wave is entirely caused by the publicity of the "we rent IaS, but not as commodity computers" cloud, and doesn't have any technical origin.
> If you have 10MB of static files to serve, and they're decently cached, you're looking at the ability to serve on the order of 50-100 new users per second with very realistic setups nowadays that would still be generally considered "entry level" in the modern environment, while in the meantime consuming almost no resources on the server because serving static files is really easy. And that's just straight off the "main server".
If your web page needs 10MB of static files to load, you're going to need a lot of round trips to get that to your users. Your server and clients may be on 10G ethernet, but that 10MB download is still going to be limited by 'slow start' congestion control unless the round trip time is low. That's why people want to use CDNs more than reducing resource use of serving static files (which is pretty low as you mention).
But as a user, I don’t want to waste time (and resources) re-fetching the same library from different sites all the time. I might not be somewhere with a good internet connection or I might pay for data, etc.
You increasingly don't get a choice. Due to the ability to fingerprint people by measuring how long it takes to access resources, browsers are moving in the direction of completely sharding the cache by site anyhow to secure people away from that. If they're not already all there, they are getting pretty close. The argument in favor of a CDN in terms of "hoping the user already has jQuery or something in their cache" is nearly dead now.
I seem to recall some people measuring the effect even before it was dead, and the hit rate was never all that great anyhow. There were so many versions of jQuery, so many other libraries, and so many CDNs, it still didn't hit as often as you might think.
> With modern computers, where even the smallest instance currently available on AWS would have been a beefy system when this advice was first diffused into the community
Cloud VM instances are for the most part very underpowered (and for the performance, overpriced). You'd have to go far back a lot of years to get to an era where a "beefy system" of the time was as weak as the smallest AWS instance (t2.nano?)
1. Anything beyond control may cause problems. For the security part: add SRI to whatever you care about, please.
2. Could we, in 2022, get rid of the troublesome Referer?
Public CDNs are super handy when you're quickly whipping something up. I feel like the DX is under-appreciated in discussions about this.
Eg skypack is just awesome, it lets you import any npm package onto a website as if it was a proper es6 module. Google fonts is amazing in similar ways. Dangerous, fine, but I empathically disagree with calling that "useless".
This article has a lot of good points and suggestions for site creators, but for consumers, there is something you can use: the Decentraleyes browser addon (https://decentraleyes.org/). It basically intercepts calls to well-known centralized CDNs and serves it locally from the browser without issuing any network calls whatsoever.
> When talking about caches, I'm primarily suggesting a paid caching reverse-proxy service, like Cloudflare, Fastly, Cloudfront, Akamai, etc
I'm confused. Where is the difference between using these companies as CDN providers versus using them as cache providers? The only minor difference that I can see is that my server would provide the original copy for every cached item, but this does not mitigate the risk of cache poisoning and the privacy risks that you also encounter with CDNs.
The difference is that they host content that's under your control - they're not a _public_ CDN. I.e. a CDN service that you don't control at all, which hosts a fixed set of libraries or resources, like Google Fonts or CDNjs.
I'm developing a markup language that compiles to HTML and (among other things) allows easily inserting LaTeX equations. Currently they're rendered using KaTeX, which requires custom fonts. Is there a way to make it work without a CDN? I don't want to sacrifice the convenience of being able to quickly write down some math and having it compiled into a single HTML file, so requiring the user to put the fonts somewhere and link them separately is unfortunately not an option.
> Most importantly: cached content is no longer shared between domains. This is known as cache partitioning and has been the default in Chrome since October 2020...
Interestingly the Google Hosted Libraries ToS[1] says:
> Our systems are designed to remove HTTP referer information before logging, to avoid associating requests with any individual website using the Google Hosted Libraries.
So they at least are claiming the CDN is not used to snoop on traffic paterns.
196 comments
[ 4.6 ms ] story [ 227 ms ] threadBut that isn't how humans work, and there needs to be some grease easing the process at the start. So they still serve a function, even if it's not the one that the CDNs imagined at the start.
We’re all on a journey in our careers. Those of us with more knowledge and experience can and should help those with less, instead of gatekeeping and lecturing.
There is a difference between capability and knowledge. We’re each on a journey.
I'd much rather work with someone that just needed to learn a few things I take for granted than someone who decides it's their right to say who's in or out of IT haha. Teach or get out of the way.
If you copy the tags from cdnjs.com this attribute will be added automatically.
The issue is this: many sites would download files from 10+ different domains and a single ‘long-tail’ DNS query, increasingly likely if you have more domains, will cause more delay than you could possibly save by using multiple servers.
But now that you bring it up, isn't the 6 resources per domain outdated? At least for HTTP2? When I've done performance testing on my site lately it definitely seemed to load more than 6 resources in parallel from one domain but I haven't looked into this topic in a long time (back when it definitely was limited)
Isn’t the maximum concurrent multiplex streams on one connection, like, 1000?
(I suspect you didn’t mean to say multiplexing)
Edit: Firefox by default uses no more than 900 parallel HTTP connections (check your about:config page), and I assume this holds true for all windows/tabs combined - which is plenty.
I think I'd prefer deploying a new CDN link to updating DNS. "No code changes or backend deployments" makes the assumption that DNS is a manual change (not terraform, etc.)
(cdnjs, that I maintain and is referenced in the article, does both of these by default if you copy a script/link tag from our site.)
(ps, I dislike the name; you don’t encounter the term “subresource” anywhere else in webdev. It’s a “subresource” of the HTML document resource, eyeroll)
A PWA with a Service Worker could perhaps implement its own client-side "gateway", translating public gateway URLs into direct IPFS access. Without the Service Worker (or without JS) it would fall back to using the gateway.
[0] https://js.ipfs.io/
It sounds like we'd need to have browsers implement IPFS protocol support directly for this to be a feasible alternative to centralized CDNs.
I checked the docs though and it seems like self-hosting is within the license.
Maybe material icons are different or maybe I'm misreading this page.
https://developers.google.com/fonts/docs/material_icons
EDIT: Unless there's a way to include metrics outside the font there really isn't a way to prevent reflows when it loads other than blanking the entire page until then.
On Firefox, this is as simple as going to about:config and setting gfx.downloadable_fonts.enabled to false.
On Chrome, it requires adding the flag --disable-remote-fonts to however you're opening it.
(There are many ways to avoid reflows with font loading, eg font-display: optional)
- The page takes an extra 100ms to load
- ~ a minute later (when you're halfway through reading it) the content will jump by some large amount.
There isn't a nice way to do custom fonts on the web and you should just avoid them.
> The page takes an extra 100ms to load
Nope. Slow connections' floor for first paint is 100ms when using `font-display: optional` – not an additional 100ms. The page is still loading like normal in this period. (If you're already under a 100ms FCP for 3G users, you know all of this already)
> the content will jump by some large amount
`font-display: optional` is literally designed to prevent this from ever occurring. Either the font is ready for first paint in 100ms, or another font is used.
https://addons.mozilla.org/en-US/firefox/addon/decentraleyes...
Required reading, “More than you ever wanted to know about font loading on the web”: https://www.industrialempathy.com/posts/high-performance-web...
Edit:
> Developers need to use a system font stack which loads fonts from the system itself instead of remote web fonts
IMO the takeaway is "self-host fonts, make sure they're small files, load early, and don't block render," not "only use native fonts"
It's not even clear if using Google Fonts is GDPR compliant (since you're leaking the fact that your visitor has visited your website): https://github.com/google/fonts/issues/1495
Even if you do want to use your own hand-picked font on your site, just self host it, or bundle it with something like https://fontsource.org/
They provide the tools to bundle the fonts and serve them yourself: https://fontsource.org/fonts/merriweather-sans
EDIT: The original comment mentioned "fortawesome" instead of "fontsource". I mixed up the names, my bad!
Your website is malware that contains code which makes the visitor's browser connect to Google's server.
Though it arguably doesn't get enforced anyways, except for some big corps.
The reasoning was that as it is so very easy to self host Google fonts and with caching as an argument gone there is actually not enough reason anymore to use the hosted version by Google and transmit PD to Google.
Would the site have used a foundry that didn't offer self hosting the reasoning might have turned out differently if the site owner could have made a strong argument for using this specific font by this foundry.
At least that was my reading but IANAL.
It doesn't often really work out that way.
Tax Law is especially interesting here, because you can basically depend on what the IRS has said but there's a chance that even if they said X, the tax court will actually rule Y (in your favor). Sometimes the risk can be worth it (if you made a good-faith effort to comply with a reasonable understanding of the law, and the court rules against you, you just have to pay the tax; even if you were found unreasonable you pay the tax + penalty which often isn't that much).
The user likely has no idea they contacted Google — it only happened because the code in your application executed it.
> The disclosure of the user's IP address in the above-mentioned manner and the associated encroachment on the general right of personality is so significant with regard to the loss of control over a personal data to Google, a company that is known to collect data about its users, and the individual discomfort felt by the user as a result, that a claim for damages is justified.
[0] https://rewis.io/urteile/urteil/lhm-20-01-2022-3-o-1749320/
Using FA as a CDN is not GDPR compliant, either.
Generally speaking using any public CDN is not GDPR compliant. If you _could_ self host the files, then you can not meet the necessity test required for any of the relevant legal basis in GDPR art 6(1).
Google Fonts and FA are worse, because the personal data is shipped off wholesale to the USA. Neither FA or Google (for fonts) offers a data processing agreement that would make it legal to use.
https://fontsource.org/
They provide the tools to bundle the fonts and serve them yourself:
https://fontsource.org/fonts/merriweather-sans
Will update original comment.
An interesting take on which part of the dog wags.
In your model, developers seem positioned to serve designers.
Having written a book on design, and practised it, I have to say that web is very unusual in allowing designers such rein. In other disciplines, like sound design or product design, the constraints and requirements of the project come first, and designers need to fit their work to that.
A very great many web projects I have seen fail went south the moment "designers" got involved. Designers seems to wield an inappropriate level of power and influence, and operate without proper technical supervision, often breaking things or creating unreasonable demands.
I think this misalignment comes from the early days of the web, when anyone who could write HTML called themself a web designer and took on an entire site development. Even though post-CGI/database the server-side roles were better differentiated, the legacy of "aesthetic driven design" lingers.
I do not want to denigrate web designers, but times have changed and in my opinion, having a website that "looks great" just isn't that important these days. I'd much rather use simpler, accessible, secure, private, content-centred sites.
That would be the role of a designer who is doing their job properly and paying attention to the specification for a simple, accessible, secure, private, and content-centred site.
Why exclude aesthetics? There is no need for it. It positively affects usability, just like the other qualities you described.
It does indeed. "Aesthetics" in the most accurate sense of the word, as opposed to orderliness or just "looking right", is about how it makes us feel. Some people seem particularly sensitive to it and say they can't use a site or application that feels wrong. I respect that nuanced choosyness. Indeed I'm sure there's a biological thing going on, as in the way we select berries to eat or choose partners to mate with. Hard to introspect parts of our brain say "that's okay" or "that's off, don't touch". Aesthetics is very real.
But (there's always a but :) ... it should never be put ahead of functionality. As I see it that's what makes "Design" design, and not Art. It's blending aesthetics and elegance within a practical value set. And very often that "requirements set" is given to us designers by another... a film director, a product manager, an information architect etc. They say - "Here's what it has to do, (functional requirement) now go design it (non-functional)".
And what I am saying is that, in Web Design at least, the designers have gotten the upper hand, and that's partly the fault of developers, system architects, or project managers for letting themselves get pushed around like that.
- If the font has associations with a particular place or time that you want to imbue your system with.
- If you give the user themselves the ability to select a font that works best for them (for example a font focused on the dyslexia reading experience in an ereader).
Such as?
I go back and forth on allowing it to set background and text colors. Forcing black text on a white background does make some pages pretty ugly, but it does force everything to be readable.
Self-hosted web fonts are fine.
More like self-indulgent wankery.
Going back and forth on allowing sites to set text/background colors.
Good content doesn't need graphic design tricks to remain interesting.
The default font display setting for Google fonts is 'swap'. Using font-display means the browser will block rendering for a short time, and then use the fallback font if the font hasn't loaded, and then swap in font when it does eventually load.
But, and here's the important bit, the block period for 'font-display: swap' is 0ms. In other words, Google Fonts works how you think it should already so long as the developer has included a fallback system font in the font-family.
I suspect you're attributing a blocking problem to Google Fonts when really it's caused by something else.
https://addons.mozilla.org/de/firefox/addon/localcdn-fork-of...
But sometimes if the webpage looks funny, you have to deactivate it.
Browsers have always loaded a font from the system over a web font if it has a font of that name.
We could just normalize having a lot more free as in beer fonts installed on the average user's machine.
The unfortunate emphasis there is "average user's machine" as font loading times are already a a deanonymization vector/fingerprinting. Way back in the day IE made a big deal about bundling a group of fonts and calling them "Web Safe" and we need an initiative like that again. Take the Top X fonts from Google Fonts and just bundle them with browsers or operating systems and spread those as widely as possible so that it isn't a useful deanonymization vector.
This isn't actually accurate. It's possible for a CSS author to write @font-face rules that behave in this way (by including local(...) sources ahead of remote-font URLs), but that's by no means universal practice.
https://developer.mozilla.org/en-US/docs/Web/CSS/font-family
`font-family` rules apply ahead of `@font-face` rules. `@font-face` rules are used to source fonts not already installed on the system.
(ETA: local() is to provide alternate family names when a font may be installed under different family names.)
See https://www.w3.org/TR/css-fonts-3/#font-family-desc:
> If the font family name is the same as a font family available in a given user's environment, it effectively hides the underlying font for documents that use the stylesheet.
Given CSS such as
this will block the browser from using an installed Palatino font and tell it to load the remote resource instead. So it's possible to use to ask for the locally-installed font if present, falling back to the remote resource otherwise.Given the web is about 65% browsed by a Google client, I'm surprised Google Font aren't directly installed into each system fonts on first load.
Best Practice does not mean "advice that I believe in." Best practices are legally binding documents issued by insurers.
But why?
> There is no single service that can go down [...]
> Each piece of content is loaded entirely independently, [...]
Both of these statements can be true, but in fact, what ends up happening is someone puts their site on a pinning service like Piñata or Infura, and then it's right back to being centralized and trackable. Filecoin helps decentralize who pins, but even then, one ends up using a pretty interface like web3.storage since using the real service is just too much overhead for just pushing a page.
I'm personally a big fan of IPFS, but I'd use it to make an entire site reliable for users who care to self-pin.
I haven't been following IPFS very closely recently, but this doesn't track for me at all.
So people pin some content on a big node.
Once you download it, now it's on YOUR node, and your friend can still get it off you. Your node is just as authoritative as the big one. They disappear and IPFS can carry on.
I remember people criticizing NFT's using IPFS links as "not solving anything" and I was truly truly baffled at why anyone would think that. You could easily hold on to your image on a thumb drive, or absolutely any method of backing content up. If every single copy on the internet got nuked, you could just publish from your usb drive again and suddenly it's back up, available for all to see. More to the point, anyone could do that. So anyone (including you) with even a slight motivation to preserve that data could authoritatively do so.
disclaimer: I do not like NFT's. I don't like them practically, I don't like them abstractly, and I don't like them culturally. It's just this is one criticism thrown at NFTs I don't agree with, IPFS makes this aspect work.
Very much performance for the time invested.
If you've run the numbers, and that's a problem, hey, great, more power to you! There's web sites where that's a problem. But, you know, remember that 100 new users per sec is a scale of nearly 10,000,000 per day. Is that really your scale? There's an awful lot of sites, even busy, productive, and profitable sites, that are looking more at the "1 new user loading a fresh copy of these things per second", if not one per minute.
I remember working with "servers" in the low hundreds of megahertz, on software stacks a lot less optimized than today. Shifting around your static serving could do something then. Today? Choking even a single CPU server's capability to serve static content takes some doing. By the time that's your core problem, you'll know.
(There's still a lot of "best practices" banging around the community from the "low hundreds of megahertz" period of time. At the risk of goring some sacred oxes, I also consider the obsession with total statelessness to date from this era. While one must still be careful with it, judicious application of state in the modern era can be very helpful. It's less panic-inducingly terrifying when I can afford the equivalent of entire servers dedicated to each individual user, where "server" is defined as "a server class machine from the time this advice first percolated out". The software engineering considerations around state are relevant and must be considered, but the solution of "zero! none! never! not any!" is no longer the only viable or best choice.)
This does not negate your argument, in fact for many use cases doing your own caching could be a better way to meet increased demand (certainly a cheaper way). CDN-related issues can be incredibly difficult to troubleshoot, too, especially without a support contract.
But I can tell you from personal experience I've been asked to produce a "CDN plan" for content access on the order of once a minute during peak hours, and which had no reasonable business case for distributing enough to matter.
I am personally responsible for one system that does need CDN-like capability, because it does serve static files at a rate and a required reliability that a single server can't meet. (We don't use a "real" CDN because for our use case it would be absurdly expensive, but we're keeping an eye on the offerings out there.) So I do know they can exist. But even that system is, in 2022, on the lower end of what you would need such a thing for, and it is serving multi-gigabyte images out on a fairly routine basis to many tens of thousands of consumers (which are automated systems, not humans). That's what it takes to be on the "low end" of blowing out a normal static file server. 15 years ago these systems were a royal pain to maintain, at a much lower level of usage, and non-trivial effort was spent optimizing what they serve. Today, they mostly just hum away doing their job.
People were less obsessed with statelessness back then. There was some push for statelessness (peaking at the time of the 10K problem), but it was much less than now.
I believe the current wave is entirely caused by the publicity of the "we rent IaS, but not as commodity computers" cloud, and doesn't have any technical origin.
If your web page needs 10MB of static files to load, you're going to need a lot of round trips to get that to your users. Your server and clients may be on 10G ethernet, but that 10MB download is still going to be limited by 'slow start' congestion control unless the round trip time is low. That's why people want to use CDNs more than reducing resource use of serving static files (which is pretty low as you mention).
I seem to recall some people measuring the effect even before it was dead, and the hit rate was never all that great anyhow. There were so many versions of jQuery, so many other libraries, and so many CDNs, it still didn't hit as often as you might think.
Cloud VM instances are for the most part very underpowered (and for the performance, overpriced). You'd have to go far back a lot of years to get to an era where a "beefy system" of the time was as weak as the smallest AWS instance (t2.nano?)
Eg skypack is just awesome, it lets you import any npm package onto a website as if it was a proper es6 module. Google fonts is amazing in similar ways. Dangerous, fine, but I empathically disagree with calling that "useless".
https://esm.sh - lots of options
https://jspm.dev - does import maps (with a polyfill) https://generator.jspm.io/
https://esm.run - jsdelivr hosted esm builds but only ones already uploaded to npm
I'm confused. Where is the difference between using these companies as CDN providers versus using them as cache providers? The only minor difference that I can see is that my server would provide the original copy for every cached item, but this does not mitigate the risk of cache poisoning and the privacy risks that you also encounter with CDNs.
TIL.
> Our systems are designed to remove HTTP referer information before logging, to avoid associating requests with any individual website using the Google Hosted Libraries.
So they at least are claiming the CDN is not used to snoop on traffic paterns.
[1] https://developers.google.com/speed/libraries/terms