Seite 2 von 2

Verfasst: 28.02.2017, 00:24
von Sebastian_
Hi Chris,

vielen Dank!
Freut mich, dass jemand an der Aufgabe mitfiebert und sich nicht mit der zweitbesten Lösung zufrieden geben wird.

Ich habe wieder ein paar Tests durchgeführt (u.a. die Background-Anweisung in das externe CSS, welches auch die Schriften beinhaltet, geschrieben und die zweite JS-Funktion rausgenommen: Gleicher PageSpeed).
Weiterhin habe ich jetzt mal Testseiten eingerichtet, damit das besser nachvollziehbar wird:

Testseite 1
Bei dieser Testseite sind die Bilddaten im ATFCSS. Der Optimierungsvorschlag von Google erhält also direkt die Roundtrips, falls es an diesen liegt (in dem Test sind mehr als vier erforderlich). Mein Clipboard hat wohl einen Teil der Daten abgeschnitten, also nicht wundern, dass das Hintergrundbild nur zur Hälfte angezeigt wird.
Ergebnis: 95/100 Desktop, 85/100 Mobil

Testseite 2
Hier habe ich das Hintergrundbild "tiny" werden lassen (100px jpg-width), das Ergebnis ist schlechter als vorher, da nun das Bild noch optimiert werden sollte. Ansonsten keine Änderung, es scheint also nicht an der Größe selbst zu liegen, sondern an dem erforderlichen Roundtrip trotz JavaScript-Pipe.
Ergebnis: 95/100 Desktop, 100/100 Mobil

Die Header sind jetzt nun auch im Sinne des Mozilla Observatory angepasst, bis auf CSP. CSP ist in der .htaccess bereits vorbereitet, kommt allerdings noch nicht zum Einsatz, denn aktuell liegt noch JavaScript inline. Sobald dies externalisiert ist, werde ich den CSP Header auch setzen.
Mozilla Observatory (aktuell): 75/100, nach der Änderung dann wahrscheinlich 100/100.
Mich hat jedoch gewundert, dass die HSTS-Preload Header Zeit vom Mozilla Observatory länger angegeben wird, als von der HSTS-Preload-List. In der HSTS-Preload-List ist die Seite bereits angemeldet, Status: pending.

Ich bin sehr gespannt, ob wir für die Herausforderung eine Lösung finden werden. Den Roundtrip der externen Ressource zu eliminieren, ohne die Ressource selbst an alle Geräte auszuliefern, wird nicht gerade einfach (bzw. die externe Ressource so laden zu lassen, dass es zu keinem FOUC kommt und der PageSpeed gut bewertet wird). Dies scheint wohl auch für meine Schriftarten zu gelten (extern im CSS, nicht im ATF CSS) - ich dachte bisher, dies hätte ich durch die JavaScript-Funktion umgehen können. Nehme ich eine andere und/oder deutlich langsamere Funktion, kommt es zu einem FOUT bzw. FOUC bei Chrome.

HTTP/2 war auch meine Idee, im Hinblick auf mehrere Ressourcen aber nicht sehr praktikabel und ohne Unterscheidung zwischen Mobil und Desktop leider zu großer Overhead.

Insbesondere, sobald mehrere Bilder ins Spiel kommen. Die Lösung für das Hintergrundbild setzt ja nur den Grundstein zur Erweiterung.

@Cin Media:
Vielen Dank für die Hinweise. Die Webseite ist, bezogen auf Content & Design, noch weit davon entfernt, vollständig zu sein. Bilder als auch Videos sind in Planung und werden selbstredend demnächst hinzugefügt.
Vielleicht kurz zum Hintergrund: Ich habe mir ein Framework geschrieben um Webseiten auf technisch höchsten Niveau ausliefern zu können. Die Bezeichnung "CMS" würde ich dafür nicht verwenden wollen, denn CMS bedeutet mittlerweile eher klicky-klacky-alles-bunt als eine technisch korrekte und performante Umsetzung. Das Framework soll auch in anderen Projekten eingesetzt werden, die Arbeit fließt also nicht nur in eine Seite.
Die doppelten Bindestriche sind Delimiter und persönliche Geschmackssache.

@Can:
Klar, kann man so machen. Werde ich jedoch nicht, siehe erster Post (Datentransfer Mobilgeräte).


Mit besten Grüßen

Sebastian Höhne
Admody RAe AG: Gewerblicher Rechtsschutz, Handels- & Gesellschaftsrecht als auch IT-Recht

Verfasst:
von

Verfasst: 01.03.2017, 02:56
von Sebastian_
Hi,

so, da ist nun meine Lösung: Keine Datenauslieferung des Hintergrundbildes an Mobilgeräte, kein Cloaking oder andere Verschleierungstaktiken.

https://www.admody.com

PageSpeed Insights: 100/100 Mobil, 100/100 Desktop
https://developers.google.com/speed/pag ... ab=desktop

Mozilla Observatory: 100/100 (A+, eigentlich 100/135)
https://observatory.mozilla.org/analyze ... admody.com

HTML-Fehler: 0
https://validator.w3.org/nu/?doc=https% ... ody.com%2F

CSS-Fehler: 0
https://jigsaw.w3.org/css-validator/val ... g=&lang=de

