[Assignments] Assignments and Modules are Slow to Load If There Is a Lot of Content

[MattHanes]

I am a Canvas Admin in a K-12 Environment. Although we have used Canvas for about 6 years, this is the first school year we are seeing very heavy use of the platform in all subject areas. One issue that we are starting to run into is that accumulated assignments and modules are causing the pages to lock up and not load all the way for anywhere from 1 minute to even longer to load the page. Sometimes the Assignments page will not load at all unless I use the API to delete several assignments first! So the crux of my idea is making the assignments page and modules page load more efficiently. 

I would love to see a sort of lazy-loading implemented on Assignments and Modules where perhaps the browser only renders assignments as the user scrolls rather than attempting to load the entire course assignments. 

We are only at the halfway point of the school year and this issue is happening in many courses. The assignments page in particular seems to give trouble when there are over 100 assignments. I know 100 assignments may sound like a lot, but that's really just one assignment per school day. We can mitigate it by sorting by grading period but sometimes the page locks up before we can hit that dropdown. That's great for the assignments page but there is no such grading period filter for the Modules page.

I am currently working around it by having teachers offload their assignments into a sandbox course (so they can keep a copy of it) and then mass deleting them with a python script I wrote. 

[e027941]

yes

[urbansk6]

Yes please! I'm on several sharing sites, and they take so long to load that sometimes it seems like they're not even worth trying to open. One of them I helped set up, and it took an extremely long time because just moving one document or module (out of hundreds) made the page freeze up for ten to thirty seconds.

[amyslack]

We are seeing the same thing with many of our courses that are hitting more assignments then normal due to the higher demands of Canvas during remote learning, this is even worse due to us using Blueprints which is leading to even more assignments on top of the ones teachers create themselves. This really needs to be addressed! 

[DerekSower]

We are experiencing the same issue.

As a solution we were told to break up the course into different content/create 4 separate courses. This may provide temporary relief but it will be a matter of time before the number off assignments get too high for these courses as well. 

I am of the mind that the more grades the better and limiting teachers to a number of grades is not a good policy to have. We need to be able to show growth, mastery and be able to identify areas in need of improvement and less grades is not the answer.

We really need a better solution. Also, I must note that Canvas support has been amazing through this process and this is no way a criticism of those that have helped in answering my questions. Canvas is an amazing platform and have been pleased with it from the start. 

[Chamberlainta]

We are experiencing the same issue.  

We have had our teachers delete any unpublished assignments but the list of published assignments is still high.

In order for some of our teachers to see grades, they have to select each module.

Our Elementary teachers use the same course all year but Canvas has instructed us that maybe we should break up the course by semester.  We would still like to use a full year course.

[cbixel]

The Canvas modules page takes a long time to load.

The reason for this is that Canvas takes the time to load every single item, even the items in topics that are collapsed.  

Once every single item has loaded in expanded form, then Canvas takes the next step of collapsing the topics that are set to collapse.

I am not sure why the programmers decided to have Canvas load and display items that have been set to not display.  Seems like a waste of time.

The other option would be to load all modules in collapsed form first, and then to simply open the modules that are set to display.  

[James]

Matt ( @MattHanes ), I've provided three recommendations for speeding up the page loads that are verified to work in testing. Don't be drinking your soda when you read them.

@cbixel,

I have experienced slow module pages for years. Just me, no one else. By that, I mean that when other people load my pages, they seem to be fine, but when I load them, they are slow. When I was at Instructure HQ in April 2017, I had some people look at it. My courses loaded fine for them but when they masqueraded as me, it was back to being slow. I've had other places where Canvas is slow with Chrome on a PC, but it flew with Safari on a Mac, but this was different. Anyway, I did a lot of looking into the problem, trying to figure out why it was me that was having the problem. I never came up with a complete fix, but I was elated it wasn't the students in my courses that were having the problem.

What I discovered were that there were two things going on that were bottlenecks.

The first is the information sent with the page itself. My course homepage is my modules page and so I have the ability to add items to the modules from my homepage. There are two things that are happening here.

First is that Canvas does include every module item as part of the HTML delivered with the page itself rather than doing a load of the information later on. It doesn't matter whether the module is expanded or not. Personally, I like that part so that the interactivity is immediate and I don't have to wait when I expand or collapse or drag a module. Expanding and collapsing modules was added after this was written, so the expansion is a retrofit to the existing behavior, but I'm not sure that Canvas would change it anyway.

