Design for scale: planning CMS performance benchmarks

Speaker 1: Hey Sage!

Speaker 2: Hello.

Speaker 1: Good to see you.

Speaker 2: Good to see you.

Speaker 1: I thought it would be great to uh get you and I talking about performance in Wagdale I don't know here who might know, but we've worked on a performance audit of Wagtail a few oh it's been a while ago now, a few months ago. Um

Speaker 2: it's almost been a year.

Speaker 1: It's almost been a year. Oh my you're right. Well time flies. And uh as part of that audit, we were very keen to look at um the front-end performance of the Whitehead admin. um but also like back end more like Django focused performance of um queries um and yeah other aspects as well right And we were hoping to set up some automated tests. And I guess the point was to make sure that Wagtail works as well as possible on bigger websites with lots of content.

Speaker 2: Yeah, of course. Being a content management system, people could have lots and lots of pages and images and well any content really

Speaker 1: Yeah, so I thought it would be cool for for because we didn't necessarily get as far with this as we were hoping. We had lots of uh plans to do some benchmarking um but in order to get there first you need like a good data set to represent uh like a large wagtail site We didn't really have this at the time, nor the the tooling. And we've made some of those improvements. There's there's more to be done, but I guess we need to plan a bit more, I suppose. Like review possible tools, have a good understanding of what it means for a wagtail site to be large. And yeah, I thought it'd be quite cool to discuss it together and make some notes, make some plans.

Speaker 2: Yeah

Speaker 1: Um Sage, we have a bakery demo website. Do you think that's a large site by Wachtel standards?

Speaker 2: Definitely not. I've heard Well, this is so far from being large.

Speaker 1: Yeah, I mean it has the knife bar at the top like suggest there's lots of side sections, but if you go in one of those You know, it's a demo site, so it only has like five, six blog articles. Uh yeah. Do you have a sense in your mind of how many pages a Wagtail site has to have to be considered large?

Speaker 2: I mean at the very minimum it should be around hundreds of pages for pages and for images. Um Well probably also hundreds, but I think it's more common to have uh thousands for websites that have been around for a while. And I guess in that sense the Wagetel. org website might fit that description. And even that, I'd say there are lots of other websites out there that are much bigger than Wagtail. org.

Speaker 1: Oh yeah. Oh this is very small fry by the standards of the Wagtail universe. Um Yeah, don't know how people are uh aware of this, but we regularly look at the the footprint of the Wagtail web and the higher profile sites out there. They have hundreds of thousands of pages. Um we don't necessarily have you know behind the scenes data about those sites. We don't collect any of that, but just from crawling the internet, you can have a sense of how many pages there are. Yeah, I think the most I've ever heard of was about a million pages. Yeah, that'll be a good challenge for us, no?

Speaker 2: Yeah.

Speaker 1: So if you were to design like Wagtail's official benchmarking suit. Obviously, I assume we'll want like a number of pages that's like a good stress test without being crazy. What's that number? Like is it 1,000 pages, 10,000? Hundred thousand, a million?

Speaker 2: Oh, I think a million would be a bit. Well If you really want to do like a stress test, that would be good. If if if it's something that's like feasible to run regularly, I suppose. But um at the very minimum I'd say About a thousand or or in the realm of thousands. That's like the minimum.

Speaker 1: Yeah. So probably we can go ex extend our reach a bit and go like a hundred thousand? That feels like um reasonably common size for a large rectal size.

Speaker 2: Yeah. And I think Um we also need to consider the breadth and the depth of the page tree. Like you want to simulate one tree that is that has like a very deep path and then also ones that have um lots of siblings like one parent has hundreds of thousands of children

Speaker 1: So the depth of page tree by which you mean um inside the CMS the pages are represented as a as a tree and we'd like to try stress test what happens if um Sorry, if I navigate to the if we had say say 10 levels or 100 levels, what are we

Speaker 2: I would say the maximum that um the library 3 beard that we use supports and Um I know that it can be configured, but I guess we could just stick with what defaults that Wagto use.

