Why to use Twitter, Facebook and Google Plus share links and not buttons | Hacker News Reader

Why to use Twitter, Facebook and Google Plus share links and not buttons

garron.me

100 pointsg-garron63 comments

If you still like the idea of buttons, but don't want to give up using the vendor-supplied buttons themselves, you can use the "two clicks for more privacy" jQuery plugin[0], which only loads the actual button when the user enables it by clicking a greyed-out placeholder.

[0] http://panzi.github.io/SocialSharePrivacy/

Nice. thanks.

I'm also partial to Socialite JS [0] - it provides a similar mechanism, the one I use is the hover option, this negates the need for clicking which I think would confuse some users.

[0] http://socialitejs.com/

I use WidgetBlock for chrome and since then sites have been blazing fast. I mean it really helps to not have all those stupid share widgets load. It does however break all the share buttons.

So using links instead of the widget codes is better for your site (performance wise), privacy wise, and it degrades gracefully when people like me use Widget Blockers.

I don't have an opinion on the core of the article, but this bit at the end is not the best advice from a user experience standpoint.

"And I am seriously thinking into serve my own copy of Twitter Bootstrap scripts instead of serving them from the Google Network."

The point of using a CDN for common js/css is to serve it as close to your users as possible as well as increase the change that they already have it in their browser cache. Hosting it yourself just means your users have to make more round-trips to wherever in the world your server lives.

BTW, Google Hosted Libraries doesn't currently include Twitter Bootstrap. You're using NetDNA's BootstrapCDN.

Sorry, you are right. it is NetDNA's

From the performance point of view is better to use that public CDN. But they have control over the javascript, and they may change it at anytime. Maybe too paranoid, so just thinking about it.

If you're that paranoid, it probably wouldn't be hard to set up a simple cron job that downloads the CDN's copy and compares its hash against a known local copy on a regular interval.

but the CDN provider might 'fingerprint' the script based on IP/frequency/headers etc and always return one version, whilst returning a different version to others... ? ;-)

There's no guarantee that the cron script and the end user would be getting the same data. So that's not really much help.

I tried to use Google's AJAX CDN (because I was thinking the same thing you are) and have been burnt several times because of it. Occasionally, it won't serve your js files, leaving users with an indefinite 'Waiting on ...' message or a partially rendered and broken page. It's fixed if they refresh. If you use your own server, at the least there's a connection already established and the JS files will be served. My suspicion is that Google is prioritizing other traffic, and the free AJAX CDN is low on the list of services that should work flawlessly.

Facebook has stated that the sharer.php is deprecated. https://developers.facebook.com/bugs/252983554810810/

It appears to have an unclear lifespan. While it has been fully replaced by the Feed Dialog, it's still working now and is used all over the internet. I can see the case where it won't see any further development or features, but it's a tough call whether or not to incorporate the deprecated method or accept possible risks of the current methods - Like button or Feed Dialog.

You can fairly easily use /dialog/feed "manually" instead of sharer.php if you're worried about the latter's lifespan – you just need to set up an app for your domain first since "app_id" is a required param (and also "next", which is a redirect URI on the same domain). Example: http://antiprism.eu/en#share

The bug you referenced is from over a year ago and in fact the feature is no longer deprecated. The documentation page [1] used to highlight the deprecated status but has recently been updated and any mentions of deprecation have been removed.

[1] https://developers.facebook.com/docs/reference/plugins/share...

Interesting, thanks for the link. When I implemented a share in an app recently, this wasn't an option. I wish there was more version information on the page. The only reference to a timestamp now is that this page was updated a week ago.

We've been using the same method for quote some time now. Not just for privacy purposes, but also performance-wise all these scripts and iframes are a bit much. Demo and code at http://simpleshare.schuttelaar.nl/

You are right. The web today is full of scripts and is slow sites.

Mmm, I've been in situations before where marketing absolutely insist on packing the page full of sharing widgets, and it has a horrible impact on clientside performance.

Those networks can still track user habits by clicking the URL. In one acorn, they will know they came from your site, any user agent information, screen size (via JS on the social network site), if they are logged in they will associate them going to your site even if they decide not to share the URL.

