はてなブックマーク

Firefoxでは、Preload Scannerという呼称ではなく、Speculative Parserと呼称されています。 Shallow Parsing Preload Scannerは、Shallow Parsing(浅いパース処理)という手法を使います。 Shallow Parsingシャローパーシングとは、文法解析の一種であり、構文解析の表層的なレベルで行われる解析手法です。 Shallow Parsingは、文法構造を完全に解析する深層解析（Deep Parsing）とは異なり、文書やコードの全体的な構造を理解しようとはせず、特定の情報やパターンを効率的に抽出することに焦点を当てています。 WebブラウザのPreload Scannerにおいては、Shallow ParsingがHTMLドキュメントの表層的な構造を迅速に解析する役割を担っています。 Preload Scann

DOMツリー最適化でブースト！ 高速・効率的なWebページへの鍵を握ろう 2023年4月24日 著者: 竹洞 陽一郎 はじめに 今回は、Webパフォーマンスの基礎となる、HTMLの解析において特に重要なDOMツリーについて解説します。 HTMLのDOMツリーは、多くの人が用語として知っているでしょう。 しかし、木構造の複雑度がCSSやJavaScriptなどの後続処理の時間計算量に大きな影響を与えることについて、十分理解している人は意外と少ないかもしれません。 この記事では、DOMツリーがどのように構築され、その複雑度がWebパフォーマンスにどのような影響を及ぼすかを説明します。 また、効果的なDOMツリー最適化の方法や、それによって得られる恩恵についても触れていきます。 Web開発者は、これらの知識を活用して、より高速で効率的なWebページを提供することができるでしょう。 今回の記事で扱

これらを、先程のheadとbodyの構造図にマッピングしてみます。 HTMLにおけるheadとbodyの構造での各ファイルのマッピング この構造図から、幾つかの事が自明となります。 1. CSSやJavaScriptはheadに書くべきである CSS CSSは文書装飾の役割を果たすため、データではなく、メタデータです。 従って、bodyの中に記載すべきではないです。 HTML Living Standardでは、CSSをhead内に記載すべきである旨を明示的に記述しているわけではありません。 代わりに、style要素に関する記述があり、style要素はメタデータコンテンツであることが示されています。 4.2.6 The style element JavaScript JavaScriptは文書機能の役割を果たすため、データではなく、メタデータです。 従って、bodyの中に記載すべきではな

パフォーマンスチューニングの基礎:プロファイリング 2023年4月3日 著者: 竹洞 陽一郎 主なポイント 実務のパフォーマンスチューニングではLighthouseだけではボトルネックの特定が難しいため、Chrome Developer Toolsのパフォーマンスタブでプロファイリングし、どのJavaScriptファイルの何行目の関数で時間を消費しているかを特定します。 「ソース」タブのオーバーライド機能を使うと、本番環境やステージング環境のコードを書き換えずに、ローカルで改善したコードが有効かを確認できます。 パフォーマンスタイムラインの遅延は計算処理の遅延とダウンロードの遅延に分かれ、ダウンロードの遅延に見えても計算処理の影響があることが多いため、遅延している画像やCSSを選択してボトムアップ、呼び出しツリー、イベントログで依存関係を確認します。 プロファイリングは、高速な光回線と高性

能動的に脱IEを押し進める 2021年1月21日 著者: 竹洞 陽一郎 皆さんのWebサイトには、IEを使ったアクセスがどの位ありますか？ それなりの数のIEでのアクセスがあり、IEを利用しているユーザを無視できず、頭を悩ませるWeb担当者も多いでしょう。 そこで、Microsoftが用意しているIEからEdgeへの自動転送の仕組みをご紹介します。 Microsoftが用意したIEを利用した際のEdgeへの自動転送の仕組み Microsoftは、2020年11月13日にMoving users to Microsoft Edge from Internet Explorerというページを公開し、登録申請をすれば、ユーザがIEを使って自社サイトにアクセスしても、Edgeで自動的に開く仕組みを用意しました。 自動転送の仕組みが動作すると、以下の説明文が画面上に表示されます。 自社の登録したサイ

