Javascript bauen und testen auf einer Seite mit extrem langer Ladezeit

[T-Rex]

Moin,

einfaches Scenario. Da ist eine Seite die braucht 30 Sekunden um geladen zu sein. Ich soll auf dieser Seite ein Javascript anpassen. Um dies zu testen müsste ich eigentlich die Seite neu laden und somit die 30 Sekunden warten. An der Ladezeit kann ich nichts ändern. Das ist nicht Thema!

Beim css konnte ich dies umgehen in dem ich der .css Datei via Chrome-Inspektor einen Parameter mitgegeben habe. Das hatte zur Folge, dass die css Datei neu geladen wurde. War zwar umständlich, aber schneller als die 30 Sekunden zu warten.

<link href="main.css?parameter=1,2,3...usw" rel="stylesheet" type="text/css">

Diese Idee funktioniert leider beim JS nicht. Meine Idee wäre ein Iframe ein zu binden, welches das Javascript läd. Dort könnte ich dann bauen was ich will und das Iframe einfach immer wieder laden - anstatt die Hauptseite.

Funktioniert meine Idee überhaupt?

Vielleicht fällt euch eine bessere Lösung ein?

Gruß fast 30cm T-Rex

[Rolf B]

Hallo T-Rex,

wenn das JavaScript auf die Hauptseite zugreifen soll, hilft Dir der iframe nichts.

In Chrome kannst Du den geladenen Code in den Entwicklerwerkzeugen editieren - ob das dann immer wirkt, ist aber sehr die Frage. JavaScript ist sehr dynamisch und wenn ein Funktionsobjekt irgendwo in einer Closure hängt, hilft Dir das Editieren des Quellcodes nicht unbedingt.

Kannst Du nicht eine halbwegs statische Version der Seite machen, gegen die Du entwickelst? Oder Dummydaten setzen? Oder irrelevante Teile abklemmen?

Eine statische Version kannst Du erhalten, indem Du einfach den Quelltext der aktuellen Seite speicherst und als "testdings.html" auf den Server lädst. Ob das geht, hängt natürlich sehr vom Kontext ab.

Rolf

[T-Rex]

Vielen Dank für deine Ideen.

Das ganze ist nicht so einfach. Die besagte Seite ist wie gesagt sehr komplex. Als Vergleich fällt mir die eigene Facebook Startseite an, also die Pinnwand wo du von allen siehst welche Beiträge sie haben. Nur das Facebook natürlich sehr schnell geladen ist. Diese Seite braucht sehr lange. Das ist aber okay, denn wenn die Elemente einmal geladen sind passiert das Navigieren in einer "akzeptabel" Zeit. Nur das komplette neu laden ist schmerzhaft.

Speichern geht in dem Fall leider nicht. Habe ich eben probiert. Die gespeicherte Seite war mehrere GB groß, hatte kein css und war generell sehr buggy und kaputt. Es ist leider auch nicht so dass man eine css Datei und eine js source korrigieren muss (wie man es ja eigentlich machen sollte), sondern es sind geschätzte 20 css und 50 js Dateien.

@Raketenwilli Die Idee eine statische Seite zurück zu geben oder die Sourcen ab zu klemmen die lange laden ist eigentlich sehr gut. So tief bin ich noch nicht in dem Projekt um zu beurteilen wo diese Sourcen sind. Diesen Zustand herzustellen dauert wahrscheinlich länger, als mit dem aktuellen Zustand zu basteln.

---

Meine Versuche bislang

Im Head den Script-Source erneut laden. Funktioniert aber nicht, da das Javascript bereits im Cache liegt. Wenn ich es nochmals lade werden Funktionen doppelt (dreichfach ... ) ausgeführt.

Wie beschrieben ein Iframe einbauen und dieses Iframe neu laden. Funktioniert aber auch nicht. Das Javascript im Iframe wird ebenfalls gecached. HTML Ausgaben werden mir verändert angezeigt, Javascript Änderungen leider nicht. Hier funktioniert auch nicht die Idee mit dem Parameter beim Neuaufruf wie beim css (oben beschrieben).

Wahrscheinlich wird es funktionieren, wenn ich den Dateinamen ändere und das Javascript in einer Closure habe welche abgearbeitet wird. Das würde aber bedeuten, dass ich eine Änderung habe, die Datei schliesse, Dateinamen ändere, auf der eigentlichen Seite im Iframe die neue Seite einbinde ... das wird so kompliziert und lange dauern, dass ich die Seite gleich neu laden kann :D.

So wie es aussieht verdirbt mir der Browser-Javascript Cache jeden Ansatz. Ich hab auch schon im Team gefragt. Die Antwort ist "da muss man durch". Deswegen kümmert sich wohl auch niemand um solche Sachen ...

Gruß neu geladener T-Rex

[Rolf B]

Hallo T-Rex,

Speichern geht in dem Fall leider nicht. Habe ich eben probiert. Die gespeicherte Seite war mehrere GB groß,

Verstehe ich nicht. Wenn Du die Seite aufrufst, Dir den Quelltext anzeigen lässt (was ggf. 30s dauert) und dann DIESEN QUELLTEXT speicherst, sollte das keine GB groß sein. Du hast nie nie nie mehrere GB HTML, selbst nicht mit inline-CSS und inline-Script.

Auf Gigabytes kannst Du nur kommen, wenn Du die ganze Seite mit Strg+S speicherst und da sämtliche Ressourcen mitkommen, was dann ggf. drölftausend Bilder oder Riesenvideos sind. Aber das sollst Du ja - aus genannten Gründen - auch nicht tun.

Wenn Du also https://example.org/foo/bar.php lädst, im Browser den Quelltext abrufst, DIESEN speicherst und das als bar.html in den foo-Ordner auf den Server lädst, solltest Du mit https://example.org/foo/bar.html eine statische Version der Seite bekommen. Wenn die natürlich noch Gigabytes an Ressourcen nachlädt, hm, ja, dann sind die 30s wohl unvermeidlich. Man könnte dann aber auch sagen: Die Seite ist konzeptioneller Schrott und will redesigned werden. Und wenn der Server über 5s braucht, um das HTML der Seite zu generieren, ist die Seite ebenfalls Marke Schrotty.

"Speichern und hochladen" ist natürlich die Version für Dumme. Raketenwilli hat die Alternative mit ssh und wget beschrieben.

Rolf

[T-Rex]

Stimmt ... ich hab speichern unter gemacht. Ich sah es als equivalent zu dem speichern unter an. Aber du hast recht, da werden Bilder und alles mitgenommen und deshalb ist es so groß.

Einfach den Quelltext zu kopieren müsste ich mal testen.

Aktuell ist das Problem erstmal behoben. Nach langem suchen habe ich die Möglichkeit gefunden den Content weg zu lassen. Da ich nur das Menü brauchte, war das ausreichend. Somit ging die Ladezeit von 30 Sekunden auf ~5 Sekunden. Ist zwar auch nicht mega ... aber passt.

Gruß weggeschnittener T-Rex

[T-Rex]

Ähm ja ... hmm ... was ist den das für'n geiler Scheiß. Es funktioniert! Und da die Ressourcen nicht mitgespeichert werden, kann ich css und js entwickeln.

Ladezeit ist mit Content (der per JS nachgeladen wird) bei ~2 Sekunden.

Und schon bin ich happy. Danke !

Gruß Happy Dino

[Rolf B]

Hallo T-Rex,

ja, im Scheiße bauen bin ich großartig 😉

shitty Rolf

[Rolf B]

Hallo T-Rex,

Beim css konnte ich dies umgehen in dem ich der .css Datei via Chrome-Inspektor einen Parameter mitgegeben habe.

Du änderst das link Element und Chrome lädt das CSS neu? Ui, da hab ich was gelernt. Und das alte CSS wird entladen? Oder hängen dann beide Stylesheets auf der Seite rum?

Aber Du kannst das CSS auch im Quelltext-Tab editieren. Du darfst dann am Ende nur nicht vergessen (so wie ich jedesmal), die Änderung auch in die eigentliche CSS Datei zurück zu übertragen.

Rolf

[T-Rex]

Und das alte CSS wird entladen? Oder hängen dann beide Stylesheets auf der Seite rum?

Das weiß ich nicht mit Sicherheit. Spielte bislang keine Rolle, da das neue css anscheinend geladen wird, sind diese Styleangaben "weiter unten im Code" und werden somit als letztes geladen und überschreiben "alles andere".

[Raketenwilli]

An der Ladezeit kann ich nichts ändern.

Doch! Genau das kannst Du. Speichere den Output des Servers als statische Webseite und rufe diese dann ab. Du willst JS und meinetwegen CSS entwickeln ohne auf die serverseitige Abarbeitung zu warten? Dann sorge dafür, dass die serverseitige Programmierung damit nichts zu tun hat.

Alles andere sind krude Versuche, die augenscheinlich nichts bringen können.

[Rolf B]

Hallo Raketenwilli,

Speichere den Output des Servers als statische Webseite

Was man je nach Aufbau der Seite mit Verstand tun muss. Die Seite einfach mit dem Browser als lokales Abbild zu speichern kann dazu führen, dass man auf einmal gegen SOP Wände rennt, weil file:/// ja nie als same-origin gilt.

Deswegen mein Vorschlag, den Quelltext zu nehmen und auf den Server hochzuladen.

Rolf

[Raketenwilli]

Hallo Raketenwilli,

Speichere den Output des Servers als statische Webseite

Was man je nach Aufbau der Seite mit Verstand tun muss. Die Seite einfach mit dem Browser als lokales Abbild zu speichern kann dazu führen, dass man auf einmal gegen SOP Wände rennt, weil file:/// ja nie als same-origin gilt.

Deswegen mein Vorschlag, den Quelltext zu nehmen und auf den Server hochzuladen.

Rolf

Naja. Das habe ich mit „als statische Webseite“ auch gemeint. Das ein Speichern auf dem lokalen Dateisystem zu allerheftigsten Problemen mit der Same Origin Policy führt müsste ein Saurier wie TRex schon wissen…

Deswegen mein Vorschlag, den Quelltext zu nehmen und auf den Server hochzuladen.

Wozu das denn?

ssh benutzer@server
cd /da/oder/dort/hin
wget --output-file=test.html https://example.org/dort/hin/supatruba.php

tut doch in vielen Fällen?

Ok. Wenn der Abruf eine Autorisierung erfordert kann das manuelle Speichern aus dem Browser heraus nebst nachfolgendem Kopieren auf den Server einfacher sein... aber meist bringt einen das nur dem Ende des Tages in größeren Schritten näher…

[Rolf B]

Hallo Raketenwilli,

wget-Gedöns ... tut doch in vielen Fällen?

Möglicherweise. Sofern man ein Linux-Saurier mit SSH Zugang ist.

Wozu ich nicht gehöre… Das Alter für einen Saurier hätte ich, Ahnung von Linux oder WGET dagegen Null Komma nüscht.

Windoof geboren und nix nichts dazugelernt. Weswegen mir nichts anderes als ein Upload einfiel. Aber wozu hab ich Dich als Selfkollegen 😉

WinRolf

[Martl]

Hallo T-Rex,

den Chrome-Inspektor kenne ich nicht. Was aber in Edge möglich ist: Das Script in die Console kopieren und ausführen. Versuch macht kluch.

Grüße, Martl