seit der ankündigung von AMP habe ich mich, vor allem aus technologischer neugier, bemüht das format bereitzustellen. im januar begann google meine AMP-formatierten seiten in den index aufzunehmen, etwa 500 AMP seiten auf wirres.net waren am 2.2.2016 indexiert. zu diesem zeitpunkt hatte ich auch bereits die meisten fehler der seiten beseitigt, heute sind meine seiten, AMP-technisch, laut webmaster console und laut debugging tool, fehelrfrei.

aber google hat nicht nur über die letzten wochen hinweg gemerkt, dass meine AMP-seiten syntaktisch korrekt sind (die 6 monierten fehler datieren allesamt auf versionen von vor dem 2.1.2016), sondern auch nur 4 meiner AMP-seiten im index.

auch als ich noch mehr seiten im google-index hatte, hatte ich maximal 1-2 besucher pro tag auf meinen AMP-seiten, im google-index war ich, soweit ich sehen konnte, AMP-mässig unsichtbar. das heisst auch mobile suchergebnisseiten, zeigten nie meine AMP-seiten an, sondern stets die regulären seiten. das ist ja nicht weiter schlimm, aber ich habe das gefühl, dass google white oder blacklists führt und AMP-seiten nur von renomierten, reichweitenstarken webseiten in die (mobilen) suchergebnisseiten aufnimmt.

ich finde die idee und die ausführung hinter dem AMP-projekt nach wie vor faszinierend, weil es verspricht, seiten im web — und nicht etwa nur in apps — effektiv und von störendem und irritierenden müll befreit, auszuliefern, aber die implementierung und adaption von AMP scheint, selbst bei google selbst, unter aller kanone zu sein. deshalb bin ich gespannt auf den öffentlichen facebook instant articles rollout mitte april, auch wenn sich die vorteile vor allem in der app auswirken werden, aber immerhin ist die facebook-implementierung so gelöst, dass es immer einen fallback auf die webversion gibt und die instant-articles-version wie ein sahnehäubchen funktioniert.

* * *

apple news ist übrigens auch eine mittlere katastrophe, zumindest, wenn man ein medium mit nur um die 100tausend seitenansichten im monat (30.000 web, 60.000 RSS) betreibt. ich habe mich dort vor einem halben jahr testweise angemeldet und vorerst nur einen (englischsprachigen) RSS-kanal angemeldet, was einer mittleren katastrophe gleich kam, weil sich die apple news inhalte per RSS nicht aktualisierten und auch nicht editieren liessen. jetzt ist das apple news format teoretisch für jeden offen, aber apple lässt auch hier seinen manischen kontrollwahn walten. meine bitte um freigabe meines apple news kanals wurde bereits zweimal abgelehnt, weil die apple-türsteher zweimal meinten, dass mein kanalname ihnen nicht passt und mich zweimal zurückgewisen haben. von mir aus kann apple seinen news-format alleine nutzen, das zudem auch noch irre kompliziert und sehr proprietär ist.

ich habe wirres.net ein bisschen schneller genmacht, zumindest laut dem google page speed tool. das scheint jetzt, nach einigen umstellen, einstellen und priorisieren, einigermassen zufrieden mit der leistung meiner seiten zu sein und zeigt die ladegeschwindigkeit meist im grünen bereich an.

die anforderungen des page speed tools zu verstehen, oder genauer, die anforderungen für schnelles seitenladen zu verstehen, ist gar nicht mal so leicht. vieles von dem was google vorschlägt hört sich für meine ohren spanisch an.

JavaScript- und CSS-Ressourcen, die das Rendering blockieren, in Inhalten „above the fold“ (ohne Scrollen sichtbar) beseitigen

woher soll ich wissen, was above the fold ist, oder welche resourcen das rendering blockieren? mit versuch und irrtum habe ich mich dem aber langsam annäheren können. entscheidend ist jedenfalls, neben den grundvoraussetzungen wie einer relativ schnellen seitenauslieferung (zum beispiel durch vorhalten fertig gerenderter seiten) und möglichst (klein) optimierter resourcen (bilder), das enthaltenen CSS- und javascript-gedöns möglichst asynchron (also irgendwann) zu laden, nachdem der hauptseiteninhalt bereits da ist.

ansatzweise hatte ich das schon vor längerer zeit gemacht, so lade ich die zahl der likes und reaktionen und die reaktionen selbst schon länger asynchron (per ajax) nach. aber noch wichtiger scheint es, möglichst viele javascripte (jquery selbst, jquery plugins und den javascript-code selbst) und stylesheets ebenfalls asynchron zu laden — eben damit sie das rendern der seite nicht blockieren.

