日経電子版での自作 SSR フレームワーク基盤について — HACK The Nikkei
こんにちは、Web チームの井手です。今日は私たち Web チームが作っている SSR フレームワーク(以下 FW)にについて紹介します。 記事を書くモチベーション 私たちのメインプロダクトである日経電子版においては k2 という自作 SSR 基盤を 2020 年から運用しています。SSR FW といえば多くの方が Next.js を想起すると思いますが、私たちは自作しています。一方で最近は Next.js の進化が凄まじく、自作 SSR 勢としても意識せざるを得なくなっています。もしかしたら「あぁ Next.js で作っておけばよかった」と思う時が来るかもしれません。特に k2 を保守する際には Next.js では実現できない機能を実現するために様々な手法や工夫を編み出していましたが、Next.js の進化に伴ってその必要性はだんだん減ってきているのを実感しています。そのためいつか N
Edge Side Frontend という新領域
at #ワインと鍋js なぜフロントエンドに Edge Worker が必要なのか、Cloudflare Workers をどう使っていくかみたいな話をしました
Cloudflare Workers それは Frontend / Node.js が CDN Edge Side まで拡張されるもの
最近は Cloudflare Workers が熱くて、週末はずっとその調査しています。この記事はそのまとめです。 注意点として、手元でいろいろなパターンで動かして試してはいますが、プロダクション環境で運用したわけではないです。それを踏まえた上でお読みください。 特に断りが無い限り、引用文は DeepL で翻訳したものです。 Cloudflare Workers とはなにか Cloudflare Workers | サーバーレスコンピューティング | Cloudflare 一言でいうなら 「ServiceWorker の API が CDN Edge 上で動く JavaScript 処理系」 です。 Technology Radar では、まだ ASSESS(調査) フェーズという扱いです。 Cloudflare Workers | Technology Radar | ThoughtWo
WebPackaging の Signed HTTP Exchanges | blog.jxck.io
Intro WebPackaging は以下の 3 つの仕様を組み合わせたユースケースである。 Signed HTTP Exchanges: Signing (コンテンツに署名する) Bundled HTTP Exchanges: Bundling (コンテンツを 1 つにまとめる) Loading Signed Exchanges: Loading (そのコンテンツをロードする) 本エントリでは、各仕様を Signing/Bundling/Loading と記す。 現状、 Signing および Loading の仕様策定が進んでおり、 Chrome は Experimental な実装を行っている。 全体的に仕様が大きく、今後も変更される可能性が高いため、今回は実装が進んでいる Signing に絞り、ユースケース、仕様、および本ブログへの適用を中心に解説する。 Signing (Si
表示速度が“爆速”なサイト、相次いで登場 その背景は
ページの読み込み速度が“爆速”のサイトが相次いで登場している。2017年後半、日経電子版がリニューアルし「表示速度を従来比2倍に」と発表した他、米国のプログラマー向けコミュニティーサイト「dev.to」の表示速度が「速すぎて不安になるレベル」と話題を呼んだ。米Googleによれば「モバイルサイトでは読み込みに3秒以上かかると訪問者の53％が離脱する」といい、表示速度の改善が「長く滞在してもらう」一助になるようだ。 こうしたサイトが利用しているのがCDN（Content Delivery Network）という技術だ。なぜ速くなるのか、CDNを提供しているファストリー（米Fastly日本法人）のチュクロ・ダグ代表取締役、松田未央シニアセールスエグゼクティブに聞いた。 CDNの基本的な仕組みは？ ユーザーがインターネットを経由してWebサイトなどコンテンツを見に行くとき、ユーザーとコンテンツの
HTTP/2が速いという幻想 - Webパフォーマンスについて
難しい話じゃないです。 皆さん、ご自分でChrome Developer Toolで簡単に確認できますから、やってみて下さい。 このブログでも、過去に統計分析をした結果は掲載したんですが、「盲信」はそうそう簡単には消えないようでして… takehora.hatenadiary.jp takehora.hatenadiary.jp 以下の図は、Chrome 63.0.3239.108での結果です。 CDNにFastlyでもAWS CloudFrontでも、どのCDNを使って実験して頂いても結構です。 CDNを使わずに、Webサーバ単体でも結構です。 同様の結果になります。 どちらもHTTPS通信です。 どちらも同じオリジン、同じファイル構成です。 HTTP/1.1は、Keep-Alive設定が入っています。 HTTP/1.1での配信 … Load Event 70ms HTTP/2での配信
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
