Images in word list and exercises load very slowly

[HuguetteAfi]

Describe the Bug

Images in the word list and exercise sections "Vokabel lernen" load very slowly, which negatively impacts the user experience.

Steps to Reproduce

1. Open the app on a Samsung tablet / Samsung phone / Iphone
2. Navigate to the word list or an exercise
3. Observe the loading time of images

Expected Behavior

Images should load quickly and consistently without noticeable delay.

Related Issues

Additional Information

Environment
Device: Samsung tablet

[LeandraH]

This could be caused in the app or in the CMS. Is it only on the Samsung tablet that you've encountered this? Was it some specific job? Did you experience similar behavior with other devices on the same internet connection?

[david-venhoff]

So the usual image size is 1024x1024 so I guess we can't actually downscale a lot without it being noticeable (for phones with 1920x1080 resolution). I guess we can take a look at speeding up the cms? And maybe this approach can be applied to the other exercises: digitalfabrik/lunes-app#1329

[david-venhoff]

I am a bit confused that the production system is slower than the test system, given that both have basically the same data right now. Can anyone else reproduce this?

[LeandraH]

Oooooh, that would explain why I have never noticed an issue. Let me check that.

In the mean time, here's a dump of what Claude suggested we do:

Root Cause Analysis
Images are 1024×768 JPEG/PNG files served directly from Django's /media/ path with no CDN, no compression optimization, and no caching strategy. On mobile networks this hits hard, especially for first loads.

App-side improvements
1. Prefetch images in SentenceTrainingScreen (quick win)
This screen has no prefetching at all. The same approach used in WordChoiceExercise after digitalfabrik/lunes-app#1329/#1330 could be applied here — prefetch the next sentence's image whenever currentSentenceIndex changes:

useEffect(() => {
const nextIndex = state.currentSentenceIndex + 1
if (nextIndex < state.sentences.length) {
Image.prefetch(state.sentences[nextIndex].image).catch(reportError)
}
}, [state.currentSentenceIndex, state.sentences])

2. Prefetch visible images in the word list
VocabularyListItem renders images inline in a FlatList with no preloading. When the list loads, it could prefetch at least the first batch of images. The FlatList onViewableItemsChanged callback could be used to prefetch the next few items ahead of scroll position.

3. ImageTrainingScreen already prefetches all images upfront — this is probably fine for that exercise.

CMS-side improvements
1. Convert to WebP on upload (high impact)
Pillow already supports WebP. In document_image.py, the crop_img() method saves the processed image back to self.image.path. That save could use format="WEBP" and quality=85. WebP is typically 25–34% smaller than JPEG at the same visual quality. The filename would need updating too.

2. Serve with caching headers
There's no Cache-Control header on media files — every app restart or cold load re-downloads images. Configuring nginx (or whatever reverse proxy is used in production) to serve Cache-Control: max-age=31536000, immutable for /media/ files would make repeat visits much faster.

3. Consider a two-tier size strategy
The word list only shows a small thumbnail per item, but it loads the full 1024×768. The CMS could generate a smaller thumbnail variant (e.g. 256×192) on upload, and the API could return both URLs. The app could use the thumbnail in list views and the full image in exercises. This is more involved but would be the most impactful change for the word list.

Priority recommendation
Change Side Effort Impact
Prefetch next image in SentenceTrainingScreen App Low Medium
Prefetch images in word list FlatList App Low Medium
WebP conversion in CMS on upload CMS Low High
Caching headers for /media/ CMS Low High (repeat visits)
Thumbnail variant for list views Both High High

The WebP conversion + caching headers on the CMS side would help all exercises and list views at once without touching app logic. The SentenceTrainingScreen prefetch is the most obvious app-side gap compared to the other exercises.

[LeandraH]

I am a bit confused that the production system is slower than the test system, given that both have basically the same data right now. Can anyone else reproduce this?

I can't reproduce that on iOS or Android. Just setting the CMS URL to the prod one or did you do anything on top?

[david-venhoff]

I can't reproduce that on iOS or Android. Just setting the CMS URL to the prod one or did you do anything on top?

Yes, but for some reason it currently is not as based as it was before. What is important that the images are not cached when you load them, so when testing try to load images that you have not loaded before

[LeandraH]

I can't reproduce that on iOS or Android. Just setting the CMS URL to the prod one or did you do anything on top?

Yes, but for some reason it currently is not as based as it was before. What is important that the images are not cached when you load them, so when testing try to load images that you have not loaded before

Good point, that was poorly phrased, sorry. I changed the URL to the prod one and then chose a new job, so the pictures were all new, and didn't see any slow loading. And I didn't see slow loading against the test CMS either.

[david-venhoff]

And I didn't see slow loading against the test CMS either.

Hmm, then I am not sure. But it would probably help to optimize the image format either way.

[david-venhoff]

I'll move this issue to the cms now. For the app tasks I opened digitalfabrik/lunes-app#1369.