Dear MODX people,
in the past days, I've struggled with a new site of mine. Revo 2.2.4, successfully upgraded to 2.2.5 now. I ran some test to look for hints, to make it faster, as it was slow as hell. Well - it's still not fast, but I managed to decrease the pageload time from about 10 seconds in the beginning to under 3 seconds now - with the same content.
As many of us are designers or rather non tech-related people, like I am nothing and everything at the same time, I'd like to share and discuss some of the things I did.
Edit: as the the great speech "Speeding up your MODX sites
" by Gauke Pieter Sietzema
on the MODXpo
on nov 10th in Utrecht draw so many attention, I just decided to publish this draft. Maybe we get some cool stuff together here in this thread.
I use the flexibility package from Menno Pieterson, which includes the foundation framewor from zurb. Menno integrated it into MODX as a package and put all kinds of packages, snippets, TVs and chunks together, to make it work out of the box.
I ran all tests several times before and after the changes, and I'll only talk about the successful ones. I used
to test all the requests and gather hints and get a rating in numbers. I started at 80.
to test the websites speed without relying on my own connection speed.
<link rel="stylesheet" href="[[++site_url]]/assets/templates/flexibility/all_in_one.css">
Leaving the site_url out, the browser does not fire another DNS request, which saves some time.
Gallery comes with default snippets and chunks as micro templates. It's based of phpThumb which scales the images for it. Using phpThumbOf instead of phpThumb speeds up the site, as the original image url's contain questionmarks. Google says that some proxies and cache engines do not cache these files.
What did I do?
1) install package phpThumbOf
[[+thumbnail]] and [[+image]]
in the thumbnail chunk (GalItemThumb) with this:
[[+fileurl:phpthumbof=`w=195&h=140&zc=1&q=75`]] and [[+fileurl:phpthumbof=`w=800`]]
With leaving the phpThumb connector behind, the images can be accessed directly and beeing cached by the browser. That is what both optimizing tools told me.
Not mentioned in any example, I reccomend to set the following parameter in the getPage call:
It will cache the output of every page it generates. Might speed up the single page by 50% (it did for me).
You really should call snippets cached where you can. The difference between this
[[!Wayfinder? &startId=`0` &rowTpl=`rowTpl` &innerTpl=`innerTpl`]]
[[Wayfinder? &startId=`0` &rowTpl=`rowTpl` &innerTpl=`innerTpl`]]
is really a lot. I run a site with some hundred resources (~700). For my landing page, I have only 7 main menu items. The difference between the two calls is... more than 3 seconds
in average - at least on my setup. So it's really worth it. if you have two menues (i.e. one for mobile devices, one for desktop screens), that simple step should reward you with a lot of speed improvement.
Today, Bert Oost showed me another way of optimizing my MODX tags. My call was this:
His proposal is this, which makes more sense:
You might want read Jasons article about a nice way of optimizing some of your tags, regarding the conditions of parsing: http://modx.com/blog/2012/09/14/tags-as-the-result-or-how-conditionals-are-like-mosquitoes/
Basically it reduces the need for parsing all
items of a conditional call.
You can't force a browser to do caching at all, but not providing any info on caching leaves it no choice but to keep its cache empty on your site. So here is what I did:
Open your .htaccess file and paste the following code into it:
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 month"
ExpiresByType text/css "access plus 1 month"
Header append Cache-Control "public"
If your apache server has the mod_expired module loaded (I hope it does), it tells your browser how long delivered files are supposed to stay in the cache as you don't expect them to change. Edit the values if they don't suit your needs. You will see that google really appreciates that, whey you check your pagespeed score before and after that.
limit queried tv fields
Sometimes you make a sidebar with getResources. Depending on the template, you might end up querying a lot of tv values which you really don't need in the &tpl. You don't even have to incluse them if they are just for ordering the output. So if you have a sidebar showind upcoming events or news, you might even not have to query TVs at all. The sortbyTV parameter will still do its job.
&processTVs = `0`
&sortbyTV = `Eventdate`
&sortdirTV = `DESC`
If you need to display some TV value in your &tpl, limit its query in the call, so it does not query every other (currently useless) TV:
&includeTVList = `eventdate`
Thanks to Pieter for that
You might also switch to getResourceField, if you only query one field anyway.
If you use some small images for menu items, borders, links, icons or what ever, put them together into sprites. Sprites are bigger images which you'll only show a part of. You set that as an offset via css, one you have the sprite. Its useful, because you only have to request and download one image instead of many.
Take a look at http://spriteme.org/
, they even have a tool that does it you your site.
combine css and js files
Combining different files into one can be another way of reducing http requests. the easiest way is to open als css files in the order they are called in your site and paste its contents into one new file. And link it instead if the others.
There is also a tool to help you with the js files: https://closure-compiler.appspot.com/home
but it will only parse "clean" code. So if scripts like jquery have trailing commas inside arrays or wrong comment formats, it will not give any output.
In your .htaccess file, you already have two lines prepared for that:
php_flag zlib.output_compression On
php_value zlib.output_compression_level 5
Uncomment them and see what happens. It depends on the browser if it can handle the compressed output, but most of them will handle it well.
These are the things you can do with ftp access and a manager login. I didnd find a way to measure them all, but as they all make sense, I'll stick to them.
There are more options, if you dive into server settings, working with apaches mod_cache / filecache / diskcache / memcache and other tools like apc.
I hope this helps some of you speed up some sites. And I'd really like to know what you're doing to archieve that. So let's talk
[ed. note: gallenkamp last edited this post 7 years, 3 months ago.]