41–50 of 110 posts
I kind of wish the whole web worked that way. Yahoo was like that in the old, old days (akebono.stanford.edu).
Earlier quoted context omitted.
Pretty close! We don't actually use GeoIP at the DNS level, we use the routing table of the internet to direct people to the closest location we have to them by announcing the same IP addresses in the routing table in many places (eg, anycast) You can find a blog post primer and general more explanation here: https://blog.cloudflare.com/cloudflares-architecture-elimina... the upshot of this is that TCP and SSL connec…
Awesome, thanks for the additional info. On a related note, I really appreciate how good CloudFlare is about knowledge sharing. Not a lot of companies would be so willing to share information that's so integral to their business.
http://tools.pingdom.com/fpt/#!/cnYAuq/https://news.ycombina...
5 requests, Total size 12.6kB, total time 661ms. 1 request for the content, 1 for css, and then 3 gifs, all from a single domain (so just one DNS request). If you look at the profile, 47% of the time was spent doing that one DNS lookup, so subsequent requests will be even quicker (plus caching will handle those gifs just fine)
That's almost no work for the end client to do. No javsacript for the client to download, parse and process, just straight content to render and done.
The reduced request count is especially important when it comes to the mobile experience, where bandwidth might be great, but latency is terrible. Every request you have to make to render a page significantly impacts the loading time (HTTP2 helps here). Along with trying to reduce the number of resources being loaded on the screen, it's especially important to reduce the number of domains you're getting them from so you keep the DNS queries down.
Loading this webpage I downloaded ~12KB. For comparison, I went to the NYT homepage and downloaded ~1.2 MB. For people with shitty downlinks like you and I, the absence of exorbitant quantities of Javascript and images makes a lot of difference - a lot more than time-to-first-byte.
that 1.2Mb gets cached. Infact that will make the site faster because once the .js are downloaded only json/partials will be fetched when visited again. It must be the backend ,ie when tasked to render the same page ,which backend would respond faster
Client-side caching is a nothing but a lie bad front-end developers tell themselves to justify producing bad websites.
Server-side is a different beast than the whole server->client part. HN does not load particularly fast for me, 300-500ms is fairly slow.
Same for me. I don't think HN's particularly fast. Barely faster than rockpapershotgun.com, which has lots of images, but not much. Given that it's all pure html text, I would expect more. RPS might have better caching that's closer to me though.
rockpapershotgun.com takes 10 seconds to load entirely and serves 1.6 MB of data. Which is OK compared to others Like Polygon and Co which serve more that 5MB on their homepage and take 20sec to load on average.
Earlier quoted context omitted.
That's impressive. What is their architecture?
http://forum.dlang.org/help#about says > This website is a web frontend to the DigitalMars NNTP server and mailing lists. It is part of DFeed, which is also a D news aggregator and IRC bot. > DFeed was written mostly by Vladimir Panteleev. Portions (including style and graphics) are Copyright © by Digital Mars. The source code is available under the GNU Affero General Public License on GitHub: https://github.com/Cybe…
With an empty cache, every asset except font awesome is getting to me - here in Poland - in under 200ms, with some under 150ms.
For 22 requests - even with a total payload of "only" 155kb - whether static or not, that is seriously impressive.
Most development practices considered "modern" prevent progressive rendering. Common tools like Bootstrap or Jquery, as normally used, cause page rendering to block until large libraries are downloaded, despite the fact that only a tiny portion of bootstrap or Jquery are actually used by the page.
The largest reason of all is that most developers dismiss such concerns as old school worries and like to harp on and on about how tools like Angular enforce wonderful software engineering practices, ignoring that most such frameworks, as commonly used, bloat pages and cause incredible rendering delays.
The difficulty with improving performance is that most "modern" pages have numerous render-blocks. The page doesn't get fast until you fix all of them. This is the reason most wise suggestions to speed up a page make little difference when tested individually.
I found that HN became much more performant for me when I got above 500 karma points.