4 ms·
My first impulse was to disagree with you, but I realised I gave the exact same advice as a consultant to a group managing one of the bigger government websites
by jiggawatts 4y ago
My first impulse was to disagree with you, but I realised I gave the exact same advice as a consultant to a group managing one of the bigger government websites that had some performance issues.
They wanted to paper over the issues by slapping a CDN in front of the site. Their users are all local, so the global aspect of the CDN wasn't the point, the benefit was that it would cache the content and provide a performance boost.
I told them that, yes, a CDN might help, but they should optimise their site first, and only then add a CDN on top if they really need to. Otherwise they'll just mask their issues. It's too easy to end up with queries that take 1 minute but are cached for, say, 1000 separate users. Most people most of the time will have a good experience, but you'll end up with a hideous 99th percentile that will be really hard to detect and fix.
- youngtaff 4y agoI’d often take the opposite approach (and have done with consulting clients) Slap the CDN on the site and then chase down the slow server responses It delivers an improved experience for the people using the site sooner than optimizing the site first The challenge of course is you then have to persuade people to go chase down the slow responses when they may response “there’s so few why should I care?”
- hinkley 4y agoFrom a web standpoint I reminded them that the browser already has a cache so you would be better off getting your cache semantics clear first, debug it at the client and then infill later if and as necessary.