埋め込みyoutubeが想像以上に戦犯級だった件 | ma-ya's CREATE / WEB DESIGN
2019/1/11 記事内容を大幅に加筆・修正しました。 こんにちわ、ma-ya’s CREATE［まーやずくりえいと］です。 youtubeの埋め込み動画をサイトに設置したいときありますよね。 そんな時は簡単です。見たい動画のページから埋め込みコードを取得してソースに張り付けるだけ。 簡単ですね、ではさようなら。 と、そうは問屋が卸しません。 youtubeの埋め込みはたとえ一つでもサイトに大きな悪影響を及ぼすことがある？ そうなんです。ざっくりと箇条書きにすると 埋め込みyoutubeの読込中はサイトの動きが止まるor瞬断される サイトのレイアウトが一瞬狂うことがある そもそも読込処理が重い たまにコンソールでエラーが出る サイト評価がすんごい下がる ※上記はいずれもブラウザ未キャッシュ時の挙動、そして可能性の話です。あしからず。 ブログなどの投稿ページだったらもうどんどん貼っちゃって
Webpack チャンク最適 テクニック - Qiita
ターゲット 巨大なSPAを作ってしまった人へ 巨大なSPAを作らないように気をつけたい人へ 今回はJSだけにフォーカスするが、もっというと、 超速本 を読んでください。 注意：本資料は、webpack チャンクの挙動を概念的に説明することを重視しているので、 webpack の詳細な設定や、出力ファイル名などは実際の処理と一致しない。適宜自分の手元にある設定とすり合わせるように。 昨今のJSビルド問題と、その解決のためのゴール設定 巨大なJS(+最近は in JS された各種SVGやCSS)はダウンロードだけではなく、UIスレッドのCPUをブロックする。 これはとくにCPUが貧弱な端末で体験が悪化する。そしてビルド時間で開発者体験を阻害する。 できれば webpack 推奨の 144kb 以内にしたい…が現実的に難しいので、 せめて 350kb ぐらいに抑えたい。 SPAなら (ローディン
Private Presentation
Private content!This content has been marked as private by the uploader.
『フロントチューニンガソン 最速を目指すには』
11:10～ 課題ページの確認＆PageSpeed Insightsの実行目的：チューニング対象のウェブサイトの改善の余地を調査 上記のgruntプラグインをインストールする npm install コマンドを実行しながら、ブラウザやIDEでチューニング対象のウェブサイトを確認し始めました。 少し見ただけでもCSSの構文エラーがあったり、使っていないJavaScriptライブラリがインポートされていたり…。 まるで無茶な運用を数ヶ月続けたかのような、カオスなファイル群でした。 ここで実行した PageSpeed Insights に画像サイズの最適化をオススメされたので、まずはそこから行うことにしました。 11:20～ 画像ファイルの最適化目的：画像ファイルサイズの削減 30 x 30pxで表示している画像ファイルが実際には150 x 150pxで保存されていたりする画像がそこそこあったの
CSSセレクターマッチングのコスト - Unreviewed
ブラウザエンジン先端観測会での、Constellationさんの話を聴いて、CSSセレクターマッチングのコストには複数のレベルがあることを強く意識するようになりました。セレクターマッチングにかかるコストを下げたい、という場合には、どのレベルで何を高速化しようとしているのかを意識しないと話がかみあいません。Constellationさんの話を私なりに整理して考えた、セレクターマッチングのコストを下げるアプローチは次の3つです。 ①セレクターを減らす ②マッチするかどうかの判定回数を減らす ③1回1回の判定処理を速くする これは、ブラウザーのセレクターマッチングの処理の各部分に対応しています。 CSSの各セレクターについて（①）、 対象となるDOM要素すべてに対して、 セレクターがマッチするかしないか決まるまで、親要素・兄要素を辿りながら（②）、 要素がセレクターにマッチする・しないの判定（③
ガベージコレクトを減らす
C#ではメモリ管理はガベージコレクション(GC)ですので、deleteする必要が無く気楽です。 が、GCはメモリ回収時に全動作を止める（所謂Stop the world）事が良く知られています。 デスクトップ環境向けのプログラムを書く分にはあまり気にしなくても良いところなのですが、スマートフォン向けのプログラムの場合、ちょっと問題です。 （実はサーバー環境でも問題なのですが） スマートフォンは性能が上がってきているとはいえ、デスクトップに比べるとまだまだ非力です。 ガベージコレクタがメモリを回収、つまり使われていない領域を開放する処理は案外重たいため、パフォーマンス上悪影響を与える事が多々あります。 パフォーマンス上の目安 あくまで個人的な目安ですが、GC間隔が１秒を超えていればチューニングの必要は無いと考えています。 逆に言えば１秒を切っている場合、無駄なオブジェクト生成が潜んでいると見
Webページレンダリングについて知っておくべきこと: ピクセルは高コスト | POSTD
Web開発者として、ユーザの画面表示にピクセルがどのように関わるのかということは知っておくべきでしょう。知ることが目的なわけではなく、効率性のため画面表示を最適化する際にその知識が必要となってくるからです。 先日、「 フロントエンド開発者がWebページレンダリングで知っておくべきこと 」を読んだのですが、重要なポイントを外してしまっている印象を受けました。その記事で強調されていたのは、CSSセレクタのマッチング、レイアウト（FirefoxのようなGeckoベースのブラウザではリフロー）、そして レイアウトスラッシング という名でも知られる強制同期レイアウトに注意することです。確かに、これらは気をつけたほうがいいことだとは思いますが、私としては、ページレンダリングについて開発者が知っておくべきことをその記事ですべてカバーしていたとは思えません。大抵の場合、Web開発者は60fpsの表示を目指
Tumblrの省メモリーな無限スクロール - 記録
無限スクロールまたはauto pagingと呼ばれるUIには、読み終えたコンテンツがどんどん画面の上のほうに溜まっていってメモリーを食い潰すという問題がある。 なかでもTumblrは画像などのコンテンツが多いため、ダッシュボードダイバーたちは無限Tumblrユーザースクリプトなどのユーザースクリプトをインストールして、読み終えたコンテンツを定期的にページ上から自動削除するといった対策を講じていた。 ところが最近のTumblrのダッシュボードでは、ポストが画面外に出るとその中の要素が一時的にページから削除され、画面内に表示されると要素が再度復元されるようになっている。どうやらこれによって無限スクロールによるメモリーの圧迫が抑えられているらしい。 関連するコードはhttps://secure.assets.tumblr.com/assets/scripts/dashboard.jsの/*! s
ブラウザのリフローを最小限にする | PageSpeed Insights | Google for Developers
ブラウザのリフローを最小限にする コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 筆者: リンゼイ サイモン（UX デベロッパー） 推奨される知識: HTML および JavaScript の基礎知識、CSS の実践的な知識 リフローとは、ウェブブラウザがドキュメントの一部または全体を再レンダリングする目的で、ドキュメント内の要素の位置とジオメトリを再計算する処理のことを指します。リフローはブラウザ内でユーザーの妨げとなる処理のため、リフロー時間の改善方法を理解し、またリフロー時にドキュメントの各種プロパティが及ぼす影響（DOM の深さ、CSS ルールの効率、各種のスタイルの変更）を理解することがデベロッパーにとって有益です。ドキュメント内の 1 つの要素のリフローによって、その親要素のリフローや、その下のすべての要素のリフローも必要になることがあります。
ブラウザ動作の理解－リフローとリペイント及びその最適化 | ゆっくりと…
ブラウザ動作の理解の2回目です。今回はレンダリング・ツリーの更新に絡む、リフロー （要素の大きさ、位置などの再計算） とリペイント （描画） に関する解説を、「High Performance Web Pages – 20 new best practices」 の著者 Stoyan Stefanov のブログエントリーから 「Rendering: repaint, reflow/relayout, restyle」 を翻訳してお届けします。 同記事は、前半がリフローとリペイントに関する解説と、表示レスポンスを向上させるためのスタイル変更に関する Tips、後半は dynaTrace AJAX Edition と SpeedTracer を使った IE および Chrome の描画パフォーマンスの計測の解説で構成されてる、長い記事となっています。 今回はその前半部分をご紹介します。 レンダ
60 fps を実現する超高速イメージキャッシュ
これは面白そう。 以下、引用： ソフトウェア開発における「プロトタイプ」とは、シミュレーションを目的とした試作品のことをいいます。本書で解説するプロトタイピングは、主に紙などを使った「低精度プロトタイピング」を中心とした手法です。リスク回避や初期段階における可能性の模索をメ...
60fpsのサイトパフォーマンスを目指す - ワザノバ | wazanova
http://calendar.perfplanet.com/2013/the-runtime-performance-checklist/1 comment | 0 pointsGoogle ChromeチームのPaul Lewisが、ページ読み込み後、つまりユーザが閲覧する際の、UIレスポンス、スクロール、アニメーションなどサイトパフォーマンスについてまとめています。 まずは60fpsのパフォーマンスを達成する。よって、16ms以上かかるフレームは全て問題とみなす。 1. Large invalidations of layout and styles エレメントでのクラスの変更やJavaScript/CSS transition/CSS animationで直接エレメントのスタイルを変更すると、ブラウザはレンダリングツリーの一部もしくは全部を無効にしてしまう。最悪のケースでは、ドキュ
Effectively managing memory at Gmail scale | Articles | web.dev
Effectively managing memory at Gmail scale Stay organized with collections Save and categorize content based on your preferences. Introduction While JavaScript employs garbage collection for automatic memory management, it is not a substitute for effective memory management in applications. JavaScript applications suffer from the same memory related problems that native applications do, such as me
GREE Engineer's Blog coming soon...
コンテンツへスキップ ナビゲーションに移動 Slackオートメーションプラットフォーム(次世代プラットフォーム)でSlackアプリを作ってみた新着!!2024/05/28hagiwaramasaru Slack情報システム部 こんにちは。情報システム部の萩原です。皆さんはSlackオートメーションプラットフォーム（少し前までは次世代プラットフォームとも呼ばれていました）をご存じでしょうか。2023年4月に正式リリースされ、端的に言うと、これま […] 新卒1年目の実体験から学んだ新卒の心構え2024/03/29hidakatakumaこんにちは！ グリーでインフラエンジニアとして働いている日高です。 今回は、就活生に向けて、新卒エンジニアとして1年間取り組んだタスクの1つとそのタスクを通して気づいたことを紹介します。そして、これらのことを通して、私が […] 非エンジニア女子がRails
なめらかに動作するUITableViewのつくりかた
矢口裕也です。 Advent Calendar 10日目はiOSのUITableViewの話をします。 ぼやき iOSアプリを開発していると70%くらいの時間はUITableViewに費やしている気がしてきます。 UITableViewは非常にめんどうなものですが、パフォーマンスがシビアでかつユーザーの快適さに直結するものなので大いに手間をかける価値があります。 この記事ではガクガク処理落ちするUITableViewを例として改善していきながら快適なUITableViewのつくりかたを解説します。 目的 以下のケーススタディでは次の目的でコードを改善していきます なめらかに動くようにする ここでのポイントは実際速くなくてもユーザが快適に感じればOKである、ということです。処理速度が高速である必要はありません。 戦略 UITableViewでのパフォーマンス問題は次の2点であることが多いです
HTML5 Conference 2013 レンダリングパフォーマンスお話してきた！
HTML5 Conference 2013 で、僭越ながら1セッション担当させていただきました！やっっったら、奥行きの深い部屋で、後ろのほうの方にはスライド見えづらかったかもしれません。ごめんなさい。部屋の奥行きのわりに、スクリーン小さいという不遇がありました orz ということで、スライドのURL共有とか、イベントの感想とかです。 Rendering Performance 動画 Webフロントエンドのパフォーマンスは、今やページの初期表示を早くすることだけではありません。昨今のHTML/CSS/JavaScriptを駆使したWebコンテンツを、スムーズに動かすには、ブラウザのレンダリング(描画)処理について知る必要があります。このセッションでは、レンダリング上のよくあるボトルネックの見つけ方と対処を中心に、最適化Tipsをお届けします。 ちと粗いのですが、今回の参考URLリストです。
ごみばこいん
アーカイブ2023/08 (2) 2023/05 (4) 2023/04 (4) 2023/03 (4) 2023/02 (2) 2023/01 (1) 2022/12 (1) 2022/11 (4) 2022/10 (3) 2022/09 (2) 2022/08 (4) 2022/07 (5) 2022/06 (4) 2022/05 (9) 2022/04 (8) 2022/03 (10) 2022/02 (21) 2022/01 (8) 2021/12 (11) 2021/11 (1) 2021/10 (4) 2021/09 (2) 2021/08 (1) 2021/07 (2) 2021/06 (5) 2021/05 (10) 2021/04 (1) 2021/03 (8) 2021/02 (12) 2021/01 (8) 2020/05 (2) 2020/04 (2) 2020/0
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
レンダリングを意識したパフォーマンスチューニング
Effective web performance tuning for smartphone
Blog - LINE ENGINEERING