Xing Share Button und JavaScript

Martinus33

Lt. Commander
Registriert
Juni 2011
Beiträge
1.625
Hallo,
Xing ist für mich nicht ganz so wichtig.

Wenn aber das JavaScript beim Laden der Seite, auf der der Button eingefügt ist, noch in keinster Weise aktiv wird, sprich keine Ladezeit kostet oder sonstwie trouble machen kann, würde ich den Button wie vorgesehen einfügen. Andernfalls nur als Bildlink.

Der Code sieht so aus:

Code:
    <div data-lang="de" data-counter="no_count" data-type="XING/Share"></div>
    <script>
    ;(function (d, s) {
    var x = d.createElement(s),
    s = d.getElementsByTagName(s)[0];
    x.src = "https://www.xing-share.com/js/external/share.js";
    s.parentNode.insertBefore(x, s);
    })(document, "script");
    </script>

Wird da beim Laden der Seite irgendwas gemacht?
 
Seby007 schrieb:
Ergo: Bild reicht

Wie meinst du das? Dass die 9 Zeilen Code nur dafür sorgen, (erst) durch einen Klick des Besuchers das JS laden zu können, aber beim Laden meiner Seite noch gar nichts passiert?

Das Bild, sprich die Grafik-Datei wird mit dem JS irgendwie vom Xing-Server hochgeladen? Die Anleitung auf https://dev.xing.com/plugins/share_button/ spricht nirgends vom Hochladen des Buttons als Grafik-Datei.
 
Morgen!

Wenn obiger Code-Konstrukt einfach iwo auf der Seite ist (z.B. im header-Bereich), dann wird die externe JS-Datei beim erstmaligen Aufruf immer, also auch ohne gesonderten Klick, mitgeladen. Ab dem zweiten Laden wird die Datei aus dem Browsercache geholt.
Das Xing-Bild würde ich einfach auf den eigenen Server hochladen und normal via img anzeigen lassen.
 
Seby007 schrieb:
Morgen!

Wenn obiger Code-Konstrukt einfach iwo auf der Seite ist (z.B. im header-Bereich), dann wird die externe JS-Datei beim erstmaligen Aufruf immer, also auch ohne gesonderten Klick, mitgeladen. Ab dem zweiten Laden wird die Datei aus dem Browsercache geholt.
Das Xing-Bild würde ich einfach auf den eigenen Server hochladen und normal via img anzeigen lassen.

Hi (bin kein Frühaufsteher),

also beeinflusst es die Ladezeit meiner Seite. Ich kenne mich mit JS nicht aus, aber die Datei scheint ziemlich groß zu sein. Hat zufällig jemand Erfahrung mit dem Button und dessen Einfluss auf die Ladezeit oder kann man das einschätzen, wenn man den Code anschaut? Da ich noch am Basteln der Seiten bin, wäre ein Versuch bei mir wenig aussagekräftig.

Browsercache ist je nach Besucher und dessen Browser für alle möglichen Elemente einer Webseite aktiv, nicht speziell für so ein JS, und nur ggf. beim 2. Besuch. Von daher kein echter "Trost".

Interessant, dass Xing kein Wort über die Grafik-Datei verliert. Ich sehe auf der Xing-Seite noch nicht mal ein Angebot zum Download der Grafik.
 
Der JS-Code lässt sich sicherlich auch direkt vor den schließenden </body> knallen. Damit kostet es so oder so keine Ladezeit beim Seitenaufbau.
Außerdem möcht ich wetten, dass man "x" auch noch das Attribut "defer" oder "async" zuweisen kann, und trotzdem alles funktioniert.
 
Ich habe mir den Code nochmal angeschaut, es wird nur die eine Javascript-Datei mit 3.9kb nachgeladen.
Daarons Tipps sind in der tat sehr sinnvoll, dann lädt er NACH dme Inhalt nur noch den Button nach.
 
Das sind gute Nachrichten. Ich hatte die js-Datei mal angeklickt, sehe eine ganze Seite mit "Code-Wirrwarr" und dachte mir, "heilige Sch...", das dauert wahrscheinlich ein paar Sekunden....

Was haltet ihr von völlig scriptlosen Lösungen? Habe das hier gefunden:
http://t3n.de/news/performance-killer-519325/
Wenn man auf den Zähler verzichten kann, wäre das nicht die simpelste, schnellste Variante, die trotzdem genauso funktioniert?
 
Verstehe ich es richtig, dass bei tn3 die Codes, also z.B. für Xing und FB