The second issue is specific to instructors or other people who can modify the modules. Canvas includes a list of every item that could be added to the modules page as part of that. For me, my homepage requires 43.4KB and takes a while to deliver unless the results are cached on Canvas' end. This is the initial delay in my page loading. In student view, that's only 24.9KB.

The second thing that takes a while to load is the assignment_info request that contains date and point information about every assignment that appears on the modules page. This happens after the page is painted, though. If you watch closely, you will note that when Canvas displays the page, it is missing the date and point information. That is added after the assignment_info request comes back. This doesn't have as big of impact as loading all of the module information does since it's done after the page is rendered.

I mentioned the Canvas internal cache. Canvas caches data on its end so that if you need the date information again relatively quickly, it delivers that cached value. When you look at the data sent, there is a cached_due_date. When I opened a new course homepage for one that has lots of module items, it took 3.53s to deliver the 45.5KB. When I refreshed the page, it took 1.48s. That's not the browser's cache as the course page isn't cached. Even if I disable the browser's cache completely, it still takes a while. That means that I have to wait 3.5s the first time I visit a new course page and 1.5s every time after that. If I come back after a while, the information will be gone from the cache and it will take the 3.5s again.

In another course, where there is not many module items, assignments, or pages, the front page loads relatively quickly.

I went to another course that had lots of modules items (so many that I undertook a course redesign after that semester) with prerequisites and requirements for each module. The front page was 63.1KB and took 5.28s to download (for the teacher). Again, this is the main page and nothing else can be started until it is downloaded. Of that, 4.39s was waiting on Canvas to prepare the page to start sending. It only took 891ms to download the page. A refresh of the page took 2.44s, of which 1.51s was waiting on Canvas to respond and 925ms was downloading. For the student, it was better, it took 2.3s to prepare the information and 678ms to send it for a total of about 3s the student had to wait. Refreshes were 560ms to prepare and 603ms to deliver. The internal cache really makes a difference on subsequent page loads.

It obviously takes longer to download more information, but the amount of time that it takes to download the content pales in comparison to the time that it takes to prepare the content. My 45KB page took 603ms to download and I don't have a broadband connection. It's at lot faster for other people. On the other hand, it's a lot slower for some.

What is slow is for everyone is the preparation of the content to deliver. That's where the real speed increase needs to come.

It's counter-intuitive, but only delivering the content that is visible will actually slow things down in the long run. Adding in which modules are collapsed or expanded is going to make the query to prepare the information slower and it would hurt the internal caching that speeds up the secondary loads. If you collapse a module, the cache now needs refreshed, which takes a while. Filtering based on which modules are expanded would have the effect of sending a smaller file, but that's not the real bottleneck in the process.

One area that could be sped up is related to the addition of module items. I cannot tell from the client end how much of the time is spent locating every assignment, page, quiz, file, or discussion in the course so they can be pre-added. In the absence of that information, I would make that a lazy load after the page is delivered or make it only be fetched when someone starts to add a module item. The number of times I visit the homepage is far greater than the number of times I add content to the homepage. It is nice to be able to add directly from the homepage without having to go to the modules page, but we don't need to load a list of every assignment before we can even start to display the page.

I would not try to save time by paying attention to whether modules are expanded. That will only hurt performance in the long run.

I have not done extensive testing to determine the effect of having lots of content with little of it linked to the modules to see where the delay is in creating that front page. That is, I cannot say for sure whether it's the large number of module items that causes the delay or the large amount of content that causes the delay. My courses that have fewer modules also have less content.

As part of writing up this message, I did copy my module/content heavy course to a sandbox and removed most of the modules. There was no student information in the course, so that might speed things up as well. Remember that my initial load in this course earlier was 63KB and about 5.3s while refreshes were about 2.5s.

Here are the timings for the sandbox course without student information.

• Initial page load right after import finished: 59.8KB, 2.65s waiting, 883ms to download, 3.54s  total.
• One module deleted: 58.9KB, 1.36s waiting, 954ms to download, 2.32s total. This shows the effect of the internal cache.
• Deleted all but one module with 2 items in it: 25.5KB, 842ms waiting, 14.22ms to download, under 900ms total.

With that result, it seems that making the list of possible module items doesn't play as big of a role as how much content is on the home page.

The first recommendation for having the modules page load quickly is to not have any modules.

Why didn't I think of that years ago? I could have avoided all my slowdowns.

A couple of areas need further testing.

This was a course that had lots of module requirements. Every module item had a requirement so students could follow their progress. I did not go through and remove the requirements while keeping the modules to see whether the module requirements made a difference in the load time due to the fetching of information (aside from there being less information to send without requirements).

