Instant.page
instant.page
instant.page
There are a lot of reasons that this software is "safe" but this absolutely isn't one of them and highlights to me as a potential user that you haven't thought through your thread model. The subresource integrity line should absolutely be the headline here.
One thing you may have meant by "serverless" is that you don't use a database / don't collect data on users. This is another angle you might want to use to highlight the safety of using your service.
What if someone modifies not only the script, but also integrity hashes in snippets on your site?
Defacing capability can be used to change the integrity hash—how it appears to the users (other developers) in snippets—to match maliciously modified script, making it trusted.
End developers using this library would thus, at their own accord, include URL to altered script and its hash in their pages by copy-pasting a snippet from the defaced landing page, satisfying browser integrity checks.
A subtle change like that is unlikely to be noticed by end developers, who would have to count on library site maintainers to have mechanisms in place to notice such an attack promptly and (perhaps more importantly) to not suppress the news about the incident.
Oh and guess what, not only there are servers, but other people can run code on the same server as your code is running. Doesn't feel as safe suddenly ;)
Alternative phrasing: "This is hosted on Cloudflare Workers, and Cloudflare engineers are probably doing a better job running my code securely than I would"
Agreed. I think "server-agnostic" or "server-oblivious" would have been a better name.
I golfed 1.2.2 down a long way, removing other configurability and functionality that I didn’t want; see https://news.ycombinator.com/item?id=23204741, part of the discussion a few months ago at https://news.ycombinator.com/item?id=23203658 (where there was much wringing of hands about the whole load-on-mousedown mess). 5.1.0 is 2,842 bytes, 1,169 gzipped; my version got to 981 bytes, 532 gzipped. At that point it’s almost certainly cheaper to inline it than to have it as an external script (though if your CSP has script-src excluding unsafe-inline, you’ll need to give it a nonce or sha hash if you want to do it inline).
Could you provide more context? Why is that catastrophically wrong?
I agree it was a bad decision to do that by default, but it's opt-in since 5.1: "Make triggering clicks on mousedown opt-in".
In general, it's 2020, and if every click on your site takes 5 seconds, something is very wrong.
Just look at its hover->click speed demo on the landing page. I'm getting 500ms+ if I click it casually like I do most links. All of that time could be spent loading the next page.
https://dev.to/ (blog platform) does prefetching to great effect.
The onus is on you to decide if this would create a bunch of false positive prefetches for your desktop users, like if your website was a bunch of densely packed links. You could also scope this to prefetch only a subset of links.
But your users deserve more deliberation over their UX than a kneejerk yay/nay.
Every page should load fast, obviously, but instantly means the data has to be prefetched and that's potentially a lot of data to download that the user might never actually need. That's a waste of everyone's bandwidth, especially on mobile. Pages that a user will view (eg first page behind a login), or that they're very likely to view (eg top result in a search), should be prefetched/prerendered but whether you should prefetch more than that requires thought and measurement.
Browser vendors should implement per-site traffic breakdown.
And if you read HN as much as I doing that could be gigabytes every day.
> it's 2020
Hmmm... I actually have stopped worrying about bandwidth completely in 2020. My home and mobile connections have virtually unlimited data. I cannot finish them if I tried. It's amazing to see tech like this that leverages the excess data I have and converts that into speed.
I think you mean "minutes".
Open the developer tools and prepare to be surprised how long the average site takes to get to the "everything loaded" state.
P.S. I'm only slightly exaggerating. There's an awful lot of bullshit being loaded behind the scenes on the average site. Good thing I'm not using a weak Internet connection.
<body data-instant-intensity="10">
It's already a static Jekyll-compiled site served from a CDN, but combined with other techniques, instant.page makes the site quite snappy. (We had the EasyList blocking problem described below, so we started bundling it into our own post-load JS bundle.)
Honestly, unrelated, but the biggest performance improvement for us has been to do server-side rendering of the LaTeX equations, rather than using MathJax client-side.
Back then the images really were the only big bandwidth hog.
RES for Reddit also has an option that preloads every post that shows on the page for instant loading at the cost of bandwidth (I had an increase of ~100gb for one month)
http://blog.moertel.com/posts/2005-10-25-google-web-accelera...
What makes Rails prominent in this was the creator of the framework blamed Google for their own bugs and told people to try to detect GWA to hide the links instead of telling people to follow the HTTP specification. People who followed his advice suffered the bug a second time, and people who ignored him and followed the HTTP specification avoided the problem.
I remember hearing several stories about employees getting reprimanded for accessing sites they never intended to visit.
I also know of a similar tail when a national football team had their DNS hijacked and visitors were served porn instead of sports news (also happened around 2000 sort of time)
> It wasn’t a problem everywhere. It was only a problem
> where people used GET in an unsafe way,
> which was a minority of sites.
Also a big discussion from last year: https://news.ycombinator.com/item?id=19122727
Some things to note:
- at it's core, this is using PREFETCH
- Safari at the moment doesn't support link prefetching, so this library doesn't work for Safari
- yes, it works on mobile and arguably people see even better results on mobile due to inconsistent network/latency of mobile networks.
An old HN discussion on the predecessor library:
This sounds great! I immediately wonder how many additional HTTPS requests will hit your web server fleet. Has anyone using this calculated a percentage of additional requests vs additional clicks from their http logs?
Drive-by downloads, malware, etc. I totally get the benefits of this mechanism until it starts being abused for tracking and delivery malware, and then add-ons will (hopefully) appear to block this.
The modern web is pulling in the background all the time.
You'd have to go back decades for 1 click to equal 1 GET.
I swear to God, so many HN comments just say "security nightmare" for everything.
Even with that extra server load we still saw improvements visitor performance as measuring using Real User Monitoring
Exact matches for instant.page found in:
- https://block.energized.pro/blu/formats/hosts.txt
- https://v.firebog.net/hosts/AdguardDNS.txt> it’s a theoretical minor violation of privacy
Their goal is to protect privacy. It makes sense to me.
I wish there was a way to easily override individual entries in easylist/ubo.
I can see how some website benefit from preloading everything, but if they should self-host the script (which won't get it blocked by EasyList) and leverage HTTP/2 Push to load the script in, instead of relying on an external domain that has full access to my IP and the URL I was visiting (through the Referer header).
To be clear, I have nothing against your project; it's just the centralized hosting that I don't trust. Unfortunately, you hosted the JS on the main page so the blocklist now also blocks your homepage; had you hosted the domain on a separate domain (cdn.instant.page) you wouldn't have had to deal with this. Because of the way links are generated, I don't disagree with the decision by EasyList though. Even if you did it by accident, you've created a tracker and that means you end up on tracker blocking lists.
I'd estimate it's roughly a 1% drawback.
That demonstration alone was enough to pique my interest and give this a try.
Min/avg/max of 10 taps, as fast as possible;
17/26.6/36 -- iPhone 6S
16/23.7/34 -- Pixel 2 XL
17/21.7/33 -- 12.9" iPad Pro
Mind that reducing (initial) page loads by a fraction will do the same for you and even more.
But isn't it dangerous? How does it know you re not preloading the "please delete everything" link?
It would be nice to have a standard html tag preloading="yes" so that one day browsers can have it as standard feature. I'd much rather have this than AMP
In a perfect world no-one would be using links for actions which modify state - they should always be a POST behind a button, not a GET behind a link.
But in the real world this is probably a legitimate concern. They do have methods to mark links as non-preloadable (https://instant.page/blacklist), but anyone using it should definitely do a thorough test, not just copy and paste and hope for the best
As a sibling comment points out, if it's possible for someone to delete everything via a link, your users have already lost. Someone could, e.g., trick your users into loading an IMG tag or an IFRAME pointing to that page, or give them a shortened URL that redirects to your "delete everything" page.
GET requests should never have side effects.
And my initial click, which was not attempting to use a long time, was about 69ms.
Hosting the script yourself is also possible. Download the latest version at https://instant.page/5.1.0 then add a module script tag just before </body>:
<script src="instantpage-5.1.0.js" type="module" defer></script>
https://w3c.github.io/preload/ https://caniuse.com/link-rel-preload
const prefetcher = document.createElement('link')
prefetcher.rel = 'prefetch'
prefetcher.href = url
document.head.appendChild(prefetcher)
Pre-loading with some third-party script as a magic fix for free milliseconds is something people should think twice about.
For as-fast-as-possible subsequent page loads, use preloading (à la instant.page) + light SPA. My previous library, InstantClick, did just that but it’s alas mostly just a proof of concept (lacks good docs), I intend to “reboot“ it this year and announce it on HN.
FANG websites aren’t a very good site speed standard. :)
From Pingdom's Washington DC test location, on this Axios page:
https://www.axios.com/tropical-storm-sally-forms-off-florida...
It rings in at 414ms, 1.9mb uncompressed (~1mb compressed), with a rather obnoxious 90 requests.
They're loading 961kb of script and 197kb of font content. A whole 41kb of actual HTML content in that obese vat of bytes.
On a small Quora page with no major images, they come in at 2mb of junk, 1500ms to load, with 79 requests.
A typical small Wikipedia page with one image will come in at 400kb-500kb and load in 400-500ms, with 26 requests.
GTMetrix lists the average load page size for their performance tests, compressed (!), at 3mb (with 89 requests). Framework bloat is like living on a sugar diet.
If you log the requests, you can see that they load everything from ampproject.org
I’d love to see a world where cloud computing / time sharing was tipped on its head and users and businesses could charge back their compute time spent running JavaScript trackers, analytics, etc from the sites their users visit. Of course this fantasy would never be technically possible but one can dream.
I can't find it now, but I thought there was an article recently that looked at page rendering times and how they have changed over the years (as bandwidth has also increased). In general, page rendering time hasn't decreased as much over the last few decades as you would expect, and a part of that is the amount of js (often for tracking - not to serve the user) that is pervasive nowadays.
I agree that the latter is a problem with many modern websites. That, however, does not mean that this approach does not have a place; many people (especially people among the HN and HN-adjacent crowd, who tend towards simple layouts and static site generators) optimise their sites as much as is reasonably possible, and specifically, don't pessimise their sites with megabytes of tracker & ad scripts. For those people, instant.page might well be a worthwhile optimisation.
Different tools for different projects. Gatsby and Gridsome, or any other static site generator is not comparable to a simple script like this.