HTML:
    <a  href="https://www.xing-share.com/app/user?op=share;sc_p=xing-share;url=YOUR-URL">Share on Xing</a> 

    <a  href="http://www.facebook.com/sharer/sharer.php?u=YOUR-URL" target="_blank">Share on Facebook</a>

noch keine Grafik erzeugen, also nur ein ganz normaler Linktext zu sehen ist?

Ich könnte mir aber doch irgendwo im Web den bekannten Button als Grafik-Datei besorgen, ganz normal hochladen und in den obigen Link-tag integrieren:

HTML:
<a  href="http://www.facebook.com/sharer/sharer.php?u=YOUR-URL" target="_blank"><img src="http://www.domain.de/button.jpg" />Share on Facebook</a>
[/HTML]

Braucht es dann noch im head den bei tn3 empfohlenen
HTML:
<link rel="image_src" type="image/jpeg" href="http://www.domain.com/path/my_picture.jpg" />
?
 
Zuletzt bearbeitet:
Das eine hat mit dem anderen wieder mal nix zu tun. Der <link> soll bei Facebook, zusammen mit den anderen Meta-Tags, für korrekte Sharinginhalte sorgen. Is nur total Panne, das so zu machen, aber DANN für Google+ die OpenGraph - Tags zu empfehlen. OG wurde von Facebook erfunden und von G+ nur adaptiert.
Wenn, dann also alles mit OG-Tags.
 
Aber das mit dem Bild kann man so machen, sprich ich besorge mir die bekannte "Gefällt mir" oder "Teilen"-Grafik und binde sie ein in den "sharer-Link"? Weil ich kann nicht erkennen, wie nur mit dem sharer-Link ein Button auf meiner Seite herbeigezaubert werden sollte.

Dieser statische, "aufgemotzte" sharer-Link erzeugt neben der Empfehlung auch ein "Like"?

Seit 2013 gibt es zwar wieder zwei verschiedene Buttons, also einen Teilen- und einen Like-Button, aber deren Funktion unterscheidet sich nur in der Art des Sharens. Siehe
http://www.thomashutter.com/index.php/2013/11/facebook-neue-like-und-share-buttons/

Mir ist nicht klar, wo/wie seit 2013 nun ein "Like" entsteht. Es soll zwar für die meisten Sumas kein Rankingfaktor sein, ist aber halt dennoch ein sichtbares, auswertbares "Signal" - für wen und was auch immer. Ich brauche es nicht für einen ZÄhler auf meinen eigenen Seiten, aber "andere" evtl. aus diversen Gründen.
 
Martinus33 schrieb:
Aber das mit dem Bild kann man so machen, sprich ich besorge mir die bekannte "Gefällt mir" oder "Teilen"-Grafik und binde sie ein in den "sharer-Link"?
Es ist ein <a>. Schreib rein, was du willst. <img>, <svg>, seit HTML5 auch Block Content,...

Mir ist nicht klar, wo/wie seit 2013 nun ein "Like" entsteht.
Es gibt Like und es gibt Share.
Ein Share ist ein aktiver sozialer Mehrwert, ein Like ist was fürs allabendliche Bullshit-Bingo beim Meeting.
 
Aha...

Es geht nicht um meine technisch validen Wünsche, sondern darum, wie bei solchen "statischen Sonderlösungen" welcher button auf meinen Seiten erscheint.

Like und Share sind keine zwei getrennten Welten, wie du es darstellst, siehe der Link von 2013.
 
Der Button erscheint so, wie du ihn gemäß W3C einbindest. Ich für meinen Teil mag CSS Sprites und Icon-Fonts...

Und was die Unterschiede zwischen Like & Share angeht... Ein Like ist eben DOCH etwas anderes als ein Share. Ein Share wird direkt und absichtlich gepostet, wahlweise an die eigene Timeline, die eines Freundes oder in einer PM. Ein Like hingege... Tja, da steht dann nur "Blabla gefällt Bla-Blubb.tld" in Blabla's Timeline und evtl. noch bei den paar Zonks, die Blabla abonniert haben... und selbst das sehr selten.

Somit:
Ein Share ist eine aktive Verbreitung und verdammt wertvoll. Der Teilende füttert seine Umgebung direkt mit deinen Informationen, allen voran natürlich deinen Produktdaten, deinem Newsfeed, deinem Video. Er kann (und oftmals: wird) diesen Share auch noch kommentieren, was unter Umständen seine Freunde zu weiteren Kommentaren animiert, wodurch deren Freunde, die nicht mit dem ursprünglichen Sharer befreundet sind, ebenfalls auf den Share aufmerksam werden können und sich ebenfalls engagieren.
Ein Like ist hingegen Tinnef. Auf einen Like folgt keinerlei soziale Interaktion. Niemand gibt einen Like dafür, dass jemand etwas nen Like verpasst hat.
 
