For example, these results are pretty lackluster. SSR would at least improve the awful FMP results.pic.twitter.com/gv5xOO9JTf
Chrome Project
& Web Standards TL; Blink API OWNER
Named PWAs w/ @phae; probably making her
DMs open. Tweets my own; press@google.com for official comms.
You can add location information to your Tweets, such as your city or precise location, from the web and via third-party applications. You always have the option to delete your Tweet location history. Learn more
Add this Tweet to your website by copying the code below. Learn more
Add this video to your website by copying the code below. Learn more
By embedding Twitter content in your website or app, you are agreeing to the Twitter Developer Agreement and Developer Policy.
| Country | Code | For customers of |
|---|---|---|
| United States | 40404 | (any) |
| Canada | 21212 | (any) |
| United Kingdom | 86444 | Vodafone, Orange, 3, O2 |
| Brazil | 40404 | Nextel, TIM |
| Haiti | 40404 | Digicel, Voila |
| Ireland | 51210 | Vodafone, O2 |
| India | 53000 | Bharti Airtel, Videocon, Reliance |
| Indonesia | 89887 | AXIS, 3, Telkomsel, Indosat, XL Axiata |
| Italy | 4880804 | Wind |
| 3424486444 | Vodafone | |
| » See SMS short codes for other countries | ||
This timeline is where you’ll spend most of your time, getting instant updates about what matters to you.
Hover over the profile pic and click the Following button to unfollow any account.
When you see a Tweet you love, tap the heart — it lets the person who wrote it know you shared the love.
The fastest way to share someone else’s Tweet with your followers is with a Retweet. Tap the icon to send it instantly.
Add your thoughts about any Tweet with a Reply. Find a topic you’re passionate about, and jump right in.
Get instant insight into what people are talking about now.
Follow more accounts to get instant updates about topics you care about.
See the latest conversations about any topic instantly.
Catch up instantly on the best stories happening as they unfold.
For example, these results are pretty lackluster. SSR would at least improve the awful FMP results.pic.twitter.com/gv5xOO9JTf
You can dismiss the results from our Preact & Glimmer experiment if you want, but that was a ~60kb JS payload for the same app we ran with both CSR and SSR with rehydration. CSR was indeed faster for fast devices/networks, but SSR handily outperformed at 90th %ile.
And this was even with several non-optimal conditions, like the gating API call for SSR performing at 1.2s at 90th %ile. A more optimized service tier would have made the improvement even larger, I suspect.
I believe @chadhietala has the WPT traces if you'd like to see them.
Don’t want to be involved here but feel compelled to respond. Data helps toward the end goal of a great experience for users of many applications. I’ll assume variables are equally accounted for in cells and look at the results, can you provide the raw data to support claims?
Take Glimmer out so I don't have a horse in the race and just look at Preact. Preact is much lighter than Polymer out of the box, and for the experiment our JS bundle size was tiny (much much smaller than e.g. YouTube Gaming). Even in that scenario, SSR had better FMP at 90p.
All I'm trying to say is that Preact is a much better fit for pages at the extreme end of performance, because it's both lighter than Polymer and gives you the option of SSR if you need it.
@chadhietala posted traces in the comments: https://infrequently.org/2018/09/the-developer-experience-bait-and-switch/#comment-256438 …
Here are the preact-only sets of runs:
CSR: http://www.webpagetest.org/result/180202_67_ae21f1a34a7f570599edae125e1c292a/ …
SSR+CSR: http://www.webpagetest.org/result/180202_VF_84ae556dc7c51e405d5fccccccb383ae/ …
As noted in the comments of the post,there's a lot of noise between runs. The user-timeline data seems to vary in access cost, which I presume affects both equally? Hard to know.
It looks like the SSR version gets ~complete 500ms sooner. This is interesting given the waterfall for the CSR version: http://www.webpagetest.org/result/180202_67_ae21f1a34a7f570599edae125e1c292a/3/details/ … Request for data is delayed by ~300ms because it's blocked by script eval? Why?
I'd have thought critical data would be H/2 pushed or at least `<link rel="preload">`-ed to get the parser working for you and prevent device speed from being a factor in getting that request out to the network.
Also, can we just stop and note how weird it is that we're talking about a low-latency network and desktop CPU in 2018? That choice surely needs exposition. One of the reasons I'd have thought SSR would be a win is that it largely removes client CPU from the equation.
...so these traces under-sell the impact of JS size and latency on the experience. Both would factors improve with SSR. Was a cable connection chosen because most LI customers have *faster* networks than that?
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.