Ajax Request Optimierung

Hey leute,

wie ihr ja wisst arbeite ich immernoch an meiner blöden map:D und nun wollte ich dort paar sachen optimieren nur bevor ich mich da in den Quellcode stürze und mich da stundenlang damit beschäftige, wollte ich zunächst fragen ob es überhaupt was bringen würde:D

Zunächst mal der Ablauf der Funktionen.

Benutzer klickt irgendwohin in der Karte, der Script ermittelt anhand der Mausposition die Richtung in der man sich bewegen möchte. Dabei werden neue DIVs in die Darstellung hinzugefügt(wenn es sein muss) die XY Koordinaten des neuen Divs werden an den Server verschickt. Der Server ermittelt anhand der Koordinaten aus welcher Area Datei , er die benötigten daten auslesen muss. Eine Area Datei ist eine php Datei die in etwa so ausschaut:

areaY0X0.php

$tile[0][0] = array("gras.png",true);

$tile[1][0] = array("gras.png",true);

//usw..

also quasi an der stelle Y = 0 und X = 0 befindet sich ein gras.png bild und der ist begehbar. Nun wurde mir geraten statt so einer php datei, eine .json Datei anzulegen.

Dazu habe ich mir dann überlegt ob ich nicht die zu ladende Areas auf der Client seite berechne und der Server gibt mir ledeglich den Kompletten Inhalt aus ohne da erst einen Ausgabe array durch schleifen und co zusammen setzen zu müssen. Der Nachteil wäre dann halt dass ich daten vom Server erhalte, die mich garnicht interessieren. Vorteil wäre dass ich auf der Serverseite ledeglich ein

echo file_get_contents("areaX".$x."Y".$y.".json");

ausgeben brauche.

Also, wird mein Ajax Request schneller ausgeführt wenn ich weniger schleifen auf der Server seite habe und weniger prüfungen? oder wird es langsamer weil am ende viel mehr daten zurückgegeben werden als benötigt?

Wenn ihr was nicht verstanden habt, einfach fragen.

MFG

Da hilft nur ausprobieren und Messen. Du solltest aber in jedem Fall daran denken, dem client nicht mehr Daten zu senden, als er wirklich sehen darf. Hast Du schon mal drüber nachgedacht, immer noch einen Bildschirmseite über den Rand hinaus im Client zu halten? Das dürfte zumindest bei bei langsamen Bewegungen über die Karte zu einer deutlichen Beschleunigung führen.

mfg Torsten

meinst du cache? ja ich kann einstellen wieviele divs angezeigt werden dürfen sobald diese grenze überschritten wird, wird alles außerhalb des bildschirms gelöscht.. somit habe ich manchmal reuqests ohne antwort aber dennoch habe ich eine ausführungszeit von 60 ms:D es hat auf dem Iphone 3 geruckelt..

http://dev.cruel-online.de/?Game&mapName=test

Hab mir mal deine Map Demo angesehen - sieht ja schon recht nett aus ;-) Bei mir "ruckelt" es auch, aber ich habe das Gefühl, dass mal wieder ziemlich viele Faktoren ineinander greifen und das die gefühlte Performance nicht unbedingt ausschließlich mit der Ajaxverzögerung zu tun hat.

Um eines vorweg zu schicken: Javascript arbeitet mit nur einem Thread d.h. solange eine function ausgeführt wird, muss alles andere warten. (Die neuen Workerspielereien mal beseite gelassen.)

Ich habe deine setTiles und loadTiles Methoden in der Map.js mal überflogen. Die sind jetzt nicht grad ein Performancewunder. Solange beispielsweise die setTiles Methode beschäftigt ist, innerhalb der doppelgeschachtelten Schleife, "steht" deine gesamte Oberfläche. D.h. der User bekommt das Ruckelgefühl, wenn er in der Zwischenzeit etwas machen würde. Die JS Engine deines iPhones ist noch eine ganze Ecke langsamer als die auf einem richtigen Rechner, daher treten diese Probleme hier stärker auf.