theoretisch geht das bei javascript ganz einfach, indem man sie mit der option async lädt. dann muss man aber darauf achten, dass die ladereihenfolge passt und nicht irgendein script versucht jquery zu benutzen, obwohl das noch gar nicht geladen ist. irgendwann hatte ich das aber rausgefunden, und jetzt lädt das ganze javascriptgedöns erst dann, wenn der browser es für nötig hält.

was ich seit vielen jahren für wichtig halte und was jetzt wieder sehr befriedigend läuft, ist wirres.net ohne aktiviertes javascript. alle grundsätzlichen funktionen, funktionieren auch ohne javascript. alles was per javascript nachgeladen wird, wie reaktionen oder kommentargedöns, funktioniert dann nicht, aber seitdem ich mich letzte woche von typekit verabschiedet habe und die brevia-schrift bei fontshop (werbelink) lizensiert habe, wird die brevia auch ohne aktiviertes javascript angezeigt. durch das schriftladen per CSS, sehen jetzt auch meine AMP-seiten mehr nach dem original aus (diese seite als AMP laden).

apropos CSS; komplizierter das google page speed tool zu befriedigen, wird es in sachen CSS. auch hier schlägt google vor möglichst viele resourcen asynchron oder zumindest später zu laden. leider gibt es aber keine möglichkeit einem <link rel="stylesheet"> einfach ein async-attribut hinzuzufügen. den CSS-code aufzuteilen und nur das wichtigste in den seitenkopf zu packen und das weniger wichtige ans seitenende zu packen, ist schonmal ein schritt nach vorne, lässt google aber immer noch meckern. es gibt aber einen offiziellen neuen weg, das über <link rel="preload"> zu machen. weil das noch nicht von allen browsern unterstützt wird, hat die filamentgroup mal wieder einen polyfill gebaut: „loadCSS, A function for loading CSS asynchronously“

der einbau dieser lösung hat mich am ende dann im google page speed tool in den grünen bereich gebracht.

* * *

die seitenladegeschwindigkeit auf wirres.net fühlt sich jetzt tatsächlich etwas schneller an, ein direkter vergleich mit einer AMP-seite zeigt, das die werte der regulären seiten ganz OK sind. AMP lädt diese seite in knapp einer sekunde (load), bzw. den DOM-content in 293 millisekunden. regulär lädt die seite in 1,29 sekunden (load), bzw. den DOM-content in 594 millisekunden. ich finde das sollte in sachen optimierung erstmal reichen.
 

seit diesem artikel ist die artikel-id meiner ez-publish installation auf 10.000 geklettert. das heisst nicht, dass ich 10.000 artikel auf wirres.net geschrieben habe, genaugenommen sinds 9429 veröffentlichte artikel. dazu kommen noch ein paar artikel von gastautoren. die fehlenden 513 artikel sind entweder gelöschte artikel, nie veröffentlichte entwürfe oder fehler.

seitdem ich für jedes instagram eine kopie als artikel aus der kategorie bilder anlege, ebenso für swarm-checkins, instagram-, twitter- oder youtube-favoriten — und tweets (meist) zuerst hier schreibe, bevor ich sie zu twitter oder facebook kopiere, ist die zahl der auf wirres.net veröffentlichten artikel stark gestiegen. deshalb ist auch die artikel-id im letzten jahr relativ schnell (nach 14 jahren) auf zehntausend gestiegen.

diese website läuft jetzt auf php7.4. das wurde erforderlich, weil uberspace, mein hoster, die alte plattform einstellt, auf der wirres.net viele jahre auf php5 lief. das CMS hier hinter ist bekanntlich sehr alt und lief nicht auf anhieb auf php7. nach zwei abenden fummeln und googlen lief dann aber doch alles auf der neuen plattform.

vorher hatte ich ziemlichen bammel auf irgend so einen modernen quatsch wie wordpress umsteigen zu müssen und meinem archiv „gute nacht“ sagen zu müssen. zumal ich das selbst wohl am meisten bedauert hätte, ich such ständig nach alten rezepten hier.

die nächsten 10 jahre wirres.net dürften hiermit aber erstmal (zumindest technisch) gesichert sein, php-rückwärtskompatibilität, stackoverflow, uberspace und geschicktem googeln sei dank. jetzt muss ich nur noch motivation finden mal wieder öfter was hier festzuhalten.

wer noch fehler findet, was ziemlich wahrscheinlich ist, kann mir gerne bescheid sagen.