Slowness in loading Avatars on ``

(Dean Taylor) #1

You probably already know about this but I thought I would mention that during a quick test with

I can see there is a lot of time and requests being spent redirecting (302) from one CDN to another for the avatars.

Based on looking at the test results here:

It looks like this adds ~7 seconds to the load time for currently (30739ms / 4 connections).

A video:

A side note - it would be nice if the initial render could take place without any avatars…
… and then later load them, getting that initial render quicker would be nice.

Obviously this might look very different when there are no 302 redirects

(mountain) #2


I have endured the same. The fastly CDN and Meta’s CDN.

All images take measurable seconds that I can fully count until it finally loads.

(Jeff Atwood) #3

This only happens when you store resources in S3 from what I understand. I do get initial render before avatars load, I know when we were in Australia on wifi I saw lots of slow network effects.

Why would image load block initial render? I certainly do not see that. The page has no knowledge of images until the JavaScript draws the html on the page…

(Sam Saffron) #4

Yeah, it is a known issue with S3 as an image host, we have a very yucky redirect.

We want to fix it but it is very complicated. If we can somehow get an avatar template going on s3 instead of different assets and guids for each resized avatar we may be able to correct it.

(Jeff Atwood) #5

Why would avatar redirects block page load though? I don’t see how that is possible.

(Sam Saffron) #6

They are not blocking page loads, just making webpagetest be upset.

You can see it in the filmstrip view WebPagetest - Visual Comparison

webpage test does not consider a page loading until N percent of the page is displayed.

(Kane York) #7

You can also see that there’s a “1 new or updated topic” bar in the end, which lowers the completion%…

(Sam Saffron) #8

Fixed per:

(Sam Saffron) #9