171–180 of 361 posts
I'm curious how this is better than Google quicklink ( https://github.com/GoogleChromeLabs/quicklink ) which is something I have active on my site currently. Can someone with more technical knowledge point out which of these two "instant pages" solutions is better?
I've been testing it for the past 30 minutes or so and found that it doesn't cause the same problems that InstantClick did. (Which was javascript errors that would randomly occur.) I'll limit it to a small subset of users to see if any errors are reported but there is a good chance this could go live for all logged in users. Maybe even all website visitors if all goes well. Seems to have no impact on any javascript,…
Earlier quoted context omitted.
Idempotency is not the issue, the issue is that a user might hover over the logout link, not click it, then move on to the rest of the site and find they are logged out for no reason.
That's exactly the problem with idempotency.
Nice idea for HTTP/1.x, however, isn't this what HTTP/2.0 [1] is meant to achieve by pushing components at the user? 1: https://en.wikipedia.org/wiki/HTTP/2_Server_Push
Many people browse the web from an employer who has rules about what types of pages may be accessed. For example, a person applying for a job with my team may include a link to a web page about their job-related background -- portfolio.html or whatever. HR tells us to be sure we don't follow links to any other page that may be more personal in nature, such as a page that reveals the applicant's marital status (which…
If your company is doing that, then do not browse on company time and/or using company equipment at all. Ever. They obviously don't (or for regulatory reasons, can't) trust you, so you should treat them as an adversary for your own good.
Remember: HR exists to protect the company, not the employees.
Each time you hover over a link it's doing a GET request bypassing the cache (cache-control: max-age), even if you hove the same multiple times. Also this will make all your analytics false... Except that indeed this can improve greatly the user sensation of speed
The analytics should only be triggered is the page is rendered, assuming it's done client side. I believe Google does this for first top 3 results if I'm not mistaken.
Earlier quoted context omitted.
> Just make sure you apply the data-no-instant tag to your logout link, otherwise it'll logout on mouseover. Logout links should never be GETs in the first place - they change states and should be POSTs.
POSTs are not Links. And Logout service is indempotent even if you can consider it changes the state of the system
Embedding via // without explicit SSL should probably be considered harmful or malicious as there is no reason to make such scripts available without SSL. Even if the end website is not using SSL users can still fetch your script securely.
Considering a user hovering over a bunch of links and then clicking the last one, and doing this in a second. Let's assume your site takes 3 sec to load (full round-trip) and you're server is only handling one request at a time (I'm not sure how often this is the case, but I wouldn't be surprised if that's the case within sessions for a significant amount of cases). Then the link the user clicked would actually be loaded last, after all the others - this probably drastically increase loading time.
The weak spot in this reasoning is the assumption that you're server won't handle these requests in parallel. Unfortunately I'm not experienced enough to know whether that happens or not, but if so, you should probably be careful and not think that the additional server load is the only downside (which part like is a negligible downside).
Embedding via // without explicit SSL should probably be considered harmful or malicious as there is no reason to make such scripts available without SSL. Even if the end website is not using SSL users can still fetch your script securely.
There’s no security gain from going to HTTPS if the site is served over HTTP, but there’s a small speed hit.