Speaker 1: Yeah, okay. Yeah, I forget the name of that parameter from tree build that allows you to configure how much room you have at different levels in the tree.

Speaker 2: Step 1 or something like that Yeah.

Speaker 1: Wonder if I should try searching it. I'll I'll look it up later on it or not. Depending on default tree beard configuration. Yeah, so tree beard um It's one of those Django packages that we depend on. Yeah, named after named after that character, I s I imagine. It's interesting because I think it's also a dependency of other um Django based CMSs, I think it's Django CMS or fine CMS. Yeah. Cool that we get to share some of those building blocks with um with them. Yeah, so like I think I've I've seen conversations about having to up

Speaker 1: that default on some sites. But it's more like on the scale of once a year that I see it mentioned. It's more like oh if your site were to grow like to uh very disproportionate scale that it's relevant. So I guess it's more future-proofing than something that people have to look at on a regular basis. Yeah, I guess so real world websites dev Can't really think of reasons why you'd want to go beyond like five, six, seven, eight levels I guess in Wagtail you have the multi-site concept where at the root level you can have multiple sites. So that's one level. Then I suppose within a single site

Speaker 1: Probably you can have a concept of specific sections being separate suborganizations. So now we are at two levels Then within those organization sections you can have something that kind of behaves like a full website in some ways. So maybe that has a home page. And then a few sections of its own, then listing pages within those sections. So yeah, maybe like eight, nine, ten levels tops.

Speaker 2: But what about something that's more like an intranet where the information. It's not really about sections, but it could be it's deep as the information.

Speaker 1: Do you think we could we could get some numbers on this like by asking people out there? What's like um depth like deepest part of your your pastry?

Speaker 2: I feel like it would be uh an interesting questionnaire for developers. Like they would uh I mean if I were a developer on a Wikto website. I would also like to know like that's an interesting question.

Speaker 1: Yeah. Presumably there is um a SQL query or just like Django query set snippet we could pass around that would return the figure for a site, right? Attempts to um Interesting. And the breadth, um, so Paige 's having siblings. Do you think that's actually

Speaker 2: Well it's usually more like blog, for example. The blog index will have lots of blog pages.

Speaker 1: Yeah. So yeah, definitely at a at a given level that's very possible for a site to be pretty flat if they don't want to reuse the white tail page tree, in which case probably what it means is There is a section of the site that has very high breadth to the order of a hundred thousand to a million.

Speaker 2: Yeah.

Speaker 1: Um Yep, okay. And um

Speaker 2: or um I guess something like um an online marketplace for example maybe like where you could have if if it if if they share the same parent then they have like millions of products maybe

Speaker 1: book section yeah that's a really good example uh we do have a fair few people out there using Wagtail for their product pages And uh yeah if your SKUs go in the millions, then those pages will as well. Um Yeah, so this would allow us to, I suppose, test those page listings and the choosers. quite extensively and then there might be more specific features like reference counting of usage figure for the pages where you would need maybe different types of scale but um That feels like a good start, I suppose. Is there anything missing on here?

Speaker 2: Um Oh, um, I guess how complex the model is, like how many fields there are, and if there is a stream field, how many blocks the stream field has.

Speaker 1: Yeah Oh yeah. Um number of fields. I think I've definitely seen it go towards 100. That's definitely like the upper end that's very challenging to to work with. But suddenly, yeah, double digits amounts of fields like 50, that's that can happen. Don't not necessarily something we recommend, but You know, people go wild when you give them multiple tabs. Uh and uh yeah, Streamfield.

Speaker 1: Uh that's really interesting because it also has this concept of of nesting and depth, right?

Speaker 2: Yeah.

Speaker 1: Um

Speaker 2: It's multi-dimensional.

Speaker 1: Yes, so no. Well, hang on, there's only two dimensions, don't hold off your

Speaker 2: Well, if you're speaking of the table, like you have rows and columns, but the stream field cell is its own dimension, kinda.

