10 ms·
but we can already make web pages load 500% faster by not shoveling a ton of shit, not loading scripts from 60 third-party domains (yes stop using CDNs for jQue
by leeoniya 10y ago
but we can already make web pages load 500% faster by not shoveling a ton of shit, not loading scripts from 60 third-party domains (yes stop using CDNs for jQuery/js libs, those https connections aren't free - they're much more expensive than just serving the same script from your existing connection), reducing total requests to < 10, not serving 700kb hero images, 1.22MB embedded youtube players [1], 500kb of other js bloat, 200kb of webfonts, 150kb of boostrap css :/
the internet is faster than ever, browsers/javascript is faster than ever, cross-browser compat is better than ever, computers & servers are faster than ever, yet websites are slower than ever. i literally cannot consume the internet without uMatrix & uBlock Origin. and even with these i have to often give up my privacy by selectively allowing a bunch of required shit from third-party CDNs.
no website/SPA should take > 2s on a fast connection, (or > 4s on 3g) to be fully loaded. it's downright embarrassing. we can and must do better. we have everything we need today.
[1] https://s.ytimg.com/yts/jsbin/player-en_US-vfljAVcXG/base.js https://s.ytimg.com/yts/jsbin/player-en_US-vfljAVcXG/base.js
- deleted 10y ago[deleted]
- kup0 10y agoYeah the problem really isn't the technology, it's our poor use of it.
- visarga 10y agoSome files could be hashed and cached locally, such as jQuery files and fonts. I don't know why we have to load it every time from the web, it's the same library for a large number of sites. Just add a hash tag in the <script> to make sure it's the same file.
- manarth 10y agoWhen JQuery is served by the official CDN, it's given a cache-header giving it a lifespan of 10 years.
- leeoniya 10y agothe bandwidth isnt the problem. your browser still has to make the https connection to the cdn and request the file with a Last-Modified or Etag header so the server can return a 304 Not Modified response. This is the real cost, not the download size itself. I'm not sure how often browsers choose to do this, but if you refresh a page, they all will.
- manarth 10y agoIn general, browsers shouldn't even revalidate the file as long as it's younger than the max-age lifespan. They may choose to "evict" it from the cache, but that's generally based on a policy of recent usage and needing to free up/prioritise disk space for more recent assets. I'm now interested to see how different browsers handle refresh/force-refresh - whether they revalidate a file that's still considered fresh, and whether they set request-headers to bypass upstream caches too. Maybe an experiment for the xmas holidays :-)
- leeoniya 10y agolast time i tested this was a couple years ago. i could not find a reliable way to make the 304 requests disappear using any available cache-related headers :/
- renke1 10y agoThere is also Cache-Control: immutable [1] which prevents browsers requesting the given file even when the site is refreshed. It's experimental though. [1]: http://bitsup.blogspot.de/2016/05/cache-control-immutable.html http://bitsup.blogspot.de/2016/05/cache-control-immutable.ht...
- manarth 10y agoCurrently only supported by Firefox (as of 49.0), according to Mozilla [1]. Interestingly, it's being used by the BBC [2], who have reported a 10.8% reduction in 304 responses as a result [3]. Google have also stated their intention to use it (comment 11 in the same Chromium ticket). [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ca... [2] https://mybbc.files.bbci.co.uk/notification-ui/2.6.8-mvt//svg/setting.svg https://mybbc.files.bbci.co.uk/notification-ui/2.6.8-mvt//sv... [3] https://bugs.chromium.org/p/chromium/issues/detail?id=611416 https://bugs.chromium.org/p/chromium/issues/detail?id=611416
- syphilis2 10y agoThis is only slightly related, but I've noticed HN comment pages take a second or two to load when there are many comments (500+). Page sizes are not unreasonable (100-200 kb). What is the cause for these pages loading so slowly? Example 900+ comment page: https://news.ycombinator.com/item?id=11116274 https://news.ycombinator.com/item?id=11116274 Example 2200+ comment page: https://news.ycombinator.com/item?id=12907201 https://news.ycombinator.com/item?id=12907201
- deleted 10y ago[deleted]
- yellowbeard 10y agoThe server is taking a long time to render the response. In the first link, 650ms or so. Open the network tab in your browser developer tools to see the details.
- icebraining 10y agoSlashdot's solution to this was to render the HTML on write, instead of on read. Whenever someone posted a new commend, a static HTML file would get generated, so that it could be rapidly served to readers. Movable Type works (can work?) much in the same way, though for blogs. I know that caching achieves a similar result and is an accepted component of a modern architecture, but I wonder if we wouldn't be better served by implementing these sort of "upfront caches" in more software.
- manarth 10y agoWhenever someone posted a new commend, a static HTML file would get generated It's essentially still a cache, with the same concerns/issues - mainly cache invalidation - as a HTTP cache. An on-disk cache of that sort has other issues though. For example, what if a request is received whilst the file is being written? Does the system deliver a half-written HTML page? You can introduce locking or atomic file operations (write to a temporary directory, then mv the file into the correct location: mv is an atomic operation), but this adds more complexity to the cache logic. One of the benefits of a HTTP cache is that they generally have a default graceful failure mode: if the cached data doesn't exist, request it from the backend application server.
- Animats 10y agoRight. CNN now has over 50 trackers and other junk blocked by Ghostery.
- EGreg 10y agoOne gripe: the canonical CDNs may have the library already cached from your visits to other sites, which is faster. I wish that web browsers would use content addressing to load stuff and do SRIs. If I already loaded a javascript file from another url, why load it again?
- leeoniya 10y agohttps://thethemefoundry.com/blog/why-we-dont-use-a-cdn-spdy-ssl/ https://thethemefoundry.com/blog/why-we-dont-use-a-cdn-spdy-...
- inian 10y agoThat is too big of a breaking change to do on the current web. There is a whole new initiative for that though - https://ipfs.io/ https://ipfs.io/
- chrisfosterelli 10y ago> stop using CDNs for jQuery/js libs, those https connections aren't free - they're much more expensive than just serving the same script from your existing connection Do you have a source for this? My understanding is that, in real usage, it is cheaper to load common libraries from a CDN because in a public CDN (for something like jQuery), the library is likely to already be cached from another website and has a chance to even already have an SSL connection to the CDN. Obviously 60 separate CDNs is excessive, but I don't know if the practice altogether is a bad idea.
- leeoniya 10y agothis has been true in my own testing (with plain SSL/TLS, not even SPDY/HTTP2/QUIC), but you can read another analysis that reaches the same conclusion here: https://thethemefoundry.com/blog/why-we-dont-use-a-cdn-spdy-ssl/ https://thethemefoundry.com/blog/why-we-dont-use-a-cdn-spdy-... another important reason i personally don't use CDNs is the privacy of my users.
- supergreg 10y ago>another important reason i personally don't use CDNs is the privacy of my users. How high up the privacy concern is using a CDN vs having cloudflare in front of you or everything being in AWS or using a browser by an ad company?
- leeoniya 10y ago> having cloudflare in front of you or everything being in AWS sure, sometimes it's unavoidable when there is real value added in using these platforms. at the end of the day most of us have to entrust our infrastructure to some hosting provider. I trust a provider I pay (with a known privacy policy) more than a public CDN (with a privacy policy that allows them to make money in unspecified ways) but yes, centralized ssl termination for distributed systems is an issue that's difficult to mitigate WRT privacy. maybe via https://en.wikipedia.org/wiki/Multipath_TCP https://en.wikipedia.org/wiki/Multipath_TCP ? i don't know enough here. > using a browser by an ad company this is up to the user
- lostboys67 10y agoTestify Testify Brother Testify!
- Ntrails 10y ago> 1.22MB embedded youtube players A guy who I used to post with wrote a new forum for us all to post on (woo splinter groups). It's pretty cool. One of the things it does is serve a static image of the underlying youtube and then load it on click. When a 'tube might be quoted 7 times on a page - that's a pretty useful trick. I'd just assumed this was a standard forum feature and then I opened a "Music Megathread" on an ipboard and holy shit loading 30 youtube players was painful.
- leeoniya 10y agoyes, you can lazy-load the youtube player, there's also a jquery plugin for it [1]. but this setup requires 2 clicks to play on mobile (because google restricts the player from autoplaying onload in mobile devices due to bandwidth/data-usage concerns). the first click will appear to do nothing as it loads the 1.22MB player, so delivers a crap experience. you're much better off just serving an html5 <video> tag. you can likely fit your entire video in mobile quality in that 1.22MB :D [1] https://github.com/tylerpearson/lazyYT https://github.com/tylerpearson/lazyYT
- keypress 10y agoBack in the day we'd try and get page sizes down to less than 100k. The Internet isn't fast for everyone. I (in the UK) have no 3G signal, let alone 4G and my broadband speed is pitiful - but it will do. There is nothing I can do to ramp the pipe speed up. I do end up turning off JS and images a lot of the time, because otherwise it ills me. As a web dev, I don't care for bloat. So I find it particularly irksome, and currently it's enough to deter me from going mobile. Once I'd have dreamed about having a modern smartphone in my pocket with any Internet connection, but the friction currently today puts me off. The UK was recently slammed for its retrograde networks.
- jaclaz 10y agoAn IMHO interesting unit of measure is the DOOM(s), JFYI: https://twitter.com/xbs/status/626781529054834688 https://twitter.com/xbs/status/626781529054834688 As in "my site homepage is less than 1 Doom" or "that crappy site is more than 3 Dooms" ...
- jiehong 10y agoIt's more general than just webpages, but applies to everything under the name “Jevon's Paradox”(https://en.wikipedia.org/wiki/Jevons%27s_paradox https://en.wikipedia.org/wiki/Jevons%27s_paradox). Basically: more power -> more resources can be analysed in the same time, and not faster to answer.
- roryisok 10y ago> literally cannot consume the internet without uMatrix & uBlock Origin hear hear. and on mobile, its painful because I can't have those (windows phone at least). planning on buying a DD-WRT compatible router soon so I can do some kind of router level ad-blocking and let me browse on the phone again PS: opera mobile for android has a built in adblocker
- leeoniya 10y agoyep, i use opera mobile and also am rooted so use a hostfile blocker (AdAway). uBlock Origin exists for Firefox Mobile btw, but i prefer opera's speed/ui.
- nattmat 10y agoA Raspberry Pi running Pi-Hole is what you want. https://pi-hole.net/ https://pi-hole.net/
- roryisok 10y agoOk, that's even better. I can get a pi for less than a new router, build my own case. If only my router had a usb port, I could even power it off that
- supergreg 10y agoI use uBlock in Firefox for Android. There's also AdAway to block domains in the /etc/hosts file.
- neurostimulant 10y agoOr just configure your router to use an ad blocking DNS (host your own or use one of those public DNS servers). Works with any router as long as it allows you to edit the default DNS config. This helps a lot when browsing on home wifi connection. Too bad you can't edit DNS config on mobile device without rooting/jailbreaking.
- zeveb 10y agoThis, this, a thousand times this. There's a site I read, really like and financially support, but which has some pretty terrible slowness & UI issues. It's so bad that they've started a campaign recently to fix those issues. But when I check Privacy Badger, NoScript and uBlock, there's a reason that it's so terrible slow: they're loading huge amounts of JavaScript and what can only be called cruft. Honestly, I think that they'd come out ahead of the game if they'd just serve static pages and have a fundraising drive semi-annually.
- amelius 10y agoActually I don't even read the articles anymore when on mobile. I just use HN, and hope somebody posts a TL;DR, or some relevant comment that gives some more information about the article. Only if this is not the case will I consider clicking on the article link. It's pretty sad actually. I secretly wish there was some way that allows us (as a community) to collaboratively "pirate" articles, perhaps as a torrent (IPFS perhaps), so we only have to download the ascii text.
- patrec 10y agoTry turning off javascript in your main mobile browser (e.g. safari) and turning it on in your secondary one (e.g. chrome).
- acdha 10y agoI use Brave as my primary mobile browser because it allows me to have JavaScript disabled but trivially enable it when I need it. The experience is massively better – on LTE the average page load is under a second except maybe for a video or lots of images, and you avoid all of the user-hostile pop-ups, app nags, etc. (I subscribe to most of the sites which I read regularly so I don't feel guilty about blocking ads but I really hope someone successfully makes a Google Contributor-style network where a trusted browser serves only static image/text ads, as much resistance as that will trigger)
- Pete_D 10y agoI usually only see lynx and friends mentioned as jokes, but 'elinks --dump <url> | less' really can be a huge readability improvement for some articles.
- pjmlp 10y agoThe browsers should have stayed HTML/CSS but then someone had this idea to try to compete with native applications....
- leeoniya 10y agobut they can compete when written properly, at least for business/productivity apps. though not for anything requiring direct hardware access, AAA games included.
- jasonkostempski 10y agoI sort of agree, i just think JS and content from other domains should have required user prompts.
- leeoniya 10y agoand https by default should have never allowed off-domain or insecure/mixed content.
- jasonkostempski 10y agoWe can dream but, even if it had been that way, I suspect it would have taken just one bad browser (probably IE) to ruin it for everyone. They'd advertise it as "no annoying prompts", everyone would flock to it and other browsers would have to follow.
- endless1234 10y ago>but then someone had this idea to try to compete with native applications You say as if that's a bad thing. Just wondering, for instance, do you use some standalone maps software instead of Google/Bing/Openstreet/... maps?
- pjmlp 10y agoEver heard of GPS devices, mobile phones or tablets? I always use native software on my own computers, unless I don't have another option and have to go the web app instead. Same applies to projects I work on, if I am allowed to choose.
- hawski 10y agoI am with you, but I don't believe that this solution will be ever used by the majority of developers. Browser caches should be bigger. They also should be more intelligent. It does not make sense to evict a library from cache if it is the most popular library used. Maybe having two buckets, one for popular libraries and another for the rest. I think that it would help if script tag had a hash attribute. Then cache could become more efficient. But without the first part it would be useless. Example: <script src="https://cdn.example.com/jquery.js" sha256=18741e66ea59c430e9a8474dbaf52aa7372ef7ea2cf77580b37b2cfe0dcb3fd7> </script> Or different syntax (whatever I'm not W3C): <script src="https://cdn.example.com/jquery.js"> <hash> <sha256> 18741e66ea59c430e9a8474dbaf52aa7372ef7ea2cf77580b37b2cfe0dcb3fd7 </sha256> </hash> </script> I would like to make an experiment, but as I am not experienced with webdev as much, it could take too much time for me. Test all major browsers with fresh install and default settings. Go to reddit or other links aggregator and load in sequence several links in same order on every browser. Check how efficiently cache was used. I would expect that after 10th site is loaded nothing would remain from the 1st one. Even though the same version of some library and maybe even link to CDN was used. I am amazed how quickly fully static pages work even after I am on capped speed mobile connection (after I use 1.5 GB packet). EDIT: The most helpful thing would be to have good dead-code removing compilers for JavaScript.
- dchest 10y agoCheck out the list of security problems you'll need to solve to implement hash-addressable caching: Subresource Integrity Addressable Caching https://hillbrad.github.io/sri-addressable-caching/sri-addressable-caching.html https://hillbrad.github.io/sri-addressable-caching/sri-addre...
- jimlawruk 10y agoThe use of CDNs is not primarily for speeding up page load times, but rather to offload bandwidth from the web server. Low budget Web sites don't always have money for server farms and are severely limited by how much bandwidth they can serve. One post to HN can take them down. Free CDNs are the poor man's approach to this problem.