3 ms·

Enhancing New York Times Web Performance with React 18

16 points by samspenc 2y ago

8organicbits 2y ago
I wish they'd consider adding lighter pages. Compare the load time of a NYT page [1] to a text NPR page [2]. I'm seeing 5.5 seconds vs 600 ms. I think the latter is easier to read as well. [1] https://www.nytimes.com/2024/06/29/us/politics/biden-donors-democrats.html https://www.nytimes.com/2024/06/29/us/politics/biden-donors-... [2] https://text.npr.org/g-s1-6773 https://text.npr.org/g-s1-6773
- deleted 2y ago
  [deleted]
edflsafoiewq 2y ago
[flagged]
- dingdong33 2y ago
  [dead]
- sonthonax 2y ago
  Wait until you learn that they believe they need Kafka. Their engineers are probably bitter they work at a media company and not a FAANG. https://www.confluent.io/en-gb/blog/publishing-apache-kafka-new-york-times/ https://www.confluent.io/en-gb/blog/publishing-apache-kafka-... > The Monolog is our new source of truth for published content. Every system that creates content, when it’s ready to be published, will write it to the Monolog, where it is appended to the end. > The Monolog contains every asset published since 1851. They are totally ordered according to publication time. This means that a consumer can pick the point in time when it wants to start consuming. Consumers that need all of the content can start at the beginning of time (i.e., in 1851), other consumers may want only future updates, or at some time in-between. > As an example, we have a service that provides lists of content — all assets published by specific authors, everything that should go on the science section, etc. This service starts consuming the Monolog at the beginning of time, and builds up its internal representation of these lists, ready to serve on request. We have another service that just provides a list of the latest published assets. This service does not need its own permanent store: instead it just goes a few hours back in time on the log when it starts up, and begins consuming there, while maintaining a list in memory. Absolutely insane. The only reason this works is that the NYT publishes less than 300 articles per day so you can get away with doing un-indexed full table scans of your entire database. But the engineers can put "I created a log based time-series architecture on their resumes".
xnx 2y ago
App-ifying articles is an unfortunate path many sites have gone down. Islands of interactivity are great for special cases (games, some charts), but delivering a few KB of text via an application framework is overkill.
- neverokay 2y ago
  Seems like they need to do this for the paywalls.
apantel 2y ago
[flagged]
- deleted 2y ago
  [deleted]
ozzcer 2y ago
As a dev that has never worked with react its, interesting, to see react '18' introducing fixes to problems that have not been issues before. I've used angular, straight SSR from PHP / node.js / .net and never suffered from 'screen jank' or huge culumative layout shift issues. Not sure we should celebrate the fixing of issues that shouldn't have ever been a problem for a site that just renders text and images.
- throwAGIway 2y ago
  I am currently solving large cumulative layout shift on a WordPress site of my friend... I really don't think these problems are reserved to React.
  - jon9544hn 2y ago
    Most (if not all) blocks in Gutenberg are react in WP
    - throwAGIway 2y ago
      It's not React, it's a jQuery mess from some low budget agency.

16 points by samspenc 2y ago

I wish they'd consider adding lighter pages. Compare the load time of a NYT page [1] to a text NPR page [2]. I'm seeing 5.5 seconds vs 600 ms. I think the latter is easier to read as well. [1] https://www.nytimes.com/2024/06/29/us/politics/biden-donors-democrats.html https://www.nytimes.com/2024/06/29/us/politics/biden-donors-... [2] https://text.npr.org/g-s1-6773 https://text.npr.org/g-s1-6773

deleted 2y ago
[deleted]

edflsafoiewq 2y ago

[flagged]

dingdong33 2y ago
[dead]
sonthonax 2y ago
Wait until you learn that they believe they need Kafka. Their engineers are probably bitter they work at a media company and not a FAANG. https://www.confluent.io/en-gb/blog/publishing-apache-kafka-new-york-times/ https://www.confluent.io/en-gb/blog/publishing-apache-kafka-... > The Monolog is our new source of truth for published content. Every system that creates content, when it’s ready to be published, will write it to the Monolog, where it is appended to the end. > The Monolog contains every asset published since 1851. They are totally ordered according to publication time. This means that a consumer can pick the point in time when it wants to start consuming. Consumers that need all of the content can start at the beginning of time (i.e., in 1851), other consumers may want only future updates, or at some time in-between. > As an example, we have a service that provides lists of content — all assets published by specific authors, everything that should go on the science section, etc. This service starts consuming the Monolog at the beginning of time, and builds up its internal representation of these lists, ready to serve on request. We have another service that just provides a list of the latest published assets. This service does not need its own permanent store: instead it just goes a few hours back in time on the log when it starts up, and begins consuming there, while maintaining a list in memory. Absolutely insane. The only reason this works is that the NYT publishes less than 300 articles per day so you can get away with doing un-indexed full table scans of your entire database. But the engineers can put "I created a log based time-series architecture on their resumes".

xnx 2y ago

App-ifying articles is an unfortunate path many sites have gone down. Islands of interactivity are great for special cases (games, some charts), but delivering a few KB of text via an application framework is overkill.

neverokay 2y ago
Seems like they need to do this for the paywalls.

apantel 2y ago

[flagged]

deleted 2y ago
[deleted]

ozzcer 2y ago

As a dev that has never worked with react its, interesting, to see react '18' introducing fixes to problems that have not been issues before. I've used angular, straight SSR from PHP / node.js / .net and never suffered from 'screen jank' or huge culumative layout shift issues. Not sure we should celebrate the fixing of issues that shouldn't have ever been a problem for a site that just renders text and images.

throwAGIway 2y ago
I am currently solving large cumulative layout shift on a WordPress site of my friend... I really don't think these problems are reserved to React.
- jon9544hn 2y ago
  Most (if not all) blocks in Gutenberg are react in WP
  - throwAGIway 2y ago
    It's not React, it's a jQuery mess from some low budget agency.