Making WordPress.org

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#1760 closed enhancement (fixed)

WordCamp | Refactor attendees system for better performance

Reported by: LucP Owned by: kovshenin
Milestone: Priority: high
Component: WordCamp Site & Plugins Keywords: dev-feedback good-first-bug


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.

Attachments (1)

CkhNO2NWkAA5r-4.jpg (21.0 KB) - added by LucP 4 years ago.

Download all attachments as: .zip

Change History (13)

4 years ago

#1 @DeFries
4 years ago

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?

Last edited 4 years ago by DeFries (previous) (diff)

#2 @LucP
4 years ago

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...

#3 follow-up: @DeFries
4 years ago

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

#4 @iandunn
4 years ago

  • Keywords dev-feedback good-first-bug added
  • Owner set to kovshenin
  • Priority changed from normal to high
  • Status changed from new to assigned

Related #230

#5 @iandunn
4 years ago

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/

#6 in reply to: ↑ 3 @LucP
4 years ago

Replying to DeFries:

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

I think lazy loading is an excellent option...

Version 0, edited 4 years ago by LucP (next)

#7 @s1m0nd
4 years ago

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.

#8 @LucP
4 years ago

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?

#9 follow-up: @iandunn
4 years ago

@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.

#10 in reply to: ↑ 9 @kovshenin
4 years ago

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.

#11 @coreymckrill
4 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

#12 @coreymckrill
4 years ago

I created #2282 to discuss comment:7.

Note: See TracTickets for help on using tickets.