画像の読込処理の違い ページ作成日 2019年12月19日 ページ更新日 2021年3月2日 著者: 竹洞 陽一郎 Webページにおいて、画像は重要な役割を果たしており、高解像度化と利用される枚数は増えていく傾向にあります。 その一方で、画像は、従来どおりの実装をしていると、HTMLのパース処理を遅延させる要因となります。 画像をいかに遅延要因としないようにするかの処理として、decoding="async"とloading="lazy"の違いを解説します。 decoding属性は、画像のデコード処理に関しての指示をユーザエージェントに明示する属性です。 decoding="async"と指定することで、画像のデコード処理を非同期にバッググラウンド処理し、他のコンテンツの表示処理が終わった時に更新処理で画像を一緒に出します。 記述の仕方としては、以下のようになります。 <img class

インデクシングされなければ検索されない 2019年4月17日 著者: 竹洞 陽一郎 多くの人々が、ユーザがGoogleの検索した時に、自社サイトのページがどれくらいの順位で表示されるのかを気にしています。 そのために、SEO(Search Engine Optimization:検索エンジン最適化)に取り組んでいます。 検索順位のランキングで優位に立つために、Webパフォーマンス(表示速度)に取り組む人々も増えてきました。 しかし、多くの人々は、SEO以前の問題として、Webパフォーマンス(表示速度)の中でも、HTMLのレスポンス時間が遅いとクローリングされない問題を認識していません。 まずは、HTMLを100msぐらいで送出できなければいけないのです。 今回は、SEOの施策としてのWebパフォーマンス(表示速度)対策より、検索エンジンにインデクシングされるためのWebパフォーマンス(表示

実際の性能を知る 2019年3月25日 著者: 竹洞 陽一郎 Googleが推奨しているAMP (Accelerated Mobile Pages)をWebパフォーマンス(表示速度)の高速化として採用している方も多いでしょう。 実際に、AMPはどのくらいの表示速度なのでしょうか？ AMPのページを計測して、分析してみました。 ダウンロード時間 まず、ファイルのダウンロード時間を見ます。 4Gエミュレート(下り30Mbps) AMPのページを15分に1回の頻度で、現在の4Gの下り帯域(30Mbps)で設定して、30日間、15分に1回の頻度で計測したものです。 4Gエミュレート（下り30Mbps）で計測したダウンロード時間 これを30日分の品質として、累積分布関数で見ます。 4Gエミュレート（下り30Mbps）で計測したダウンロード時間の累積分布関数 変曲点は、99パーセンタイルです。 この3

画像を大きく、美しく、しかし軽量に 2017年12月5日 著者: Kameerath Kareem 翻訳: 小川 純平 この記事は米Catchpoint Systems社のブログ記事 Web Performance 101: Tuning Tips for Imagesの翻訳です。 Spelldataは、Catchpointの日本代理店です。 この記事は、Catchpointの許可を得て、翻訳しています。 ビジュアルコンテンツは、モダンなWebサイトにとって、なくてはならないものであり、最もミニマリスト志向のWebサイトデザインですら、完全なエンドユーザ体験のために、シャープで綺麗な画像に頼っています。 スマートフォンからタブレット、ノートPCからデスクトップPCまで、近年はスクリーンサイズが多様になり、高品質な画像を用いて、正しく、あらゆるviewportで表示できるようにすることが重要

高速にJavaScriptを実行するための基本 2017年11月27日 著者: Kameerath Kareem 翻訳: 小川 純平 この記事は米Catchpoint Systems社のブログ記事 Web Performance 101: Optimizing Javascriptの翻訳です。 Spelldataは、Catchpointの日本代理店です。 この記事は、Catchpointの許可を得て、翻訳しています。 JavaScriptは、Webアプリケーションを再定義しました。滑らかなレスポンシブデザインの、動的なWebサイトの時代の到来を告げています。 それは開発者の間で多くの支持を集め、jQueryやAngularJSのような、人気のあるライブラリーやフレームワークは全てJavaScriptで構築されています。 (訳注: Angularの現行バージョンは、正確には主にTypeScr

求められる「品質の明文化」 2017年6月27日 著者: 横浜ステーション法律事務所 代表弁護士 紺野 晃男 主なポイント 改正民法では、現行民法の「瑕疵担保責任」が、目的物が種類・品質・数量に関して契約の内容に適合しない場合の「契約内容不適合責任」に変わりますが、両責任の内容に根本的な違いはなく、瑕疵の判断基準を明確化したものと考えられます。 「品質」が契約内容に適合しなければ法的責任が生じると条文に明記されたため、Webサイト制作・開発やWebサービス販売の契約では、何が契約内容に適合した「品質」かを契約書で明確に定めておく必要があり、Webページの表示速度についても一定の水準が「品質」として要求されることが考えられます（2016年10月6日付記事参照）。 仕様を契約書に明確に定めていなくても、請負業者は責任を免れられるわけではなく、取引観念等から想定より高い水準が「品質」と認められ、

顧客体験を「見える化」する更なる指標 2017年5月5日 著者: 竹洞 陽一郎 主なポイント ダウンロード完了時間やRender Startだけでは、表示が始まってから描画が終わるまでの途中経過が分からないため、実際の顧客体験を定量的に測ることはできません。 Speed Indexは、Film Stripの計測インターバルごとの未表示領域の割合を表示完了まで足し合わせた値(IntervalScore = 計測インターバル * (1.0 - (表示完了度/100))の合計)で、数値が小さいほど早く表示されたことを意味します。 Speed Indexは、Film Stripの計測インターバルによって値が変わり、SPAや動的に一部だけ変わるページ、カルーセル表示のあるページでは正しく計測できず、計測マシンのCPUやGPUなどのスペックにも大きく左右されるため、Render StartやDocum

1nmは、10億分の1mです。 ウィルスが100nm、分子の大きいものが10nm、原子は0.1nmです。 今後、プロセスルールは、10nm、7nmまで微細化していく事が期待されていますが、技術的な問題より、収益の問題で難しいと言われています。 新しいプロセスルールの工場を建設するには、1兆円の投資が必要となります。 しかし、PCは以前ほど数が売れなくなってしまったので、1兆円の投資をして、より微細化したプロセスルールでCPUを製造しても、投資した金額分の利益を回収するのが難しいのです。 また、プロセスルールが細くなればなるほど、量子力学の法則が支配する世界となります。 量子力学の法則の支配する世界には、トンネル効果というものがあります。 古典力学的には乗り越えられないはずのポテンシャル障壁を、粒子があたかも障壁にあいたトンネルを抜けたかのように通過する量子力学的現象です。 プロセスルールが

確実な高速化に必要な基本原則を知る 2017年3月７日 著者: 竹洞 陽一郎 主なポイント Webサイトの高速化とは本質的には計算量を減らすことであり、その方策は、ハードウェアリソースを増やす「追加」、異なる実装にする「交換」、計算そのものを減らす「削除」の三つです。 方策を闇雲に試すのではなく、まず表示速度を計測してデータを分析し、パレートの法則に従って全体の遅延の80%を引き起こしている20%の原因を特定します。 特定した遅延要因には、最も強力な「削除」をまず考え、削除できない場合は「交換」、交換ではどうにもならない場合に「追加」という、削除→交換→追加の順番で策を検討します。 高速化するとアクセス数が増えて別の遅延要因が現れ、次のWeakest Linkは実際にやってみないと特定できないことが多いため、計測と分析は継続的に行う必要があります。 (2026年9月追記) 本文で「交換」の

モバイルサイトに「遅延」は許されない 2017年3月1日 著者: 竹洞 陽一郎 主なポイント Googleが2017年2月に公開した記事によると、53%のユーザはモバイルサイトのページ読込に3秒以上掛かると離脱するのに、モバイルサイトの平均読込時間は22秒です。 この22秒はパケットロスをエミュレートしていない回線での値であり、1〜5%のパケットロスが50〜90%の速度遅延をもたらすことを考えると、実際のモバイルサイトの読込時間はさらに長くなります。 Spelldataの計測データでは、4G携帯網でも1ページ200KB以内でなければ95%の確率で3秒以内に配信することは困難で、1ページ300KBまで容量を増やすと3秒以内に配信できる確率は75%に下がります。 GoogleとSOASTAの共同調査では、読込時間が1秒から3秒に遅延すると直帰確率が32%、10秒に遅延すると123%上昇し、その