Meine neueste Erkenntnis ist, dass die Bereitstellung einer performanten, zugänglichen, responsiven und skalierbaren Website nicht ausreicht: Ich muss auch die Auswirkungen von Skripten Dritter berücksichtigen. Egal wie solide mein Prototyp meiner Meinung nach ist, das entbindet mich nicht davon, darauf zu achten, was während der Implementierung passiert, insbesondere wenn es um die Hinzufügung dieser Skripte Dritter geht.
Ich hatte kürzlich ein Gespräch mit einem Freund, der an einer ziemlich hochkarätigen E-Commerce-Website arbeitete. Sie wurden beauftragt, die Website zu entwickeln, aber besonders mit Blick auf die Leistung. Sie verfolgten den PWA-Ansatz, wurden jedoch sofort durch Skripte Dritter behindert. Eines davon, anscheinend unvermeidlich, konnte nicht HTTPS sein, was bedeutete, dass die Website sofort für die PWA disqualifiziert wurde. Sie konnten in vielen anderen Bereichen immer noch gute Arbeit leisten, aber rechts und links wurde ihre großartige Performance-Arbeit von Skripten Dritter zerschlagen. Ich beneide sie nicht um diese Position.
Schuld sind oft „Tag-Manager“. Es gibt eine ganze Reihe davon. Hier ist ein Marketing-Pitch für einen davon
Vermarkter wünschen sich Tag-Management, das einfach, zuverlässig und einfach in bestehende Systeme integrierbar ist… Sie werden Programme schneller starten, damit Sie schnellere Entscheidungen treffen können.
Mit anderen Worten: „Geben Sie Ihrem Marketingteam die Möglichkeit, schnell beliebige JavaScript-Drittanbieter hinzuzufügen, ohne den normalen Bereitstellungsprozess durchlaufen zu müssen.“ Ich kann verstehen, warum sie in einigen Organisationen benötigt werden, aber es jagt mir trotzdem einen Schauer über den Rücken.
Drittanbieter-Skripte könnten konzeptionell Teil eines Design-Styleguides sein. Direkt neben Ihren Schaltflächen und Modals könnte eine Liste der auf einer Website vorhandenen Drittanbieter-Skripte stehen. Brad Frost
Die Idee ist, dass jemand (oder wie Trent anmerkt, *etwas*) hypothetisch alle auf einer Website enthaltenen Skripte durchgehen und sie im Styleguide neben allen Farbfeldern, Symbolen, UI-Komponenten usw. anzeigen könnte. Schließlich beeinflussen sie die Benutzererfahrung genauso (wenn nicht sogar mehr) wie all diese anderen Designelemente. Sie können sie visuell nach ihrer Komplexität gewichten und so nachdenkliche Gespräche mit Ihrem Team führen – insbesondere mit den Leuten, die gedankenlos all diese leistungsschwächenden Skripte einwerfen – über die Vor- und Nachteile jedes aufgenommenen Skripts.
Drittanbieter-Skripte sind wahrscheinlich die Hauptursache für schlechte Leistung und schlechte UX im Web. Es ist kein Wunder, dass Dinge wie AMP existieren. Die Tatsache, dass es Drittanbieter-Skripte verbietet, ist wahrscheinlich der größte Beitrag dazu, dass Websites schnell werden. Allerdings höchst umstritten, was seine anderen Entscheidungen angeht.
Wie es das Schicksal wollte, ist JavaScript von Drittanbietern dank Spectre und Meltdown gefährlicher als je zuvor. Jorgé
F: Ist JavaScript in meinem Browser anfällig?
A: Ja, das Surfen im Web kann Drittanbietern den Zugriff auf den Arbeitsspeicher Ihres Computers über den Browser hinaus ermöglichen.
😳
Mehr zu Drittanbieter-JavaScript
Wenn Sie, wie Trent, vorhaben, Ihre Kenntnisse im Bereich Drittanbieter-JavaScript zu vertiefen, finden Sie hier eine Sammlung von Beiträgen anderer Entwickler aus den letzten Jahren, die sich damit auseinandersetzen. Einige davon richten sich an *Sie als Anbieter* von Drittanbieter-JavaScript.
Drittanbieter-JavaScript (aus der dritten Person) Slides von Alex Sexton
Zu Drittanbieter-JavaScript – Die Prinzipien von Gergely Nemeth
Beim Ausliefern von Drittanbieter-JavaScript-Anwendungen sind die Größe und die Cache-Richtlinie entscheidend, da beides nicht nur die Wartezeit Ihrer Benutzer auf die Anwendung beeinflusst, sondern auch Ihre monatlichen Rechnungen.
Siehe auch: Das Schreiben von Drittanbieter-JavaScript – der Integrationspart im Überblick.
Drittanbieter-JavaScript von Ben Vinegar und Anton Kovalyov
Dinge, die man über Drittanbieter-Skripte wissen sollte (und potenzielle Gefahren) von Yaphi Berhanu
Das Web ist voll von Skripten Dritter. Websites nutzen sie für Werbung, Analysen, Retargeting und mehr. Aber das ist nicht immer die ganze Geschichte. Skripte können Ihr Verhalten, Ihre Vorlieben und andere Informationen verfolgen.
Ich ernte Kreditkartennummern und Passwörter von Ihrer Website. So geht's. von David Gilbertson
Mein Ziel ist es einfach darauf hinzuweisen, dass jede Website, die Code von Drittanbietern enthält, alarmierend anfällig ist, und zwar auf eine völlig unerkennbare Weise.
Ain’t No Party Like A Third-Party JS Party von Rebecca Murphey
Sie dachten, Sie hätten dieses ganze JavaScript-Ding im Griff, aber jetzt befinden Sie sich in der Welt des Drittanbieter-JavaScript, in der Sie nur ein einzelnes Skript-Tag kontrollieren und es fast unmöglich ist, sich alle feindlichen Umgebungen vorzustellen, in denen Ihr Code funktionieren soll. „Es funktioniert auf meiner Maschine“ klang noch nie so hohl. In diesem Vortrag werfen wir einen Blick auf einige der erfreulichen Fehler, die wir bei Bazaarvoice lösen mussten, während wir an der Drittanbieter-JavaScript-App arbeiteten, die Bewertungen und Rezensionen für einige der größten Einzelhändler der Welt sammelt und anzeigt.
(Abonnement erforderlich)
Cheat Sheet für das Management von Drittanbieter-JavaScript
Die Einbindung von Drittanbieter-JavaScript-Code in eine Webanwendung erfordert die Berücksichtigung von insbesondere 3 Risiken
- Der Kontrollverlust über Änderungen an der Client-Anwendung,
- Die Ausführung von beliebigem Code auf Client-Systemen,
- Die Offenlegung oder Weitergabe sensibler Informationen an Dritte.
Ich bin Autor eines Drittanbieter-Skripts und habe einiges darüber geschrieben, ein guter Drittanbieter-Anbieter zu sein. Dieser Beitrag befasst sich damit, wie Ihre Kunden Ihre Leistung messen können: http://www.lognormal.com/blog/2017/07/25/a-study-of-timing-allow-origin/, während dieser Beitrag über den performantesten Weg, Ihr Drittanbieter-Skript in die Seite zu laden (wird bald aktualisiert), handelt: http://www.lognormal.com/blog/2012/12/12/the-script-loader-pattern/
Laut Google-Richtlinien müssen wir Drittanbieter-Skripte so weit wie möglich vermeiden.
Es gibt keine Wahl. Eine E-Commerce-Website *muss* über HTTPS laufen, also entweder behebt der Drittanbieter seinen kaputten Mist oder es wird eine Alternative gefunden. Wenn ich heute eine E-Commerce-Website sehen würde, die kein HTTPS verwendet, würde ich sie nicht nutzen.