Kommentare von

beats TEST blog

Weblog Kommentare

Vorschaubilder 400px

Ian Styx am |

Nicht das ich das wirklich verstehe..., aber in den Chrome Dev Tools unter Performance ist der längste Load bzw Warte / idle Strich (?) bei den woff2 raleway Google fonts Dateien. Und manche von ihnen sind grau, andere grün markiert.

Ich interpretiere das so, dass gar nicht alle fonts gebraucht werden und man schon an dieser Stelle einiges kürzen könnte.

Insgesamt wäre es ja mal interessant diese google fonts einmal zum intensiveren Testen des delays komplett herauszunehmen, bzw abzuschalten.

(und die skins/moona-lisa/icons.png des cke)
Beides zusammen sind schon fast eine Sekunde, wenn ich richtig rechne, nicht eingerechnet die Bearbeitung derselben bis Render fertig..

Beat Post author am |

Um schnell einen Eindruck zu kriegen: Könnte ich auf www.beatsblog.ch nicht einfach ma auf das pure-Theme wechseln und wäre somit die (in pure-beat eingebauten) Google-Fonts los? Dann Speed-Test machen und danach Theme wieder umstellen.

Irritierend find ich trotzdem, dass ich hier auf www.blog.dokumenzi.ch diese Verzögerungen nicht habe... für mich als Laien scheint das schon irgendwie mit dem Hosting zu tun zu haben.

Beat Post author am |

Ich habe das rasch getestet. Die Seite: https://www.beatsblog.ch/2599-Sizilien-Planung-abgeschlossen.html

braucht mit pure-beat-Theme 4,47 sec. und mit pure-Theme noch 4,10 sec. (davon werden 3,70 sec. als "wait" ausgewiesen.) Auch mit 2K11-Theme braucht die Seite 3.96 sec.

Die Verzögerung scheint also nichts mit dem Theme zu tun zu haben.

Diese Seite hier: https://www.blog.dokumenzi.ch/2629-Vorschaubilder-400px.html braucht gerade mal 900 msec., davon 277msec. "wait" ?

Ian Styx am |

Ja schon, aber es könnte/muss hier ein cache proxy (*) oder so für eklatante Beschleunigung sorgen...
Die load chain sieht komplett anders aus und der Unterschied ist frappant! (* Varnish ist es glaube ich nicht, denn mit dem hat es ganz ander Aussetzer)

Das wird sich aber in nächster Zeit noch weiter eruieren lassen wenn weitere Installationen auf verschiedenen Serverkonfigurationen dazukommen. Lokal ist das bei mir auch blitzschnell. An PHP 7.4 sollte es auch nicht liegen, denn so arg unterscheiden sich die 7er Versionen nicht in der Geschwindigkeit.

Ian Styx am |

https://www.beatsblog.ch/2598-endlich-mal-wieder-biken.html nur Wartezeit des Ladens 3910ms - rendering, parsing, composition, etc. geschieht erst danach und geht schnell.

https://www.blog.dokumenzi.ch/2629-Vorschaubilder-400px.html mit über 50 Kommentaren Zeit des Ladens 293ms
https://www.blog.dokumenzi.ch/1208-Schneetour.html 229ms Zeit des Ladens ist ca 17-fach kürzere Geschwindigkeit

Beat Post author am |

Die Situation ist immer noch die Selbe. Vom Manitu-Support habe ich nun seit 3 Wochen auch nichts mehr gehört. Da sollte ich wohl mal nachhaken.

Hast Du irgendwas mitgekriegt? Hat vielleicht Manitu mit Dir diesbezüglich Kontakt aufgenommen?

Ian Styx am |

Nee, ich habe mit denen nichts zu tun.

Ian Styx am |

Hast du auch schon probiert die/deine APC etc Optimierungen mitsamt dem Google fonts zum testen abzuschalten?

Ich finde diesen Delay immer noch ziemlich ridicullous - Frische 3.0 Installationen auf Debian Buster sind rasend schnell, natürlich ohne den Ballast von einem gut gefüllten Blog und deinen Seitengeschichten. Aber wie gesagt das sollte höchstens ~1 Sekunde betragen und nicht 4-5. Manitu sollte mal messen was da networkmäßig passiert. Ich kann mir das nicht erklären.

Beat Post author am |

Habe jetzt auf www.beatsblog.ch die Original .htaccess wieder aktiv (nach der Styx-Installation gesichert). Das macht (auf den ersten Blick) keinen Unterschied.

Den weiteren Kontakt mit Manitu betreffend dieser Single-Entry-Performance-Geschichte habe ich noch auf meiner ToDo-Liste, doch im Moment gurkt mich das Thema etwas an . ?  Aber ja, ich muss das nocheinmal anpacken.

