Beiträge von Synonym

Ja, das mit dem "unused" ist auch so ein Thema, das ich oben meinte. Google widerspricht sich da. Ich für meinen Fall habe alles in einem File, CSS und alle JS, 1 Jahr Cache-Freigabe. Natürlich ist da vieles drinnen, das man dann auf der expliziten Seite nicht braucht, aber eben auf anderen. Also was tun? Wieder splitten? Dann ist "unused" weg, aber die Requests steigen und die Zugriffszeit, da eben kein Cache mehr.

Danke für die Info Also leere Divs und <p> hatte ich noch nicht auf dem Schirm. Aber ja, letztendlich kann es alles sein. Aber wie gesagt, ohne die Seite zu kennen, Schneekugel.

Wie erstellst Du denn das "critical CSS"? Passt nun nur nicht hin, aber ja, das ist auch ein Faktor. Hast Du ein Tool dafür, das das gut kann? Ich selbst nutze da https://jonassebastianohlsson.com/criticalpathcssgenerator/

Welches Feature? SVG als Inline-Bild? Wäre ja Mist, musste so lange suchen.... Oder was meinst Du genau? Es gibt LazyLoad ja nun als drei Varianten, siehe oben.

Das steht in den Berichten. Wenn Du das Tool von Google nutzt, dann steht unten 6.1. Wenn Du Chrome nutzt und dort Lighthouse startest, dann steht da 5.7. Genau genommen ist es 5.7.1 im aktuellen Chrome.

Google Insights

Chrome

Ok, hat sich überschnitten....

Ja stimmt, mit einem Container drum rum geht das auch. Ich habe das so gelöst, ging ebenfalls: Natives Lazy Loading mit 1x1 Platzhalter und Kumulative Layoutverschiebung (CLS)

Entscheiden ist dabei, das Native LazyLoading. Das normale per Script ging immer

Du hast Infos / erfahrungen? Dann teile sie doch einfach mit. Das hier ist ein Hilfe-Forum. Jeder freut sich, wenn er Infos bekommt ohne erst gezielt nach was fragen zu müssen, wo er vielleicht gar nicht weiß, was er fragen soll. Danke!

Habe mich nun mal wieder etwas mit meinen Seiten beschäftigt und kann daher sagen, anhand der Screenshots, dass Lighthouse wohl auch ein Problem mit CSS display:flex hat und das nutzt Bootstrap sehr wahrscheinlich.

Ich habe hier z.B. per Desktop einen Wert von 0,2, wo ich absolut keine Verschiebung sehen kann. Per Mobile ist es 0,015, aber da sehe ich eine. Komisch irgendwie.

Man muss auch beachten, dass das "Page Speed insights" mit Lighthouse 6.1 arbeitet, während die Felddaten mit 5.7 ermittelt werden.

Oh ja, was für ein Thema. Hatten wir doch schon mal, aber egal. Ohne URL und das selber sehen ist das schwierig. Die Kumulative Layoutverschiebung kann von sehr sehr vielen Dingen ausgelöst werden, darunter auch welche, die man extra nutzt, damit die Seite an sich schneller wird, z.B. LazyLoad bei Bildern. Das ist aktuell ein wenig das Problem bei Google und dem Tool. Man setzt Techniken ein, die einen Wert besser machen, dafür machen genau diese Techniken einen anderen schlechter.

0,015 ist ja schon mal ein guter Wert. Ich komme in der Regel nicht unter 0,2.

Mit den Bildchen vom Tool kannste auch nicht viel anfangen. Ich empfehle Chrome in dem Fall. Dev-Console auf, Reiter Performance. Wichtig: Dort Screenshots einschalten, dann Aufnahme starten und Seite neu laden. Aufnahme wieder stoppen. Da bekommste dann viel viel mehr Screenshots und kannst erkennen, was sich hier nun genau verschiebt.

So Aussagen wie das col-12-Div sind meist einfach nur Unfug. Bei mir meckert Google als Position das "<div id="content">" an. Klar. Das ist der Main-Container. In meinem Fall ist es Lazyload, der dann ein passendes Bild liefert, das aber andere Seitenverhältnisse hat als der Platzhalter. Daher verschiebt es den floatenden Text darum und reicht auch noch, dass die nächste Überschrift etwas "zuckt".

Verantwortlich kann dafür sehr vieles sein. Lazyload, externe Fonts. Scripte, die was nachträglich einbauen, Werbung, CSS, das per Defer kommt etc.

