How to 速度改善 ーWebパフォーマンスについて知っておきたいこと7選ー - Qiita
今回のテーマ Webパフォーマンスを改善する上で知っておきたい知識をまとめてみました。 前回の記事では使わなかった（使えなかった）技術や方法なども含めて記載します。 また、ブラウザのレンダリングなどについても書きたいと思います。 (2019年5月23日追記) 過去の記事はこちら How to 速度改善 ー計測・知識編ー How to 速度改善 ー原因調査編ー How to 速度改善 ー実装&技術調査編1ー 1. ブラウザレンダリングの仕組み 推測するな、計測せよ という言葉にあるように、闇雲にチューニングを初めても良い結果は出ません。まずはブラウザレンダリングの仕組みからみていきましょう。 ブラウザレンダリングの流れ レンダリングの大まかな流れは Loading→Scripting→Rendering→Painting（これでページが表示される） となっています。 この処理の内容をフレーム
Webパフォーマンス虎の巻
Webパフォーマンス向上施策のために、今更ながら超速本1を読んだので、今までの自分の知見と合わせてまとめてみます。 なるべく柔らかく、**改善施策ってまず何をどうすればいいの？**という疑問を持った人に向けて書いています。 ▪️格言 そもそもWebは速い。遅くしているのは我々です。大抵は技術の問題ではなくて、人の問題。 引用元： テクニックではなく、今、本気で取り組むべきWebパフォーマンス （html5jパフォーマンス部 部長 竹洞さん） 心得 パフォーマンス向上に対する施策は大別すると以下の２通り 軽量化 （単純にやりとりするデータ容量を小さくすること） 圧縮 削除 最適化 （その時に最も適している実装・実行をとること） 経路・順番の変更 非同期 もっとも遅くしている原因を探して、それを対策するのが原則。「対効果」が絶対的正義である。手段から入るのは愚策。まず先に原因を知ることが重要。
JavaScriptでのDOM操作は重いのかという話とForced Synchronous Layoutについて - id:anatooのブログ
2015年にもなるのにJavaScriptでのDOM操作のパフォーマンスについて書く。ウェブページにインタラクションを持たせたい時に、JavaScriptでDOM操作を行うことがよくある。このDOM操作のパフォーマンスについて、よく聞く意見を大別すると次の2つがある。 JavaScriptによるDOM操作は重たい レンダリングが重いだけで、DOM操作そのものはそれほど重たくない JavaScriptでオブジェクトのプロパティを操作したりする単体の処理は通常1ミリ秒もかからないが、DOM操作をするとレンダリングが完了するまでに数十ミリ秒程度かかったりする場合がある。1番目のDOM操作が重たいと言っている人は経験則的にそう言っていることが多い。 レンダリングの仕組みを知っている人は2番目の意見を言うが、重箱の隅をつつくような話をするとこれも必ずしも正しいわけではない。DOM操作するコードによっ
High Performance HTML -さまざまなデバイスに配慮されたクリーンで簡潔なHTMLの書き方
多くのWeb制作者はパフォーマンスというと、JavaScriptや画像の最適化、サーバーの設定、CSSなどのファイルの圧縮や結合を検討します。そして、Webページのコアとなる言語にも関わらず、HTMLは無視されがちです。 HTMLは単に複雑さと要素の数を減らすだけでは、パースにかかる時間をあまり改善することはできません。しかしよく作られたHTMLはページを素早くロードするための決定的な土台になり、異なるビューポートサイズに対応するレイアウトになります。 さまざまなデバイスに対して素早くロードし、うまくいくコンテンツを作ることができるクリーンで簡潔なHTMLのコードを紹介します。 High performance HTML 下記は各ポイントを意訳したものです。 著者のSam Dutton氏は、Google ChromeのDeveloper Advocateをされています。 ※当ブログでの翻訳
モバイル時代のWebパフォーマンス
2014/8/30に開催された「HTML5とか勉強会 in IWATE 2014」のセッション資料です。
[フロントエンド] ブラウザレンダリングの仕組みを理解して、ブラウザに優しいJavaScriptを書こう - YoheiM .NET
[フロントエンド] ブラウザレンダリングの仕組みを理解して、ブラウザに優しいJavaScriptを書こう こんにちは、@yoheiMuneです。 ブラウザのレンダリングの仕組みはHTML5 RocksやHow browsers workで詳しく解説されてきました。しかしそれらはとても詳細で、読破して理解するのは大変です。 今回のブログでは手軽にレンダリングの概要を理解できるように心がけました。またより詳しく学べるようなリンクも記載しました。 そしてブラウザのレンダリングの仕組みを理解した上で、どのようなJavaScriptを書くべきかについても記載しました。 目次 ブラウザのレンダリングの仕組み この章では、HTMLとCSSが読み込まれてから画面に表示されるまでの間に、ブラウザがどのような処理を行っているかを説明します。 ファイル読み込みから表示までの一連の流れは以下図の通りです。 [1]
![[フロントエンド] ブラウザレンダリングの仕組みを理解して、ブラウザに優しいJavaScriptを書こう - YoheiM .NET](https://cdn-ak-scissors.b.st-hatena.com/image/square/705cdef7654f2f96a242f9a2834ce643b78de75c/height=288;version=1;width=512/https%3A%2F%2Fwww.yoheim.net%2Fimage%2F336.jpg)
Tips - 静的リソースのURIに?をつけるべからず : 404 Blog Not Found
2014年03月14日20:00 カテゴリTipsCode Tips - 静的リソースのURIに?をつけるべからず Webを支える技術 HTTP、URI、HTML、そしてREST 山本陽平 であればなおのことこの実装はNG。 ブラウザのキャッシュを利用できれば、余分なリクエストを減らすことができます。はてなブログでは、なるべく長い間ブラウザにキャッシュを保存するために、JavaScriptなどの一部の種類のファイルのレスポンスに、以下のようなヘッダを指定しています。 はてなブログにおけるページ表示速度改善の取り組みについて - Hatena Developer BlogはてなブログではJavaScriptを配信する際には、上記のURLのように、?よりあとの部分にabc078624b2a746c618156847827166bのようなバージョンIDを付与しています。JavaScriptが変更
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
NAVERまとめに見る遅延ロードのすすめ « NAVER Engineers' Blog
あけましておめでとうございます。NAVERまとめのフロントエンドを担当している縣です。初詣で引いた大吉のおみくじを握りしめながら今年も張り切っていこうと思います。 今回はJavaScriptの遅延ロードの仕組みをNAVERまとめに導入した際のお話を紹介します。 遅延ロードの検討 昨年NAVERまとめのまとめ閲覧ページや、まとめ編集ページでのJavaScriptファイルの読み込みを遅延ロード化する作業をしました。元々はページ読み込み時に全て読み込ませていましたが、JavaScriptファイルが巨大になってきてパース・実行に時間がかかるようになったことから遅延ロードを検討することになりました。 遅延ロードの利点というとJavaScriptファイルの読み込み・実行によるブラウザのレンダリング停止を防ぐのはもちろんですが、どのファイルがいつどこで必要になるかを明確にすることもでき、依存関係を動的
改行削除するくらいなら gzip したらいいじゃない
CSS や JavaScript ファイルなどを gzip 圧縮して転送量の削減や Web サイト表示速度の向上を実現する方法を解説。既存 Web サイトのソースには一切手を加えない方法でまとめています。おまけでキャッシュ関連の記述もあり。 いや、1バイトの無駄もゆるせねぇんだよとか、難読化したいとかなら別にやればいいんですけど、CSS や JavaScript ファイルの改行やスペースを削除しただけでファイル容量圧縮、読み込み速ーい的なこという人がいるので今さらですが書いてみます。すでに色々なところで書かれてるのでかぶるのは承知の上で。 改行や無駄なスペースなどを削除すること自体が悪いと言ってるわけではありませんのでその辺は誤解ないようにお願いします。ただ、gzip 使って圧縮するのに比べたら、改行削除して削れるファイルサイズなんて微々たるものです。もちろん、両方やれば最大限ファイルサイ
JavaScriptの読み込みを最適化してページの表示速度を高速化する6つの方法
[対象: 中〜上級] 僕のブログではてブ数がいちばん多いのはウェブページを高速化するTIPSを解説した記事です（まだ読んでない人はぜひ読んでください！）。 その記事では高速化全般を扱っていましたが、今日の記事ではJavaScriptに的を絞って表示速度をスピードアップできる施策を6つ紹介します。 もともとはSearch Engine PeopleブログのOptimizing JavaScript for Better Web Performanceで説明されていたものです。 記事作者のJoydeep Deb（ジョイディープ・デブ）氏に僕のブログでの転載許可をもらえました (Thanks, Joydeep!)。 逐一の翻訳ではなく、書かれている内容をもとに僕の言葉で解説していきます。 1. HTTPリクエスト削減のためにJavaScriptファイルを1つに統合する ウェブページの表示を高速化
jsPerf: JavaScript performance playground
jsPerf — JavaScript performance playground What is jsPerf? jsPerf aims to provide an easy way to create and share test cases, comparing the performance of different JavaScript snippets by running benchmarks. For more information, see the FAQ. Create a test case Login with GitHub to Create Test Cases
コードの圧縮や外部ファイル化とページの読み込み速度について
なぜ、ごちゃごちゃしてるのか？ぱっと気づくのがこの2点です。 改行やスペースがほとんど使われていない CSSやJavascriptが外部化ファイル化されていない Googleとしてはソースがきれいなことよりも、読み込み速度を速くすることでユーザーのストレスを軽減したり、ファイルサイズ小さくすることでサーバーへの負荷を減らしたりすることの方が重要だと思います。 もちろんアップする前にこのような状態にしているだけで、それまではきれいに書かれているはずですが。 ということで、「コードの軽量化」と「外部ファイル化」の2点について考えてみます。 コードの軽量化について HTML、CSS、JavaScriptなどのコードは、改行やスペースを使わずサイズを小さくした方が読み込みは速くなります。 これは当然ですね。 コードの見やすさよりも読み込み速度やサーバーの負担軽減を優先するなら、できるだけファイルを
JavaScriptコーディング等を書く上でのパフォーマンス確認事項３０:phpspot開発日誌
30 best practices to boost your web application performance - Web User Interface Architect JavaScriptコーディング等を書く上でのパフォーマンス確認事項３０。 自分へのインプット＆メモがてらにちょっとまとめてみます。 JavaScript DOMの操作は可能な限りやめる eval, new Function() は遅いので可能な限り使わない withステートメントを使わない（使った事ないですが） for-in 文ではなく for 文を使う。 ループの中で try-catch ではなく、try-catchの中にループを置く グローバル変数をなるべく使わない aaa+='AAA';aaa+='BBB'; の方が aaa+='AAA'+'BBB';より速い 複数の文字列連結には、Array で文字列
JavaScriptを高速化する6つのテクニック | エンタープライズ | マイコミジャーナル
Thomas Fuchs, author of the script.aculo.us user interface JavaScript library, a member of the Prototype core team and a Ruby on Rails core alumnus. Thomas Fuchs氏が6 easy things you can do to improve your JavaScript runtime performanceにおいてJavaScriptの実行パフォーマンスを改善するための6つのテクニックを紹介している。Thomas Fuchs氏はscript.aculo.usの開発者であるとともにPrototypeコアチームのメンバーも務めている。またRuby on Railsでコアチームで開発を担当していたこともある。 JavaScriptエンジン
id:mindcatさんのJavaScriptエントリに少しだけコメント - os0x.blog
FAQ形式によるJavaScriptの本質がわかる超入門 - 風と宇宙とプログラムが凄く良く出来てて、くやしい。じゃなくて、折角なので少しだけツッコミを。いや、これだけ完成度が高いのにツッコミというのも無粋ですが。 数値を文字列に、逆に文字を数値に変換する String(x)、Number(x)を推奨されていますが、一応、IE6ではパフォーマンスに差が出る点に注意が必要だと思います。 to_string (関数呼び出しのコストのため)IE6だとこのように結構な差がでます。(といっても10万回での結果ですが。) "" + 78ms "" + 63ms String() 125ms String() 125ms確かにChromeなどString()のほうが少しだけ速いみたいなので、ケースバイケースですね。 JavaScriptで ""+x を文字列変換に使うのは気持ち悪い - 風と宇宙とプログ
理由がない限り、Array.join("") による文字列連結は使わないほうがいいみたい - latest log
JavaScript の勉強を開始したときに「文字列の連結には Array.join() を使え」といった記事を見た覚えがあります(ソース失念したけど、 Operaの技術文書だった気がする ⇒ IE の技術文書だったかも)。 一年ほど信じてて、念のためベンチとってみたら「うそやーん」でした。ってお話。 ベンチの条件は、 3種類の文字列連結方法を試す 1. + Operator 2. String.concat() 3. Array.join("") 文字列の要素数を 11個 と 55個で試す <!doctype html><html><head><title></title> </head><body> <script> window.onload = function() { var now = +new Date, lp = 100; while (lp--) { job(); } d
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JSのパフォーマンスをお手軽に解析する方法 - Qiita
Effective web performance tuning for smartphone
creatorish.com