Haargenau das Gleiche ist es natürlich nicht und die Auswirkungen bez. User-Verhalten mögen ebenfalls unterschiedlich sein.

Mir geht es hier aber doch um die scriptlosen, statischen Buttons und inwieweit man damit alle Funktionen erhält. Und speziell bei FB gibt es eben zwei, share und like, deren Entstehung über Buttons auf einer Homepage aber ähnlich läuft. Bis Nov. 2013 gab es offiziell unterstützt sogar nur noch den Like, der das Sharing beinhaltete.

Dieser sharer-Link scheint das explizite Liken nicht zu unterstützen. Ob das Liken dann "irgendwie automatisch miterfolgt" beim Sharen oder der User vielleicht auf andere Weise beim Sharen irgenwie nachträglich vereinfacht liken kann, darum geht es mir.

Jeder hat andere Websites, User, FB-Präsenzen, Absichten und Ziele... Deine in der Breite und Tiefe beeindruckenden Kenntnisse in Ehren, aber wie sinnvoll etwas ist, hängt von vielen individuellen Faktoren ab.

Vielleicht neigen meine Besucher dazu, ein schnelles, einfacheres Like zu vergeben, als sich die Mühe zu machen, einen langen Share zu erledigen? Wer weiß, wie die Sumas das eine oder andere oder beides gleichzeitig jetzt oder in Zukunft bewerten? Und und und...
 
Martinus33 schrieb:
Dieser sharer-Link scheint das explizite Liken nicht zu unterstützen. Ob das Liken dann "irgendwie automatisch miterfolgt" beim Sharen oder der User vielleicht auf andere Weise beim Sharen irgenwie nachträglich vereinfacht liken kann, darum geht es mir.
Ein Share ist ein Share, ein Like ist ein Like. Wenn du einen schnell-ladenden Share-Link einbettest, dann hat dein Besucher nur Share, kein Like, zur Verfügung. So einfach ist das.

Und auch wenn die Geschichte von T3N mit dem Datendurchsatz THEORETISCH stimmt, praktisch sieht es ganz anders aus. Praktisch gibt es Browser Caches. Die JS-basierten & voll funktionsfähigen laden allesamt nicht-blockierend, wenn man es richtig macht. Da der zu ladende Inhalt auf jeder 3. Webseite enthalten ist, werden deine Besucher weite Teile des geladenen Codes eh bereits im Cache haben. Also wie hoch ist wohl der Zeitaufwand für einen Cache-Access? Und wie hoch ist wohl der Zeitaufwand für n DNS Resolve tatsächlich? DNS-Requests werden vom OS gecached UND oftmals noch vom Router.
Also: Pffffffrrrrt! Wenn es dir nicht um Privacy geht, dann bette die regulären Snippets KORREKT ein. Geht es dir um Privacy, dann bette die Heise-Lösung ein.

Wer weiß, wie die Sumas das eine oder andere oder beides gleichzeitig jetzt oder in Zukunft bewerten? Und und und...
Das ist recht einfach zu beantworten: Quasi gar nicht.
Warum sollte Google z.B. Facebook-Interaktionen hoch bewerten? Das ist für die ein konkurrierendes Netzwerk. Warum sollte sich Bing einen feuchten Dreck um G+ - Likes/Shares kümmern?

Außerdem: wo sollen die Crawler die Daten her holen und später zuordnen? In den sozialen Netzen wäre es schwer, weil es keine brauchbaren URLs gibt. Auf der Webseite ist es hingegen gleich mal gar nicht möglich, da Social Buttons am Ende immer <iframe>s sind und sein müssen.... außer ein wahnsinniger Irrer findet einen Weg, für Social Buttons die Same Origin Policy auszuhebeln....
Die einzige Methode, wie Crawler tatsächlich die Daten abgreifen und deiner Seite zuordnen könnten: Du müsstest über die jeweilige API des Social Networks die Inhalte serverseitig holen und direkt im HTML-Code einbetten. Kann man machen, sollte man aber echt nicht.
 
Ich möchte die scriptlosen Buttons aus mehreren Gründen.

