Single Line, Multiple Attributes and Page Performance

(Lewis) #1


Does anyway know if there is a way of gathering multiple attributes about the current asset in an asset listing, in one line of code.?

For example (and I’m not saying these keywords actually exist lol) - %asset^as_asset:asset_name,asset_url_path,asset_type_code%

I see that you can do it for child and parent assets (the keyword %asset_children% returns an array, for example) but not for the actual asset you’re working on. It always ends up having to write each individual attribute as a single line and keyword, for example:


The reason I ask is because I think it’s causing a performance issue with my asset listing - the time printBody takes is much, much longer than anything else and is contributing to something like 70-80% of the page’s load time, resulting in an overall nearly 7seconds to load the page!

I’m using SSJS to decide what ends up being actually printed to the user in the browser and I’m having to rely on around five keyword replacements. I’m thinking, if I can reduce all these individual keyword replacements down to just one I might save significant time, which would show through the printBody in performance mode.

(John gill) #2

You can use ^as_asset on the assetid of the current asset


but whether it’s any faster will be another matter.

(Bart Banda) #3

Requesting the asset data all in one keyword vs separate keywords probably doesn’t affect the performance that much, because Matrix still has to fetch the data the same way regardless (might depend on what version you are on as well).

Probably need a bit more insight into your implementation to see why it’s taking 7 second to print the frontend, might be based on how many assets you are listing?

(Lewis) #4

Thanks for the suggestions guys. I’ll take a look at these.

Bart - It’s iterating through several hundred assets. I read that Squiz have performed tests using different scenarios and discovered that possibly meta data-related keywords like %asset_metadata_istileenabled% may have a significant impact but that even that reduces as the number of assets increases, to overtake the performance of standard keywords like %asset_name%, for example.

I can imagine that this is down to the JOINs necessary to bring custom fields into a SQL result set (I’m guessing the data is stored something like that behind the scenes).

If there was a way to replace the two metadata keyword replacements I’m using at the moment I may see a performance increase but I’m hypothesising that it’ll only be around 2 to 3 seconds quicker, which still wouldn’t be acceptable though.

Hmm …