The only thing they aren't seeing is additional analytic data they're missing out by not having there JS installed on your site, but its still enough data that they can use on there end for targeting advertisements which is what they are using this data for.

:( At least I am trying to do my part. And that is the only thing I can do.

>> Those networks can still track user habits by clicking the URL.

Isn't that kind of the point though - if I don't click the URL then FB/Twitter/G+ etc etc don't get notified of my visit to a third party site that includes their buttons. If I do, fine, I'm going there and they get the info, but usually I don't.

But only the habits of people who "like" the page, not the habits of every facebook user who merely /visits/ the page

I've recently done this on some client sites - it's far neater than including several sets of js each loading their own support libraries etc. The main reason for doing it was speed (each button makes several requests for js and assets), but it does also obviate serving multiple third-party js files, and protects your users from tracking by Facebook etc. which some of them won't be keen on. It's a shame that FB, Google etc insist on hosted js - a nicer solution would just be a link around one dynamically generated image showing the user the same information, though I guess that could still be used for limited tracking by IP.

After trialling the standard js we decided to forgo the dynamic buttons for speed, security and the privacy of our users and use locally hosted images of the buttons or logos with a simple link to the social site. For the readers it's very similar experience, but a much faster solution.

This seems like a great time to plug RequestPolicy:

"ReuestPolicy is a Firefox extension that improves the privacy and security of your browsing by giving you control over when cross-site requests are allowed by webpages you visit."[1]

It is even better if you pair it with NoScript.[2] Whenever I toy with the idea of switching to Chrome I am always end up sticking with iceweasel because of the lack of equivalent RP+NS functionality in Chrome. If you are currently using ghostery I highly suggest you switch to RP+NS.

[1] https://www.requestpolicy.com/index.html

[2] http://noscript.net/

I used to use RequestPolicy and thought it was great and did what it said it would. But it broke a lot of things like buying something on Newegg. I was afraid to allow something and try again thinking I would be charged twice.

Ghostery, while not as strict seems like a nice compromise. My mom uses it and she doesn't even notice it.

I think ghostery is probably the better choice for non-tech folks. You are a better son than I am, I should install ghostery or my mother. For people with a little time and basic knowledge of how the web works I think NS+RP is the way to go.

I've tried noscript and it breaks most things. Ghostery quite rarely breaks things.

There are two schools of thought for privacy enhancing technologies. The ghostery model is to try not to be disruptive and to ask as little as possible of the user. No script takes the other approach which is a "default block" and require the user to whitelist sites that she needs to work.

Right, and that will break a majority of websites out there, because they sniffed a fully capable desktop browser but the JS they sent as a result of the sniffing failed.

Default block doesn't work.

I completey agree. Default block does not work for a userbase that does not have the time or inclination to read the documentation and configure it to meet their needs.

This is a great write-up with a simple solution - one that I recently realized that I needed.

I put the AddThis button block on some of my article pages at the beginning of May. I was getting less click-throughs to my product page, so I started looking into possible causes. The Site Speed reports in Google Analytics showed that my page load times had increased 2-3x. I profiled some of the slower pages and found that the AddThis external call stack can be pretty deep. After removing them, everything's nice and speedy again, and click-throughs are back up to normal levels.

And for share counts https://gist.github.com/jonathanmoore/2640302

I actually agree with this article...from an optimization standpoint. Whenever I've had to integrate paypal, youtube, or even coinbase...I always add the images to my static sprite sheet (to reduce http requests), and will serve a post href link...instead of button code suggested.

Even before the whole tracking was exposed, I always hated paypal's 1px blank gif that is integrated in their button code.

I made a similar article recently. I provide a complete block which you could copy/paste on your website directly. It uses javascript to create the right link using the current url.

http://yannesposito.com/Scratch/en/blog/Social-link-the-righ...

Another note: you can create realistic share buttons by fetching the Like counts via JavaScript.

I run that on my own website and it works well.

Can you give me your website url, please?

In his profile - minimaxir.com

Whoops, it's in the profile. Sorry about that. (last time I linked directly to my website in a HN comment as an example of the implementation it was accused as self-promotion.)

It's not super advanced JS but it gets the job done.

Just wanted to chime in with my 2 pennies to say I agree 100% with this article.

My feeling is that if social interaction is core enough that it needs to appear on every single page of your site (or at least on core, highly trafficked pages) then the common way of doing this sucks on two levels;

1) Depending on other websites to load content? Madness.