Wenn Browser Caching der heilige Gral für Performance wäre, dann müssten nicht "alle" an allen Ecken und Enden ständig nach mehr Performance suchen und würden nicht so viele über die normalen Buttons klagen.

Am wichtigsten ist es beim ersten Besuch, weil da evtl. der Besucher aus Ungeduld verloren geht und dann hilft Browser-Caching nichts mehr, weil es keinen zweiten Besuch mehr gibt. Kommt er aber ein zweites Mal, weil er beim ersten Mal zufrieden war, dann ist er wahrscheinlich eh geduldiger.

Und geht es in puncto Performance nicht auch um irgendwelche Requests, die ständig hin und hergehen? Siehe t3n-Artikel.

Wie gesagt, Performance ist nicht der einzige Grund, Datenschutz und Design-Vereinfachungen bei meinem Theme kommen noch hinzu. Und in meiner Branche spielt Vertrauen eine Rolle, d.h., Datenschutz hat diesen zusätzlichen Aspekt in meinem Fall.

Das einzige, das m.E. gegen solche Sonderlösungen spricht: Wenn FB irgendwann mal die sharer-Funktion aufgibt, dann steht man da und wird das vielleicht sogar erst Monate später merken. Und dann wieder rummurksen, nach Lösungen suchen usw.
 
Martinus33 schrieb:
Wenn Browser Caching der heilige Gral für Performance wäre...
Browser Caching IST der Heilige Gral, nur sind viele User inzwischen hochgradig paranoid geworden und schalten alle möglichen Funktionen mutwillig ab. Wer nur in Anon Tabs mit abgeschalteten Cookies, Cache,... surft, der hat halt höhere Ladezeiten.

Am wichtigsten ist es beim ersten Besuch, weil da evtl. der Besucher aus Ungeduld verloren geht und dann hilft Browser-Caching nichts mehr, weil es keinen zweiten Besuch mehr gibt.
Du hast immer noch nicht begriffen, was "blockierungsfreies, asynchrones Laden" bedeutet, oder? Und der User cached die Social-Buttons nicht nur von DEINER Seite. Das ist doch der große Vorteil von CDNs: Solange der User irgendwann mal auf einer anderen Seite war, die diesen Inhalt aus diesem CDN verwendet, dann ist es bereits im Cache.

Und geht es in puncto Performance nicht auch um irgendwelche Requests, die ständig hin und hergehen? Siehe t3n-Artikel.
Ja, und das ist auch Schwachsinn.
1.) DNS Requests werden gecached... vom OS, vom Router, vom ISP. Ich habe gerade dieselbe Domain 2x nacheinander aufgelöst. Der erste Request dauerte 50ms, der nächste 0. Toll, nicht?
2.) Browser stellen traditionell nur eine sehr begrenzte Anzahl synchroner Verbindungen zu EINEM Host her, das ist einer der Gründe, warum CSS Sprites viel besser als Einzelgrafiken sind. Sobald du ein CDN ansprichst entfällt dieses Limit. Der Browser kann jetzt 10 Verbindungen zur eigentlichen Webseite für CSS, Grafiken, JS... aufbauen UND parallel noch 10 zum CDN.

Wie gesagt, Performance ist nicht der einzige Grund, Datenschutz und Design-Vereinfachungen bei meinem Theme kommen noch hinzu. Und in meiner Branche spielt Vertrauen eine Rolle, d.h., Datenschutz hat diesen zusätzlichen Aspekt in meinem Fall.
Heise 2Klick Social, so wie hier im Forum. Sieht recht gut aus, ist datenschutzkonform, kostet keine Ladezeit,...
 
Wenn Browser-Caching andere Websites und deren Inhalte mitcacht müsste angesichts der millionenfachen Verbreitung der Standard-Buttons niemand ein verzögertes Laden und Besserung nach Einbau scriptloser Buttons bzw. 2-Klick-Lösungen erfahren. Das Web ist aber voll von solchen Erfahrungen, weil verständlicherweise kein User seinen Browser-Cache das ganze Web cachen lassen will!? Und deswegen faktisch-praktisch die Buttons meist nicht gecacht werden?

Folglich läuft es dann doch meistens auf das von mir beschriebene Szenario hinaus, gerade bei meinen Besuchern, die an der Standard-Einstellung zum Cache-Volumen nichts ändern. Weil sie diese gar nicht kennen.


Warum die 2-Klick-Lösung, warum nicht gleich völlig scriptlos?


Als Grafik möchte ich die am bekanntesten Original-Buttons verwenden. Icon Fonts fallen daher weg.
 
Zurück
Oben