Speaker 1: Supported by JSON Fields. Okay, so yeah, probably we could discuss having a hundred blocks. That's kind of uh again large large scale that we would never recommend but sometimes happens and uh 10 levels of nesting 10 levels is a lot.

Speaker 2: I wonder what the UI would look like.

Speaker 1: I think that's that's a good point. I think the most I've ever tested our UI with was on the order of five levels.

Speaker 2: What's on your everything page?

Speaker 1: I don't have my everything page right here.

Speaker 2: I think I saw it.

Speaker 1: You saw it?

Speaker 2: Yeah, yeah. There at the bottom.

Speaker 1: I think it's probably a mistake. I removed it because it was hard to maintain the everything page with everything on it. Uh I'll see if I can find it on an older website. Maybe it's definitely possible. What page ID is it? Yes, I was working on this when we were redesigning the page editor. It was really crucial for us to have um good understanding of how each and every field renders and different combinations. So it was 2022, 23. So there is a chance maybe. That I would have it in one of those sites

Speaker 1: This is all fully static by the way I don't um I don't maintain ten different copies of White Tail version. Someone has to do its age.

Speaker 2: I mean I did at one point it for my white tail space talk but it's all local

Speaker 1: Oh look at that. Takes us back.

Speaker 2: Oh what is this? Throwback Friday?

Speaker 1: Interesting, I missed it. I don't know don't know where it is, Sage.

Speaker 2: Okay.

Speaker 1: Um it's entirely possible that um I didn't configure things correctly and it's just it oh it's there it's going to work though like Okay. Okay, it's not so big.

Speaker 2: Yeah.

Speaker 1: The stream fields. Probably has much less going on. Of course it does. Wanna support every field type?

Speaker 2: Niche fields.

Speaker 1: Ooh. Field group row inside field row inside field group. Hold you can do this if you want. Doesn't make it a good idea. But yeah, there can be lots of nesting. Every block under the sun is probably yes. But this only scratches the surface because we can have a lot of nesting in here. Yeah, stream block inside stream block.

Speaker 2: Oh, that's it.

Speaker 1: That's not even that many levels compared to real websites. I think I've seen it very common where you have a body or content stream field. The first level is just sections. So within those sections, there's gonna be a stream field for the content of the section. And then you can happen that that section has say an accordion block Then you have to configure the items in the accordion. Those items can themselves be something that has to have pluggable blocks within them so you quite easily if you just choose that path arrive at um like five six levels Do you remember the days where that used to look horrendous and now it's quite a bit more manageable?

Speaker 2: By horrendous you mean like 3. 0 and before?

Speaker 1: Let's take another another trip back memorial and I can't can't resist. Let's look at our actually the recipe pages. The recipe pages I built them in big parts to stress test the stream field side of the UI a bit more. So they have um They have a list block and uh the table blocks as well. So we can try that out in 3. 0 possibly. I didn't um re-report back the content in a way that worked on that version

Speaker 1: Anyway, um yeah, those were the days. Um and

Speaker 2: oh it looks a bit cursed without the borders now.

Speaker 1: Uh I mean it looks it looks decent, just looks well yeah dated doesn't use space. nearly as wisely. No place for a preview panel in here. Anyway, so yes, 100 blocks. 10 levels of nesting and probably quite a bit of content within those fields, right?

Speaker 2: Yeah.

Speaker 1: Um hundred items in in line. panel hundred paragraphs in rich text so yeah different types of complexity that will allow us to test the performance of different aspects of uh

Speaker 2: I can't think of a few more.

Speaker 1: Oh yeah?

Speaker 2: Um hundreds of thousands of revisions for a single page maybe?

Speaker 1: That can happen.

Speaker 2: I'm not sure. Um I'm not sure if it makes a difference, but just having like millions of revisions which um but for different pages probably doesn't make that big of a difference, but I don't know. And oh, the other bit is having multiple levels of page model inheritance. Um

