Das Folgende ist eigentlich ein alter Hut, der aber seit einigen Hauptversionen nicht angefasst wurde, obwohl das ein Leichtes wäre. (Stattdessen wird es auch bei Neutwicklungen fortgeführt, was argumentativ wahrscheinlich nicht sein sollte.) Es richtet sich an Entwickler bzw. Professionelle, die JSON-APIs bauen und implementieren. Den Ausführenden bei der GF werden sich des ungünstigen Designs bereits bewusst sein.
Verschiedene APIs übertragen schlichtweg viel zu viele Daten, von denen das absolute Gros redundant ist (z. B. da der Client sie schon kennt oder es sich um generische Inhalte wie Texte handelt, die für alles gleich bleiben). Viele APIs übertragen komplette Strukturen statt nur Inhalte.
Beispiel component=galaxyContent&galaxy=…&system=…: Der Inspektor bemängelt lange Ladezeiten bei jedem Systemwechsel. Beim Durchgehen von Systemen (z. B. beim Scannen) werden pro System (!) ca. 70 KB umgewälzt. (Gzipped nur ca. ⅒, aber die Ausgangsgröße ist einfach viel zu groß.) Ankommen tut in der galaxy-Eigenschaft also soetwas:
Sieht das richtig und sauber aus? Muss das alles für jedes System erzeugt und übertragen werden?
(Das Foren-Limit reicht nicht für diese Daten aus; hier sind die vollständigen Daten, die pro System übertragen werden: https://pastebin.com/YTbgPYiN)
Beispiel action=getDetails: Das Öffnen von Details bei Forschungen/Gebäuden dauert bei mir ca. 2–3 Sekunden. Ich vermute, das liegt u. a. daran, dass in den technologydetails jedes Mal soetwas übertragen wird:
Ist es wirklich nötig, für jede Details die selben Lokalisierungen zu übertragen? Das ganze HTML ist schon auf dem Client und müsste nur mit ein paar neuen Daten befüllt werden.
Das sind nur zwei offensichtliche Beispiele, die aufgrund der ungewöhnlichen Verzögerung ein Nachschauen provozieren. Es gibt natürlich noch andere Stellen, an denen jeder Spieler oft vorbei kommt (Beispiel page=messages&ajax=1, wo der Browser auch die langsame Übertragung von ~2500ms statt empfohlenem Maximum von 500ms bemängelt). Vom Shop/Inventar ganz zu schweigen, was bei mir 30+s (!) und 48+ KB (gzipped!!) braucht. Teilweise werden die ‚betroffenen‘ Seiten u. U. hunderte Male täglich aufgerufen, was die Sache betrachtenswürdiger macht (als wenn es nur 1× tgl. wäre).
Hier geht es nicht um neue Features oder Bugfixes, sondern um Architekturentscheidungen, die keine Vorteile bringen außer vielleicht Bequemlichkeit. Das Verschlanken des Overheads und Abwälzen auf den Client (mit seinen gewaltigen Ressourcen) bedeuten auch keine monatelangen Umbauarbeiten, weil Gerüste und Rahmen ja schon da sind. Ob PHP das HTML zusammenschreibt und man es dann einhängt, oder ob der Präprozessor nur Daten durchreicht und man die dann vor Ort zusammenpackt und einhängt ist gehüpft wie gesprungen, nur dass die Performance extrem auseinanderklafft. (Der Server muss sich den Stress auch gar nicht machen, wenn der Client die Zusatzarbeit nichtmals merken würde.) Anpassungen dieser Art klappen auch im laufenden Betrieb und tun gar nicht weh.
Also, Kritik: APIs sind unökonomisch und ungepflegt, und sie kosten unnütz Ressourcen und vor allem Kunden unnötig Zeit.