Ja, die Felddaten sind über einen längeren Zeitraum, daher gibt es auch nicht bei jeder Webseite welche. Es muss schon eine gewisse Anzahl an Zugriffen da sein. Der Zeitraum ist 28 Tage und wird von Usern mit Chrome-Browsern erfasst. Daher sind da auch Unterschiede zu den selbst gemessenen Lab-Daten, denn andere User haben andere Computer. Und ja, die Daten passen sich nicht unmittelbar an, quasi nur täglich, wenn der erste Tag raus fällt und ein neuer dazu kommt. Sollte sich aber da nicht grundlegend was an der Webseite geändert haben, also bei den neu hinzukommenden Tag, dann bleiben die Daten in der Regel fast gleich, ist eben ein Durchschnitt.

Was ich selbst noch nicht so ganz verstanden habe ist, was der Unterschied zwischen Felddaten und Origin Summary ist. Letzteres, wenn ich mich nicht irre, sind echte Daten, auch aus den letzten 28 Tagen, aber zu wenige, um Felddaten zu erzeugen. Die Felddaten scheinen also aus den "Origin Summary" zu kommen.

Eigentlich sollte da nichts unterschiedlich sein, denn wenn ein Formular gesendet wurde, die "Dankes Seite" da ist und man F5 drückt, dann hat man ja keine Option, etwas zu ändern. Der Browser schickt dann ja einfach alles noch mal.

Und nein, so was wie einen Token habe ich nicht. Bzw. schon, aber nicht im serialize. Da sind genau deswegen nur die Daten drinnen, die oben erwähnt sind. Natürlich gibt es noch weitere Daten, IP, Zeitstempel, andere Felder, DSGVO etc, aber das ist alles nicht im Hash enthalten.

Und ja, ich logge nun schon das komplette $_POST mit. Bisher habe ich nur welche, die ebenfalls einen Reload machten, der aber abgefangen wurde. Seit dem Post oben kam wieder mal keiner doppelt und dreifach durch.

Und ja, natürlich wird validiert. Die Zeilen oben sind quasi direkt nach der Prüfung, danach kommt DB-Eintrag. Vorher sind noch 200 weitere. Die Felder können z.B. nicht leer sein oder falsche Angaben enthalten, das wird vorher geprüft und wenn erforderlich, abgebrochen mit Fehlermeldung. Das Datum kann man z.B. gar nicht per Hand eingeben, das macht eine Auswahlbox, damit eben schon mal da das Format stimmt. Email wird geprüft, ob von der Syntax her richtig und der Host auch erreichbar ist etc.

Danke Forumsfossil.

Weg 1 ist nicht wirklich eine Lösung, denn so weit ich weiß bekommt man bei einem "insert irgnore" keine Rückmeldung, ohne da noch andere Abfragen zu starten. Es geht nicht um den Eintrag in die DB, sondern darum, dass der überhaupt erzeugt werden soll. Natürlich kann ich das auch so machen und damit zumindest verhindern, dass Mails mehrfach raus gehen.

Weg 2, also normalisieren. Ist hier nicht gefragt oder sinnvoll. Das sind tausende verschiedene Nutzer, die tausende verschieden Kunden anfragen. In der Regel ist das eine Anfrage pro Nutzer. Normalisierung wäre hier nur nachteilig. Die Datenbank ist in dem Fall nur ein Massenspeicher. Die Daten werden später nie wieder benötigt.

Dein Code hört sich interessant an, wobei ich eigentlich der bin, der von JS weg will. Deines scheint auch noch jQuery zu sein, aber das ist nicht das Problem, kann man ja auf "vanilla" umschreiben.

Die Frage an sich ist aber immer noch. Warum werden bei bestimmten Usern MD5-Hashes aus dem gleichen Post-Request unterschiedlich errechnet? Heute wieder 12, die auch neu gesendet hatten. Die wurden abgefangen, gleicher Hash. Aber eben wieder einen, bei dem es nicht ging,

Kann ich ja nicht sagen, daher frage ich ja, was das sein könnte. Normalerweise sendet ein Post-Request bei einem Reload die gleichen Daten noch mal. Oder eben, wenn man die Seite einfach per "back" zurück geht, dann hat man ein bereits ausgefülltes Formular und kann das neu abschicken per Button.

Mit denen arbeite ich dann und kann eben sagen "ist schon da". Egal ob vor 2 Minuten oder 2 Tagen, so soll das auch sein. Nur irgendwelche schummeln sich da durch. Daher auch beide Ansätze, weil einige z.B. gar keine Cookies an haben und die Session nicht geht.

Habe sogar gesehen, die 7 Anfragen, die die Dame heute geschickt hat, die hat sie gestern 100% genauso schon mal um 19 Uhr geschickt, aber nur einfach. Also sind es eigentlich 8 Anfragen. Gestern eine und heute gen 11 Uhr 7 mal binnen 5 Minuten.