Speaker 1: Where does it make a difference?

Speaker 2: Um it does need it needs to join multiple tables.

Speaker 1: Yeah. But like is there, I mean is there like a point at which it's way too many?

Speaker 2: Well that's what we want to find out now.

Speaker 1: Okay. So I guess I might call that separately scale of uh implementation complexity. Yeah good question. I'm just trying to think in my mind how often I've seen it go to many levels. Because you know when when we do work tele site audits we often look at the size of the inheritance tree and uh generally recommend only Two two three levels. Um I say ten.

Speaker 2: Yeah. That's plenty enough, joining ten tables at once.

Speaker 1: Yeah, that is uh plenty enough. I would never recommend like none of those numbers are super reasonable. We want them to work. Um There is a clear case for us to support sites with a million pages, maybe 10 million someday. But this is an anti -pattern. This is somewhat questionable unless a page was like I guess if it's you know if it's one it's always the same like you don't have your whole site like that right you just have the one page on the site that is so complex Um well

Speaker 2: you never know.

Speaker 1: Yeah, yeah. I've seen Wagtail pages, for example. Um is it is it Yeah, I wasn't sure I remembered the address. So this uh the JPL, NASA JPL team uh famously used Wagtail. They've gone publicly about this and one of the larger pages on their site is just this timeline. And you know, if your organization is close to a hundred years old, then the timeline will have at least one hundred blocks on it. Or not necessarily, you know, but that that's the idea that's That's how you reach really large scales of content. So there's probably a hundred images on here. I'm scrolling really fast through them. Yeah, maybe even 200 if each of those items has

Speaker 1: Multiple ones. So that's what we need to think of. The extreme cases.

Speaker 2: Okay.

Speaker 1: Maybe the bakery website should have a timeline page on it. I'm not joking, like you know

Speaker 2: Timeline with every single day on the calendar.

Speaker 1: It's really useful to have for us to have this content with really like silly fake data to get the numbers. But it's also really useful to be able to demo that it works quite well at those scales. And if you want to demo it, I'd much prefer we yeah, build a page with this bakery's hundred year history. I'm gonna add it to the idea. I I don't think it's that silly

Speaker 2: Yeah, yeah. It still fits the theme, like it's realistic enough.

Speaker 1: Yeah, so I didn't uh introduce these documents, but we've been working on a on a redesign for our bakery website. And when I say redesign, like it's way more than a coat of paint. I suppose we want the demo site to be better able to represent the type of WattL usage we see at a larger scale. But I guess we want to do that without compromising on the site also being an interesting reference at a smaller scale. So we have to pick our concepts somewhat carefully. So yeah, proposed content timeline page with uh a lot of blocks 100 So just like having one heavyweight page on the site, that feels pretty reasonable to demonstrate, even for a site that overall might be

Speaker 1: for a small organization.

Speaker 2: Yeah.

Speaker 1: Yeah, redirects, that's that's a great example, I think, of something where um if you're migrating from an existing site and that existing site had hundreds of thousands of pages. You can arrive at 100,000 redirects if your team is particularly eager to not let any existing requests fall through the cracks. Not something that we advise, but definitely come on that it makes sense to go that way. And yeah, multilingual content. Do you have a sense like the bigger sites out there, how many languages do you support?

Speaker 2: I don't think I've ever seen one with more than twenty, I'd say. In the tense, definitely. Well, oh Wikipedia, I mean it's it's a different beast. It depends on the um page that you're looking at, so

Speaker 1: I'm just trying to think of a page that would

Speaker 2: I know there there should be the globe thing that um that displays all the languages. Maybe if you click on the top left thing.

Speaker 1: Let's go for Greece. Oh wow. 300 languages. Yeah. So I think for Wactail, I'll be happy if we have 10 languages in our demo site. But it's good to have ambitions.

Speaker 2: What about the article for Earth?

Speaker 1: 300 wow.

Speaker 2: Okay.

Speaker 1: Good spotting Sage. Can we have an article about Earth on our bakery site?

