Tomorrow Comes Today

Entgegen dem Stand vor wenigen Jahren ist Google Maps sehr belastbar und stabil geworden. Um die Möglichkeiten und Grenzen für den Einsatz etwas besser einschätzbar zu machen, habe ich einige Tests gemacht.

Zur Erzeugung von vielen Punkten auf einer Map verwendete ich dazu einen “Random Point Generator” (http://www.geomidpoint.com/random/). Hiermit kann man große Mengen an Punkten erzeugen und in Google Maps darstellen. Allerdings wird hier kein HTML-Code für die Beschreibung des Punktes mitgeliefert. Getestet habe ich auf einem recht schnellen Desktop Rechner mit aktuellen Browsern, auf einem aktuellen mittelmäßig schnellem Notebook und einem alten Rechner mit dem Internet Explorer 6.

Ergebnisse / Performanceauswertung:
Firefox 3, Internet Explorer 7, Safari 3, Opera 9.6 auf dem schnellen Rechner und dem Laptop:

• bei ca. 200 Punkten noch akzeptabel performant
• bei ca. 500 Punkten wird die Karte deutlich langsamer (Aufbau ca. 5-6 Sek.)
• bis zu 2000 Punkte haben funktioniert, aber der Aufbau ist dann zu langsam für einen Einsatz auf einer Website (1500 Punkte knapp 20 Sek., 2000 Punkte knapp 40 Sek.)

Internet Explorer 6 auf dem älteren Rechner:

• ab ca. 25 Punkten wird der Seitenaufbau langsamer
• ab ca. 50 Punkten ist der Seitenaufbau zu langsam für eine sinnvolle Nutzung, Aktionen in der Karte sind sehr hakelig (zoomen, bewegen)
• bei ca. 150 Punkten wird sogar noch eine Karte aufgebaut, die Wartezeit im Browser suggeriert aber einen Absturz

HTML Beschreibung:

• Eine einfache HTML-Beschreibung erzeugt vor allem HTML-Markup in der Seite, was zum langsameren Laden führen kann.
• Wird das Markup einfach gehalten, gibt es beim Aufbau im Frontend zwar ein kleines Flackern (bei 250 Punkten), aber die Aufbauzeit scheint sich nicht wesentlich zu verzögern.

Fazit:
Wenn man mit bis zu max. 50 Punkten arbeitet, gibt es keine Probleme. Möchte man mehr Punkte verwenden, sollten ältere Browser (IE6) ausgeklammert werden, da die Nutzung dort dann nicht mehr sinnvoll möglich ist. Und auch dann mehr als 250 Punkte sind kritisch zu sehen. Es funktionierten zwar auch mehr Punkte halbwegs performant, aber hier habe ich auch schnelle aktuelle Rechner verwendet.

Die TYPO3 Workspaces sind für die Trennung von redaktionellen Arbeiten und dem letztlichen Publizieren eine sehr gute Idee - jedoch gibt es im Detail noch eine Reihe von technischen Problemen und scheinbar auch Bugs in TYPO3. Hier einige Punkte und deren Lösungen:

• Für Teaserlisten - welche wir gewöhnlich mit TYPO3 Menüs erstellen - verwenden wir je nach Anforderung häufig das HMENU mit special = list, worin wir dann eine UID-Listen von Seiten übergeben. Das HMENU löst bei special = list allerdings nicht die Workspace Versionen bzw. das Version Overlay auf. Das führt dazu, dass man solche Teaserlisten im Draft Workspace zwar anlegen kann, aber die Vorschau je nach Versionszustand der Zielseite falsche Teaser anzeigt. Wir haben die Stelle per XCLASS angepasst. (TYPO3 Bugtracker 0010901: HMENU with special = list does not use versionOL)
• Ebenfalls für solche Teaserlisten aber z.B. auch für andere Zwecke nutzen wir zusätzliche Bild-Attribute in den Seiteneigenschaften (genau wie das Feld wie Media). Leider werden die DAM Referenzen zur Tabelle pages nicht entsprechend ihrer Workspace Versionen aufgelöst und auch hier kommt es folglich zu Problemen. (TYPO3 Bugtracker 0010902: dam references of page attributes do not work with workspaces)
• Bei der Verwendung von Bildern und Dateien im Draft Workspace kommt es zu dem Phänomen, dass die Seitenvorschau nur bereits Live publizierte Bilder oder Dateien anzeigt. Laut TYPO3 Bugtracker soll das Problem bereits behoben sein, aber bei uns treten die Probleme noch auf. Neuigkeiten folgen! (TYPO3 Bugtracker 0007344: DAM does not preview correct files in workspaces)

Evtl. sind die Workspace nicht häufig bei größeren Websites im Produktivbetrieb - jedenfalls scheint es noch einige “Kinderkrankheiten” zu geben.