Jetzt nochmal auf zurück zu "Datenmenge" des Requests. Ich denke, da hast du dir schon halb die Antwort gegeben. Deine Request dauern ca. 60ms auch ohne, dass du Daten zurück erhälst. Wenn du mal im Firebug schaust, siehst du, dass er die kompletten 60ms "wartet" - also Daten senden 0ms und Daten empfangen 0ms (zumindest auf meiner Leitung). Die Kosten für einen Request sind wesentlich höher als ein paar Daten mehr zu schicken, zumindest in den Dimensionen die ich sehen konnte.

also bist du der meinung, ich soll weniger daten beim Request mitverschicken und wieviele daten ich dann erhalte spielt garkeine rolle?

bei der setTiles methode sind die einzigen sachen die mich stören:

mapDiv.children("div").attr('name','hidden');
mapDiv.append('

Y:'+y+'/ X:'+x+'');
$('#Y'+y+'X'+x).attr('name','visible');
$('#objectY'+y+'X'+x).attr('name','visible');

aber ich wollte halt allen divs einen namen hidden geben danach , wenn ein DIV element noch nicht exestiert, eine neuen div hinzufügen dabei aber alle divs im sichbaren bereich den namen visible geben. zum schluss lösche ich alle divs die hidden sind .. das war mein grund gedanke.

sollte ich vielleicht statt jquery bei solchen sachen , reinen JS verwenden? zb

document.getElementByID("map").innerHTML += "

also müsste ich mich mit den beiden Methoden zunächst beschäftigen und mit der Menge der zu sendenden daten?

Ich werd mal sehen was ich machen kann:D

Vielen dank für die Tipps

EDIT: ach ja es kann auch sein dass es lagg weil da auch einige elemente drin sind in der demo map, die garnicht hingehören , zb span mit der ID , diese spans benötige ich im Editor aber nicht in der richtigen map, eventuell wirds auch schneller wenn ich diese weglasse, dann ist document lenght kleiner und eventuell wird js dann schneller ausgeführt

also bist du der meinung, ich soll weniger daten beim Request mitverschicken

Vielleicht hab ich mich hier etwas schlecht ausgedrückt....du brauchst nicht weniger Daten senden - die Übertragung der Daten zum Server und zurück dauert derzeit jeweils 0ms. Da hast du also noch Luft. Wie Todi schon meinte, musst du verschiedene Messpunkte setzen. Wielange dauert die Verarbeitung auf Server, von dem Zeitpunkt wo der Request eintrifft, bis der Response abgesendet wird. Wie lange dauern die einzelnen Methoden.

Schleifen

Bei den Schleifen - nimm alle Schleifeninvarianten (Werte die sich bei den Durchläufen nicht ändern) raus.

Beispiele:

(tileHeight/2)

Das berechnest du in jedem Schleifendurchlauf mehrfach. Einmal vor dem Durchlauf berechnen und dann immer wieder benutzen. Jeder unnötige, zeitaufwändige Befehl potentiert sich innerhalb der Schleifen.

Unnötige DOM Zugriffe / jQuery

$('#Y'+y+'X'+x).attr('name','visible');

Natürlich hast du Performanceverluste, wenn du jQuery einsetzt. Ein einfaches document.getElementById ist schneller. Den Selektorstring muss jQuery natürlich erst parsen um dann selber document.getElementById zu machen. Allerdings sollte das erst die allerletze Maßnahme sein. Viel wichtiger an diesem Beispiel ist die Tatsache, dass du das Element 2 Zeilen vorher erzeugst, hier also unnötige DOM Zugriffe hast. Warum schreibst du an der Stelle nicht gleich das Namensattribut mit rein?

DOM Manipulation

Noch eine Sache, die ich sonst als Regel kenne ist, dass du Veränderungen am DOM minimieren sollstest. Derzeit wir immer wenn ein Div-Element erstellt wird. Dieses sofort in den DOM gehängt bzw. du appendest dieses in deine komplette Karte. Ich kann mir vorstellen, dass dein innerHTML der Karte relativ lang ist und du führst sehr viele Stringverkettungen aus. Ich bin nicht 100% sicher, aber ich vermute, dass hier der String im Speicher sehr viel umkopiert werden muss. Verwende besser ein DocumentFragment, dem du alle DIV Elemente anhängst und dass du am Ende in den DOM hängst. Das DocumentFragement hat die angenehme Eigenschaft sich beim appenden in den DOM selbst aufzulösen und es werden nur die Children eingehängt.

Styling der Elemente

Beim Styling der Elemente habe ich mich ein wenig gewundert, da du ja ein Player CSS hast. Du setzt einzelne Attribute des Styles um die Elemente in die richtige Breite, Höhe und mit Hintergrung zu versehen. Spricht etwas dagegen einfach nur "grasTile" als CSS Klasse anzulegen. Übrigens würde es reichen diese Klasse per  JSON zu übertragen, anstatt die lange URL zum Bild. Du sparst Datenvolumen und vereinfachst die Verarbeitung in JS. Dann brauchst du nur noch die Positionierung vorzunehmen.

Reihenfolge der Aufrufe

Wenn ich es richtig gesehen habe, dann erzeugst du zunächst die Div-Elemente und führst dann den Ajax aus? Evtl. kannst du auch erst den Ajax abschicken und während dieser läuft die Teile erzeugen. Hier ist dann ein wenig Fingerspitzengefühl gefragt, wie es läuft, wenn der Ajax vorher zurück ist.

Erhöhung der wahrgenommenen Performance

Als kleinen Trick könntest du die Ajax Anfrage bereits auf das MouseDown Event legen und nicht erst den kompletten Klick abwarten. Sobald der User klickt, wir der Ajaxrequest geschickt.

Anderes Konzept zum nachdenken

Nochmal ein kleiner Gedankenanstoß für das gesamte Konzept. Warum hälst du alle Positionsdaten per ID im DOM Baum an den Elementen? Du könnstest dir auch in Javascript ein Object/Array mit allen HTML Referenzen und Positionen halten. Du hälst nur eine feste Anzahl, die den Bildschirm komplett ausfüllt (+etwas Puffer). Divs die den sichtbaren Bereich verlassen, werden nicht gelöscht, sondern du schaltest sie unsichtbar, weißt Ihnen neue Styles zu und positionierst sie neu. Du erstellst initial die benötigte Menge, brauchst keine neu erzeugen und keine löschen, keine Selektoroperationen im DOM mehr nötig.

Original von SurelyPlus

Bei den Schleifen - nimm alle Schleifeninvarianten (Werte die sich bei den Durchläufen nicht ändern) raus.

Beispiele:

(tileHeight/2)

Das berechnest du in jedem Schleifendurchlauf mehrfach. Einmal vor dem Durchlauf berechnen und dann immer wieder benutzen. Jeder unnötige, zeitaufwändige Befehl potentiert sich innerhalb der Schleifen.

Da haste recht, habe nicht drauf geachtet

Unnötige DOM Zugriffe / jQuery

$('#Y'+y+'X'+x).attr('name','visible');

Natürlich hast du Performanceverluste, wenn du jQuery einsetzt. Ein einfaches document.getElementById ist schneller. Den Selektorstring muss jQuery natürlich erst parsen um dann selber document.getElementById zu machen. Allerdings sollte das erst die allerletze Maßnahme sein. Viel wichtiger an diesem Beispiel ist die Tatsache, dass du das Element 2 Zeilen vorher erzeugst, hier also unnötige DOM Zugriffe hast. Warum schreibst du an der Stelle nicht gleich das Namensattribut mit rein?

hier hast du mich falsch verstanden. Es ist so die 2 Schleifen durchlaufen den Totalen sichtbaren bereich, jedoch wird nur dann ein DIV appended, wenn er im dom nicht vorhanden ist. Das heißt dass beim ersten Anzeigen der karten, könnte ich name="visible" direkt in den string reinschreiben. Jedoch bei der ersten bewegung, würden nur die DIVs den namen erhalten, die neu dazugekommen sind und alle anderen würden den namen hidden kriegen(auch wenn die im anzeigebereich liegen) somit würde ich dann alle divs löschen außer die paar, die neu dazugekomen sind

DOM Manipulation

Noch eine Sache, die ich sonst als Regel kenne ist, dass du die Zugriffe auf den DOM minimieren sollstest. Derzeit wir immer wenn ein Div-Element erstellt wird. Dieses sofort in den DOM gehängt bzw. du appendest dieses in deine komplette Karte. Ich kann mir vorstellen, dass dein innerHTML der Karte relativ lang ist und du führst sehr viele Stringverkettungen aus. Ich bin nicht 100% sicher, aber ich vermute, dass hier der String im Speicher sehr viel umkopiert werden muss. Verwende besser ein DocumentFragment, dem du alle DIV Elemente anhängst und dass du am Ende in den DOM hängst. Das DocumentFragement hat die angenehme Eigenschaft sich beim appenden in den DOM selbst aufzulösen und es werden nur die Children eingehängt.

das ist eine gute Idee, dann werde ich einen langen string zusammen setzen und erst nach der schleife appenden.

Styling der Elemente

Beim Styling der Elemente habe ich mich ein wenig gewundert, da du ja ein Player CSS hast. Du setzt einzelne Attribute des Styles um die Elemente in die richtige Breite, Höhe und mit Hintergrung zu versehen. Spricht etwas dagegen einfach nur "grasTile" als CSS Klasse anzulegen. Übrigens würde es reichen diese Klasse per  JSON zu übertragen, anstatt die lange URL zum Bild. Du sparst Datenvolumen und vereinfachst die Verarbeitung in JS. Dann brauchst du nur noch die Positionierung vorzunehmen.

Ja ich hatte mir vorher sogar überlegt eine Spritemap zu erstellen und klassen zu übergeben. Dies würde bei Strategie games locker funktionieren da dieses Genre wenige unterschiedliche Tiles besitzt, bei einem RPG sieht das ganze schon anders aus , eine Spritemap kann ich da nicht verwenden. Wegen den Klassen, ich wollte später ein TileManager programmieren, in dem ich die Tiles hochladen kann und umbennen und so weiter, dann müsste ich ja eine css datei generieren. Ich werds mir das noch durch den kopf gehen lassen mit den klassennamen aber ich glaube nicht dass es so ein großen unterscheid machen würde ob ich nun URL oder ClassName versende. Ich räum mal den QUellcode ein bisschen auf.

EDIT: wegen reihenfolge. Anhand der erzeugten div Elemente, weis ich was ich über Ajax anfragen soll, ich denke ich würde das gegenteil erhalten wenn cih erst berechne, dann ajax reuqest ausführe und dann neue divs im DOM anlegen, muss ich aber noch ausprobieren

MFG

das ist eine gute Idee, dann werde ich einen langen string zusammen setzen und erst nach der schleife appenden.

Da hast du recht, den String nehmen ist noch einfacher.

hier hast du mich falsch verstanden.

Jap, da hast du Recht ;-) Bin nicht ganz durchgestiegen, was da passiert.

