Optimize the back end page speed

[leofeyer]

Optimize the back end page speed according to the front end optimization (e.g. try to aggregate the style sheets).

Download the attachments

--- Originally created on August 7th, 2010, at 11:32pm (ID 2400)

[leofeyer]

Implemented in d798baaed17d56a85d8828bd3dd60d2f.

--- Originally created on March 24th, 2011, at 05:57pm

[xchs]

Cool - sehr schön

![](

Hier einige Anmerkungen, welche mir einstweilen beim Testen so aufgefallen sind:

Contao 2.9.4   Backend Startseite:   Page Speed Score 85/100
Contao 2.9.4   Backend Login:        Page Speed Score 96/100

Contao 2.10.beta1   Backend Startseite:   Page Speed Score 88/100 (OHNE "Poor Man's" CDN) | 89/100 (MIT "Poor Man's" CDN bzw. Subdomains für statische Ressourcen)
Contao 2.10.beta1   Backend Login:        Page Speed Score 98/100

1. Habe gesehen, dass für das Header-Bild der Demo "Music Academy"

<img src="tl_files/music_academy/image.png" id="top_image" width="670" height="273" alt="Music academy" />

die Ersetzung der Subdomain anscheinend nicht greift, während beispielsweise die vier Icons der Syndikation bzw. Lightbox-Vorschaubilder korrekt über die entsprechende Subdomain (aus dem Feld "Datei-URL" bzw. "TL_FILES_URL") geladen werden. Müsste man also in solchen Fällen für Bilder (oder andere statische Ressourcen), welche beispielsweise über ein Frontend-Modul vom Typ "Eigener HTML-Code" eingebunden werden, immer auch gleich die dafür vorgesehene Subdomain in der URL mit angeben oder?

1. Beim Festlegen der drei Subdomains im Backend-Modul "Einstellungen" / Bereich "Statische Ressourcen" habe ich weiters festgestellt, dass für die Subdomains dort jeweils auch das Protokoll (http://) eingetragen werden muss, damit es richtig funktioniert. Vielleicht könnte man hier prüfen, ob ein Übertragungsprotokoll angegeben wurde (oder ggf. beide mögliche Eingaben entsprechend berücksichtigen)?
2. Könnte man die in den diversen Backend-Templates ("be_install.tpl", "be_login.tpl", "be_main.tpl" usw.) per Conditional Comments eingebundenen IE-Stylesheets ("@iefixes.css" bzw. "@ie8fixes.css") nicht auch über die entsprechende Subdomain ("TL_SCRIPT_URL") laden, ähnlich wie das ja auch im Frontend der Fall ist?

<)--[if lte IE 7]><link type="text/css" rel="stylesheet" href="<?php echo TL_SCRIPT_URL; ?>system/themes/<?php echo $this->theme; ?>/iefixes.css?<?php echo VERSION .'.'. BUILD; ?>" media="screen" /><

![]([endif]-->
<)--[if gte IE 8]><link type="text/css" rel="stylesheet" href="<?php echo TL_SCRIPT_URL; ?>system/themes/<?php echo $this->theme; ?>/ie8fixes.css?<?php echo VERSION .'.'. BUILD; ?>" media="screen" /><

![]([endif]-->

1. Hab' auch mal probiert, im Backend-Template be_main.tpl eine zusätzliche Variable für das Skript-Verzeichnis hinzuzufügen:

<script type="text/javascript">
<)--//--><

![]([CDATA[//><)--
var CONTAO_THEME = '<?php echo $this->theme; ?>';
var CONTAO_COLLAPSE = '<?php echo $this->collapseNode; ?>';
var CONTAO_EXPAND = '<?php echo $this->expandNode; ?>';
var CONTAO_SCRIPT_URL = '<?php echo TL_SCRIPT_URL; ?>';
//--><!]]>
</script>

und in der contao.js entsprechend zu ergänzen:

var path = CONTAO_SCRIPT_URL + 'system/themes/' + CONTAO_THEME + '/images/';

[Und weil es mir in diesem Zusammenhang gerade auffällt: Im HTML-Bild-Element des "Limit-Toggler" der Artikel-Inhaltselemente ("grüner/grauer Pfeil") fehlt das alt-Attribut.]

1. Laut Netzwerk-Monitor im Firebug/Page Speed sieht man auch, dass einige der statischen Ressourcen (insbesondere Backend-Icons aus diversen Core-Modulen) nicht über die Subdomain geladen werden, andere aus dem "themes"-Verzeichnis hingegen schon.
2. Wäre es eventuell günstiger, wenn die Versionsnummer von Stylesheets/JavaScripts jeweils direkt im Dateinamen einkodiert werden würde, anstelle dafür URL-Parameter zu verwenden? Google schreibt dazu in Page Speed etwa: "Resources with a "?" in the URL are not cached by some proxy caching servers. Remove the query string and encode the parameters into the URL." (Remove query strings from static resources) Oder spricht diesbezüglich etwas dagegen?
3. Performance-technisch könnte man noch einiges raus holen, wenn man es irgendwie schafft, zusätzlich auch noch die Icons und Bilder im Backend über geeignete "Image Sprites" entsprechend zu gruppieren (#1175).
4. Die folgende Fehlermeldung erhielt ich, wenn im Verzeichnis "system/scripts" das Stylesheet "@basic.css" (bzw. "music_academy.css`") noch nicht generiert/vorhanden war:

Fatal error: Uncaught exception Exception with message File system/scripts/basic.css does not exist thrown in /www/htdocs/system/libraries/CssCombiner.php on line 71
#0 /www/htdocs/system/modules/frontend/PageRegular.php(367): CssCombiner->add('system/scripts/...', '1195909656', 'all')
#1 /www/htdocs/system/modules/frontend/PageRegular.php(118): PageRegular->createHeaderScripts(Object(DB_Mysqli_Result))
#2 /www/htdocs/index.php(198): PageRegular->generate(Object(DB_Mysqli_Result))
#3 /www/htdocs/index.php(333): Index->run()
#4 {main}

Das ist beispielsweise genau dann der Fall, wenn im Backend-Modul "Systemwartung" das Verzeichnis "system/scripts" bereinigt wird. Eventuell müsste der Automator "purgeScriptsFolder()" auch ein "`$this->StyleSheets->updateStyleSheets();@" triggern.

--- Originally created on March 26th, 2011, at 02:25am

[leofeyer]

zu 2. Für diesen Fall brauchen wir Inserttags (env::files_url, env::script_url, env::plugin_url).

zu 3. Das werde ich ergänzen.

zu 4. Auch das werde ich ergänzen.

zu 5. Beides werde ich korrigieren.

zu 6. Welche Ressourcen sind das genau?

zu 7. Der Hinweis ist mir bekannt, dadurch würden wir aber die Möglichkeit verlieren, die Änderungen in der jeweiligen Datei im SVN verfolgen zu können, weil jedes Mal eine komplett neue Datei angelegt wird.

zu 8. Auch das ist bekannt, steht aber aufgrund des immensen Implementierungsaufwands derzeit nicht zur Debatte. In der Version 3 dann :)

zu 9. Automator::purgeScriptsFolder() sollte StyleSheets::updateStyleSheets() triggern.

--- Originally created on March 26th, 2011, at 11:17am

[leofeyer]

zu 2. Ergänzt in 0d3bcbf421648d45fb1a2a044e78a444.

zu 3. Ergänzt in 0d3bcbf421648d45fb1a2a044e78a444.

zu 4. Ergänzt in 0d3bcbf421648d45fb1a2a044e78a444.

zu 5. Korrigiert in 0d3bcbf421648d45fb1a2a044e78a444.

zu 9. Ergänzt in 0d3bcbf421648d45fb1a2a044e78a444.

Offen bleiben die Punkte 6 und 7, daher schließe ich das Ticket noch nicht.

--- Originally created on March 26th, 2011, at 11:48am

[xchs]

Offen bleiben die Punkte 6 und 7

zu 6. Welche Ressourcen sind das genau?

Konkret wären das bei mir die folgenden Icons/Bilder:

system/themes/default/images/modMinus.gif
system/modules/calendar/html/icon.gif
system/modules/faq/html/icon.gif
system/modules/newsletter/html/icon.gif
system/modules/comments/html/icon.gif
system/modules/tpl_editor/html/icon.gif
system/modules/rep_client/themes/default/images/catalog16.png
system/modules/rep_client/themes/default/images/install16.png

Alle anderen Ressourcen werden über eine der festgelegten Subdomains ("TL_SCRIPT_URL" bzw. "TL_PLUGINS_URL") geladen. Browser-Cache/Cookies wurden jeweils vollständig geleert und der Browser (Firefox) neu gestartet. Sehen kann man das entweder im "Netzwerk"-Tab von Firebug oder unter "Ressources" im "Page Speed" Add-on.

zu 7. Der Hinweis ist mir bekannt, dadurch würden wir aber die Möglichkeit verlieren, die Änderungen in der jeweiligen Datei im SVN verfolgen zu können, weil jedes Mal eine komplett neue Datei angelegt wird.

Ah ja, stimmt. Das ist dann natürlich nicht sinnvoll.

Und die Versionsnummer anstelle direkt im Dateinamen beispielsweise in der Ordnerstruktur einzukodieren, so wie es Google u.a. für seine APIs (http://ajax.googleapis.com/ajax/libs/mootools/1.2.5/mootools-yui-compressed.js) macht, scheint wohl auch keine einfache, praktische Lösung zu sein.

Dann doch lieber - so wie bisher - die Versionierung im Query String.

Bzgl. Mediabox-Integration im Backend (d40a9d63d0831d6d1bb6b7844d70edc8): Im Template be_main.tpl könnte man (gleich wie für das JavaScript) die "TL_PLUGINS_URL" angeben:

<link type="text/css" rel="stylesheet" href="<?php echo TL_PLUGINS_URL; ?>plugins/mediabox/css/mediabox_white.css?<?php echo MEDIABOX; ?>" media="screen" />

Ist diesbezüglich eigentlich geplant, die Funktionalität der Mediabox im Backend konfigurierbar zu machen (bzw. eine Option zum Ein- und Ausschalten)? Denn falls nicht und das Plugin standardmäßig immer mit eingebunden und geladen wird, dann könnte man doch das betreffende Stylesheet ("mediabox_white.css") bzw. das JavaScript ("@mediabox.js") über die Funktionen "CssCombiner()" bzw. "JsCombiner()`" mit all den anderen Ressourcen jeweils zu einer einzigen Datei kombinieren.

Ansonsten gefällt mir das Mediabox-Overlay für die bisherigen Popups im Backend recht gut. Insbesondere im Backend-Modul "Dateiverwaltung" ist das Gruppieren der Lightbox-Overlays zu einem "Set" (`rel=lightbox [details ...]@) ein wahrer Genuss, wenn man etwa in der Vorschau ("File preview") per Tastaturnavigation (Pfeiltasten bzw. "N"/"P") oder über das betreffende Icon bequem von einer Detail-Ansicht zur nächsten wechseln kann :) Wie verhält es sich denn bei den "Hilfe-Assistenten", wenn es davon mehrere pro Seite gibt (wie beispielsweise im Editiermodus einer Benutzergruppe): Sollte man dort auch im Lightbox-Overlay von einem Hilfe-Assistenten zum nächsten wechseln können?

--- Originally created on March 26th, 2011, at 04:36pm

[leofeyer]

Jetzt müsste alles behoben sein (79c7fadd9ab2356924e1e831c65f6b22).

--- Originally created on March 27th, 2011, at 11:09pm

[xchs]

Perfekt! Sämtliche statische Ressourcen laufen nunmehr über die festgelegte Subdomain und die Dateien des Mediabox-Plugins werden (zusammen mit den anderen Stylesheets/JavaScripts) entsprechend in jeweils einer Datei kombiniert. **thumbsup**

--- Originally created on March 27th, 2011, at 11:26pm

[xchs]

Anbei noch einige Patches/Diffs mit jenen Stellen, die ich noch gefunden habe (Da die Funktion "Eine weitere Datei hinzufügen" hier in Redmine wohl nicht korrekt funktioniert und man somit immer nur jeweils eine Datei hinzufügen kann, habe ich jetzt die Patch-Dateien allesamt in ein einziges ZIP-File gepackt.)

Was den Patch "@tiny.patch" betrifft, habe ich noch nicht rausgefunden, wieso das RTE-Plugin nicht mehr funktioniert, wenn das JavaScript über die Subdomain geladen wird. Ist dazu eine zusätzliche Anpassung in der "tiny_mce_gzip.php" nötig? Wenn ich anstelle der "tiny_mce_gzip.js" das Skript "tiny_mce.js`" lade, dann funktioniert es nämlich...

Weiterhin offen bleiben die Anpassungen in den "Repository"-Modulen: Habe versucht, den "themepath" mit "`TL_FILES_URL@" entsprechend zu erweitern, hat aber offensichtlich noch nicht so ganz hingehauen...

--- Originally created on March 28th, 2011, at 01:08pm

[leofeyer]

--- Originally completed on March 27th, 2011, at 11:09pm