81–90 of 361 posts
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…
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…
Any companies with such onerous policies could block sites like instant.page at the firewall.
I mean that firewall was used to track every website you browse and other evil stuff.
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.
No! You should NEVER load javascript over https on a page that was served over http. It gives a false sense of security that doesn't exist. Because the source page was served over http, the source page can be modified by an attacker, making the script be loaded under ssl makes you think its protected. But its not since an attacker could just modify the script tag to remove the https bit in transit then modify the scr…
Does it help much? No. Should you use it? Yes.
Is this a re-rebranding? I remember using something similar 4-5 years ago (instant.js/instantclick). But quite an interesting little thing, especially useful for older websites to bring some life into them. The effect is very noticeable.
1) What, if anything, is the downside here?
2) Is (Google) analytics effected by the prefetch? That is, does that get counted as a page visit if the link that triggers this prefetch is not actually clicked?
Tia
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…
Jesus. I hope they pay you well for that. I've heard a lot of stories of ridiculous rule-by-HR culture, but that's so extreme it sounds made up.
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…
Jesus. I hope they pay you well for that. I've heard a lot of stories of ridiculous rule-by-HR culture, but that's so extreme it sounds made up.
The other part about log analysis seems crazy, though, I agree with you on that.
Earlier quoted context omitted.
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.
Good point. What would be a good way to avoid prefetch requests in your analytics if you only derive analytics from server access logs?
I looked (quickly) through most of the comments below and couldn't answer these questions: 1) What, if anything, is the downside here? 2) Is (Google) analytics effected by the prefetch? That is, does that get counted as a page visit if the link that triggers this prefetch is not actually clicked? Tia
Client-side analytics like GA aren’t affected.
Earlier quoted context omitted.
There's nothing stopping GET requests from having side effects. It's like pointing to a list of best practices and saying "everyone surely follows these." For example, someone changed their signature to `[img]/logout.php[/img]` on a forum I posted on as a kid and caused chaos. The mods couldn't remove it because, on the page that lets you modify a user's signature, it shows a signature preview. Good times.
> There's nothing stopping GET requests from having side effects. > It's like pointing to a list of best practices and saying "everyone surely follows these." It’s not a ‘best practice’ it’s literally the spec for the web.
Browsers take a more practical approach than "well, it's in the spec, they should know better" which is apparently what you're suggesting.
It's the same reason browsers will do their best to render completely ridiculous (much less spec-complaint) HTML.