@zebateira - per our conversation, are you able to work with @cwaring and @jdiogopeixoto to get this and #34 resolved? As we discussed, we might also want to look into establishing some sort of ongoing instrumentation for the blog to keep an eye on performance as the blog continues to expand over time. Thank you!

Note re instrumentation: @atopal recommends https://speedcurve.com/.

@zebateira and @jdiogopeixoto - I've added #84 as a larger issue for adding ongoing performance instrumentation to the blog (as well as other IPFS websites). In the meantime, the high-level metrics on WebPageTest don't look as bad as I'd feared compared to the existing blog metrics, but are you able to look into these in closer detail to identify other areas of optimization? We can open a separate issue if that's easier. Thank you!

cc @atopal, per his request.

@zebateira and @jdiogopeixoto - I've added #84 as a larger issue for adding ongoing performance instrumentation to the blog (as well as other IPFS websites). In the meantime, the high-level metrics on WebPageTest don't look as bad as I'd feared compared to the existing blog metrics, but are you able to look into these in closer detail to identify other areas of optimization? We can open a separate issue if that's easier. Thank you!

This is great 🙏
It looks like this payload issue is the main one showing up in the metrics, so I'll go over this issue to get a fix in and then we can re-evaluate other performance issues.

Progress report 1

I'll continue next week, but I wanted to leave some of the progress I have so far: https://www.notion.so/protocollabs/Performance-issue-on-IPFS-Blog-74fae8476b3e413abdde7704a9170a02

The main issue that I have found is that the whole entire list of blog posts is downloaded on the homepage (but not in the blog post page) which includes the blog post parsed markdown data as well. You can read the details in the Notion page above and to understand how I reached that conclusion.
I'm still looking at what is causing this to happen.

👋🏻 hi folks, so I've investigated this a little further over the weekend and unfortunately it is related to a core component of how Vuepress 1.x bundles the application data. Essentially the frontmatter for every page is parsed and loaded into memory, designed this way to power the default theme search box, but as we're not using that functionality here it causing wasteful clientside overhead.

Related issues:

vuejs/vuepress#2689
vuepress/core#8

Good news this is fixed in Vuepress 2.x, bad news this is still in alpha and some essential plugins that we depend on (such as vuepress-plugin-blog have not been upgraded yet.

Next options, as I currently see them:

1. Accept that Vuepress 1.x is not a suitable solution for a site of this size and focus efforts on a 2.x migration:
   Risky if the timeline is short given the missing plugins and alpha build status.

2. Attempt to post process the application bundle to remove the unnecessary payload:
   There are plenty of ways to hook into the build process, this will fix the client-side issues but add additional processing overhead to the webpack bundle (which is already slow)

3. Migrate to another framework for the blog such as nuxt or gridsome:
   This will require significantly more custom development but we can control the pipeline and output precisely.

One additional note, when I originally evaluated these bundlers Vuepress was the only one I that I could get to work with relative path urls suitable for meeting the requirement of hosting on IPFS (using vuepress-plugin-ipfs). At the time we didn't have an origin domain proxy in IPFS ({{CID}}.ipfs.dweb.link) so this was a critical implementation, if this is no longer a hard requirement we have other framework options at our disposal.