Beiträge von chris21

Ich hatte eine Seite, wo es Probleme gemacht hat. Da konnte man den Inhalt einer Liste in einem iframe mit einem Button expandieren (wodurch sich über dem Button die Liste verlängert) , also zB zu Eintrag 1 bis 10 dann 11 bis 20 dazuladen. Der FF66 hält dann die Leseposition des Buttons, scrollt also heimlich weiter runter. Damit sieht man dann aber Eintrag 20 zuerst, obwohl man ja bei Eintrag 11 weiterlesen wollte. (Hinweis: der Aufbau war noch viel komplizierter, aber damit ihr ungefähr versteht, worum es geht).

Eigentlich geht es um folgendes:

Wenn ich mit meiner lahmen 16er DSL Leitung Spiegel Online aufrufe, habe ich es ganz oft geschafft, beim Klick auf einem Link aus der Liste "Meist gelesen" (rechte Spalte) ausversehen auf eine Anzeige zu klicken, weil da Anzeigen nachgeladen wurden, wodurch sich der Inhalt weiter runtergeschoben hat und während ich klicke unter dem Mauszeiger nicht mehr der meistgelesen Artikel verlinkt ist sondern eine nachgeladene weiter oben stehende Anzeige die Fläche besetzt. Dieses: "Inhalt wird durch nachladen weiter oben positionierter Elemente runtergeschoben" soll overflow-anchor verhindern, damit man im Lesefluss nicht gestört wird, auch wenn über der Leseposition noch irgendein Zeugs (meist ja leider Anzeigen) nachgeladen werden.

Für alle, die endless pages einsetzen, mit Scrollpositionen spielen, Content nachladen oder expandieren oder iframes einsetzen, bitte unbedingt das Seitenverhalten im neuen FF (>=66) testen. Die haben jetzt auch overflow-anchor im CSS drin mit default auto. Allerdings spinnt der FF im Verhalten hier (anders als Chrome, der es schon länger hat) öfter mal und schießt über das Ziel hinaus. Also unbedingt testen.

@Syno: messerscharf gute Analysen. Der Punkt mit den Zielen (auch bei Reisezielen): da ist G. seit einigen Monaten "krank". Wird für uns also schwer, G. da besser zu lenken.

Aber die Strukturanalyse von v-k ggü. abo ist super.

Ich wollte hier den richtigen Begriff nicht schreiben, daher hatte ich auf die Niederländer verwiesen. Hanseaten kennen es meines Wissens nicht, aber ich war ja lange genug Forenser. Mir ging es aber gerade um Bo..eln und das hat mit "Chef"eln nichts zu tun...

Seit wann schreibt man denn Klootschieten mit Doppel-s? Soll die Seite die Schweiz ansprechen? Langes o, also ß.

Auch wieder wahr.

Warum soll man bei irgendeiner Software auf eine X.X.0 Version aktualisieren? .= sind immer neue Features, aber eigentlich immer mit Bugs. Ich aktualisiere in Produktivumgebungen immer erst, wenn es eine .1 oder .2 gibt, egal ob Firefox, iOS, Matomo oder was auch immer... Die .0 er sind allenfalls zum testen der neuen Features in Nicht-Produktivumgebungen.

Stimmt, crossorigin hätte ich noch erwähnen sollen, dabei habe ich das doch gerade Di. gemacht... zuviel los diese Woche.

Auch wichtig: die Werte bei Lighthouse können schwanken, derzeit rasselt der Server zB und schon gehen die Werte runter, weil eben TTFB extrem wichtig ist. Und das ist eben nicht Frontend Arbeit sondern Backend Arbeit. Die Eintrag hier von gestern zu diesem Thema kam tatsächlich daher, dass ich im Servercode ein Skript in der Laufzeit um 70% reduzieren konnte und damit endlich auf die 100% im Desktop kam. Normalerweise doktere ich eher im Frontend rum. Aber neben der TTFB Geschichte sieht es bei ganz gut aus, dass heißt, wenn der Server ziemlich am idlen ist, bin ich bei 91 bis 93 mobile. Mit Adsense oder anderem Mist von G wird man da nur hinkommen, wenn man alles von G lazy loaded.

Wenn Du also bei der Betrachtung bessere Laune bekommen willst, teste mal nachts um 23 Uhr oder um 1 (sofern da nicht besondere andere Systeme bei Dir Resourcen ziehen).

Früher waren die Pagespeed Tests ja reine Frontend Geschichten. Inzw. ist - über webpagetest.org (von Google gekauft) und dem Lighthouse Projekt, was darauf fusst, die Servergeschwindigkeit viel wichtiger geworden. Und da sind eigentlich Du - und vll. auch Alex - besser für aufgestellt. Alex redet ja auch immer von 200ms TTFB. Das ist nun auch mein Kampfbereich.