Ja ich hatte mir vorher sogar überlegt eine Spritemap zu erstellen und klassen zu übergeben. Dies würde bei Strategie games locker funktionieren da dieses Genre wenige unterschiedliche Tiles besitzt, bei einem RPG sieht das ganze schon anders aus , eine Spritemap kann ich da nicht verwenden.

Wenn du einfach eine CSS Klasse verwendest, hast du Veränderungen leichter in der Hand. Kommen bspw. weitere Attribute hinzu musst du sie auf Serverseite mit in den Request packen und auf Clientseite wieder auslesen. Wenn du auf Spritemap oder Base64 CSS umstellen willst, musst du nur die CSS Datei anpassen.

Was hälst du von der im letzten Beitrag vorgeschlagenen Idee?

also .. ich habe ein bisschen geupdated.

Ajax Requests werden nur dann ausgeführt, wenn neue divs dazukommen.

1000 Divs bleiben maximal im DOM sobald es über 1000 werden, wird alles außerhalb des sichbaren bereich gelöscht.Die größe ist einstellbar.

In der SetTiles methode wird ein string in schleifen zusammengesetzt und dann an die map appended.(aber nur wenn das div nicht vorhanden ist)

Nur nötige berechnungen finden in schleifen statt. also kein Math.round oder tileWidth/2