Ian Styx am |

zur Sicherung würde ich auf mal htmlcomments ausschalten

Ian Styx am |

auch die GZIP-Kompression?

Wenn man aus dem Quelltext einer single Seite die einzelnen assets anklickt, sind die auch ziemlich schnell da - soviel zur Vermutung das irgendetwas schlecht oder schnarchlangsam lädt...

Ian Styx am |

und die drei Vorschaubilder... das Plugin mal deaktivieren.

Alleine das hier https://www.beatsblog.ch/uploads/2017/20170215_901.styxThumb.jpg braucht lt. Chromium
Duration 428.58 ms (100.25 ms network transfer + 328.33 ms resource loading)

Vielleicht muss man die irgendwie cachen zb für eine Zeit lang.... ?!?

Beat Post author am |

Ich habe mal auf www.beatsblog.ch alle Seitenleisten-Plugins versteckt, den Template- und den Browser-Cache gelöscht und dann die Seite mit pingdom.com getestet. Die Ladezeit betrug 4,08 sec. davon 3.67 Wait. Alle Pugins wieder aktiviert und dann betrüg die Seitenladezeit 4.59 sec. davon 4.16 Wait. Sieht also nicht so aus, als ob die Seitenleisten-Plugins einen grossen Einfluss haben.

Ich mache solche Sachen nicht gern, weil ich einfach zuwenig Ahnung davon habe. Für mich als Laie reicht der Vergleich zwischen hier und beatsblog.ch. Nehme ich z.B. die (zufällige) Seite /1230-zum-zweiten-Mal.html so dauert es auf beatsblog.ch 4.19 sec. davon 3.77 Wait und hier braucht der Seitenaufbau 0,52 sec. davon 0.18 Wait. Das sind einfach Welten! Klar: Welche Server- und Caching-Systeme jetzt wo und wie genau im Einsatz sind, übersteigt mein Wissen als Endkunde und ehrlich gesagt interessiert es mich auch nicht sonderlich. Da sollen Profis ran und dafür denke ich, dass möglichst identische Konfigurationen/Datenmengen zu Vergleichszwecken hilfreich sind.

Und ja, ich trete mir jetzt in den Hintern und schreibe den Manitu-Support nocheinmal an.

Ian Styx am |

sehr wohl ..! Allerwerteste gehören getreten, auch Sattelfeste ? (*)

ich kann mir auch nicht richtig erklären warum sehr viel mehr server- und db-load auf der list (entries) Seite so viel schneller läuft als ein single request, auch wenn in diesem ein paar zusätzliche JS mit entsprechenden requests geladen werden. Ich hatte halt das Chromium Audit tool entdeckt und ein wenig herumgespielt. Man muss halt den zusätzlichen CKE load und das horrible non Standard imagesidebar Plugin als mögliche Ursachen definitiv ausschließen können. Darum ging es mir (nur).

(*) Der Renner mit dem roten Sattel ist ja interessant und hat mich wieder erinnert mal nachzufragen... Sind solche schmalen Dinger eigentlich geeignet für nicht so sattelfeste Hintern? Ich habe jedesmal Schmerzen nach einer Stunde Fahrt und meiner ist ein ganz normaler Fahrradsattel. Und nachdem ich letztens über die ulkigen BikeBalls lesen durfte fiel mir das jetzt quasi "siedendheiß" wieder ein... ?

Beat Post author am |

Letzte Woche hat der Manitu-Geschäftsführer nach einen Feedback gefragt (vermutlich ein Standard-Mail an alle Neukunden). Heute habe ich zuerst beim Support nachgefragt (und Ihnen die obige Messung mitgeschickt). Danach schrieb ich mein Feedback-E-Mail. Beides zusammen baut vermutlich nun etwas Druck auf. Mal sehen.

Fahrradsättel ist ein Thema, zu dem es keine richtig/falsch oder gut/schlecht Antworten gibt. Jeder Arsch ist verschieden ?

Es gibt niemanden, der untrainiert länger Fahrrad fahren kann, ohne Sitzbeschwerden zu kriegen. Es spielen viele Faktoren eine Rolle: Abstand der Sitzknochen, Sitzposition (aufrecht-gestreckt), Fahrergewicht, Einsatzzweck und sonst noch ein paar Dinge. Der rote Sattel auf dem Foto ist vermutlich der hässlichste Sattel, den ich kenne. Doch für meinen Freund ist genau dieser Sattel auch auf lange Distanzen bequem und nur das ist wichtig. Jeder halbwegs ambitionierte Biker hat wohl X Sättel getestet, bis er das passende/bequeme Modell gefunden hat. Das ist die traurige Realität.

