Charm pages at jujucharms.com really shouldn't be generated at load time
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
juju-gui |
Invalid
|
Undecided
|
Unassigned |
Bug Description
It seems to me (from the page load time) that charm pages, such as:
https:/
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.
https:/
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/
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:/
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.
Changed in juju-gui: | |
status: | New → Invalid |
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.