und einen jQUery selector durch document.getElementByID ersetzt.. ist es nun besser geworden? irgendwie merk ich da kein unterschied.

das mit der CSS klasse habe ich nicht verstanden was du meinst. wie kann eine css klasse von meinen attributen des feldes was mitkriegen? zb andere spieler auf dem feld oder monster auf dem feld usw.. das geht nicht

zu deinem EDIT @surlyPlus:

ich werde mir mal gedanken drüber machen. auf jeden fall hört sich das gut .

zu deinem Gedanken: dann müsste ich also folgendes machen

1) 2 schleifen um zu errechnen welche Tiles ich benötige

2) Die Tiles per Ajax anfordern und das ergebnis als css klasse den divs setzen

3) 2 schleifen um die Tiles nach dem Dragen neu zu positionieren

Denke das könnte klappen

EDIT: mir ist gerade aufgefallen, dass wenn ich die TestMap nicht im vollbild laufen lasse dann ist es flüssiger und ruckelt nicht. also ist die idee mit dem cache eigentlich schlecht, denn je mehr elemente im DOM sind, desto mehr laggs habe ich

toll jetzt läufts nicht im IE... könnt kotzen

Ich bin heute über eine interessante Seite für Javascript Performance Vergleiche gestolpert.

Dort kann man ganz einfach selber Testfälle erstellen. Ich habe mal ein Beispiel zum Thema jQuery vorbereitet:

http://jsperf.com/attr-vs-setattribute

Die attr Funktion für das setzen des name-Attributs scheint extrem langsam zu sein.

ich glaube ein anderes problem ist die animation der spielfigur. es ist so, ich nutze die funktion .animate() von jquery und da gibt es eine funktion step in dieser funktion hole ich mir die aktuelle zeit und prüfe ob zwischen letzer speicherung und aktuellen zeit 60 milisekunden vergangen sind, wenn ja dann wird das nächste frame der spielfigur angezeigt  ich glaube in der step funktion das now = new Date(); verlangsammt das ganze auch noch..

Hast du mal eine objektive Messung an dieser Stelle durchgeführt?

Ich würde an deiner Stelle empirisch messen wieviel Zeit in welchen einzelnen Schritt geht. Damit weißt du genau, an welcher Stelle es sich effektiv lohnt zu optimieren. Danach solltest du schauen ob der Gesamtablauf deiner Schritte und wie du deine Map organisierst optimal ist oder ob es eine bessere Möglichkeit gibt. Die gezeigten jQuery/Javascript Optimierungen solltest du dann durchführen, wenn der Ablauf bereits gut ist.

Kleine Ergänzung zu Frameworks wie jQuery:

Erstens ist es extrem ratsam, sich vorher zu informieren, welche Art von Selektor wie geparsed wird und wie er zu optimieren wäre. Ein byId ist natürlich schneller als ein byTag (natürlich auch im "Core-JS"). Und ganz zu schweigen von idiotischen Konstrukten wie div#myid oder gar html> body > div > #myid.