GTMetrix PageSpeed: 100/100
https://gtmetrix.com/reports/www.admody.com/EINc3MYg


Einziger Wermutstropfen: FOUC/FOUT aktuell bei mir im Chrome, ggf. muss ich die JavaScript-Funktion anders ausführen oder das Rendering um ein paar ms verzögern lassen.

Beste Grüße

Sebastian Höhne
Admody RAe AG: Gewerblicher Rechtsschutz, Handels- & Gesellschaftsrecht als auch IT-Recht

Verfasst: 01.03.2017, 08:56
von Can
Ja der fout ist übel, vor allem da er auch immer beim Navigieren auftritt. Würde testweise die fontface Anweisungen mit ins inline CSS packen, oder meckert dann der Test?

Verfasst: 01.03.2017, 09:50
von ole1210
Servus Sebastian,

hast du mal über ein generell neues Layout nachgedacht? Du greifst die selbe Farbgestaltung wie irgendwelche warez&co Seiten auf.

Ich würde alles deutlich heller, seriöser & vertrauenserweckender gestalten. Damit hältst du die Kunden länger auf der Seite, generierst mehr Seitenaufrufe, etc. Das wiederum ist deutlich relevanter als ein Pagespeed von 97 oder 100 Punkten.

Nebenbei sprichst du mit einem seriösen Auftritt auch mehr Mandanten an!

Verfasst: 01.03.2017, 13:50
von chris21
@Sebastian:

Dann war der Lösungsansatz von hier https://www.abakus-internet-marketing.d ... ml#1002196 :
Eventuell sogar mit einem eigenen externen CSS und dort als data URI, die mit rel="stylesheet" und media="screen and (min-width:769px)" geladen wird (eventuell async).
ja recht passend (zusammen mit dem nachladen des externen css über die media-Anweisung im JS). Danke, werde ich gleich mal bei einem Projekt testen.

PS: Im noscript-Bereich scheinen die media Angaben für die beiden CSS vertauscht zu sein (bzgl. min-width und max-width).

Verfasst:
von

Verfasst: 01.03.2017, 14:16
von Sebastian_
@chris21:

Noch nicht ganz - die Lösung würde zu einem Pagespeed von 80/100 (Mobil) und 91/100 (Desktop) führen (selbst mit async, was ein HTML-Fehler wäre), siehe

https://www.admody.com/test--6

bzw.

https://developers.google.com/speed/pag ... tab=mobile

@can:
Die JavaScript-Anweisung ist zwar für den Pagespeed gut, allerdings ist der FOUC @Chrome (leider nicht nur FOUT) noch zu heftig. Da bin ich mir des Lösungsweges noch sehr unsicher. Ich werde mir mal bei Gelegenheit genauer angucken, wie man konkret einen Repaint in der Konstellation verhindern kann.

@ole1210:
Ich mag das Design, obwohl es wie gesagt nicht final ist.

Verfasst: 01.03.2017, 14:53
von chris21
@Sebastian:

schon klar, statt async ist die media Änderung durch JS drin. Deswegen "recht passend" (d.h. die Richtung aufzeigend) und nicht 100% passend.

Aber schön, dass wir das Tool auch nach dem neusten Update wieder austricksen können ;)

Verfasst: 02.03.2017, 00:13
von nerd
Hallo,

late to the party, aber hier trotzdem noch ein paar anmerkungen:

Das hintergrundbild its mit 1700 breite viel zu gross. auch wenn es inzwischen viele laptops mit 1920x1080 px displays gibt, heisst es nicht dass dein hintergrundbild auch jedes pixel davon individuell nutzen muss.
Bei vielen laptops sind die bildschirme immer noch relativ klein, aber dafuer hochaufloesend. Soll heissen das man beim normalen leseabstand sowieso nicht jedes pixel einzeln erkennen kann, wie noch vor 20 jahren als die laptops mit 800x600 bildschirmen hergestellt wurden.
Es ist durchaus ok das bild auf 1200 breite runterzuskalieren, und dann vom browser wieder hochskalieren zu lassen. Gerade bei hintergrundbildern die nur zur dekoration diehnen schaut der user nicht so genau hin, sodass du da mit der bildqualitaet nicht so anspruchsvoll sein musst wie z.b. bei hochglanz-produktbildern im shop.
Ich habe das bild mal testweise auf 1200 breite verkleinert und die jpeg kompression auf 20% gesetzt, das ergebniss sieht immer noch gleich aus, es sind keine artefakte zu erkennen aber die datei ist nur noch halb so gross.

Ich wuerde davon abraten, solche grossen dateien als base64 einzubinden, einfach weil es extrem viel overhead erzeugt (um die 25%?) im vergleich zu einer normalen datei die extern eingebunden ist. Sowas mache ich selbst eigentlich nur bei kleinen icons die im header/footer auf jeder seite eingebunden werden, und damit mit dem CSS file selbst vom browser gecachte werden koennen.

Dann setzt du noch GZIP fuer jpeg files. Ist unsinn, da jpeg ohnehin schon komprimiert ist und du mit gzip die datei im unguenstigsten fall sogar wieder groesser als das original werden koennen. gzip macht nur sinn bei text-basierten dateiformaten wie html, css, js, xml usw...