ChromeとFastlyのEarly Hintsの効果計測に貢献する — HACK The Nikkei
この記事は Nikkei Advent Calendar 2020 20 日目の記事です。 日経電子版 Web チームの阿部です。今回は HTTP/2 の目玉機能の 1 つであった Server Push の事実上の終焉と、現在 Chrome チームや Fastly 社が実験中の 103 Early Hints について、日経電子版 Web での取り組みを紹介させていただきます。 HTTP/2 Server Push HTTP/2 Server Pushは HTTP/2 で策定された、一言で言ってしまうと「必要なリソースがリクエストされる前にサーバーからクライアントに送ってしまおう」という技術です。 これによりクライアントがリクエストするリソースを先回りしてサーバーが送ることで、必要なリソースが揃うまでにかかる時間を短縮できるため、パフォーマンスの向上が期待されていました。 Server
Webpagetestから始める継続的パフォーマンス改善
autoscale: true Webpagetestから始める継続的 パフォーマンス改善 ページロードタイム編 :hourglass: 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info Create: textlint, Almin アジェンダ パフォーマンス改善は指標を決めて行わないと迷子になる パフォーマンス改善を行うには継続的な計測を行う 今回はページロードについて、ランタイムは範囲外 パフォーマンス改善のアプローチ 継続的なパフォーマンス計測とリグレッションの検知 ^ 目的はパフォーマンス改善には計測が必要という事実を知ること ^ パフォーマンス計測は継続的に行う必要がある ^ パフォーマンス改善は何を目的、指標にして改善するかを決めないと迷子になる ^ 目的をもって継続的にパフォーマンス改善を行い
#reject_sushi でReactとチーム開発について話してきた
React.js meetup #3に参加できなかったので#reject_sushiに参加してきました。 #reject_sushi - Togetterまとめ Draft.js | Rich Text Editor Framework for React ©年号を見る感じ結構前から実装してそう How to work as a Team @ azu #reject_sushi で発表したReact+Flux的な何かの意思決定と情報設計の話。 "How to work as a Team" https://t.co/qM4iyipRFS — azu (@azu_re) February 23, 2016 自分はチーム開発でReact + 何かを採用するときにどういうフローで話を進めていってるかについてを話しました。 まだ結論はないですが、Flux的な何かを採用したからといって設計がすごく簡
HTTP2 を前提とした HTML+CSS コンポーネントのレンダリングパス最適化について | blog.jxck.io
Intro Chrome が予定している <link rel=stylesheet> の挙動の変更について、 Google Chrome チームの Jake が、興味深いブログを上げている。 The future of loading CSS この内容は、単に Chrome に対する変更だけではなく、 HTTP2 によって変化する最適化手法と、それを最も活かすための HTML, CSS の構成についてのヒントがある。 今回は、この内容を意訳+補足解説し、本サイトに適用していく。 HTTP/1.1 時代の CSS HTML 自体がコンポーネントを意識した作りになっている場合は、自然と CSS も class などを使いコンポーネント単位に作ることができるだろう。 しかし、 HTTP/1.1 では、リクエストの数を減らすために全ての CSS を 1 つ(もしくは少数個)に結合する最適化が主流だ
サイトに適したリソース配置とasync/defer完全マスター – レンダリング優先のグッド・プラクティス | ゆっくりと…
タイトル、少し変えました 😉 。 第1部「サイト高速化の「戦略」と「戦術」- GradeAのその先へ」では、YSlow や PageSpeed がアドバイスする Tips のうち、HTTP リクエストの削減を優先すべしという「戦略」の話をしました。 また css や js を束ねて結合し、HTTP リクエストを削減する時の「戦術」の話もしました。 今回は、「サイトの特性に適したリソースの配置を行う」ために、「束ねたリソースをドキュメント中にどう配置するのが適切か」を見い出したいと思います。またそのポイントとなるブラウザの基本的な挙動についても言及します。 ブラウザごとの挙動が確かめられる、実験サイト contentloaded.com を立ち上げたので、以下、同サイトから幾つかの例を引きながら話を進めたいと思います。 リソース配置を決める戦術 基本的な戦術 第1部 では、css や js
2014年のWebパフォーマンスふりかえり - 来年以降の期待etc
ひさびさにWebフロントエンドパフォーマンス系の話題をつらつらと書いてみます。例によってモバイル系開発者寄りの視点かもしれません。文中の参照リンク多め。 ファクタ まずはパフォーマンスに影響を与えるファクタについての所感。Webパフォーマンスにおけるイニシャライズとランタイム ::ハブろぐ で示した分類に基づきます。 イニシャライズ（いわゆるページロード） 4GやLTEが普及してもコンテンツの肥大化には追いついていない concat と CSS Sprites の呪いが解けない HTTP/2 の Streams and Multiplexing に期待 HTTP/2 の Server Push にも期待 画像周りだと <picture> 関連仕様も使いたい（srcsetだけならいける？） WebRTC とか WebSocket とかストリーミングとかは？ （やや疎い、てかイニシャライズじゃ
画像を分割もしくは合体させてパフォーマンスは本当に変化するのか? - Webパフォーマンスについて
これは、HTML5 Advent Calendar 2014の7日目のエントリーとして書いております。 2008年4月1日に初版が発行された、オライリー・ジャパンの「ハイパフォーマンスWebサイト」を未だに参考にされている方は多いと思います。 ウェブページ内で、背景やボタン、ナビゲーションバー、リンクなどで多数の画像を使う場合は、CSSスプライトを使うのがエレガントな解決策です。そうすることで、マークアップが整理され、扱うべき画像の数も減り、レスポンスも高速になります。 ― 「ハイパフォーマンスWebサイト 高速サイトを実現する14のルール」 Steve Souders著 その部分を参照されてか、時折、「CSSスプライトを使うことで、HTTPリクエスト数が削減されて、高速化に繋がる」と書かれている方をお見受けします。 しかし、それは本当なのでしょうか? そこで、今回、本当に効果があるのかど
Private Presentation
Private content!This content has been marked as private by the uploader.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「HTTP/2」制定の背景や「HTTP/1」との違い、Akamaiのマーク・ノッティンガム氏が説明 