WordCamp | Refactor attendees system for better performance

[LucP]

Now that WordCamps are getting bigger (WordCamp Europe has +/- 2400 attendees listed), attendee-pages in WordCamp sites are getting ridiculously large...

I've added a screenshot of the load of WordCamp Europe's attendee-page. With +3000 requests it's half a minute of load-time over my broadband connection.

I wanted to start this ticket to see if we could discuss possible solutions for this. A quick fix could be to paginate the attendee-page and provide a simple search-form for quick-access.

Most of the load is due to gravatar-requests though, so a (possibly) better solution in my opinion would be to periodically generate a spritesheet of all attendees and make it one request.

I'd love to hear your input.

[DeFries]

Instead of generating it "continuously" (I'm aware there's page caching helping there), perhaps cache the entire query to a database option field so all the page has to do is spit out one chunk of HTML and render the images in a lazy load type fashion?

[LucP]

That would still leave you with +3000 requests though... gravatar-latency is the biggest culprit:

The grey bars represent request-time on the external-server...

[DeFries]

Lazy loading would bring that down to whatever a screen can display in one go.

[iandunn]

Related #230

[iandunn]

Another thing to take into account here is that sometimes people will put multiple [camptix_attendees] tags on a page.

e.g., ​https://2015.us.wordcamp.org/tickets/attendees/

[LucP]

Replying to DeFries:

Lazy loading would bring that down to whatever a screen can display in one go.

Didn't read your previous comment careful enough;
I think lazy loading is an excellent option...

[s1m0nd]

With WordCamps Europe and US now expecting thousands (plural) of people, we're beyond a point where simple alphabetical presentation makes sense.

I agree, there's an immediate need for better performance: I'd strongly favour lazy-loading over pagination, since the former at least allows me to use my in-browser search function. But really, it's probably time we were looking ahead to a proper, ideally faceted, search function.

[LucP]

I'll work out a first patch next week with lazy-loading and caching the entire query.
Does anybody have any tips on how this caching could/should work? Everything stored in one giant serialized array seems a bit odd... Maybe cut the query up in multiple rows?

[iandunn]

@kovshenin, do you have any thoughts on comment:8? It'd be nice to get this resolved in time to avoid any problems with WCUS.

[kovshenin]

Replying to iandunn: If we want to solve the performance problem I think paginating is the way to go, maybe a new per_page shortcode attribute. Also use a sane default, like 1000 versus the current 10k. Or 500 even. If we want to make it more fancy we can add search, infinite scroll, etc.

[coreymckrill]

Fixed via lazy loading the Gravatars, along with some changes to the caching.

Commits are here:

• ​https://github.com/Automattic/camptix/commit/a71f818a138b8903e71f800ad5f7c137fe1c7902
• ​https://github.com/Automattic/camptix/commit/55360da924d80770503a22e168240a88923f8658

[coreymckrill]

I created #2282 to discuss comment:7.