Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve first-load performance #392

Open
chasenlehara opened this issue Aug 25, 2017 · 2 comments · Fixed by #393
Open

Improve first-load performance #392

chasenlehara opened this issue Aug 25, 2017 · 2 comments · Fixed by #393
Labels

Comments

@chasenlehara
Copy link
Member

If you load canjs.com with Slow 3G enabled in Chrome’s DevTools, you’ll see it takes ~20 seconds for everything to load. There are probably some easy things we can do to improve the load time.

@imaustink
Copy link
Contributor

imaustink commented Sep 1, 2017

Preliminary testing seems to show there isn't much to improve on the client side: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fcanjs.com%2F&tab=mobile

I would like to dig a little deeper here before making any final decisions. But in my experience, Google's page speed test is a pretty solid metric.

In my opinion, the biggest performance boost we could achieve would be from improve caching headers, and moving to HTTP/2, as most of the lag comes from the large number of individual connections. As far as I can tell, neither of these changes are possible with GH pages by itself. In the past, I've used CloudFlare to augment such functionality. If we wanted to pursue this option, I believe the free plan would work just fine for our needs.

Let me know if you have any other thoughts.

@imaustink
Copy link
Contributor

imaustink commented Sep 1, 2017

  • Static JS (probably won’t be able to find any quick wins here)
  • Optimize images (drag & drop all our PNGs into ImageOptim)
  • StealJS optimize build
  • Too many buttons

imaustink added a commit that referenced this issue Sep 2, 2017
Since we have a CSS animation on the width of the bar, and on a fast network the progress event usaully only fires once (at 100%), hiding the loading indicator eminently after calling `.end()` would not allow the animation to complete before the bar hidden.

This PR adds a timer to wait for the CSS animation before hiding the bar.

closes #392
@chasenlehara chasenlehara reopened this Nov 1, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants