Chromium では Prefetch や Prerender を総称して Speculative Loading と呼ぶことになった話
Chromium では Prefetch や Prerender といった投機的なリソースローディング機能を総称して Preloading と呼んでいました。しかし、Preloading という名称は既に広く使われており、特に具体的な API である <link rel=preload> や Service Worker の Navigation Preload などと被ってしまうため、評判がよくありませんでした。 I've complained before that "preload" is a heavily overused term in frontend/#webperf, with many conflicting meanings and nuances. Now Google will make it even worse by using "preloading" fo
設計に悩みすぎる前に手を動かしてみる話
私がソフトウェア開発において心がけていることの一つに「設計に悩み始めたらとりあえず手を動かす」というものがあります。今まで深く考えずにそう心がけていましたが、この記事で自分がなぜそうしているのか整理して言語化してみたいと思います。 話のスコープ ここでいう「手を動かす」とは「コードを書く」ことです。設計と聞いて人によって思い浮かべるものが違いますが、ここでは「一人のソフトウェアエンジニアが四半期程度かけて開発する規模の機能の設計」を想定しています。何人ものソフトウェアエンジニアが長期に渡って行うような大規模開発には当てはまらないです。 本題 次のような経験はないでしょうか？ 設計を考えながらデザインドキュメントを書いていたら細部の粗が見えてきて無限に悩み続けてしまった。考えなきゃいけないことがどんどん膨らんでいって、いつまでも実装に手を付けられなかった。 これに対して私は「設計に悩み始めた
JavaScript のスレッド並列実行環境
これは Chromium Browser アドベントカレンダーの十日目の記事です。本記事では Chromium における JavaScript のスレッド並列実行環境について仕様・実装・API の面から包括的に紹介します。ブラウザの内部実装に興味がある人を対象に、各機能の使い方ではなく実行モデルに焦点を当てて説明しているため、難易度は高いです。使い方を知りたい人は MDN などの記事を読んでください。この記事をきっかけに実装解読に挑戦してみる人が一人でも増えると幸いです。 本記事を書くにあたり、yuki3 さんに多くのコメントをいただき、議論に付き合っていただきました。ありがとうございました。なお、文責はすべて私 (nhiroki) にあります。誤りや補足、質問などは気軽に GitHub Issue もしくは Twitter へお寄せください。 更新履歴 2018/01/15 Layout
リソースの読み込みを助けるウェブブラウザ API の世界
ウェブブラウザはネットワークから様々なリソースを集め、それらを処理して組み合わせてウェブページをレンダリングします。リソースが揃わないとレンダリングできないので、この一連の処理のどこかが遅れるとページの表示も遅くなります。レンダリングをすみやかに開始できるようにウェブブラウザはリソースの取得やその処理を最適化するための API を提供しています。本記事ではそれらを網羅的に紹介し、ウェブアプリの性能改善を図る上でどのようなブラウザ機能が使えるのかを知ってもらうことを目的としています。各機能の具体的な適用事例については他の記事に委ねます。 本記事の内容は記事公開時点での情報に基づいており、閲覧時点では既に古くなっている可能性があります。最新の正確な情報は一次情報源を参照してください。また特定のブラウザ実装について言及する場合は、断りがない限り Chrome を想定しています。誤りや補足、質問な
チームにいると頼りになるソフトウェアエンジニア
チームにいると頼りになるソフトウェアエンジニアのメモです。自分のロールモデルでもあります。私のキャリアはほぼウェブブラウザ開発一筋なので、その辺に生息している人たちを思い浮かべながら書いてます。思いついたら随時更新します。 コードマニア コードやドキュメントを読むのが好きで、暇があれば適当なレビューに飛び入り参加したり、自分のプロジェクトとは関係ないコンポーネントもひたすら探検している。不穏なコードを見つけるとなんとリファクタリングもしてくれる。コードサーチがお友達。 やたらコードに詳しいので、何か分からないときはとりあえず聞きに行く。チームに一人いるとレビューが捗るし、コードベースも綺麗になる。コードマニアはコードベースを広く熟知している上に未知のコードに対する耐性も高いので、プロジェクトを移動してもすぐに活躍できる。 コードマニアの亜種にスペックマニアもいる。こちらはウェブやネットワー
Design Docs への思い
Message Passing での話題を契機に、色々な人が自身の Design Docs 観を共有していて、とても興味深く読ませてもらいました。普段「仕事を進める上で当たり前に必要なもの」として書いている自分に気づき、これを機に自分の Design Docs 観も言語化してみようと思ったのが本記事です。実践の一例を付け加えることが狙いであり、「Design Docs はかくあるべき」と主張するものではないです。 はじめに 「人によって思い浮かべる Design Docs 観が全然違う！多様で面白い！！」というのが話の出発点ですが、さすがに想定しているものが違いすぎると話が発散してしまうので、本記事では Design Docs を「ソフトウェアエンジニア (私) が何らかのプロジェクトやタスクを進める上で書く文書」としておきます。 次に私の立場を明確にしておきます。私はオープンソースのウェ
『Web ブラウザセキュリティ ― Web アプリケーションの安全性を支える仕組みを整理する』を読んだ
『Web ブラウザセキュリティ ― Web アプリケーションの安全性を支える仕組みを整理する』の読書メモです。 感想 私は Chromium ブラウザの開発に携わっており、本書で紹介されている機能の一部の実装者の立場で読みました。 ブラウザの持つセキュリティ機能が体系立てて紹介されており、機能間の関係性が分かりやすくまとめられている。特に最新のブラウザセキュリティ機能はブラウザの内部構成 (例えばプロセス分離) に強く依存しているので、ブラウザが何をどう守りたいのか抽象的なところから理解していかないと各機能の必要性が分かりにくいが、この本はその抽象的なところからしっかり整理してくれているのが良かった。 プロセス分離に関して恐らく日本語で最も詳しく整理された資料だと思います。過去の研究実装から最新の仕様までしっかり言及されていて、ここまで調べてまとめあげるのは大変だったと思います。これからウ
crossorigin 属性の仕様を読み解く
本記事では HTML タグに指定可能な crossorigin 属性について仕様を参照しながら詳しく解説します。crossorigin 属性は複数の意味を表しており、またそれを指定するタグの他の属性値によって振る舞いが変わってしまうことから、その挙動を正確に理解するのがなかなか難しい属性です。 HTML 仕様は日々進化しています。本記事で説明している内容は記事執筆時点のものであり、閲覧時点では古くなっている可能性があります。正確な情報を知りたい方は必ず最新の仕様を確認するようお願いします。 要点だけを知りたい方は最後の「まとめ」を読んでください。 目次 crossorigin 属性はどこで使われている？ crossorigin 属性は何を意味するのか？ request mode credentials mode crossorigin 属性の意味のまとめ crossorigin 属性の振る
ウェブの進化とウェブブラウザ開発の最前線
学部 3, 4 年生向けの特別講義で『ウェブの進化とウェブブラウザ開発の最前線』というタイトルで話をしてきました。 ウェブの進化の歴史を知ることで現在のトレンドについて理解し、またウェブブラウザというグローバルで大規模なソフトウェアの開発の一端を垣間見ることで、ウェブやウェブブラウザの開発に少しでも興味を持ってくれたら良いなぁという気持ちで話をしてきました。 なお歴史観については私の事実誤認も含まれると思うので、間違いを見つけたら教えて下さい :-) 追記 (随時) たくさんの反応を頂きありがとうございます！次回同じような資料を作るときの参考にできるよう、ここにメモしていきます。ウェブは無限に話せる話題があって楽しいですね！ ウェブ以前のハイパーテキストの歴史も取り入れるべきでは？ ありがとうございます！おっしゃるとおりで、ウェブの進化史と言いつつウェブが公開されてからの話しかしていないの
environment settings object の origin の仕様を追う
iframe や worker といった実行コンテキスト (environment settings object) が持つ origin がどのように決められるのか仕様を調べたメモです。長文でかつ難解なので、結論だけ知りたい方はまとめを読んでください。 この記事は 2020 年 2 月 16 日時点の各種仕様を元に記述しており、現時点では参照している仕様が更新されていたり、リンクが切れている可能性があります。ご了承ください。 目次 はじめに iframe の場合 (about:blank) iframe の場合 (navigate) Web Worker (Dedicated Worker / Shared Worker) の場合 Service Worker の場合 Worklet の場合 まとめと雑感 はじめに HTML standard では iframe や worker といっ
Chrome 69 で Web Worker から Web Worker を作れるようになった話
少し前のバージョンですが、Chrome 69 より Web Worker から Web Worker を作れるようになりました。この機能は Nested Workers とも呼ばれています。 Nested Dedicated Workers - Chrome Platform Status Intent to Implement and Ship: Nested dedicated workers - blink-dev 使用方法とユースケース 使い方は Window 上で Worker を作る場合と同じです。次のコードでは、Window から Parent Worker、Parent Worker から Child Worker を作り、postMessage() で Child Worker から Window までメッセージを送信します。 // index.html const wo
新卒のソフトウェアエンジニアになるまで
流れに便乗して私がソフトウェアエンジニアになるまでにやってきたことを書いてみます。学生を想定読者にしています。進路を考える時の参考になると嬉しいです。 私は修士一年の 2010 年に Google Japan の Chrome OS チームでインターンし、 2012 年に新卒のソフトウェアエンジニアとして入社しました。現在は東京オフィスの Chrome ブラウザの開発チームにいます。インターン中や入社後の仕事については以前「就職して 6 年過ぎた」という記事に書いたのでそちらも是非見てください。 本記事では学生時代に何を学び、それがどのように現在へと繋がっていったのか紹介します。ソフトウェアエンジニアとしての能力や経験をどのように磨いてきたかが中心です。面接を含む Google 固有の話題は他の記事で十分語られているのであまり書きません。 長文です。結論だけ読みたい人は『最後に』を読んでく
日々の進捗の出し方
私は「何かを習慣化してやり続けてそこそこのレベルまで持っていく」のがわりと得意な方だと思っています。本記事はその辺りのことを言語化してみようという試みです。 大体いつも二つのことを意識しています。一つは「毎日前に進む」、もう一つは「当たり前のレベルを上げる」です。 毎日前に進む 身も蓋もない話ですが、やらないと進捗は出ません。一方、少しでもやり続けていればいつか絶対にゴールに到達できるはずです。眠くても疲れていても毎日ちょっとずつ前に進むべきです1。ここで大事なのは「量はどうでもいい」ということです。「毎日やり続ける」ことが重要で「毎日 15 ページ本を読む」のように決まった分量をこなすことをルールにしてはいけません。破綻します。 さて「いつか絶対にゴールに到達できるはず」と言いましたが、ゴールがあやふやだといつまでも到達できません。ゴールは到達判定可能で少しずつ近づけるものにし、進捗もざ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