Speaker 2: Mm-hmm.

Speaker 1: Um okay so might say here 100 languages Okay.

Speaker 2: But you also have to think about how many languages do we or Django support.

Speaker 1: Do you think there's a limit?

Speaker 2: Um well yeah uh not all languages are supported, I think. And Oh, maybe hold on. Um sorry, that's that's a different thing. I guess that's just like the admin interface.

Speaker 1: Oh, yeah.

Speaker 2: But yeah, for for I think for the for the content languages. It's uh yeah, it doesn't require Well, at least I I think so, yeah. Never mind.

Speaker 1: Um what about something like images? We

Speaker 2: Oh yeah.

Speaker 1: We want lots of images on our site.

Speaker 2: Um I think at least hundreds or thousands. And you definitely also want An image that's used in lots of pages

Speaker 1: Yeah, so I guess here as well there is a case that maybe for the default demo you want hundreds. And at scale you want a million, up to a million. Um Let's say 10,000 for now. That's a reasonable place to start. And you know, at those scales that we're talking about. We are not going to manually create that content anyway, right? So it's not much of a problem for us to change the configuration to generate 10 times more if we had to at some point. Um and so yeah you said lots of usage of a single image. How much are we talking?

Speaker 2: Thousands? I mean, if it's not too hard, maybe have hm. Have have it used on all every single page that we have.

Speaker 1: Every single page?

Speaker 2: No, maybe that's that's that's silly. Well

Speaker 1: you know, if you can imagine an image that's say reused on 10 pages of an English language site and you translate that 10 times right away you have a hundred usages of the same image so it can go reasonably fast I think Um I think the the guide websites that we have for our Wagtail user guide is a good example of this where um It's set set up to support multiple Wagtead versions and multiple languages. So as Wagteil accumulates versions over the years, at some point we'll reach 100 versions Each of those could have 10 translations each

Speaker 1: right away or have a thousand copies of each and every page. Notwithstanding, you know, the same image being reused in multiple ones. We're not there yet, obviously. Um not all languages Sorry, not all translations are for old versions.

Speaker 2: This is off topic, but do you think we should retire some of the older versions from the guide website?

Speaker 1: At some point, yeah, of course. Yeah. you know, um there's different amounts of retirement, but suddenly within this picker interface this is um too cumbersome. probably should have those languages uh sorry versions

Speaker 2: separate

Speaker 1: and languages yeah separate pickers and then have the versions ordered by numbers obviously the most relevant would be the latest at the top And um yeah the older ones uh at the point that you have a good UI maybe it doesn't matter as much to retire them but you know at some points white sale forward would definitely be completely irrelevant. Uh such from the historical value, I suppose.

Speaker 2: Yeah.

Speaker 1: Okay, um, so we have a sense of the scale. Um, is there any other aspects of the wagtail? experience that you think is important to test at scale. Obviously there's lots we could do but that immediately comes to mind. How about snippets? Do we need thousands, hundreds, thousands of snippets?

Speaker 2: We could.

Speaker 1: Yeah.

Speaker 2: Yeah.

Speaker 1: Okay, I'll add that and then we can try what we have right now to support this.

Speaker 2: And I'm not sure how much we care about form form builder. I mean

Speaker 1: Yeah. I mean, you know, it's something where I I think once we start treating this kind of scale problem more seriously. You know, we're quite pragmatic. So page three is the obvious thing we want to be spending time on first. And then over time, if we realize that there is a case to have automated testing for other things, we we add them. Yeah, I want to switch over to trying out what we have right now, I suppose. So now we're looking at the code of the Bakreademour website and we have those two commands that have been set up to generate more content. Have you tried them before yourself?

Speaker 2: I don't think I have.

Speaker 1: Okay, so we're gonna I've never tried this one and we're gonna try it together and see what happens, I suppose. When you have a command line tool like this, how much do you like look at documentation and implementation and how much do you just like do it and see what happens?

Speaker 2: I think I would at least yeah do what you just did um not passing any arguments or maybe using the dash dash help to see if It prints anything useful. Yeah.

Speaker 1: Yep. So it's it's so inconsistent from tool to tool though, like how you get access to that information. So sometimes I just Wing it. How many pages of each type to create? How many snippets of each type? How many images? That sounds great, no?

Speaker 2: Yeah.

Speaker 1: Let's uh start small or start start big? How do you feel?

Speaker 2: Um let's start with ten each, I suppose

Speaker 1: It's ruby numbers.

Speaker 2: Okay.

Speaker 1: I was thinking to myself, like, I probably have to times 10 whatever whatever Sage

Speaker 2: says. Oh no.

Speaker 1: Okay, what do we have here?

Speaker 2: It's probably something about images.

Speaker 1: Yeah, images is the one that is the most likely to

Speaker 2: fail.

Speaker 1: Update dimension fields. Okay, so it looks like there's something that's changed that broke it. Let's just skip images, see what happens. I think it's time to skate up. I thought it would take a bit longer than this. Okay, we are on our way. Um

Speaker 2: calendaries

Speaker 1: Okay, so looks like the implementation is pretty small. Should be simple enough for us to check what is going on there and and fix it. It could be that it's trying to read. images in formats that we've changed since and uh this doesn't account for that. Um let's look at the website while this is happening and see what happens in now. So We created a lot of snippets. Ooh, page 2216. Oh

Speaker 2: nice.

Speaker 1: And uh I assume I can press next on this until the end of times. Okay, I'm on an older version of Wagtail, which is why we don't have the new pagination. Should I upgrade?

Speaker 2: Well, I thought you're running the Dev version.

Speaker 1: No, no, I'm not. I'm running a separate copy.

Speaker 2: Okay.

Speaker 1: And pages of different types. Standard page. Okay, only two in there, so I suppose there's just more for it to do news. This is probably the chat GPT generated content that I tried on another occasion.

Speaker 2: Mm-hmm.

Speaker 1: Okay, so it looks like it's just filling in the different sections as it's found the index pages probably.

Speaker 2: Probably, yeah.

Speaker 1: So this is pretty useful. Then we just need to um I suppose agree together on what type of scale is meaningful for us to test things. And then yeah, do you think it's something where we should like curate the content and then share a fixture or Should we update our automated creation to have those nuances of revisions and usage count and

Speaker 2: I don't think you would want to share the fixture It's just a hassle to maintain and keep up to date, I suppose. And yeah, um, although maybe for some cases where Like we have one case with very compli like let's say a page with a thousand stream field blocks. Maybe you do want a fixture for that if uh if you don't want to define it in code. But Yeah, I think we can just start with code and then figure it out later if we need fixtures.

Speaker 1: Yeah. So then the benchmark you'd say like, okay, we track the number of um say the time it takes to load this view depending on the size like relative to the number of items.

Speaker 2: Yeah.

Speaker 1: So we could benchmark say at 10,000, see what the number is and if we ever were to change the net number we could um To a relative benchmark?

Speaker 2: Yeah, I guess so. Um like for example a single page of the listing should in theory be It it shouldn't get slower.

Speaker 1: Yeah.

Speaker 2: Yeah. Unless you somehow accidentally fetch all the things at once.

Speaker 1: But when we when we if you say like sharing the fixtures isn't helpful, um if we were in a CI context Regenerate the data every time then?

Speaker 2: Oh, that's a good point. Um I think my concern was probably just about No ha uh if we want to have such big fixtures, it probably shouldn't live in the same repo

Speaker 1: Just because of the size of the files.

Speaker 2: Yes.

Speaker 1: Yeah. How much do you know about um git LFS, which is built to solve changes like this?

Speaker 2: Can't recall if I've ever used it, but yeah, if Yeah, we definitely would use something like that, I suppose, if we w if we care about the revision or otherwise we could just keep overwriting a single commit in in a separate repo.

Speaker 1: The dark arts.

Speaker 2: Yeah.

Speaker 1: Yeah. Oh you know we we have plenty of um file storage infrastructure we could use for for one-off efforts like this. Let's try my my other chat GPT powered command. I haven't tried. This is where the AI comes in. So you know we want to be very thoughtful about our usage of AI. And I wouldn't necessarily recommend using it for your website's content, but for test content, you know, it is definitely useful for us to have test content that doesn't look too out of place. And um Yeah, I think it's just a promising way to generate this. Right now I have it hooked up to Chat GPT, but it's definitely possible for

Speaker 1: us to hook this up to a local uh local LLM. Um yeah, I don't know um Just wanted to check how it works so that I could uh explain it. So it's using the chat GPT API with a Python wrapper. and uh this specific model and then giving instructions on how to generate the content based on those prompts that are derived from the I think first it generates a list of titles Yeah, and then generates the content for each title. I don't know like how idiomatic it is, but it worked well enough to give it a go.

Speaker 1: So create GPT generated data. What should the blog post be about Sage?

Speaker 2: The greatest thing since sliced bread. No, that's that's already a blog post in the No

Speaker 1: If it works for you, it works for me. Do you want to change your mind or are we are we rolling with it?

Speaker 2: I think we can see what its opinion on it is.

Speaker 1: Let's start small ten. See what happens. Uh root Alright, so glad it chugg along, see what happens. Let's check in on our creation of content. Creating people. Maybe I was a bit too optimistic with my numbers. Okay. We'll give it one more go and if it doesn't work. We'll move on. Ten.

Speaker 1: No.

Speaker 2: Beyond the loaf.

Speaker 1: Oh, I can show you something cool related to this sage while we're on this.

Speaker 2: Yeah.

Speaker 1: I have to bring up my my other browser for this though.

Speaker 2: I think it failed again.

Speaker 1: Did it? Do you use um AI tools much in your day-to-day day-to-day work?

Speaker 2: Hmm, I mean I have GitHub Copilot enabled, but I don't rely on it too often, I suppose.

Speaker 1: Mm-hmm. So one of the things we've been working on recently is um adding little AI-powered features in the CMS, not necessarily like as Wagtail core features. super appropriate. But just experimenting if people want to build those as packages, what it would look like. So this demo site I have has a demo of generating the content of the fields based on summarizing the content of the pages. Let's get this this page previewing and I can show you what it looks like. Yeah, so here that's a chat GPT generated demo page. So just text

Speaker 1: not super meaningful, but for um for a demo that's good enough. Yeah, it's just this little generate button underneath the field. So when you hit that, um it takes the field name and the help text as a prompt. To summarize it based on the content of um the page in the preview panel.

Speaker 2: Oh, so it reads the preview?

Speaker 1: Yep. It's risk to preview. Um, you know, when you think of the page's content, like using that to infer the content of other fields or to give feedback. I guess you could look at the form, but that you don't really know how meaningful the different parts of the of the form are. The form doesn't really tell you the whole data you have to extract. quite a bit for if you have um other model instances in there whereas um the page in the browser It's much closer to what uh what a person would perceive once the page is live, right?

Speaker 2: Yep. That makes sense.

Speaker 1: Yeah, there's trade-offs all around, but um Yeah, it it does it like this in this case. And um what's really interesting about it is actually that it all happens in the browser in this case.

Speaker 2: Um

Speaker 1: there's no chat GPT here. This is um I'm not sure if you've come across this before. It's called the built-in AI project by Google. They've been working on this for for a wee while now and they have those uh one, two, three, six different APIs. that are meant to ship in like JavaScript for any site to use. And yeah this is the summarizer API which is available in Chrome 138 beta Um yeah, anyway.

Speaker 2: Um

Speaker 1: yeah, it's cool. I don't know where it will go because you know very consumed uh energy um intensive to to create those kinds of um like prompts for the for the LLM and have it come back with data not not every computer can support this not every device can and um yeah then you have to have browser vendors agree that it's a good idea Lots that can go plenty of different ways there. This is taking forever. I made a mistake, Sage.

