Charm pages at jujucharms.com really shouldn't be generated at load time

[Dustin Kirkland ]

It seems to me (from the page load time) that charm pages, such as:
  https://jujucharms.com/fullscreen/search/precise/squid-reverseproxy-1/
are dynamically generated at user access time.

That's not ideal from a user perspective for several reasons... The page is rather slow to load, and it's really difficult (if not impossible) for search engines to index these pages.

I have some experience here, having authored and maintained manpages.ubuntu.com for 5 years. The equivalent service from Debian, manpages.debian.net, is a CGI service that dynamically renders manpages. Unfortunately, Google does not know about a single page under that domain, since every one is rendered dynamically:
https://www.google.com/search?q=site%3Amanpages.debian.net&client=ubuntu&channel=cs&oq=site%3Amanpages.debian.net&aqs=chrome.0.69i57j69i58.3770j0&sourceid=chrome&ie=UTF-8

Instead, a nightly cronjob runs on manpages.ubuntu.com that looks for packages which have changed since the previous run, and re-renders each affected manpage. It uses Apache server side includes (SSI), CSS, and Javascript includes to ensure that headers/footers/styles/javascript are easily updated without having to re-render hundreds of thousands of pages.

Coupled with proper sitemaps.xml, this ensures that Google knows about these pages and enables millions of people to easily context search hundreds of thousands of manpages:
https://www.google.com/search?q=site%3Amanpages.debian.net&client=ubuntu&channel=cs&oq=site%3Amanpages.debian.net&aqs=chrome.0.69i57j69i58.3770j0&sourceid=chrome&ie=UTF-8#channel=cs&fp=3f829fc1ec7ea187&q=site:manpages.ubuntu.com&safe=off

As a nice side benefit, page load times are screaming fast, since it's just serving up static HTML, and caching proxies can handle it appropriately.

[Richard Harding (rharding)]

Can you define 'slow' to help set metrics we can reach for? It's not going to be suitable to pre-generate since the data is loaded from a backend api, but we can look to speed things up and attempt to reach goals of performance and make the bug targeted towards specific metrics.

[Gary Poster (gary)]

Thank you for filing this. I debated what to do with it. For now, as written, this bug is invalid for the GUI. Everything is built in the browser in a single-page JS app, from a reasonably snappy API call that simply returns JSON.

More broadly, pre-rendered pages are one of many reasonable implementation strategies for different tasks. I doubt we'll be pursuing that in the short or medium term, at the least, and with other goals (authentication and various abilities associated with it) I'm not sure it is the right long term approach. Caches of content for anonymous users can still work quite well with this, or you can even pre-render parts of the page. That's an optimization discussion for well down the line, when things look different than they do now.

But most broadly, to Rick's point, the time it takes to load the GUI, and then for a browser to render a page, is something we can improve in a variety of ways, large and small. This is the underlying problem I think you are identifying. However, we need to identify a specific goal and a priority. I think that will be driven by ongoing conversation. I'm not confident that it is a true bug at the moment, or a low priority bug, or possibly a high priority one. I'll link you into related bugs as we make them.

Thanks again.