![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
#1760 closed enhancement (fixed)
WordCamp | Refactor attendees system for better performance
| Reported by: | LucP | Owned by: | kovshenin |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | WordCamp Site & Plugins | Keywords: | dev-feedback good-first-bug |
| Cc: |
Description
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)
Change History (13)
#2
@
10 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:
↓ 6
@
10 years ago
Lazy loading would bring that down to whatever a screen can display in one go.
#4
@
10 years ago
- Keywords dev-feedback good-first-bug added
- Owner set to
- Priority normal → high
- Status new → assigned
Related #230
#5
@
10 years ago
Another thing to take into account here is that sometimes people will put multiple [camptix_attendees] tags on a page.
#6
in reply to: ↑ 3
@
10 years ago
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...
#7
@
10 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
@
10 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:
↓ 10
@
10 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
@
10 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.
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?