Zweitens haben einige Frameworks bereits integrierte Optimierer bzw. Cachemanager für die Selektoren, bzw. können sich optimieren.. ähnlich Punkt 1: Vorher informieren, das spart Arbeit (durch den Einsatz des Frameworks) und kostet dann dennoch nicht zu viel Zeit (Power).

Drittens kann man auch mit einem Framework bereits bekannte Objekte zwischen speichern, denn das Suchen von einem DIV innerhalb eines bekannten Tags geht natürlich schneller als wenn man den gesamten DOM-Baum ab html noch mals durchsuchen lässt.

Zur Performanceanalyse: Im WebKit/Chrome gibt es da ein paar Tools, am einfachsten: Chrome runterladen und nach SpeedTracer Googlen. Damit kann man sich detailliert anzeigen lassen, wo wann was wie warum wie lange gemacht wurde (rendern, ausführen, laden, ...).

Hab ich noch ganz vergessen zu sagen...jeder Browser hat seine Stärken und Schwächen bzgl. Performance kann das sogar bei ähnlichen Befehlen so sein. Beispielsweise reagieren die Browser auf createElement und cloneElement sehr unterschiedlich. Es gibt also selten die optimale Lösung für alle Systeme. Vergleiche IE und Firefox: http://jsperf.com/clone-vs-create/3

IE hängt fast in allen Bereichen hinterher - bzw. muss man sich mit mehr älteren Versionen rumschlagen, die dann zwangsläufig schlecht performen. Daher ist es immer wichtig zu wissen in welchem Browser die Performance Probleme auftreten und auch in diesem zu testen. Wahrscheinlich wirst du mit dem aktuellsten Chrome die wenigsten Probleme haben, dafür auf dem IE6 erhebliche.

naja erhebliche probleme habe ich in garkein browser(wenn ich den Cache ausmache) , jedoch will ich hier und da noch ein bisschen mehr rauskitzeln:D ich mein, es läuft ja flüssig bei nicht vollbild und ausgeschalteten cache. das Spiel wird soweiso nicht im Vollbild laufen sondern auf einer fläche von 750px width. und die ursprüngliche frage war ja ob der ajax request schneller eine antwort schickt wenn ich die map statt in eine php, in eine json datei speichere. da es ja doch eine menge arbeit ist, den editor auf json datei umzustellen, wollte ich mich vorher informieren:D

Wo ist der gemeinsame Nenner bei der Frage "PHP oder JSON"?

Original von BlackScorp

und die ursprüngliche frage war ja ob der ajax request schneller eine antwort schickt wenn ich die map statt in eine php, in eine json datei speichere. da es ja doch eine menge arbeit ist, den editor auf json datei umzustellen, wollte ich mich vorher informieren:D

Was ist denn mit php Datei gemeint? Bzw. wie sehen die beiden Formate aus?

also ich habe ganz oben ja hingeschrieben dass ich die Tiles bzw welches bild, sich an welcher Position befindet, in mehrere Dateien abspeichere. Jede Datei Kann 100x100 Felder speichern. Die Datei, in der die Felder gespeichert werden , ist eine .php Datei die so aussieht:

$map[0][0] = array("gras.png",true);

usw..

