Community App Performance : General Report

[sushilshinde]

Community app challenge listing page is very slow compared to the number of actions that it can perform. It should be one of the fast pages in the app as community members are most likely to come to listing looking for new exciting challenges.

Community app (https://www.topcoder.com/challenges) on production with moderate internet speed performs very badly. I have done and audit and profiling of community app with these profile attributes

1. Network: Fast 3G
2. CPU: 4x slowdown

This is how lighthouse audit performance report looks like

And this is how profiling looks like, there is huge scripting time and call chaining involved in the rendering of the app. That creates the bad user experience and add server payload cost.

There a is a huge opportunity for improvement in every area, I will divide this report into three main categories in the order of low hanging fruits.

A. Build Improvements

1. Build artifacts contain unused code

Some of these files are huge, the amount of code that is being downloaded isn't used by the application. And it blocks main thread and a network connections.

In some of the files more than 50% of the code is not used indicated by red zone

And it can be reduced with treeshaking, which will reduce the size of the build artifacts.

2. Files that are non-essential to display of listing components

Some of these files are huge and loaded synchronously in a parser blocking manner, they are also blocking the main thread and network connections.

These are the list of files

1. google analytics
2. zendesk
3. messo
4. google tag manager
5. hotjar
6. connect.facebook
7. even raven.js

These files can be downloaded with async/defer as these aren't neccessary for first paint.

<script src="some-analytics.js" async></script>

B. API calls improvements

On the listing page, essential components that need to be rendered in order to make a user interface ready for interaction are

1. Challenge Summary
2. My Challenges
3. Open of Registration

To render these components, we only need

41      // 20 open for registration, 20 Past and 1 challenge summary
+ X     // My challenges
= 41 + X // Total records 

If we decide to show past challenges lazily, in that case, total records are necessary to show first painted view is only 21 + X

Instead, app is fetching

50      // Past
+ 50    // Completed
+ 50    // Active
+ 50    // Active 50 to 100
+ X     // My challenges 
= 200 + X // Total records

Lots of unnecessary data calls

Here is the detailed report on calls

C. Misc

These calls are not compressed and consuming the network time

1. https://lc1-user-settings-service.herokuapp.com/saved-searches
2. https://d2nl5eqipnb33q.cloudfront.net/static-assets/loading-indicator-animation-1529020371826.js
3. Cloudfont will not compress font file with woff extension, https://d2nl5eqipnb33q.cloudfront.net/static-assets/fonts/bae8500e15c460acae92cfc8da3b4f3d.woff

PS : I'm still investigating bottlenecks, I will continue to add to the list

[dmessing]

Let's remove past challenges all together and show only if someone wants to view pasts challenges.

[ajefts]

Past challenges are removed from the main UI, but maybe the app is still fetching them for some reason...

…

On Jun 25, 2018, at 10:16 AM, David Messinger ***@***.***> wrote: Let's remove past challenges all together and show only if someone wants to view pasts challenges. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[vic-tian]

Also an interesting read about react-specific optimizations with potential to further optimize the pages and our approach towards performant front-end: https://medium.com/airbnb-engineering/recent-web-performance-fixes-on-airbnb-listing-pages-6cd8d93df6f4.

[Oanh-and-only-Oanh]

closing tickets dated 07/2017 and back