In my sandbox, there were no students. It also appears that the student information may have something to do with it (the copy of the course delivered a smaller page and did it faster than the original course). Even with the effect of the cache, it was still quicker to load the same content on a course with no students. I'm not sure what student information is showing up on the home page.

The second recommendation to a quicker loading modules page is to not have any students.

I didn't get into the assignments page here. The page itself is quick to load/display because the assignment information is downloaded separately using the assignment groups API. They do a lot of filtering, but switching to graphQL could make it go faster and also convince them that they need to improve their graphQL solution. They only load 50 assignment groups at a time, but all assignments within those assignment groups, so if you have more than 50 assignment groups then it will require multiple API calls.

One thing that I've done to improve the loading of the assignments page is to offload the instructions for the assignments to their own pages rather than putting them in the assignment itself. That is more work for the students, but my instructions are so long that I wanted a separate process for creation vs submission. This was before assignment enhancements came along. Still, the assignment groups fetch of all of the data includes the assignment information, so if you have long assignment instructions, then those are fetched every time that you get a list of assignments. By not having to fetch that, it sped things up for me.

The third and final recommendation for speeding up Canvas is to have assignments without instructions.

2021-12-10 Update: I double checked and the assignment descriptions are specifically excluded, so my third recommendation does not help speed up the assignments page. Sorry for any confusion.

[James]

I wanted to follow-up before someone responded that I left out #4: Don't have any assignments.

That would be silly of me to recommend.

The others recommendations are actionable. While none are ideal, you can remove modules after they're done (it makes it harder to copy the course from term to term), you can remove (conclude or make inactive) students who drop, and you can remove instructions from assignments (I do have short instructions that link to my actual instructions).

However, once a student has a grade for an assignment, you cannot remove the assignment without losing their grade information. We don't use grading periods, so I'm not sure how that would affect things; keeping one grade for the entire period may work out, especially if grades are double-entered (SIS and Canvas).

Having fewer assignments would help, but I will admit that it's not always possible. In my calculus course, I had one assignment for all of their written homework for a chapter rather than having a separate assignment for each section of homework. I had a rubric within that assignment that I provided feedback. That's more work for me, but fewer assignments and it works well with my drop the lowest grade policy. My external homework system has the ability to pass a single grade back into Canvas, rather than a grade for each assignment, but I want students to see the detail, not just a single composite grade.

Another way to have fewer assignments might be to develop the course on the fly. That is, copy the assignments into the course near the time they're needed rather than putting them all in at the beginning. That makes for more work and students (at least in college) like to see how many points there are for the course so they can plan out how little they can do and still pass.

[MattHanes]

@James, thank you for the thorough response and testing! 

We were mainly having this issue in our Elementary schools when everything was virtual. Teachers that were self-contained (teach the same 20+ kids all day) were putting everything into one course. We ended up forcing them to break it out into subject area courses like Math, Reading, Science, etc... which helped a great deal.

I went back and pulled up one of those courses that precipitated me typing up this idea and it is pulling up twice as fast as it was previously, but still takes over 30 seconds to load up the Assignments page!

I was also wondering recently if GraphQL might be the solution to getting faster load times on these pages since I just finished a React course on Udemy that used GraphQL to pull from Content Management System. It seems to be very responsive although my CMS didn't have a ton of content to pull yet and I hadn't needed to figure out the pagination.

If there were a way to scope the loading of the assignments page to only get the current assignments for the grading period unless you change which grading period you have selected, that would probably help a lot. It appears to download the entire list of assignments and then filter it. It wouldn't really help on the modules page though. 

Our mitigation strategies that we have recommended in the meantime are:

1. A popular thing for teachers to do is to create a daily "do now" assignment for students to do at the beginning of each class. With 180 days of school, you can imagine how slowly that loads. I've been trying to work with those teachers to recommend doing a weekly assignment with the do nows instead. So that drastically cuts down on the number of assignments.
   
   
2. For teachers with large courses, we have been recommending offloading content from the course into a Sandbox when the grading period changes. Some teachers prefer to have a separate sandbox for each 9-week grading period so they don't copy an entire course from the previous year into the current year. It kind of chunks everything up into smaller bites.

It never occurred to me to try offloading the content of the assignment description as an option. I am extremely tempted to copy her course and experiment with removing the instructions from every assignment (with a script, of course) just to see how much that speeds up the loading of the assignment list. Elementary loves to add a lot of uncompressed images to their instructions.

Thanks again!