diese PHP datei wird included in der Ajax.php und das $map array wird ausgegeben mit der json_encode funktion. Und da habe ich mich halt gefragt ob die Map nicht schneller laden würde wenn ich die Tiles in eine JSON Datei abspeichere. zb so
map:{

0:[0:{"gras.png",true},1:{"gras.png",false}, //usw...],

(ist jetzt einfach mal so eingetippt)

desswegen zusammenhang zwischen PHP und Json

MFG

Im Prinzip stellt sich die Frage also ob die etwas unflexiblere Auslieferung größerer, fertiger JSON Strings schneller abläuft, als die maßgeschneiderte Generierung in PHP.

Relativ schnell kannst du ja testen, ob sich das Ganze lohnt, indem du die in PHP generierten JSON Strings mal in Dateien schreibst und diese in einem 2ten Durchlauf einfach direkt an den Client schickst, als gefakten Dataprovider. Damit bekommst du dann die untere Zeit-Schranke für deinen Request (ausgenommen ausgeklügelte Cachings). Die kannst du dann mit den Zeiten für die vollständige Generierung vergleichen.

In einem 2ten Durchlauf kannst du einfach mal einen großen Mapteil übertragen und sehen, wie weit fertige JSON Dateien skalieren.

So sparst du dir vorerst aufwändige Anpassungen und kannst sehen, wieviel Zeit du damit rausholen kannst.

Falls deiOriginal von BlackScorp

also ich habe ganz oben ja hingeschrieben dass ich die Tiles bzw welches bild, sich an welcher Position befindet, in mehrere Dateien abspeichere. Jede Datei Kann 100x100 Felder speichern. Die Datei, in der die Felder gespeichert werden , ist eine .php Datei die so aussieht:

$map[0][0] = array("gras.png",true);

usw..

diese PHP datei wird included in der Ajax.php und das $map array wird ausgegeben mit der json_encode funktion. Und da habe ich mich halt gefragt ob die Map nicht schneller laden würde wenn ich die Tiles in eine JSON Datei abspeichere. zb so
map:{

0:[0:{"gras.png",true},1:{"gras.png",false}, //usw...],

(ist jetzt einfach mal so eingetippt)

desswegen zusammenhang zwischen PHP und Json

MFG

Falls das bei dir wirklich so abläuft: Cache on Demand. In etwa so etwas, was mein Vorposter meint, aber mal beim Namen genannt. Dann aber bitte mit gutem Header und readfile(). :)

Man kann natürlich gerne das beim Builden des Projektes erledigen, m.E. aber wohl unnötig; würde nur den Umweg über PHP ersparen, falls ein entsprechender CDN/Resourcen-Server genutzt wird.

Original von knalli

Falls das bei dir wirklich so abläuft: Cache on Demand. In etwa so etwas, was mein Vorposter meint, aber mal beim Namen genannt. Dann aber bitte mit gutem Header und readfile(). :)

Man kann natürlich gerne das beim Builden des Projektes erledigen, m.E. aber wohl unnötig; würde nur den Umweg über PHP ersparen, falls ein entsprechender CDN/Resourcen-Server genutzt wird.

Und jetzt auf Deutsch für Newbies:P

Cache on Demand := Zwischenkopie auf Anfrage

So ein Cache bringt aber nur etwas, wenn man auch einen ordentlichen Http-Header mitschickt (bspw. ETAG für den Inhalt zur Trafficreduzierung oder ein "Last-Modified" anhand des Zeitstempels des Cache). 

readfile() habe ich deswegen angesprochen, damit Du nicht den Fehler machst, und im PHP-Prozess den Cache mit so was a la file_get_contents ausliest -- das geht eben mit readfile() nicht nur eleganter, sondern auch schneller.

Oder, um es aufzulisten:

1. Client fragt /data.json an
2. Server mappt das bspw. auf /JsonDataController.php (wie auch immer das jetzt bei Dir aussieht)

1. Falls data.generated.json noch nicht existiert: Generiere diese anhand der konfigurierten Daten (via PHP).
2. Lese für Http-Header Modified, Größe aus und schicke die korrekten Header.
3. Lese die datei data.generated.json aus und schicke es direkt in den Ausgabestrom (readfile()).

Finito.

Man könnte das natürlich auch beschleunigen, wenn man beim Builden des Projektes (vorausgesetzt, so einen Schritt gibt es bei Dir) diese Cache-Dateien einmal erstellt. Dann könnte man sich die obigen Punkte komplett sparen, und direkt auf die Dateien zugreifen. Da der Zugriff dann ohne PHP geschieht, hätte man diesen Overhead gespart.

Ein CDN (Content Delivery Network) bzw. ein einzelner, separater CD(N)-Server (kann auch auf dem gleichen Server unter einer anderen Subdomain laufen, bspw. mit lighttpd) ist nur für die Bereitstellung statischer Ressourcen, Assets oder Daten angedacht. Dort sollte man i.d.R. kein PHP, Java oder sonstiges finden.

Wie immer: Man muss abwiegen, wie viel Aufwand man betreiben muss, will und kann. Neben bereits erwähnten Tools (ich empfehle da neben YSlow auch die WebKit-Devtools (Safari, Chrome) oder auch Googles PageSpeed Speed Tracer) seien auch so Artikel wie der des IE9-Teams zu empfehlen. Dort kann man etwa gut sehen, dass sich manche Optimierungen wie CSS/JS-Selektorenoptimierungen überhaupt nicht lohnen, wenn es eh ein Problem des Durchsatzes (sprich: Traffic) oder DNS-Fetch ist.

edit: 

• ETAG ist oft einfach eine Kombination aus URL+md5(filecontent). Browser, die das unterstützen, senden es; die anderen ignorieren es.
• php.net/readfile
• PageSpeed http://code.google.com/intl/de-DE/speed/page-speed/
• SpeedTracer https://chrome.google.com/webstore/detail/ognampngfcbddbfemdapefohjiobgbdl

also um json files auszulesen sollte ich readfile statt file_get_contents nutzen aber der zugriff ohne PHP würde nicht funktionieren weil ich jedesmal prüfen muss ob gerade mein charakter auf der map läuft, ob das nächste feld begehbar ist usw aber danke zunächst für die Tipps, nach meiner Abschlussprüfung werde ich mal schauen ob json schneller bzw sinnvoller ist und dann es eventuell einbauen

MFG

Du könntest die Kartendateien vom Apache (oder was du für einen Server für statische Dateien benutzt) die .json Kartendaten ausliefern lassen, und diese bei Veränderung von PHP ändern lassen (Das wäre wahrscheinlich sinnvoll wenn sich deine Karte relativ wenig wandelt). Dann hast du allerdings keine verdeckte Karte mehr (weil der Zugriff nicht über ein Skript kontrolliert wird). Die Begehbarkeit musst du auf jeden Fall auf Serverseite testen, da man ja sonst cheaten könnte. Du kannst aber auch noch den Client (den JavaScriptteil) prüfen lassen, dann kann die Figur laufen, noch während der Server validiert. Wenn dabei etwas schief läuft muss die Figur halt dementsprechend zurückgesetzt werden.

Während die Figur läuft können die Kartenteile in der Umgebung nachgeladen werden. Mit einer AJAXAnfrage holst du das weitere Kartenmaterial, und bewegst die Figur parallel.

Der Browser arbeitet letztlich nicht parallel (weil du keine Workers einsetzt), kann aber die Zeit nutzen, die die AJAXAnfrage braucht, und der Spieler muss nicht warten, weil schon der Clientteil deiner Anwendung in der Lage ist einen Teil der Spielmechanik zu verarbeiten (Validierung der Benutzereingaben).

Du kommst ja so oder so nicht drum herum relativ viel JavaScript zu schreiben, weil deine Karte damit aufgebaut wird.

bezüglich der begehbaren oder nicht begehbaren felder, bin ich da auf eine idee gekommen.

Früher bin ich davon ausgegangen dass ich nach dem klick prüfen muss ob ich in die richtung laufen darf oder nicht. wenn ja dann soll die karte animiert werden.

Jetzt mache ich es so dass ich beim ersten laden der karte in der antwort vom server noch zusätzliche variablen übermittle. und zwar in welche richtung ich mich überhaupt bewegen darf.

ich müsste mal die aktuelle version uploaden, da exestiert ncoh ein kleiner bug, wenn ich zu schnell in irgend eine richtung laufe, dann komme ich manchmal auf ein feld, welches nicht begebar ist.

vielleicht sollte ich so eine 1 sekunden pause einbauen, so dass der spieler sich nicht zu schnell bewegen darf.