Intro 本サイト blog.jxck.io 以下については、 Markdown から静的ファイルを生成するスタイルで作成している。 この変換時に以前から思っていた HTML の最適化 を実施することにした。 しかし、 md->html 変換時にそれをできるツールが見当たらないため、 Markdown の AST から HTML を構築する過程で、省略を施すスクリプトを自作した。 ただし、ソースはあくまで観賞用なので、インデントやコメントは残している。 チューニングではなく単なる実験としてサイト全体にこれを適用し、その結果を記す。 静的コンテンツの最適化 パフォーマンス改善の常套手段として、コンテンツの最適化がある。 ただ、ここ最適化と言っているものには大きく二つある。 gzip などのアルゴリズムにより経路上で圧縮する bmp を png, jpeg, webp などのフォーマットに変
Index 2025 2025-01-27 "Less Password" 時代のアカウント防災訓練 2025-01-22 Web 技術年末試験 2024 講評 #web_exam2024 2025-01-16 Cookie Theft 対策と Device Bound Session Credentials 2024 2024-12-31 2024 年を振り返る 2024-12-12 3PCA 30 日目: 2024 年の 3rd Party Cookie まとめ 2024-11-14 Dialog と Popover #12 2024-11-01 Dialog と Popover #11 2024-10-22 Dialog と Popover #10 2024-10-16 Dialog と Popover #9 2024-10-11 Dialog と Popover #8 2024-1
Image 画像は <picture> タグを用いて表現する。 必ず .webp も提供する必要がある。 webp の推奨は以下 $ cwebp -q 40 img.png -o img.webp Video markdown 上は画像と同じ記法で、拡張子が mp4 の場合は <video> で展開する。 必ず .mp4、.webm 両方を提供する必要がある。 QuickTime で screen record を取り gif 的に表示するなら推奨は以下。 # メタデータを消し、 frame rate を 24 にし、Audio を消す $ ffmpeg -i video.mov -map_metadata -1 -r 24 -an video.webm $ ffmpeg -i video.mov -map_metadata -1 -r 24 -an video.mp4 サンプルコード イ
Intro textarea などに入力された文字数を、JS で数えたい場合がある。 ここで .length を数えるだけではダメな理由は、文字コードや JS の内部表現の話を理解する必要がある。 多言語や絵文字対応なども踏まえた上で、どう処理するべきなのか。 それ自体は枯れた話題ではあるが、近年 ECMAScript に追加された機能などを交えて解説する。 なお、文字コードの仕組みを詳解すること自体が目的では無いため、BOM, UCS-2, Endian, 歴史的経緯など、この手の話題につき物な話の一部は省くこととする。 1 文字とは何か Unicode は全ての文字に ID を振ることを目的としている。 例えば 😭 (loudly crying face) なら 0x1F62D だ。 1 つの文字に 1 つの ID が割り当てられているのだから、文字の数を数える場合は、この ID の
Intro 今月の Web メモ Browser Chrome 2/2: Beta Chrome57 Grid Add to Home Screen Media Session text padding SW NavigationPreload remove vender prefix from IDB Chrome58 Beta, Dev, Canary release (stable updates tag) updates chromium canary Firefox 1/31 Stable Firefox51 new logo e10s Firefox52 Beta Firefox53 Dev TURN/TLS support Firefox54 Nightly es modules が動くように release nightly Safari Safari 10.0 tech p
Intro W3C の TAG から、主にブラウザ API の Polyfill に関するドキュメントが公開された。 Polyfills and the evolution of the Web Polyfill は便利な一方で、時として標準化の妨げになってしまう場合があるため、それを避けるために、Polyfill 実装者、利用者、仕様策定者などが、どう振る舞うべきかという趣旨である。 今回はこの内容を元に、Web の進化と協調する Polyfill のあり方について、主に「実装者」がどうすべきかに着目し記す。 Web における Breaking Change Breaking Change は、簡単に言えば 後方互換を失うことで既存のものが壊れる可能性がある変更 のことを表す。 そして、Web における Breaking Change (Break the Web)、具体的には Web
Intro このブログで CSP レポートの収集を開始してもうすぐ 1 年になる。 現状、対象ドメイン内で <input> は一切提供しておらず、大半が静的に生成されたページであるが、この条件でも、かなり多くのレポートが集まった。 今回は、収集した実際のレポートを例に、攻撃ではないと思われるレポートとしてどういったものが送られて来たかを中心に、その内容やレポーティングサーバ、CSP の運用に関する現時点の考察についてまとめる。 収集目的 CSP の基本は、意図しないリソースの読み込みや、Inline Script の実行を防ぐことにある。 例えば、エスケープ漏れにより XSS が発生し、悪意のある Inline Script が埋め込まれた場合でも、Inline Script を禁止するポリシーを適用したページでは、その実行はブラウザによって Violation(違反)と判断されブロックさ
Intro 月一メモ Browser 1/25 Chrome 56 scroll イベントの passive 化 webvr web bluetooth position: sticky writeable streams HTML5 default 1/24 Firefox 51 https://developer.mozilla.org/en-US/Firefox/Releases/51 webgl default idb2 1/23 Safari 10.1 fetch idb2 custom elements input events form validation async/await grid layout News Mozilla の new logo フォントも無料公開されるらしい マイナンバーサイト 32bit IE/Safari + Java IC カード対応のため止む
Intro HTTPS 移行の問題点の一つに、mixed contents への対応がある。 逆に mixed contents の発生を恐れ、HTTPS に移行できないサービスもあるだろう。 本エントリでは mixed contents の正しい理解と、その検出や解消に利用できる可能性のある、CSP の Upgrade-Insecure-Request および、Block-All-Mixed-Contents を解説する。 mixed contents HTTPS で配信されたコンテンツが、サブリソースとして HTTP のコンテンツを含む場合、これを mixed contents という。 HTTPS は MITM に対する耐性があるが、HTTP は MITM への耐性がないため、mixed contents の状態ではサブリソースを起点にメインコンテンツへの改ざんが成立してしまう可能性
Intro 例年通り、今年を振り返る。 Blog 移行 このブログを移行した。 Web に関する新しい技術についてエントリを書いておきながら、それをブログ自体が使ってないという片手落ち感をずっと感じていたので、これまで使っていた hatena blog や Qiita など、制限のある他のプラットフォームを離れることにした。 おかげで、HTTP のヘッダや、TLS の設定単位で自分の好きなことを試せるようになり、非常に良い検証環境となっている。 https://labs.jxck.io も、好き勝手できるので非常に良いデモ置き場となっている。 もっと早くやっておけば良かった思う、このままどんどん色々試したい。 今年書いた記事は、このエントリをいれて 35 本。 下書きは溜まりに溜まってるが、まぁまぁだろうか。 mozaic.fm mozaic.fm も移行した。 もともとは、この Podc
Intro これは、 http2 Advent Calendar 2016 の 16 日目の記事である。 HTTP に新しいステータスコード 103 Early Hints が追加されようとしている。 HTTP/1.1 および HTTP2 双方と関わり、リソース配信の最適化に利用することができる。 いったい何のために必要なのか、どういうメリットが考えられるかを解説する。 HTTP2 Push の復習 まず HTTP2 の Push について復習する。 H2 Push は、簡単に言えば PUSH_PROMISE フレームを用いて、レスポンスよりも先に依存するリソースを返すための仕様である。 例えば /users のレスポンスは script.js と style.css をサブリソースとして含んでいるとする。 HTTP2 では SQL を発行して Users の一覧を取得している間に、先行し
Update Foreign Fetch は削除される方向で進んでいる。 別途エントリを上げたのでそちらを参照。 Foreign Fetch が削除されそうな理由と Cookie の double keying | blog.jxck.io Intro Service Worker に Foreign Fetch という機能が提案されている。 この機能があるとクロスオリジンへの fetch をフックできる Service Worker を、その対象オリジンから提供できるようになる。 一体どういう仕組みなのか、これによって何が可能になるのかについて、デモを交えて記す。 1st Party と 3rd Party 例えばこのブログであれば、筆者自身が Service Worker を登録することで、 Push などの機能を提供することができる。 ここではこれを、 1st Party の Ser
Intro Service Worker を登録する方法は現状 3 つある。 HTML meta タグでの追加ならば、 Service Worker を追加するためだけの JS であれば不要になる。 HTTP ヘッダでの追加ならば、 HTML を持たない API にも Service Worker を追加した対応が可能である。 次の記事で foreign fetch について解説する予定であるため、その前提知識として本機能を分離し紹介する。 JS での登録 ページ上で実行されている JS (main.js とする) の中で Service Worker のコード(sw.js とする)を登録する場合は、以下のようになる。 // main.js navigator.serviceworker.register("/sw.js", { scope: "/" }); Service Worker
Intro Node v7.0.0 が公開され、今回のリリースで WHATWG URL の実装が Experimental として入った。 既に標準で含まれていた url module との違いや、 URL API などについて解説する。 WHATWG URL URL は非常によく使われる、 Web において重要なフォーマットの一つだ。 ものによっては一見シンプルに見えるかもしれないが、その仕様はそれなりに大きい。 しかし、これまで DOM/JS はこれをパースする専用の API を持っていなかったため、例えば <input type=text> に入力された URL 文字列のパースは、片手間な正規表現で行われることも少なくなかった。 同様に、動的生成されるクエリやハッシュなどを URL に含める場面でも、やはり文字列操作による構築が行われてきた。 片手間な正規表現や文字列処理が、 URL
Intro ブラウザに追加される新しい機能に対して、Vender Prefix の代替となる Origin Trials の導入が徐々に始まっている。 今回は、これまでの Vender Prefix の問題点と、代替として提案された Origin Trials のデザインや導入方法などについて記す。 Avoid Breaking the Web Web が壊れることは、避けねばならない。 Web に関する、特にブラウザが実装するような機能については、その仕様や実装を変更することにより、既存の資産の挙動が壊れることがある。 これを Breaking the Web といい、プロトコルにしても API にしても、標準化団体やブラウザベンダなどは、これを避けることを念頭に置いて作業を行っている。(セキュリティ的な理由など、例外は多く有る。) 一方で、新しく提案される仕様はフィードバックを集めなけ
Intro Google の中の人からお声がけ頂き、 Google Developer Experts (GDE) に Web Technologies の Expert として Join することになりました。 GDE GDE は、簡単に言えば Google の技術についての啓蒙などを行う、社外アドボケート的な位置づけである。 https://developers.google.com/experts/ 各自専門領域(Android, GCP etc)があるが、自分はやはり Web Technologies ということになる。 Web に関する多くが標準技術であるため、 Google Developer Experts という名だが、別に Google や Chrome に限った内容を扱うわけではない。 活動 実際に何をするかというと、特に明確なタスクを詰まれるといったわけではないとのこ
Intro 「Socket.IO 使ったほうがいいですか?」 という主旨の質問をもらった。 これは、WebSocket が繋がらない環境に向けて、フォールバック機能を有する Socket.IO にしておいた方が良いのかという意味である。 WebSocket が出てきた当初と比べて、Web を取り巻く状況は変わったが、変わってないところもある。 念のためと Socket.IO を使うのもよいが、「本当に必要なのか」を問うのは重要である。 Rails も ActionCable で WebSocket に対応し、ユーザも増えるかもしれないことも踏まえ、 ここで、もう一度現状について、把握している範囲で解説しておく。 "繋がらない" とは 最初に、なぜ 繋がらない ことがあるのかを、きちんと把握したい。 まず WebSocket の有史全体をみれば、繋がらないとして語られていた現象は、大きく三つ
Intro UNIX コマンドを SQL で抽出できるツール qq を作った。 というエントリを読んで、そういえば似たようなものを作ってたなと思い出した。 自分の dotfiles の中にある、便利コマンド集の中にある selects についてである。 このコマンドは SQL という検索を記述的に表現する共通言語をファイル検索に応用し、 Ruby の動的言語として表現力を使って実装したものといえる。 その実装方法と実行例などについて記す。 selects 結論からいうとこういうコマンドだ。 $ selects mtime, size, basename from './entries/**/*' where extname '==' '.md' and size '>' 1000 order by mtime 2016-07-06 22:45:44 +0900 18437 web-font
Intro WHATWG が定義する Fetch API は、出たばかりの仕様では、途中でのキャンセルや、プログレスイベントの取得が含まれていなかった。 しかし、後の更新で fetch 結果の Response Body が WHATWG Stream API を実装することになったため、現在の仕様ではプログレスを取ることもキャンセルをすることも可能となっている。 今回は、こうした API のアップデートについて記す。 Update 最初の公開時には、以下のように書いていた。 「XHR ではできるが Fetch ではできない」ことが、仕様上は無くなったことを意味する。 しかし、現時点で仕様としてまだ出来ないことがあることが判明した。 Upload の Progress これに伴い、記事の一部を修正した。 Fetch 最新の Fetch の仕様は以下で確認できる。 Fetch Spec 仕様
Intro ブラウザはリロード時に、 max-age に満たないキャッシュを持っていても Conditional GET によってキャッシュの Validate (有効性の問い合わせ)を行う。 Cache-Control Extension として提案されている Immutable 拡張は、キャッシュが max-age 内であればリロード時もキャッシュヒットさせる拡張である。 このヘッダの効果と、本サイトへの適用について記す。 Cache-Control Cache-Control に max-age を指定することで、ブラウザにリソースをキャッシュさせることができる。 このキャッシュは max-age の期間内は fresh とみなされ、 fresh であればサーバへの問い合わせなく再利用される。 サーバへの問い合わせ(RTT)が無いため、事実上最速のリソース取得となる。 Reload
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く