Optimizing YAML resource for performance

support
, ,
1

I have a fairly large (growing) YAML resource which is used by a shortcode. I quickly put together a POC code that “just works”, but the issue is that it is traversing the whole YAML to find the needed node, then traverse it further, like so:

{{ $p := where $data "id" $pid }}
{{ range $p }}
  {{ $.Store.Set ... }}
  {{ if $sid }}
    {{ $sdata := (index . "sec" )}}
    {{ $s := where $sdata "id" $sid }}
    {{ range $s }}
      {{ $.Store.Set ... }}
    {{ end }}
  {{ end }}
{{ end }}

There is a “primary” and “secondary” levels to the YAML data ($pid and $sid - if any - is passed into the shortcode), but ranging everything is very inefficient. There’s multitude of these shortcodes on every page. It’s noticeably hogging the site generation.

With a usual paradigm I would make these into maps where IDs are the keys, but I am not sure how to approach this with Hugo templating. I have the feeling this is a use case for hugo.Store, but I am not sure how to prepare it for the shortcode calls to access it only when ready.

Thanks for any help pointing me in the right direction.

2

Output formats have weights. The lower the weight, the earlier it’s rendered.

Create an output format “foo”, make sure its weight is 1, and set the other output formats to have weights greater than 1. Then create a home page template for the “foo” output format, wrangle the data into whatever you want, and store the data for use by subsequent output formats using either site.Store (if language specific) else hugo.Store.

1 Like
3

Output formats have weights. The lower the weight, the earlier it’s rendered.

Thanks for this! I did not realise this, but I suspect even if I did, it would not occur to me to use it in this way. I think it’s a neat trick I will remember for other use cases in the future!

1 Like