So zur Info ist diese Seite recht gut: https://www.sq-lab.com/ergonomie/sqlab-kontaktstellen/becken/

Ian Styx am |

Uff. Ja so ist das wohl. Danke. Eine Wissenschaft für sich!

Ich sagte ja auch "..interessant.." ;-) Erinnert ein wenig an die Schnabelschuhe aus dem Mittelalter https://sattlerei.cz/de/kategorie/52-schnabelschuhe

Beat Post author am |

Ich schreib jetzt nicht, woran mich der rote Sattel erinnert... ?

Wohlgefallen - DANKE !

Ian Styx am |

Zu 1

1. Beispiel:

<a class="serendipity_image_link" href="/uploads/test/The_Whale.jpg"><!-- s9ymdb:237 --><picture><source alt="" class="serendipity_image_left" height="375" srcset="/uploads/test/.v/The_Whale.serendipityThumb.webp" type="image/webp" width="400" /><img alt="" class="serendipity_image_left" src="/uploads/test/The_Whale.serendipityThumb.jpg" style="width:400px" /></picture></a>

und für das 2. Beispiel

<picture><source alt="" class="serendipity_image_left" height="375" srcset="/uploads/deinBild.webp" type="image/webp" width="800" /><img alt="" class="serendipity_image_left" src="/uploads/deinBild.jpg" style="width:800px" /></picture>

siehe 
https://www.blog.dokumenzi.ch/2567-webp-Bilder.html#c5444
https://www.blog.dokumenzi.ch/2567-webp-Bilder.html#c5439
https://www.blog.dokumenzi.ch/2567-webp-Bilder.html#c5445

Nochmal zum mitschreiben...

Browser können heute alle eine "Fallback"-kette nutzen. Man bietet etwas an in seiner modernsten und besten Form (zb mit dem kleinsten load impact), darunter verschiedene abgestufte Varianten bis hin zum "veralteten" einfachen Bild. Dazu benutzt man das picture/source Element. Hier stark vereinfacht:

<picture>
    <source srcset="/uploads/deinBild.webp" type="image/webp" />
    <img src="/uploads/deinBild.jpg" />
</picture>

Videos oder Audios sind davon unbhängig, aber haben ähnliche fallback chain Geschichten auch mit dem source Element.

Nun bekommst du von Styx zwei Buttons "Medien Einfügen" und "Als Picture Element". Den Rest macht das System automatisch und fügt das generierte dann in deinen Quelltext ein. Je nach Browser lädt nun deinBild.webp oder eben das alte und schwere deinBild.jpg.

Beat Post author am |

Ich glaube, soweit verstanden zu haben...? Das heisst, ich speichere/uploade immer noch jpg-Bilder, wähle unter Wartung "Erstelle alle Bild-WebP-Format-Variationen" und füge  das Bild dann mit "Als <picture> Einfügen" in meinen Beitrag ein? Denn würde ich ja bereits ein webp-Bild hochladen, würde der Safari-Besucher nichts sehen. Richtig ❓

Ian Styx am |

Zu 2:

Bis vor ein paar Jahren verwendeten Serendipity wie auch die Anfänge von Styx eine Auszeichnung für vom System generierte Thumbnails, also die Vorschauen. Da war das sehr lange serendipityThumb, dass dann einfach zum Namen hinzugefügt wurde, so dass man immer 2 Bilder desselben in der Mediathek hatte. Das heraufgeladene (und ev. beschnittene) Originalbild und das generierte Vorschaubild. Das kam mir irgendwann zu lang vor, deswegen die Änderung auf styxThumb.

Alte Einträge mit serendipityThumb und neue Einträge mit styxThumb können völlig unbehelligt voneinander in der Mediathek leben. Man muss sie nicht umstellen. Wenn man es aber - schon aus ästhetischen Gründen - doch gerne möchte, kann und sollte man dies über die Wartung (Mediathek: Vorschauen erneuern: Erneuere alle (*.serendipityThumb) Vorschaubilder und vice versa) automatisiert ablaufen lassen.

Bis man Vertrauen in die dortigen Routinen hat, sollte man sich vorher ein SQL-Backup der image, mediaproperties, entries, entryproperties und staticpage Tabellen ziehen und auch den uploads Ordner einmal weg-(backup)-packen.

Ian Styx am |

Zu 3:

