Hacker News Reader

Comment by tcdent | Hacker News Reader

> "...if you’re a user, chances are, you’re quite relieved (or even ecstatic) at the ability to block web fonts and experience a faster web."

These days, with increased processing power and standards adoption generally available, we really have been able to push the weight of websites.

Conversely, battery powered devices and sketchy wideband internet access are growing rapidly.

Sure, we have the power, but it's becoming apparent that at this scale effeciency is very important. More users than ever want more content faster than ever.

Globalized (literally) asset sharing, with technologies like digest references in script and link tags could make a big difference. Why not even pre-package really popular stuff (jQuery, Helvetica, etc) with the browser or OS?

View on HN

You may have forgotten that Helvetica licenses cost money. http://www.linotype.com/1308886/Helvetica-family.html?numLic...

Feel free to buy me one, I'm a starving designer :)

Also, it's not in the spirit of the web to package content natively with the browser, because then only certain clients are able to understand the content correctly. The thought is to make everyone able to see exactly the same thing, with nothing stored on a local machine.

Buy? For the web it's worse - they nickel and dime you based on the number of visitors to your site.

It's an subscription.

The popular stuff should be just as performant as if it were packaged with the browser - most sites are pulling jquery from one of the big CDNs and caching it for as long as possible. You aren't downloading jquery for every site that needs it, you're downloading it once for the thousands of sites that use the same cdn. Packaging it into the browser is just going to introduce a whole bunch of complexity around versioning and updates and standardization.

You aren't downloading jquery for every site that needs it, so long as they are using the same CDN and the same version of jquery. I wonder what the hit rate really is...

Personally, I avoid it. The client can afford CDN delivery and then we can assure availability. Donated project hosting doesn't have that guarantee.

I think people seriously overestimate how useful CDNs are for static assets. Even if the page you visit happens to call for the same version of a resource you might have cached, there is no guarantee it is requested from the same CDN. And all these hostname lookups slow things down too. I frequently see a site request assets from multiple different CDNs when those assets are all available from a single CDN. The designer clearly copied a snippet of HTML without regard for the extra lookups when they could have found all the necessary assets on a single CDN.

I tried finding reliable data for cache hit/miss rates for popular CDNs but was unsuccessful. Is there a site out there tracking this that designers could refer to? It would be good to know if simply concatenating all your CSS (for example, or JS) into one file and serving it from Cloudfront would beat scattering it across several providers and hoping the majority of visitors had cached copies. I suspect the single file would perform better but I have no reliable data to support this.

Reply on news.ycombinator.com