Speaker 2: I wonder why though.

Speaker 1: There's something special about people. They're harder to create than bright ingredients. We'll scale back our experiments down to Yes, 10,000 bread pages. Yeah, so with this in place, I guess what we can decide then is what type of scale we want to test with Then we start testing, we have a sense of the numbers for a given market version and over time we keep tabs and um that will improve the CMS. When we were preparing our performance audits, um

Speaker 1: did we have a sense of which tools we'd use to do this?

Speaker 2: On CI or

Speaker 1: or even outside as a one-off?

Speaker 2: Yeah, first Silk is pretty much the go-to that people use usually.

Speaker 1: But

Speaker 2: I personally haven't used it.

Speaker 1: So we'd set we'd try a bunch of different ones and then see how they keep tops of the numbers decide for which views to test them and both your own

Speaker 2: cool. Yep

Speaker 1: Okay. Well be very interesting. I think it'll be very interesting even without those tooling in two this tooling in place to just um spend time in the CMS and see how the different listings interact.

Speaker 2: So

Speaker 1: I think the like a clear example would be if we had um did it make progress on those bread pages Okay, still taking a while. So if we had um one of those listings that has a lot of contents, the filtering, how much time it would take, right? Um page type. something like this that should be really fast should be really fast no matter what Yeah, and see how that reacts when we have much larger listings. So I guess the the goats there would be here if you search and do search the whole sites

Speaker 1: Can you filter the whole sites?

Speaker 2: I think so

Speaker 1: Okay, so this kind of query should go everywhere and then give you a good approximation of like the worst case of performance. Oh that is really fast. Thank you, pagination.

Speaker 2: Oh I know. So if you go to the the page with lots of um children Can can you try doing that? Like maybe you want to see.

Speaker 1: Looks like those pet pages are coming in. What have we done there? Is the editing view dependent on the side of the tree?

Speaker 2: I don't think so.

Speaker 1: Is it my browser choking or is it

Speaker 2: your computer?

Speaker 1: My computer is struggling.

Speaker 2: What database are you using? Uh

Speaker 1: SQLite. That's not the database. Um Don't know what I've poked. Um so breads. So you were saying go here?

Speaker 2: Yeah, and then at the top uh click on the three dot menu and click on sort menu order.

Speaker 1: That is a good point, Sage. Something where the ordering of all the pages is important. But um Does it does it is there no pagination for this? Does it load all the pages?

Speaker 2: Yep.

Speaker 1: Oh no, we found Sage 's secret page to crash the Wagtail

Speaker 2: site. I'm sure there is a way to fix this. So you wouldn't do pagination in the traditional sense, but you would do something like an infinite scrolling. Where more pages get loaded dynamically as you scroll down.

Speaker 1: But you'd never need to sort manually that many pages anyway, right? What's the

Speaker 2: Well let's say you start off with like 10 pages, right? And then you sort them manually and you keep adding more. But you want to pretty much just keep the um order of the rest of them unchanged and then it occasionally you need to reorder some pages like near the uh for the first few pages or the last few maybe I don't know what would prompt you to do that, but you know. And then at some point you end up with thousands of pages, but you still want them to be manually of Drupal.

Speaker 1: And then it explodes both in the browser and server side. Nice one. I think that's a great one to end on. Really good example of uh practically where where it breaks. Hopefully not many sites have a need for this.

Speaker 2: But

Speaker 1: yeah, you know, it's always the case that you have those one-off scenarios where And you know, even for smaller sites, we want this to be very snappy. So the next steps, review the numbers we arrived at with more people, devise like what's a reasonable set of numbers for um um already usable benchmark make those tools run that benchmark See what happens.

Speaker 2: See what happens. And well, once we figure out, then we'll fix the issues, if any.

Speaker 1: Nice one, Sage. Thank you.

Speaker 2: Yeah, thank you