Der Wartungsaufgabe "Mediathek: Vorschauen erneuern - Erstelle alle Bild-WebP-Format-Variationen" ist für Upgrader gedacht (so wie du jetzt einer bist, mit all deinen alten Bildern und entries etc.) und hilft ihnen all die alten Bilder automatisiert als webp Variationen neu zu generieren. Das heißt, jedes Bild und jedes thumb bekommt eine webp Variation in demselben Ordner als Subordner /.v/ und dem gleichen Namen, halt mit webp extension. Dies gilt, sobald dein System GD / ImageMagick das auch kann.

Alle neu heraufgeladenen Bilder im format jpg / jpeg / png usw (soweit zulässig) werden automatisch auch als webp Variation gespeichert. Man macht also nicht anderes als das was man vorher auch schon gemacht hat.

Auch Safari kann damit umgehen, wenn man es über das picture source Element ausgibt. Dann pickt sich Safari halt die "alten" jpg/png Dateien im generierten img tag stattdessen (herunter).

Einzige Ausnahme ist, du lädst gleich webp Original Dateien herauf. Dann werden sie so behandelt wie andere Bilder auch, bekommen aber natürlich keine Variation und können auch nur von Browsern anzeigt werden, die dies beherrschen.

Pfui Apple! Setzen! 6!!

Ian Styx am |

Fast!
Ja, Nein, Ja, Ja, Ja,
...siehe andere antworten ?

Ian Styx am |

Ich konnte mich bei den Vorschaubildern nicht für eine grössere Grösse als 200px (Breite) entscheiden. Smartphones zeigen aktuell ca. 400-500 Pixel in der Breite. Oft platziere ich links und rechts im Text ein Vorschaubild. Bei 200px Breite können diese noch nebeneinander dargestellt werden.

Ich breche nochmal eine Lanze!  Die default Breite von 400px für ein Thumbnail hat visuelle Gründe, wie die Darstellung und Feinabstimmung in der Mediatheksanzeige und deren Tasks und für die Mediatheksanzeigen für die Eintragsformulare. Aber es hat auch praktische Gründe, denn Browser können heutzutage skalieren, besonders, wenn man ihnen wie auf Serendipity und besonders Styx dabei hilft. Ist das Ausgangsmaterial bereits zu klein, wie bei zu kleinen Thumbs, wird auch keine Variation erstellt, da sich das dann oft nicht lohnt.

Das heißt, 400px werden auf Smartphones nicht als 400px angezeigt, wenn der Breite kleiner ist! Ausprobieren!

Das heißt auch, dass links- und rechtsumflossene Bilder auch entsprechend herunterskaliert werden, je nach Device; denn dort gilt (für viele themes) eine prozedurale "interaktive" Skaldierung! Du kannst also für alles was unterhalb einer gewisssen Größe liegt, dies auch so in die user.css einfügen, was den ungemeinen Vorteil hätte, dass größere Screens auch etwas zu sehen bekommen würden, denn - ehrlich - von diesen Minis kann man ja nun nicht behaupten, dass sie einem (älteren) Auge ? auch alles zeigen würden. Also ist man immer gewungen die großen Bilder durch die lightbox zu laden.

/* auto scales 400px left and right oriented images with floated text */
@media screen and (max-width: 767px) {
    .post p > .serendipity_image_left,
    .post p > .serendipity_image_right {
        max-width: 48%; }
}

Wie du sehen kannst, kann die WebP Variation bei gleicher Qualität und Bildgröße erhebliche KB Einsparungen ergeben, so dass alles viel flüssiger läuft und erheblich mehr zur gleichen Zeit und mit dem gleichen impact angezeigt werden kann (siehe die Anzahl Einstellung und das temporäre verkleinern durch die "2-3-4-Zebras", du erinnerst?!).

Zb ist das vorher oft ein Problem gewesen, wenn man in Spartacus die zusätzliche Themes anzeigen Option aktiviert hatte. Dann wurden 112 zusätzliche Themes gezeigt. Hier hat webp wahnsinnig geholfen.

Das gilt eben auch für die Mediathek.

In ein paar Monaten wird es ein weiteres Format geben mit dem schönen Namen AVIF, von der Alliance for Open Media (AOMedia), dass noch einmal einen deutlichen Qualitäts-Erhaltungs bei gleichzeit deutlichen Schrumpfungsprozeß ermöglicht und webp damit ganz toll erweitert. Es wird dann bald nicht anderes mehr geben, prophezeie ich..! ?

Ian Styx am |

Ich würde das scriptled sogar gerne in pure so oder so ähnlich als default style übernehmen wollen, allerdings kann dann niemand mehr out-of-the-box kleinere Thumbs verwenden. Die wären dann nur noch Miniaturen Makulaturen. ?

Oder gar in die default_fallback style...  ach das gäbe ein Geschei... ?