Und fülle ich eben das Formular mit den gleichen Daten aus, dann wird bei mir der Hash "1ed935abc7e7548e9384bdc4a592e122" errechnet. Mache ich das dann noch mal, dann kommt "Anfrage wurde bereits verschickt", weil der Wert erneut berechnet wird und eben schon in der DB steht. Bei den komischen Leuten / Anfragen, sind es immer unterschiedliche Hashes. Also muss bei den Daten ja was anders sein, auch wenn es nur ein Zeichen ist (genau der Grund, warum ich bei dem Vergleich Dinge wie IP, Zeitstempel etc nicht nutze, sondern nur die User-Eingaben selbst). Aber meine DB sagt nein, identisch. Lässt sich am besten nachvollziehen, ohne jedes Zeichen per Hand kontrollieren zu müssen, wenn ich dann in der DB bei allen Datensätzen durch die DB einen Hash erstellen lasse. Der ist dann gleich.

Also nicht falsch verstehen. Die Lösung oben funktioniert sehr gut. Die fängt sicherlich 99,5% ab, aber ich weiß nicht, warum die anderen 0,5% nicht. Habe die gleiche Anfrage mir selbst mal geschickt und dann auf allen möglichen Wegen noch mal versucht. Ging nicht, wurde blockiert. Daher ist das ja das Komische, dass andere irgendwie "durchkommen".

Mit Cookies arbeite ich schon als zweiten Ansatz. Also alles was oben im Array steht steht auch noch mal in der Session und wird von der Verarbeitet. Da geht es aber schon mit dem Timeout los, wenn einer zwischen Eingabe und Absenden zu lange braucht.

Zeitlich geht das nicht. Es gibt auch Leute, die sich vertippt haben und was korrigieren wollen. IP ist auch unsicher. Gibt genug Proxys, wo jeder Request eine andere IP ist.

Vielleicht sieht hier einer einen Fehler, ich leider nicht. Im Grunde ist es ein simpler Reloadschutz für die Anfrage-Formulare. Leider kommt es aber dennoch immer wieder vor, dass ein Nutzer das Formular mehrfach absendet und das auch funktioniert. Eben eine Dame 7 mal "reloaded" binnen 5 Minuten.

$checksum_arr = array();

$checksum_arr['uk_id'] = $_POST['unterkunft_id'];

$checksum_arr['name'] = $_POST['name'];

$checksum_arr['email'] = $_POST['email'];

$checksum_arr['telefon'] = $_POST['telefon'];

$checksum_arr['nachricht'] = $_POST['nachricht'];

$checksum_arr['anreise'] = $_POST['anreise'];

$checksum_arr['abreise'] = $_POST['abreise'];

$checksum_arr['personen'] = $_POST['personen'];

$checksum_arr['kinder'] = $_POST['kinder'];

$checksum_arr['hunde'] = $_POST['hunde'];

// Checksumme über alle Anfragedaten bilden

$checksum = md5(serialize($checksum_arr));

Anschließend wird die Datenbank abgefragt, ob "$checksum" schon da ist. Wenn ja, dann wird normalerweise abgebrochen und wenn nein, dann werden die Daten normal in die DB geschrieben und die $checksum eben auch, damit sie dann bei einem Reload vorhanden wäre.

So, das Problem nur, die $checksum ist bei diesen bestimmten Personen immer eine andere und ich habe keinen Schimmer warum. Ich nutzte ja extra aus dem Post-Array nur die bestimmten Daten, die bei einem Reload gleich bleiben. Es stehen auch exakt die gleichen Daten in der Datenbank, halt eben mehrfach. Nur die gebildete checksum ist anders. Rein theoretisch müssten also beim Reload andere Daten kommen, wenn dem aber so wäre, dann müssten auch andere Daten in der DB stehen.

Hat einer eine Idee?

Der im Video erzählt aber schon teilweise echten Mist oder nutzt mathematische Zeichen falsch. Alleine schon die Aussage, "ich hoffe ihr könnte noch Prozentrechnung". Das was der da machte war "Dreisatz", nix anderes.

Ja, das Heim meine ich. Wobei das mit "Routine-Abstrich" hier seltsam geschrieben wurde. Der Mann wurde mit eindeutigen Symptomen ins Krankenhaus eingeliefert und dort wurde dann der "Routine-Abstrich" gemacht. In dem Artikel hört sich das fast so an, als ob das im Heim als Routine gemacht würde.

Beim BR, inFranken, Mainpost, Radio-Gong etc steht das etwa so:

"Er hat nun wieder Coronavirus-Symptome gezeigt und wurde deshalb in ein Krankenhaus gebracht. Beim Screening für die stationäre Aufnahme wurde er positiv auf das Coronvirus getestet"

Die Aussage ist aber auch klasse. Irgendwie alles oder nichts:

"Laut dem Würzburger Virologen Lars Dölken kämen verschiedene Erklärungen in Frage: "Einer der beiden Tests war falsch positiv, die Proben wurden verwechselt, die Infektion war noch nicht komplett ausgeheilt oder der Mann hat sich wieder infiziert", so Dölken in einer schriftlichen Einschätzung."

Mit "die nächsten Tage der komplette Lockdown" meinte ich, dass die Senioren dann auch das eigene Zimmer nicht mehr verlassen dürfen. Aktuell dürfen sie ja raus in den Hof, aber nicht mehr das Gelände verlassen oder Fremde betreten.

Na, von dem ethischen Teil lasse ich nun mal die Finger, aber ja, Bayern hat die höchsten prozentualen Werte und von denen jeweils die höchsten in Altenheimen. Mit ganz vorne in der Liste steht das Altenheim hier gleich nebenan. Der "Witz" der Sache, 22% der Bewohner sind im März und April verstorben, viele haben überlebt. Dann galt das Heim als Corona-frei. Nun gestern die Meldung, ein Mann, der schon im März auf intensiv lag, ist erneut eingeliefert worden. Wieder Corona. Und sie haben derzeit keine Ahnung, wo das her kommt, denn der Mann war weder draußen außerhalb des Geländes noch hatte er Kontakt zu Fremden, nur zur Tochter und die ist "negativ" getestet. Nun werden wieder alle Senioren getestet, Besuche sind schon verboten und sehr wahrscheinlich kommt die nächsten Tage wieder der komplette Lockdown für die Einrichtung. Hm, also mich macht das traurig.

Möglich wäre auch, wenn in dem Heim zu viele positiv sind, denn sie durften ja raus und einkaufen gehen und sonst was, dass dann ein Lockdown für den Ortsteil kommt, denn 25 pro 100.000 wäre dann überschritten.

Da wird auch noch was nachkommen. Wie gesagt, ich beobachte Kroatien, das ja angeblich "frei" war. Die haben nun höhere Zahlen als zuvor

Und vorhin erst mitbekommen. Bayern hat die Kontaktbeschränkungen verlängert. Kleine Märkte wie Kunstmärkte oder Flohmärkte dürfen wieder öffnen, aber nur im Freien. Und, im Freien, es besteht Maskenpfllcht.

Ok, hört sich auch komisch an. Schaue mir das dann morgen noch mal an oder übermorgen. Ich habe hier weder "Logo" noch eine zweite "Rufnummer". Ich habe nur die 11811 und die baut nicht selbst auf, verhindert mein Tel. Aber wie gesagt, kann bei älteren Versionen durchaus so sein.... Mein ältestes ist ein Android 3.4, aber da habe ich weder eine SIM für, noch einen funktionierenden Akku

Wenn an Deinem Handy aber die Tel von Aldi angezeigt wird, dann muss da auf der Seite noch mehr laufen, was ich noch nicht weiß. Im "data-telefono" steht die nicht. Und das ist im Grunde nix anderes als ich auch mache mit meinen "DynLinks", also einen Wert aus "data-href" auslesen und per window.location weiterleiten. Nur, wenn Du dann am Endgerät eine andere Info hast, dann muss die ja irgendwo her kommen. Ist halt nur ein gewaltiges Problem, ein echtes Handy zu debuggen. Geht, aber mit sehr viel Aufwand. Die Simulation eines Handys könnte man vielleicht sogar leicht umgehen, siehe VW-Abgasmessung am Prüfstand.

Ich meinte auch den Rahmen, den mehr war ja nicht zu sehen Ist für mich halt ein Rahmen, Tacker-Dinger und fertig. Ob gut oder schlecht, kann ich da beim besten Willen nicht rauslesen. Ist halt krum, also wohl nicht so gut. Stand aber auch über Jahre schräg angelehnt im Dachboden der Vorbesitzerin. Dachte das kommt da her und stellte es eben genau versetzt angelehnt nun bei mir an den Kamin.

Das Bild stelle ich hier nicht ein. Mache ja vieles, das aber nicht. Unikat soll Unikat bleiben. Bekommste aber per Nachricht. Wie gesagt, nix besonderes an sich, nur ne Tasse und Bohnen. Würde aber perfekt in meinen Flur passen, da liegt schon ein Läufer mit "Kaffee".