Ich habe kein 100 auf mobile.

Oben auf dem Screenshot wird ja Desktop gezeigt, mobile bin ich irgendwo über 90, so bei 91 bis 93.

Bzgl. Mobile 100 siehe mal die Insel der Sissi. Und da wird es lustig, weil die Seite nicht responsive ist und die Techniken von annodazumal, aber läuft :). Daran sieht man auch, dass nicht die untenstehenden Hinweis entscheidend sind bzgl. Punkten bei Lighthouse sondern die Werte, die oben bei mir im Screenshot noch mit drin sind, also TTFB, First Draw, etc.

Ein alter Bekannter aus dem Forum schafft sogar ein 100/100. Mit einer Nicht-responsive Seite und Technik(en) von vor 10 Jahren. Übrigens viele sehr alte, früher mal gut optimierte Seiten schneiden da gut ab. Wenn mann aber Fotogalerien, Interaktive Karten und (zuvor auf Serverseite) umfangreichste Skripte laufen hat, wird es schwierig, insb. bei letzterem.

Es geht um die Tiefe bei dem Woff laden. Tiefe 1 (CSS direkt im HTML, daraus Anweisung auf Woff) ist besser als Tiefe 2 (CSS Anweisung aus HTML, Woff Anweisung aus CSS).

Preload hilft dafür nicht (bzgl. Tiefe), weil es dabei nur ums laden geht und nicht ums "verwenden"/"ist wichtig" Wissen für den Browser als Interpreten.

as="font" type="font/woff2"

und dann entsprechend synonym für die anderen font types.

Ich würde erstmal mit CSS für above the fold in eine head style node anfangen, da dort ja die font drin ist, reduziert sich die Tiefe des kritischen Pfades gleich mal um eins. Auf preload Anforderungen würde ich nicht immer achten, weil sie manchmal Stuss sind. Aber preload setzen kannst Du ja immer (wo es sinnvoll ist), wenn der Browser preload nicht versteht, wird er ja später noch die Anforderung finden. Durch preload alleine ist es ja nicht vorhanden, es muss ja auch irgendwie referenziert sein.

Mit einmal geladen und langen expires ist schön und gut, gilt aber nicht für den Erstbesucher und der ist die Messlatte.

Für den würde ich das alles css für above the fold in eine style node in de head packen und nen preload für die open-sans. Also jetzt auf f-n bezogen. Und sowas wie leaflet.css und ähnlichen Krams per js nachladen, wenn Du nen Ready hast und die Map gezeichnet werden soll.

Und inline muss das css ja nur geladen, wenn er keinen cookie von dir hat und der letzte Besuch über ein Jahr her ist. Das wäre doch einfach zu regeln

Syno, warum brauchst Du denn externes CSS, statt für alles above the fold direkt im head?

Könntest Du wenigstens alternativ http/2 unterstützen?

PS: Kannst Du Adsense nicht komplett lazy loaden? Also das ganze Script?

Die Tiefe der kritischen Anforderungen ist praktisch der Dateibaum, der für ein erstes Zeichnen benötigt wird, also das HTML selbst, dann - sofern noch ohne defer oder async im head verlinkt, das CSS und dann zB im CSS hinterlegte Hintergrundgrafiken, Fonts, etc. D.h. alles, bei dem es noch heißt: a darfst Du erst ausführen, wenn du auch b (und c und d ...) dafür hast, wobei a eben das HTML wäre, b, c, d, etc. blockierende css, js, Grafiken, fonts, etc.

Aufwand für Hauptthread sind HTML/CSS/das meiste JS, Request Animation Frames, etc, alles was nicht asynchron laufen kann/definiert ist.

Bzgl. Adsense: Googles Services sind in meinen Augen immer der größte Verbreche für Pagespeed, daher nutze ich nirgendwo irgendwas von Google, weder Maps, noch Adsense, noch Fonts, noch Analytics noch irgendwas anderes aus dem Hause Google und allgemein auch nichts aus externen Quellen, die ich nicht selbst kontrolliere/kontrollieren kann.

Der größte Gewinner in meine Nische hat tatsächlich mobile 99 und desktop 100 bei pagespeed insights. Für mich sieht es vielmehr wie ein Scharfstellen/Verschärfen des Mobile Speed Updates von Juli 18 aus. Daher bin ich da ja auch gerade massiv dran.

Schick mir mal bitte ne pm mit einem der mobil verlorenen Reiseportale. Vll. fällt mir was auf.