2) Depending on JavaScript to execute core functionality? Pointless.

I have solidified my thoughts better here: http://tosbourn.com/2013/01/development/replacing-social-med...

I have also written up how you can get the functionality without the JS in this github repo https://github.com/tosbourn/nojs-socialshare

I love how security expert Bruce Schneier (https://www.schneier.com) has implemented it. This also gives you an ability to see how popular an article is (based on the sharing numbers) if you want, which is another purpose these widgets serve.

There is one downside to share links vs. buttons: visitors can't see how many times the page has already been shared.

At https://starthq.com we've opted for a half way solution by confining the share buttons to individual iframes. This way we don't prevent the tracking, but do contain their ability to break our page or grab users' data.

In regards to not tracking users...integrating a http request to Google for JQuery, is still tracking users.

I always find this ironic about these articles don't track your users, or prism is watching, let's use mailvelope, some of these pages that is promoting privacy, integrates google analytics, have a share button, or some type of off server request.

That is why I said, I am thinking about not serving scripts from CDNs, at least not from public CDNs.

The Google CDN serves its scripts from a cookie-less domain and with an aggressive far-future expires header. Best case, a given user may only need to make one request to Google per year for a given script, and even when they do there aren't any tracking cookies to make that request worth much at all in terms of tracking. You're right that Analytics isn't great for privacy, but their AJAX Libraries CDN is configured in a diametrically opposite way.

It occurred to me yesterday how powerful Twitter must be. They must have a good portion of most peoples' web histories, which could sell for a lot in certain markets. This is all just wild speculation, but I also wonder if they made a data-sharing deal with CNN, given CNN's constant Twitter promotion over the years.

The discussion is also relevant for sharing widgets (addthis and friends). If anyone is interested, I wrote about their behavior and how to circumvent them: http://www.j-ro.me/nixing-the-dataholic-sharing-widgets.html

Your Facebook button says "Like", but it's a share. There's no liking involved.

Thanks, changing it now.

Now its not clear what the button does. Why not brand each link to match its respective network?

Edit: Your WordPress permalink code looks fine by the way.

In other words it's not buttons in and if themselves that should be avoided (according to the author) but pulling in the widgets from FB, Twitter and G+. You can host the same buttons on your end (really just a picture with a link)

This is about the way I see it these days. Pulling 2, 3, up to 5 outside scripts via sharing widgets is just too much. Much snappier to skip and just link out as the example shows.

"and thus giving them the possibility to track your visitors"

This is an understatement. There's no reason for them not to do it - it's fodder for them.

An implementation that uses image maps without scripts:

http://www.strchr.com/share_buttons

Thanks.

This applies to usage of Google Fonts as well, isn't it? Similarly, Adobe gets the hold of site visitors via use.typekit.com

http://sharrre.com/

The links to Facebook/Twitter/etc. should best be HTTPS, I think.

Thanks for the advice. I will change them later.

I agree and have been replacing share buttons with an icon an link also

A small typo in the title: Javascript and not java script.

Which title? Anyhow, it's "JavaScript" with a capital 'S'.

The title here in HN. It was originally "Don't expose your visitors to tracking. Use share links instead of Java scripts"

It was then edited (by a moderator I assume) to reflect the actual title of the post.

...and find your click rates plummet.

Which is fine if you're OK with that cost. But a lot of users aren't going to notice those links, let alone select them, copy them and paste them.

If I already have to copy and paste a link, why not the actual page URL?

Why wouldn't users be able to click links? He is simply providing URLs for popular social sites that can be used in link hrefs to share the page being viewed. Ie,

http://facebook.com/sharer.php?u=http://url-of-the-post

You use this to make regular links that users can click, instead of buttons loaded inside iframes, etc.

Reply on news.ycombinator.com