Open xtina-starr opened 7 years ago
kanaabe
commented
7 years ago I'd be happy to dig into the mess of 3rd party scripts we run on most of our pages for analytics, etc. This is a pretty big killer. See https://www.webpagetest.org/result/170202_K2_D5BR/2/details/#waterfall_view_step1 towards the bottom for example
craigspaeth
commented
7 years ago If our only partner was MONA we'd have so much better performance! :trollface:
Nearly a MB of JS 🤔 Seems like ~1/4 of that is from external integrations and the rest is our beefy app code...
There's probably some low hanging fruit in leveling up our browserifying process with features like de-duping multiple bundles, excluding libraries we use CDNs for like jQuery, and eventually tree shaking when we migrate to ES6 modules 😶 . This could get the 3/4 of our JS bundles down in size.
It'd be worth investigating if we're requesting images that are significantly larger than we need on critical pages. On-the-fly image processing is great in this case because we can be very precise in the image dimensions we request based on screen size, and not request 1024px on a small phone screen. However, that comes with the tradeoff of burdening our Gemini servers and if abused it could mean images actually loading slower b/c we're constantly waiting to process new sizes (something Isac has been optimizing with GPU powered servers).
Not sure what is falling under that bucket, but surprised it's number three on the list.
As Kana points out, a significant chunk of those 310 requests are from third parties which can cause a bunch of overhead in the number of roundtrips the browser is making and page thrashing happening. We should definitely take a pass over those and make sure we eliminate anything we're not using. After that, we could talk with the various business/marketing teams to see if any Segment integrations or otherwise could be consolidated, but I certainly wouldn't say we should always choose performance over tracking/marketing/ad tools. If it's still a significant overhead after that cleanup we could get clever in seeing how async those tools are loaded.
We'll definitely want to dig deeper into the lifecycle of this 9–10 seconds. Force's server reports an average of ~500ms, so most of that total time is client-side—which IMO is definitely the place to start with performance work. However, as I alluded to in Requests, there will be only so far we want to go in eliminating client-side overhead after we hit limits in the number of marketing tools/scripts we can consolidate/eliminate and total JS/CSS/HTML/Image size we can transfer.
After picking off the low hanging fruit client-side, we'll want to consider improving server-side performance through tracing slow/hungry requests through MP > Gravity/etc. Potentially we could eliminate the roundtrip overhead via Force-side caching (or even in front of Force with something like Varnish—however, mo' cache mo' problems, so I'd certainly caution against this and use it only if we really really need the extra milliseconds.
Finally, after taking a pass at optimizing client + server-side performance, we should investigate the rendering lifecycle of pages and get more nuanced in how we measure things. For instance, 9–10 seconds roughly estimates the loading of resources on the page, but it doesn't give us a clear sense of things like when the above the fold content is visible to time-to-interact. For particularly performance critical pages we might want to write our own performance measuring scripts to track things like "time to first auction countdown clock tick".
😅 rant over. Here's some interesting reading:
The purpose of this issue is to have a place to start capturing some basic metrics around performance and load time for force.
Average for the homepage as a logged in user Load time: 9-10 seconds Page size: 7.5 MB Requests: 310 *this is a rough average captured with google timeline
Here are some breakdowns about content from a tool called pingdom
cc @alloy @kanaabe @craigspaeth I figured I'd create a small issue to start a discussion and start looking into some items regarding performance optimization.