Der folgende Text ist ein Gastbeitrag von David Attard von DART Creations. David wird uns AMP (keine Ahnung, was das ist? Lesen Sie weiter) vorstellen und wie Sie eine bestehende Website in eine AMP-Website umwandeln könnten. Tipp: Das bringt große Leistungsgewinne. AMP wird immer wichtiger. WordPress macht es. Ich habe von Google die Aufforderung bekommen, es zu tun und dass Analytics es unterstützt.
Wenn Sie das Interesse Ihrer Besucher im Auge behalten, wissen Sie, dass eine schnelle Website einer der Hauptfaktoren für eine gute Benutzererfahrung ist. Schnelle Websites tragen maßgeblich dazu bei, dass Ihre Nutzer zufrieden sind und wiederkommen. Entschlossene Website-Administratoren jagen immer nach diesen wenigen Millisekunden Geschwindigkeitsverbesserung.
Diese Millisekunden machen einen echten Unterschied.
Eine große neue Methode, um Ihre Website schnell zu machen, nennt sich Accelerated Mobile Pages (AMP), ein Projekt, das von Google angeführt wird. Mobile Daten sind anders als unsere heimischen WLAN-Verbindungen. Sie sind langsam. AMP zielt darauf ab, dies auf eine streng vorgeschriebene Weise zu beheben, indem die ineffizientesten Teile von Websites eliminiert werden.
Lassen Sie uns AMP ausprobieren!
Wir werden sehen, wie wir ein bestehendes Webdesign in AMP konvertieren können. Dann werden wir den Unterschied messen, den es macht.
Warum Accelerated Mobile Pages?
Telefone in Mobilfunknetzen haben typischerweise Latenz-Probleme.
Selbst bei einfachen Artikeln mit statischem Inhalt können Seiten lange brauchen, um den Text zu laden. Skripte, Bilder, Videos... all das dauert noch länger. Vielleicht kommen Anzeigen noch später herein, und die Seite passt sich an, um den neu geladenen Inhalt widerzuspiegeln. Nicht gerade eine angenehme Ladeerfahrung.
AMP möchte all das ändern. Verlage und Technologieunternehmen haben sich zusammengetan, um Best Practices zu etablieren, die Seiten schnell rendern lassen.
Dies ist ein nicht triviales Problem. Der anfängliche Fokus von AMP liegt auf statischem Inhalt, der radikalere Optimierungen ermöglicht.
Vorerst ist AMP ein Open-Source-Proof-of-Concept. Tatsächlich werden wir auf einige Einschränkungen stoßen, die zeigen, dass sich diese Technologie noch in den Kinderschuhen befindet.
Was macht AMP schneller als eine herkömmliche Website?
AMP hat sehr strenge Regeln für die Quelle, um die großen Geschwindigkeitssteigerungen zu erzielen, auf die es abzielt.
Die Grundprinzipien von AMP sind:
- Nur asynchrone Skripte. Nicht-asynchrone Skripte blockieren den DOM-Aufbau und verzögern das Rendern der Seite.
Tatsächlich beschränkt AMP die Verwendung von JavaScript sogar. Skripte sind nur innerhalb benutzerdefinierter AMP-Elemente erlaubt, die sorgfältig für Leistung entwickelt wurden. Beispiele für benutzerdefinierte AMP-Skripte sind Google Analytics, Facebook, Twitter und YouTube.
Drittanbieter-Skripte (wie Anzeigen oder Drittanbieterdienste) werden aus dem kritischen Pfad herausgehalten und sind nur in Iframes erlaubt. Auch dies blockiert nicht das Rendern der Seite.
Mehr über Skripte später.
- Externe Ressourcen müssen feste Abmessungen haben. Dinge wie Bilder und Iframes benötigen Größenangaben, um sicherzustellen, dass AMP die Größe der Elemente kennt, bevor sie heruntergeladen werden.
- Lassen Sie nichts das Rendern blockieren. Einfach gesagt, nichts hindert AMP am Rendern. Externe Elemente sind in Iframes enthalten. AMP erstellt die Iframe-Box, ohne überhaupt zu wissen, was sie enthalten wird.
- CSS muss inline sein und eine Größenbeschränkung haben. AMP geht den umgekehrten Weg im Vergleich zur normalen Wahl, CSS in einer externen Datei zu verlinken. AMP erzwingt Inline-CSS aus demselben Grund wie Skripte: weil CSS das Rendern und das Laden der Seite blockiert.
Es gibt ein Maximum von 50 Kilobytes Inline-CSS, um sicherzustellen, dass es effizient verwendet wird.
- Schriftart-Laden muss effizient sein. Webfonts können ziemlich groß sein und die Leistung stark beeinträchtigen. Unter normalen Umständen werden Browser am Herunterladen von Schriftarten gehindert, bis Skripte und Stylesheets heruntergeladen und bereit sind. Dies führt zu einer langen anfänglichen Wartezeit, bis der große Font-Download beginnt.
In AMP ist CSS inline und Skripte sind asynchron. Der Browser muss also nicht auf deren Abschluss warten, bevor er die Schriftarten herunterlädt.
- Nur Animationen auf der GPU ausführen. Einige Animationen erfordern Seitenlayout-Updates, die vom Browser und nicht von der GPU durchgeführt werden. AMP beschränkt Animationen auf
transformundopacity, damit keine Seitenlayout-Updates erforderlich sind und alle Animationen auf der GPU bleiben, wo sie schnell sind. - Ressourcenladung wird priorisiert. AMP optimiert den Download von Ressourcen so, dass die wichtigsten Ressourcen zuerst heruntergeladen werden. Bilder werden nur heruntergeladen, wenn sie wahrscheinlich vom Benutzer gesehen werden.
- Seiten werden sofort geladen. Die PreConnect-API wird verwendet, um Ressourcen vorab abzurufen, zu rendern und herunterzuladen, die wahrscheinlich vom Benutzer verwendet werden. Dies geschieht effizient: Inhalte werden vorgerendert und nur heruntergeladen, wenn sie wahrscheinlich angefordert werden (z. B. Inhalte „above the fold“).
Die Teile von AMP
Es gibt eine Reihe von „Änderungen“ an Standard-HTML, CSS und JS, die Seiten, die mit AMP optimiert sind, einen Geschwindigkeits Schub verleihen.
- AMP HTML: Dies sind HTML-Tags, erweitert um benutzerdefinierte AMP-Eigenschaften.
- AMP JS: eine Bibliothek, die sicherstellt, dass AMP HTML-Seiten schnell gerendert werden.
- AMP CDN: liefert die HTML AMP-Seiten über HTTP 2.0 für maximale Effizienz.
Die Schritte zur Konvertierung einer Seite in AMP
Da ich völlig neu bei AMP war, habe ich ihre empfohlene Checkliste befolgt.
Ich wollte mit einer bestehenden normalen (Nicht-AMP) Seite beginnen, also wählte ich einen Pen von CodePen: Example Article Layout von samyerkes.
- Fügen Sie das Attribut amp zum Tag hinzu.
<html amp lang="en"> - Fügen Sie ein kanonisches Link-Element hinzu.
<link rel="canonical" href="index.html"> - Änderte das Charset-Tag. Beachten Sie, dass dies anders ist als das ALL-CAPS UTF-8 und AMP empfindlich darauf reagiert.
<meta charset="utf-8"> - Fügen Sie das Meta-Viewport-Tag hinzu.
<meta name="viewport" content="width=device-width,minimum-scale=1"> - Fügen Sie das AMP Project CDN-Skript am Ende des
<head>hinzu.<script async src="https://cdn.ampproject.org/v0.js"></script> - Alle
<img>-Tags wurden in<amp-img>geändert und die Attributewidthundheighthinzugefügt. Beispiel:<amp-img src="http://farm4.staticflickr.com/3595/3288866270_23cb40f37c_b.jpg" alt="Crashed plane vintage photo" height="1024" width="734"></amp-img>Sie müssen diese Syntax verwenden, wenn Sie
<amp-img>-Tags verwenden.- Es muss eine explizite
widthundheightangegeben werden. - Es wird empfohlen, einen Platzhalter einzufügen. Der Platzhalter wird sofort angezeigt, sodass etwas Sichtbares da ist, bis die eigentliche Ressource geladen ist. Zum Beispiel könnten Sie eine Vorschau mit niedriger Auflösung eines Bildes laden, das gerade geladen wird.
<amp-anim src="animated.gif" width=466 height=355 layout="responsive" > <amp-img placeholder src="preview.png" layout="fill"></amp-img> </amp-anim> - Optional:
layout="responsive". Lesen Sie mehr über andere Layout-Optionen.
- Es muss eine explizite
- Entfernte das
<link>Stylesheet und inline CSS mit<style amp-custom>
Die Ergebnisse: Verbesserte Ladezeiten
Die Testumgebung bestand aus ein paar Subdomains, die auf einem SiteGround GoGeek Shared Hosting-Account erstellt wurden. Die Tests wurden mit GTMetrix und Pingdom durchgeführt und mehrmals wiederholt, um Schwankungen durch externe Umgebungen zu eliminieren.
Test 1: Kurzer Artikel
Der erste Test, den wir durchführten, erfolgte mit dem genauen Artikel wie im CodePen angegeben, wo der Artikel relativ kurz ist.
| Example Article Layout (nativer HTML) | Example Article Layout AMP | |
|---|---|---|
| Test 1 | 3,3s, 1,17 MB, 8 Anfragen | 1,7s, 1,18 MB, 5 Anfragen |
| Test 2 | 1,2s, 1,17 MB, 8 Anfragen | 2,0s, 1,18 MB, 5 Anfragen |
| Test 3 | 1,3s, 1,17 MB, 8 Anfragen | 1,0s, 1,18 MB, 5 Anfragen |
Man kann einige Schwankungen erkennen. Wenn man sich den Wasserfallgraphen genau ansieht, wird man feststellen, dass die Schwankungen hauptsächlich vom AMP CDN stammen. Das ist leider eine Nebenwirkung der Nutzung einer gemeinsam genutzten Ressource, die unter Last geraten könnte.
Test 2: Dreifache Artikel-Länge und dreifach so viele Bilder
| Example Article Layout (nativer HTML) | Example Article Layout AMP | |
|---|---|---|
| Test 1 | 1,1s, 2,3 MB, 14 Anfragen | 1,6s, 1,18 MB, 5 Anfragen |
| Test 2 | 1,1s, 2,3 MB, 14 Anfragen | 0,9s, 1,18 MB, 5 Anfragen |
| Test 3 | 2,3s, 2,3 MB, 14 Anfragen | 1,1s, 1,18 MB, 5 Anfragen |
Interpretation der Ergebnisse
Über die tatsächlichen Ladezeiten hinaus ist die *Anzahl* der Anfragen auf einer AMP-Seite geringer als auf einer normalen Seite. Das allein macht eine Seite schneller, da die Anzahl der Anfragen kleiner ist und somit weniger Latenz für das Warten entsteht (jede Anfrage unterliegt Latenz).
Auch die Gesamtgröße der Seite verringerte sich bei AMP-Seiten signifikant. Große Artikel mit vielen Bildern scheinen stärker von AMP zu profitieren.
In einem unserer frühen Tests haben wir einen relativ kurzen Artikel mit nur wenigen Bildern getestet. Dieser Test war nicht sehr aussagekräftig, also erhöhten wir den Einsatz. Im hier vorgestellten Test verdreifachten wir die Länge des Artikels und verdreifachten die Anzahl der Bilder. Interessanterweise stieg die Anzahl der Anfragen in der AMP-Version des Artikels nicht, obwohl wir die Anzahl der Bilder verdreifachten.
Soweit ich das verstehen kann, lädt AMP – neben der tatsächlichen Effizienz der AMP-Spezifikation – nur die Inhalte oberhalb der "Fold" (was erklärt, warum die Anzahl der Anfragen nach einer Verdreifachung der Bilder gleich blieb). Es lädt nur den ersten Teil des Artikels, den „Above the Fold“-Inhalt, und deshalb ist der Inhalt kürzer, kleiner und natürlich schneller.
Ein Wort zu <script>s
Wörtlich zitiert von der How It Works Seite:
Eine Sache, die wir früh erkannt haben, ist, dass viele Leistungsprobleme durch die Integration mehrerer JavaScript-Bibliotheken, Tools, Embeds usw. in eine Seite verursacht werden.
was bald gefolgt wird von
Mit diesem Wissen trafen wir die schwierige Entscheidung, dass AMP HTML-Dokumente keine vom Autor geschriebenen JavaScripts oder Skripte von Drittanbietern enthalten würden.
Meiner Meinung nach etwas drastisch.
Irgendetwas muss nachgeben, das verstehe ich. Erhöhte Leistung hat ihren Preis. Selbst bei der Optimierung normaler Websites für Leistung muss man Kompromisse eingehen.
Manchmal ist es die Bildqualität Ihrer Website. Hochwertige Bilder gehen zu Lasten großer Dateigrößen. Manchmal auf Kosten der Entfernung von Funktionalität. Manchmal auf Kosten der Entfernung von Skripten von Drittanbietern, wie z. B. sozialen Netzwerkintegrationen.
Sie werden immer einige schwierige Entscheidungen treffen müssen, basierend auf Ihren eigenen Prioritäten.
Skripte komplett zu eliminieren ist meiner Meinung nach etwas zu drastisch. Bibliotheken wie jQuery, Bootstrap, Angular, React... essentielle Bausteine der heutigen Webentwicklung.
Skripte komplett zu entfernen, schießt AMP ins eigene Bein. Es schießt AMP komplett vom Planeten in eine kleine Welt für sich allein.
Es wird nur dann praktisch, wenn Sie bereit sind, sehr ernsthafte Kompromisse bei der Funktionalität einzugehen, die Sie auf Ihren Webseiten haben möchten. Selbst im Bereich der Nachrichten-Websites, dem ursprünglichen Fokus von AMP, wird es einige schwierige Verkaufsgespräche geben.
Können wir erraten, wohin AMP geht?
Es sind noch frühe Zeiten, und es ist schwer, die Zukunft von AMP vorherzusagen. Ehrlich gesagt, ich möchte wirklich, dass AMP erfolgreich ist. Webseiten sind aufgebläht geworden, und der Leistung wird zu wenig Aufmerksamkeit geschenkt. Wir brauchen eine echte Anstrengung, um das Web schneller zu machen. HTTP/2 ist ein Schritt in die richtige Richtung. AMP auch.
Leider fühlt sich AMP durch den mangelnden Skript-Support beeinträchtigt. Ich hoffe, dass Webentwickler zusammenkommen, um eine faire Lösung zu finden, die das Web schnell hält und gleichzeitig die benötigte Funktionalität ermöglicht.
Das ist eine Einladung an Sie. Nehmen Sie sich Zeit, um am AMP-Projekt mitzuarbeiten. Wenn Sie nicht technisch genug sind, lesen Sie darüber und testen Sie es. Predigen Sie darüber und wecken Sie Interesse. Wer möchte nicht Teil eines besseren, schnelleren Webs für alle sein?
Wenn man Google schon eine Weile verfolgt, kann man erwarten, was Google tun könnte, um AMP einen Schub zu geben. Wir werden bald hören, dass AMP ein SEO-Ranking-Signal ist. Sie haben es hier zuerst gehört.
Ich nicht, wenn es bedeutet, das kostenlose und offene Web durch eines zu ersetzen, das auf einer bestimmten Plattform gehostet wird.
Ich bin ziemlich sicher, dass Sie Ihren Hoster nicht wechseln. Sie hosten dort, wo Sie möchten.
Ich verstehe den Punkt aber. Es IST eine super seltsame Syntax, die Browser nicht nativ unterstützen und man muss sich verbinden
damit es etwas tut. Das ist ein Skript eines Drittanbieters, das man nicht kontrolliert. Sieht so aus, als wäre es eine offene Spezifikation mit vielen Mitwirkenden mit unterschiedlichen Interessen. Ich habe keine Ahnung, wie hoch die Chancen sind, dass es eine „echte“ Spezifikation wird. (wahrscheinlich gering).
Fürs Protokoll: Tim Kadlec hat ähnliche Bedenken und es gibt Alternativen.
Ich hoffe auch, Sie schlafen gut ;)
Ich verstehe. Sie fügen also ihre JS-Datei hinzu (wahrscheinlich muss sie im Head sein) und sie parst die Seite neu. Das ist wohl besser. Es ist aber immer noch stark vom CDN abhängig. Und man kann viel von der Entschlackung selbst machen (einschließlich Inline-CSS, wenn das Ihr Ding ist). Ich hoffe, Google gibt AMP nicht explizit Bonuspunkte, ohne anderen, die die gleichen Ergebnisse erzielen können, den gleichen Schub zu geben.
Hallo Casey,
Die Tatsache, dass wir tatsächlich über effizientes Coden sprechen, ist bereits ein Schritt in die richtige Richtung.
Und wie Chris richtig sagte, man kann dort hosten, wo man möchte. WordPress hat gerade ein Plugin veröffentlicht, um Ihre Seite zu AMPen, also kein Stress, woanders hosten zu müssen.
Meine „Sorge“ ist die Tatsache, dass man eine Art „andere“ Version der Website haben muss. Ich mochte früher das m.site.com-Ding nicht, ich finde, dass Responsive viel besser war, aber das geht wieder dorthin zurück.
Zum Schub: Ich stimme durchaus zu, dass keine solche Voreingenommenheit besteht, aber ich glaube, Google belohnt bereits schnelle Seiten. Aber ich bin sicher, sie werden AMP einen kleinen Vorteil verschaffen. Sie haben die Angewohnheit, Dinge, die sie mögen, stark durchzudrücken: HTTPS, mobilfreundlich... Ich bin sicher, das wird wieder passieren ;-)
Auch ein großes No-No für Nicht-JS-Benutzer (Technik hängt komplett von JS ab).
Also guter Weg – falsche Technik.
Das existiert bereits
http://motherfuckingwebsite.com
http://bettermotherfuckingwebsite.com
Beachten Sie, wie schnell diese beiden Seiten laden? Das führt natürlich sowohl zu fragwürdiger UX als auch dazu, dass die meisten Anforderungen an Websites nicht erfüllt werden. Aber wenn man all den nutzlosen Schnickschnack und Kram entfernt, sind die Seiten erstaunlich schnell!
Ich habe meine eigene Website, die der zweiten sehr ähnlich ist. Minimales CSS und das war's.
Das Web ist wie Softwareentwicklung geworden. Es gibt mehr Ressourcen, daher kümmern sich Websites und Softwareentwickler oft nicht darum, wenn sie immer mehr Ressourcen verbrauchen. Auch wenn sie diese verschwenderisch nutzen. Schließlich wird alles zu einem aufgeblähten Haufen Müll, der immer weiter in einen größeren Haufen Müll gerollt wird, weil die Leute von diesem Haufen Müll abhängig sind.
Gut gesagt, Nadya, ich musste lachen, als ich mich erinnerte, dass diese beiden Seiten immer noch existieren.
Manchmal wird das alles zu aufgebläht und unnötig...
Hallo Nadya,
hehe, es ist eine Weile her, seit ich diese Seiten besucht habe!
Das ist aber genau der Punkt – das Web ist aufgebläht geworden, weil sich viele Leute einfach von all den schönen Dingen mitreißen lassen oder einfach keine Zeit haben, sich um Effizienz zu kümmern (sagen wir einfach nicht Faulheit – denn ich weiß, dass ich auch schuldig bin). Das ist genau der Punkt von AMP – wenn Sie es nicht selbst tun wollen, werden Sie dazu gezwungen.
Noch besser: Wenn die Mehrheit des Webs es unterstützt, können wir uns einfach nicht darum kümmern, und alles wird serverseitig für uns automatisiert...
Die Tatsache, dass wir dieses Gespräch führen, ist bereits eine gute Richtung.
David
Ich denke, wenn Sie sagen „inline CSS“, meinen Sie, dass Sie alle externen Stylesheets in ein einziges eingebettetes Stylesheet umgewandelt haben, richtig? Die verlinkte Seite beginnt mit der Diskussion über Inline-CSS, aber das Beispiel auf dieser Seite ist ein eingebettetes Stylesheet.
Hallo Sasha,
Ja, das habe ich getan, ich habe das gesamte Stylesheet eingebettet, weil es zu viel Zeit gekostet hätte, die gesamte Seite neu zu schreiben, um das CSS zu inline zu machen.
Im Wesentlichen sind beide in Ordnung – der Punkt ist zweigeteilt.
Kein externes CSS muss vollständig heruntergeladen werden, bevor das Rendern beginnt.
CSS ist auf 50K begrenzt, um sicherzustellen, dass es effizient genutzt wird und im Wesentlichen schlank (und schnell) gehalten wird.
David
Ich verstehe den ganzen AMP-Hype nicht.
Dass große Seiten, die sich auf das Blogging-Element konzentrieren, davon profitieren, ja, absolut, das verstehe ich. Aber abgesehen davon ist es nur Googles Art, mit Facebook und Apple konkurrieren zu können.
Und weil es Open Source ist, sind alle so gehypt?
Hallo Piet,
Der Punkt von AMP ist, das mobile Web schneller zu machen… erinnern Sie sich, dass ein großer Teil der Welt (besonders Entwicklungsländer) über sehr schlechte Datennetze auf das Internet über Telefone zugreift. Selbst in entwickelten Ländern gibt es viele Gebiete, in denen mobile Daten langsam sind.
Selbst wenn Daten reichlich vorhanden sind, sind sie oft stark mengenmäßig begrenzt, sodass die Effizienzsteigerung mehrere Vorteile hat.
Mehr als das alles macht es den Zugriff auf AMP-Seiten wirklich, wirklich schnell. Sie müssen es ausprobieren und erleben, um den Unterschied in der Realität zu sehen.
Nun, was Googles Konkurrenz mit Apple und Facebook angeht, glaube ich wirklich nicht, dass das der Punkt ist. Viele große Verlage sind darauf aufgesprungen, weil es den Nutzern eine positive Benutzererfahrung bietet. Ich bin sicher, sie haben alle ihre eigene Agenda, aber meiner Meinung nach wird viel Gutes daraus entstehen.
Und wie würde Google mit AMP mit Apple und Facebook konkurrieren?
Ich lebe tatsächlich in Shanghai, das in einem dieser Entwicklungsländer liegt, von denen Sie sprechen, und ich kann Ihnen sagen, dass 4G dort, wo es Abdeckung gibt, VIEL schneller ist als die meisten WLAN-Verbindungen :)
In den Nachrichten gab es viel Veröffentlichungen darüber, wie Google AMP mit Apple News und Facebook Instant Articles verglichen wird und/oder sich davon unterscheidet.
Fortune hat im Oktober letzten Jahres einen Artikel veröffentlicht und es gibt viele weitere.
Verstehen Sie mich nicht falsch, für die großen Verlage und andere Seiten, die viele Artikel veröffentlichen, ist es wahrscheinlich großartig.
Aber ich sehe nicht den Sinn, dass jeder davon gehypt wird, also Leute ohne Blog.
Es gibt andere Möglichkeiten, eine Seite schnell zu machen, ich denke an statisches Laden. Jetzt, das ist, worüber der Hype sein sollte, meiner Meinung nach :)
Okay, ich verstehe, was Sie mit der Konkurrenz meinen. Ich kann nicht widersprechen, aber. Was auch immer die Eigeninteressen sein mögen, jedes Mal, wenn eine neue Technologie unseren Arbeitsweise auf eine neue Ebene hebt (im guten Sinne), denke ich, ist das immer gut – was auch immer der Katalysator dafür sein mag.
Und deshalb ist der Hype meiner Meinung nach gut, denn wie ich in einem anderen Gespräch sagte, wann immer wir über die Beschleunigung des Webs sprechen, gewinnen wir alle, oder denken Sie nicht?
Ich bin begeistert von AMP. Es ist schade, dass es sich auf ein Google CDN und ein von Google gehostetes Skript konzentriert, aber der Rest sind die Best Practices, über die die Community gesprochen, aber größtenteils nicht implementiert hat. Die Geschwindigkeit, mit der AMP-Seiten von einer Google SERP geladen werden, ist beeindruckend, also hoffe ich, dass Nicht-Entwickler diese Geschwindigkeit bemerken und sie von den Websites, die sie nutzen und verwalten, fordern werden.
Es stimmt, dass man keine benutzerdefinierten Skripte laden kann, aber man kann Iframes laden, sodass man trotzdem Einbettungen und Ähnliches machen kann.
(Kleinigkeit am Rande: Ich bin sicher, dass die Größen von Websites in Megabytes MB oder Mebibytes MiB gemessen werden sollten und nicht in Megabits Mb mit einem Kleinbuchstaben „b“.)
Hallo Flimm,
Ich bin sicher, dass wir uns an das Google CDN gewöhnen können. Oder einen besseren Ort zum Hosten finden – es ist noch früh, Verbesserungen werden erwartet.
Ich stimme der Geschwindigkeitswahrnehmung zu. Ich hoffe, dass dies schließlich von mehr großen Playern übernommen wird... und dann ist es eine Frage, wie die Leute aufholen, um mit den Best Practices Schritt zu halten.
Ich stimme zu, dass wir mit zunehmender Akzeptanz mehr Lösungen für die „Probleme“ oder Einschränkungen finden werden, die derzeit bestehen.
Danke für den Hinweis, wir werden es aktualisieren!
David
AMP scheint mir etwas überbewertet zu sein. Es ist nur die Durchsetzung von Performance-Best-Practices (d. h. keine Skripte verwenden, notwendiges CSS inline einfügen, alles asynchron laden usw.).
Jedenfalls, diese Zeile aus dem Artikel
Macht nicht viel Sinn. AMP ist für statische Inhaltsseiten, wie Nachrichtenartikel. Es gibt keinen Platz für Skripte und andere dynamische Elemente auf statischen Inhaltsseiten. Natürlich gibt es einige Ausnahmen, wie Anzeigen, Analysen usw. – aber am Ende des Tages sprechen wir nicht darüber, AMP für etwas Dynamisches überhaupt zu verwenden.
Hallo Agop,
Sicher, es ist nicht viel mehr als die Durchsetzung von Best Practices – stimme zu. Da WordPress seine Unterstützung dafür gegeben und ein AMP-Plugin veröffentlicht hat, halte ich es für einen ausgezeichneten Schritt, um die Website schnell zu machen.
Zur anderen Anmerkung, Sie weisen selbst auf die Bedürfnisse hin. Mein Punkt in diesem Teil des Absatzes ist: Was wäre, wenn wir AMP über Nachrichtenartikel hinaus auf Dinge wie Blogartikel erweitern müssten? Nicht sehr dynamisch, aber es gibt immer noch viele Skripte, die beeinträchtigt würden. Es gibt sicherlich viel Raum für Verbesserungen, meiner Meinung nach.
Ich plädiere für eine Lösung des Skript-Problems, anstatt mich darüber zu beschweren.
Für Drupal-Nutzer schauen Sie sich das Modul (eigentlich eine vollständige Distribution) AMP an. Es gibt auch einen Walkthrough-Blogbeitrag dazu, der gerade heute veröffentlicht wurde. Es gibt eine Beta-Version für Drupal 8 und eine Dev-Version für Drupal 7. Laut dem Blog wird es in den nächsten zwei Wochen eine Beta-Version für Drupal 7 geben.
Es gibt auch das alternative Modul und Theme Amp Project. Obwohl es dort aktuelle Commits gibt, gibt es derzeit keine Veröffentlichung (nicht einmal eine Dev-Version). Aber Sie können es über Git abrufen. Sieht aus, als wäre es auf Drupal 7 ausgerichtet.
Danke fürs Teilen, Ivan
Ich habe hart daran gearbeitet, meine Website reaktionsfähig und leicht zu machen. Maximal 1 oder 2 CSS, 1 JS, SVG für alles außer Fotos. Das ganze Programm – dank Chris dafür! – und das Ergebnis ist eine ziemlich schnelle mobile und Desktop-Website. Ich habe nicht mit AMP verglichen, vielleicht ist AMP schneller. Vielleicht auch nicht. Was aber den Unterschied macht, ist die Werbung. Ich muss mit vielen beschissenen Anzeigen fertig werden, mit Tonnen von JS, Trackern und Mist, die meine Seiten langsam und aufgebläht machen. Und sie alle brechen die Hauptideen von AMP (asynchrone Skripte, Render-Blocking usw.)!
Und selbst wenn das bei AMP nicht der Fall sein wird, weil es sich auf schlechte Anzeigen auswirken wird – oder so erzählen sie uns zumindest im Moment –, wie lange noch? Wenn Publisher schlechte Anzeigen auf AMP schalten, sind wir wieder am Anfang, aber wir müssen immer noch zwei Versionen unserer Website verwalten.
Was bringt es, meine Seite überhaupt zu optimieren, wenn ich auch AMP-Seiten machen muss? Ist das nicht das Ende des responsiven Designs, das wir alle vor ein paar Jahren angenommen haben?
Und wird Google nicht auf lange Sicht eine Art Monopol bei der Auslieferung von Anzeigen auf AMP-Seiten aufbauen?
Warum eine neue Syntax für etwas implementieren, das mit der bereits vorhandenen Syntax, mit bereits guter Browserunterstützung und allgemeinem Wissen gemacht werden kann? Die Wahl scheint nicht logisch zu sein, oder bin ich zu sehr in der Vergangenheit gefangen? Für mich ist die Arbeit mit AMP keine technische Entscheidung, wie „Werde ich Sass für dieses Projekt verwenden oder nicht?“, „Sollte ich einen Iconfont oder SVGs verwenden?“ usw. Für mich geht es mehr um Marketing als um Entwicklung und gute Webpraktiken.
Und natürlich, in einer Welt, in der einige Idealisten – wie ich – versuchen, alle Google-, FB- usw. Skripte von ihren Seiten zu entfernen, wie z. B. den Wechsel von Analytics zu Piwik, das Entfernen von FB-Like-Buttons usw., um Tracker zu vermeiden, und ihnen alle meine Daten gebe und meinen Besuchern etwas Privatsphäre gewähre, sagst du mir, dass ich ein neues Google-Skript auf all meinen mobilen Seiten platzieren muss? Mann, die sind gut.
Diese AMP-Sache wirft sicher viele Fragen in meinem Kopf auf. Dieser Artikel ist aber ein guter Überblick. Wenn ich WordPress verwenden würde, würde ich es sicherlich ausprobieren.
Hallo Francois,
du wirfst viele interessante Punkte auf. Optimierte Seiten sind sicherlich nicht das alleinige Reich von AMP. Du kannst (und solltest) die von dir vorgeschlagenen Vorschläge umsetzen, und du wirst keine AMP-Seiten benötigen.
Ich glaube nicht, dass du „wählen“ musst, ob du deine Seiten mit AMP ausstattest oder nicht. Mein Gefühl ist, dass WordPress und andere Content-Frameworks in Zukunft die AMP-Umwandlung sogar automatisch durchführen werden.
Das würde Vorteile für alle bringen. Du (als Entwickler) müsstest dich nicht darum kümmern, mit AMP arbeiten zu müssen. Content-Autoren (die nicht technisch sind) müssten sich nicht fragen, warum ihre Seiten langsam sind. Und mobile Besucher erhalten automatisch AMP-Seiten.
Das ist eine ideale Welt und mag passieren oder auch nicht. Ich denke, wir müssen abwarten, was passiert.
David
Ich stimme all den Fragen und Argumenten, die du ansprichst, voll und ganz zu. Bis auf den letzten Absatz. Ich sehe nicht ein, warum eine WordPress-Seite von AMP profitieren würde und eine Nicht-WP-Seite nicht.
Weil es einfach wäre, die Plugins zu installieren und das auszuprobieren, ohne etwas coden zu müssen. Ich habe kein CMS, also muss ich alles von Grund auf neu machen.
Ich meinte nicht Piet, jede Seite kann von AMP profitieren, wenn sie implementiert ist, egal ob es eine WP-Seite ist oder nicht.
Also wirft AMP Fragen auf, aber diese Fragen gäbe es nicht, wenn du eine WP-Installation hättest?
Entschuldigung, das ergibt keinen Sinn. Was hindert dich daran, eine WP-Installation einzurichten, damit du AMP ausprobieren kannst?
Hast du auch einen Test durchgeführt, um den Speed Index zu ermitteln? Soweit ich das verstehe, ist der Hauptvorteil von Dingen wie Inline-CSS, den kritischen Inhalt zuerst zu laden. Die Seitenladezeit ist keine so aussagekräftige Messung.
Ich denke, das ist wirklich ein sehr guter Programmieransatz und Best Practice, wenn man sich für die Gesamtleistung interessiert. Derzeit ist es eine schreckliche Benutzererfahrung, wenn man auf eine Seite wartet oder die Seite einfriert, damit eine Anzeige geladen werden kann. FRAGE: Was macht das mit einem responsiven Ansatz? Gedanken?
Die Messungen sind nicht sehr aussagekräftig für das tatsächliche Ergebnis, wie du richtig bemerkst. Es ist etwas schwierig, gute tatsächliche Messungen zu erhalten, da wir nicht speziell auf die Messung von AMP-Vorteilen abzielen.
Das ist eine sehr gute Frage ... Ich denke, es muss einen Weg geben, beides zu vereinen. Responsiv auf Mobilgeräten über WLAN sollte anders sein als bei AMP-Seiten über langsame mobile Datenverbindungen.
AMP als SEO-Signal ist schlecht für das Web als Ganzes.
AMP mag schlecht für das Web im Allgemeinen sein. Google möchte, dass der gesamte Webverkehr irgendwann über seine Server läuft, und für ein Unternehmen und seine Unterstützer, die oft die Idee von abgeschotteten Gärten kritisieren, selbst wenn sie nicht wirklich existieren, scheuen sie sich sicherlich nicht davor, ihre eigenen Mautstraßen zu schaffen.
Quentin, ich sage nicht, dass ich diesen Weg befürworte, ich vermute nur, dass er in Zukunft eintreten könnte, wenn Google ihm einen guten Schub geben möchte.
Würde der neue responsive Image sizer von Cloudinary helfen, ohne amp-img verwenden zu müssen?
Alles, was Bilder verkleinert, hilft, deine Website schneller zu machen.
Das hat aber nichts mit AMP zu tun.
Ich stimme nicht zu…
Wenn Skripte erlaubt wären, würden wir feststellen, dass innerhalb eines Tages 4 Bibliotheken geladen würden und auf jeder Seite 5000 Zeilen benutzerdefinierter JavaScript vorhanden wären.
Was wäre dann überhaupt der Sinn von AMP…?
Wenn du Bibliotheken und benutzerdefinierte Skripte laden musst… Dann benutze kein AMP… Optimiere und straffe einfach deine responsive Website.
Ray,
Ich denke schon, dass Skripte in AMP nützlich sein könnten. Dinge wie Twitter, Facebook und Google Analytics haben bereits eine „Lösung“, die AMP-kompatibel ist.
Was ich sagen möchte ist, dass es vielleicht einen Mittelweg gibt, der das Beste aus beiden Welten vereint. Ich habe natürlich keine Lösung dafür…
Ich weiß, was du meinst…
Es würde wirklich vom Entwickler Zurückhaltung erfordern.
Aber aus meiner Sicht, d.h. als Digital Director einer kundenorientierten Agentur, kann ich sehen, was passieren wird…
Der Kunde wird X, Y und Z auf seiner AMP-Seite haben wollen und die Entwickler werden nachgeben und anfangen, jQuery usw. zu laden.
Bald werden wir das, was AMP tun sollte, zunichte gemacht haben… Und ich werde viele Stunden Entwicklerzeit ohne wirklichen Nutzen verschwendet haben.
So wie es ist… AMP ist neu und die meisten Kunden wissen nicht, was es tut und warum es wichtig ist. Also kann ich im technischen Meeting sagen: „Leute… Wir können AMP für Ihre Website anbieten. Aber hier sind die Einschränkungen.“
Und in gewisser Weise ist das sogar gut…. Weil es verhindert, dass Kunden Amok laufen.
Derzeit investieren wir ohnehin viel Zeit und Mühe in die Optimierung unseres mobilen Erlebnisses… AMP ermöglicht es uns lediglich, dies weiter zu verbessern.
Auf diesen Punkt stimme ich dir vollkommen zu.
Und da AMP hauptsächlich auf artikel-/nachrichtenorientierte Websites abzielt, sind die Skripte sicher kein kritischer Bestandteil davon.
Ja, wenn du zu einem Kunden gehst und sagst: „Hör mal, du willst das schnellste Erlebnis? Das sind die Einschränkungen, kannst du damit leben oder nicht?“
Ich bin froh, dass wir uns auch über den letzten Punkt einig sind, dass AMP die Grenzen verschiebt und bei der vollständigen Optimierung des mobilen Erlebnisses hilft.
Ich habe vor ein paar Wochen einen Artikel geschrieben, in dem ich eine Reihe von Fragen zu Google AMP gestellt und einige Geschwindigkeitstests durchgeführt habe. Würde mich über Feedback freuen! https://medium.com/@mattshull/questions-for-google-amp-a6c1963b13cd#.283qqccfa
Insgesamt bin ich sehr besorgt über diese Richtung, sicherzustellen, dass das Web schnell ist. Ich hatte viele Fragen, die oben erwähnt wurden, aber meine größte Sorge/Frage ist das Preloading von Assets und wie weit das im Hinblick auf Buzzfeed-Seiten geht. Ich habe dort einige Erkenntnisse gewonnen.
Toller Artikel, David!
Hallo Derek, danke für deine Kommentare.
Ein ziemlich guter Einblick in AMP und du wirfst eine ganze Reihe guter Fragen auf. Was die Frage des Preloadings betrifft, glaube ich, dass AMP nur den Inhalt lädt, der gerade sichtbar ist (d.h. oberhalb der Falz). Eine bildlastige Website sollte den Nutzer also nicht benachteiligen, da die Bilder rechtzeitig geladen werden, wenn der Nutzer zu ihnen scrollt. Wenn es so funktioniert, dann ist das eine sehr innovative UND effiziente Art, Bilder zu laden. Deshalb musst du auch die Abmessungen der Bilder angeben, damit der Artikel beim Laden der Bilder nicht springt.
David