Live data from Hacker News

Some analysis of the 1M most popular sites on the web

jacquesmattheij.com

81–90 of 130 posts

Re: Some analysis of the 1M most popular sites on the web

#81
post #72
post #36

Earlier quoted context omitted.

Can you please elaborate how using share libraries is "pretty much pointless and incurs a performance penalty"? That goes against my intuition of how they work.

Think it means that most machines are not memory or disk constrained these days, but there is extra processing to perform the dynamic linking. Sort of a cost-benefit argument it seems. Doesn't address the issue of security etc and the benefit of just having 1 instance of a library to update when maintaining a complete system however.

[deleted]

Re: Some analysis of the 1M most popular sites on the web

#82
post #62

Earlier quoted context omitted.

What about the common trick of serving static assets via a separate domain (one that's still owned and hosted by you) to avoid the overhead of cookies from the main site being included in asset requests?

That's a good point. That would require some more work to rule out, for instance by doing a whois lookup to see if the domains have the same controlling entity.

Yep, it's a tricky one to sort out. Harder still if the domains are using a whois privacy protection service.

Checking if both domains resolve to the same IP could help establish a link in certain cases (e.g. where the same haproxy load balancer is terminating traffic for both sites).

Maybe also checking if the asset domain contains the string of the main site domain e.g. company.com and companystatic.com or company.com and companyassets.com

Edit: if both sites are served over SSL you could also sniff the cert to see if its the same one in both cases (i.e. they're using one cert and multiple subjectAltName entries).

Re: Some analysis of the 1M most popular sites on the web

#83
post #13

Likely culprits are "performance analyzers" that grade a website and report an "F" (failing) grade for not using CDN-hosted common libraries. This is a red herring: this idea that the user will already have a cached copy of CDN-hosted jQuery is bogus. Even for a common library like jQuery: the number of versions of jQuery that are in use is likely above 50, and the number of popular CDNs that host jQuery is surely ab…

Eh, I can fit one copy of libc in L2 cache, but not 30 copies.

What if we add kernel same-page merging to the mix? Might still be a little less efficient at run time than the optimal use of shared libraries. But shared libraries make packaging more complex, especially if one does it Debian-style, with each shared library in its own package, a separate -dev package, etc.

Re: Some analysis of the 1M most popular sites on the web

#84
post #64

Earlier quoted context omitted.

Minifying your JS and CSS files is a very good practice as it's not only secure, but also is compact. Grunt is a very powerful tool that does this.

As an example, on a previous project all of the javascript libraries + the app concatenated together at 3MB. Minification with uglify reduced the size to 1.5MB and using Gzip compression further reduced the transfer size to ~800K.

Have you compared that to the transfer size of gzip without a minification step? I haven't seen a real difference, myself, and I've been considering taking the minification step out.

Re: Some analysis of the 1M most popular sites on the web

#86
post #85

Evercookies sound terrifying. Not that I'm doing anything that I really worry about hiding, but I can't stand invasion of privacy like this. Are there effective protections against them? If not, I wonder why the EFF hasn't taken up the charge to fight them?

Too many battles to wage for one fairly small organization

Re: Some analysis of the 1M most popular sites on the web

#87
post #85

Evercookies sound terrifying. Not that I'm doing anything that I really worry about hiding, but I can't stand invasion of privacy like this. Are there effective protections against them? If not, I wonder why the EFF hasn't taken up the charge to fight them?

Too many battles to wage for one fairly small organization

Re: Some analysis of the 1M most popular sites on the web

#89
post #25

Earlier quoted context omitted.

Agree the advice is well intentioned and is correct (in theory according to what I read) but not entirely practical. For example: "then at a minimum you should verify regularly that the code has not changed (you have to hope that you are looking at the same code that your users see)" Who exactly is the "you" in the above statement and who pays the "you" money to fix this and keep on top of it on an ongoing basis? And…

Regularly pulling a hash for the libraries you include and alerting you when a hash changes unexpectedly is no work at all. And if you need to be paid money to fix it then you have a problem anyway so one would assume that you'd be paid just as much to fix it when you're being alerted to it by a cron job as you would be paid to when you're alerted by a horde of users. As for machines without guards: I've worked (exte…

Machines: Yes this was the 80's (sorry I didn't point that out my mistake) and things have changed. However to that point if you have your golden machine operator turning out good work (and he is only 1 of 2 on a particular line) and it's not easy to hire a replacement, let alone a good replacement, you tend to get a bit lax.

Security: I am primarily a business guy (who does some light programming and knows Unix since the 80's) so I hire others to do work for me. I am just thinking that for the people that I have hired in the past how would anyone know if any of this is happening (other than code audits) and what is the mechanism to make sure the right thing happens even if you know what the right thing is? It's kind of a version of the advice "make backups but make sure that you test your backups as well".

Re: Some analysis of the 1M most popular sites on the web

#90
post #89

Earlier quoted context omitted.

Regularly pulling a hash for the libraries you include and alerting you when a hash changes unexpectedly is no work at all. And if you need to be paid money to fix it then you have a problem anyway so one would assume that you'd be paid just as much to fix it when you're being alerted to it by a cron job as you would be paid to when you're alerted by a horde of users. As for machines without guards: I've worked (exte…

Machines: Yes this was the 80's (sorry I didn't point that out my mistake) and things have changed. However to that point if you have your golden machine operator turning out good work (and he is only 1 of 2 on a particular line) and it's not easy to hire a replacement, let alone a good replacement, you tend to get a bit lax. Security: I am primarily a business guy (who does some light programming and knows Unix sinc…

The motto is 'trust but verify', and indeed that goes for your backups as well. And incidentally that's one of the most failed items during the dd's I've done and after verification several companies turned out to have lived without backups at all.

It usually takes two things to go wrong for a disaster to happen: some $0.05 part that fails and a procedural error.

And the consequences can be just about anything.

Post reply on HN