Performance Audit

[daveriedstra]

A number of pages are suffering severely. We should use fancy chrome tools and stuff to trace down the stray processes, memory leaks, etc.

• tasks page took almost 5s to load
• we're probably pulling more data from firebase than we need to
• there's a $scope.$apply() in content-nav.controller.js in a window.timeout for every 500ms that needs to be removed, but doing so creates a delay for content rendering (maybe because the incomplete content is applied to the scope before the Provider has finished working with it?)

[daveriedstra]

@brianbest @clouie87 @colin-macinnis suggestions for optimizations? pulling down only the most recent n statuses?

[brianbest]

Yeah there was a fancy article on smashing mag about lazy loading lists, a la Pinterest style. If we only brought down the first 20 updates or so, only when the user was on the feed page we could make that work.

As well we could only bring down the tasks assigned to the user then on request we get everyone else's

For both of these I think we are grabbing the last 100 statuses and all of the tasks

[brianbest]

Here's that blog. It's a good read but it basically says have user controlled lazy loading https://www.smashingmagazine.com/2016/03/pagination-infinite-scrolling-load-more-buttons/

[daveriedstra]

maybe something to implement after the google cal integration?

[brianbest]

Yeah sounds like a plan

[daveriedstra]

our data structure is partially responsible for this. We can't make one big call to get all of a team's data during init because that will also grab all their statuses and project (task) data. In the next DB structure, we should do

$teamID {
  "meta" : {
    "name" : "ACME",
    "members" : { ... },
    "slack" : { ... }
  },
  "statuses" : { ... },
  "projects" : { ... }
}

and then we'll be able to address team.meta in one quick call to get everything loaded immediately, then statuses and projects can use their own FB queries (eg, limitToLast)

[daveriedstra]

(which is to say that right now I'm patching this by making a buncha little calls to each property so that statuses can be its own call. Unfortunately our best solution, I think...)

[daveriedstra]

high latency HTTP requests on cache-less load (on my localhost in a cafe) (requests over 500ms):

• zendesk files (800ms-2s, main.js downloaded twice and also a config file)
• gravatars (500ms-3s each)
• /api/pays/find (1.62s and multiple calls, I'll look into this)
• stripe v2 (948ms, can we try to only load this when we need to?)
• open sans from google cdn (880ms)

[daveriedstra]

from Chrome audit (on /feed): (moving mixpanel script to bottom of body fixed this)

1 inline script block was found in the head between an external CSS file and another resource. To allow parallel downloading, move the inline script before the external CSS file, or after the next resource.

and

2367 rules (89%) of CSS not used by the current page.
http://localhost:9000/: 100% is not used by the current page.
http://localhost:9000/: 75% is not used by the current page.
app.css: 88% is not used by the current page.
toaster.css: 95% is not used by the current page.
fullcalendar.css: 100% is not used by the current page.

[brianbest]

Had to put Stripe back in on all pages in the current prod. Reason being billing is completely shot with out it untill we can find a better way to load scripts in as needed with angular