1ミリ秒でも早く届けたい! HTMLで画像読込を高速化するために取り組んでいること - ICS MEDIA
ウェブサイトの表示スピードはサイトの健全性における重要な観点の一つです。Googleが提唱するCore Web Vitalsコア・ウェブ・バイタルズと呼ばれる指標の中にもサイト表示スピードに関する項目があり、表示されるまでの時間が単なるユーザー体験だけでなく、SEOでも無視できない存在です。表示スピード低下の要因はネットワークやサーバーサイド、そしてフロントエンドまで広範囲におよびます。本記事ではその中でも画像の読み込みについて改善できるテクニックを改善前と改善後を比べながら紹介します。 改善前サンプルを別ウインドウで開く 改善後サンプルを別ウインドウで開く 画像読み込みBefore / Afeter 上図はLighthouseによるチェックの結果です。Lighthouseはウェブサイト検査ツールで、ウェブページのパフォーマンス、アクセシビリティ、SEOなどの状態を計測できます。Googl
JavaScript Start-up Optimization | Articles | web.dev
JavaScript Start-up Optimization Stay organized with collections Save and categorize content based on your preferences. As we build sites more heavily reliant on JavaScript, we sometimes pay for what we send down in ways that we can’t always easily see. In this article, we’ll cover why a little discipline can help if you’d like your site to load and be interactive quickly on mobile devices. Delive
『アメブロのAMPを終了します』
アメーバスタッフブログでも記載させていただいた通り、11/15より順次アメブロのAMP対応を終了させることになりました。 なぜAMPをやめるのか？2016年の3月にアメブロはAMP対応をスタートさせていました。 （当時のブログ記事はこちら） そこから5年以上AMPを採用し、モバイルの検索結果からはAMPキャッシュに飛ぶようになっていました。 Googleの検索結果からはGoogleのキャッシュに移動するわけで、当然体感速度としては良好なものであったと思います。 「それなのになぜやめるのか？」 ですが、基本的にはビジネス的な問題となります。 ウェブ界の状況、社会状況等々によっての総合的な判断ということになります。 検索結果がクリックされた際にGoogleのキャッシュが表示されるという点では、CDNのコスト削減等はあるのですが、それでもやはりトータルで考えたときに今回はAMPを終了させるという
本サイトの AMP 提供の停止とここまでの振り返り | blog.jxck.io
Intro 前回の記事で、奇遇にも本サイトの AMP 対応を落とすことになった。しかし、そうでなくても AMP をどこかでやめることは考えていたため、きっかけの一つが SXG 対応になったのは、順当な流れだと筆者は感じている。 これは AMP がなぜ始まり、なぜトーンダウンしつつあるのか、そしてこれからどうなっていくのか、という流れをまとめるいい機会でもある。 その過程で生み出され、本サイトでも検証を続けてきた Performance Timing API, Core Web Vitals, Signed HTTP Exchange 、そして今構想されている Bento AMP などを踏まえ、一連の流れを覚えている範囲で記録としてまとめておく。 ソースは筆者の主観であり、眺めてきた体感を mozaic.fm の Monthly Web などで話してきたものがベースなので、信頼性や正確性は期
リソースの読み込みを助けるウェブブラウザ API の世界
ウェブブラウザはネットワークから様々なリソースを集め、それらを処理して組み合わせてウェブページをレンダリングします。リソースが揃わないとレンダリングできないので、この一連の処理のどこかが遅れるとページの表示も遅くなります。レンダリングをすみやかに開始できるようにウェブブラウザはリソースの取得やその処理を最適化するための API を提供しています。本記事ではそれらを網羅的に紹介し、ウェブアプリの性能改善を図る上でどのようなブラウザ機能が使えるのかを知ってもらうことを目的としています。各機能の具体的な適用事例については他の記事に委ねます。 本記事の内容は記事公開時点での情報に基づいており、閲覧時点では既に古くなっている可能性があります。最新の正確な情報は一次情報源を参照してください。また特定のブラウザ実装について言及する場合は、断りがない限り Chrome を想定しています。誤りや補足、質問な
フロントエンドのパフォーマンスチューニングを俯瞰する - 30歳からのプログラミング
去年からフロントエンドのパフォーマンスについて断続的に学んでいるが、自分の頭のなかにある知識はどれも断片的で、まとまりを欠いているような感覚があった。 知識と知識がつながっておらず、各施策が何のために行われるのかも、必ずしも自明ではなかった。何となく「パフォーマンスに効果がある」と言ってしまうが、それが何を指しているのかは実は曖昧だった。 このような状態では新しい知識を得ていくのが難しいというか、効率的に行えないように思えた。議論の背景が分からないし、文脈や問題意識を上手く掴めないから。何の話をしているのかよく分からない、という状態になりがち。書かれてあることの意味は分かっても論旨を掴めているわけではないから、自分のなかに定着しない。 そこで、現時点で自分が知っていることを整理して、自分なりに分類しておくことにした。 当たり前だが、どのテクニックがどの程度有効なのかは、状況によって違う。
AMP におけるパフォーマンス改善 | Recruit Tech Blog
はじめまして、ホットペッパービューティーコスメ(以下 HPBC) の Web フロントエンドエンジニアとして学生アルバイトをしている三島です。3 ヶ月間のアルバイト期間で、案件に関わる機能開発や SEO 施策の検討と実装、パフォーマンス改善など様々な業務に取り組ませていただきました。本記事ではその中でも、私が取り組んだ HPBC におけるパフォーマンス改善について紹介します。 目次 1. はじめに 2. 想定読者 3. AMP とは 4. パフォーマンス改善の前提知識 5. 現状計測 6. 問題特定 7. 問題解決 8. 今後 9. まとめ はじめに HPBC の開発プロジェクトでは、Web ページを閲覧してくれるユーザーにとってページが完全に表示されるまでのスピード、つまり「パフォーマンスが大事である」という認識をチーム全体で共有しています。Web サービスのプロダクトは、機能の追加・改
超高速な静的Webページを作ろう！ - Qiita
PageSpeed Insights 計測結果 モバイル/パソコン 共に100点 速度という点に絞ると信用できるものではないかもしれませんが、100点という数字は単純にうれしい:) それでは！以下が私のやったことです リクエスト数を極限まで減らす CSSはstyle属性やstyleタグで設定 複数箇所で使う場合はstyleタグに、要素固有のスタイルはstyle属性で設定してしまいましょう。 style属性で設定する場合はセレクタでの捜索が発生しないので、ごく僅かながら速くなると思います。 画像はbase64で埋め込む こことかでデータURIスキームに変換してhtmlに埋め込みます。 base64エンコードすると容量が1.3倍くらいに増加するため大きな画像には向かない方法ですが、小さなアイコン程度ならリクエスト数減らすほうが効果的な場面があります。 複数箇所に使う画像の場合はCSS変数でba
Smashing Magazineのパフォーマンス改善ケースが凄まじい件 - MOL
Frontrend Advent Calendar 2014 - Qiitaの24日目。たぶん。知らんけど。 ちょっと前になるが12/13にバンクーバーで開催されたThe Style & Class Conference 2014に参加してきた。前日にSmashing Conferenceが、ウィスラーというバンクーバーから比較的近い所で開催されていて、本当はそっちに行きたかったんだけど高額なため、地元コミュニティのほうにだけ参加した。ウィスラーの方の記事は@ygoto3が書いてたっぽい。 Smashing Conferenceで登壇していたJohn Allsopp氏やVal Head氏もこのカンファレンスで登壇するということで、『なんだ、ウィスラーのついでかよー』と思い全然期待してなかったのだが、行ってみたらカンファレンス全体の構成などすごく考えられていて、とても素晴らしいカンファレンス
2014年のWebパフォーマンスふりかえり - 来年以降の期待etc
ひさびさにWebフロントエンドパフォーマンス系の話題をつらつらと書いてみます。例によってモバイル系開発者寄りの視点かもしれません。文中の参照リンク多め。 ファクタ まずはパフォーマンスに影響を与えるファクタについての所感。Webパフォーマンスにおけるイニシャライズとランタイム ::ハブろぐ で示した分類に基づきます。 イニシャライズ（いわゆるページロード） 4GやLTEが普及してもコンテンツの肥大化には追いついていない concat と CSS Sprites の呪いが解けない HTTP/2 の Streams and Multiplexing に期待 HTTP/2 の Server Push にも期待 画像周りだと <picture> 関連仕様も使いたい（srcsetだけならいける？） WebRTC とか WebSocket とかストリーミングとかは？ （やや疎い、てかイニシャライズじゃ
High Performance Web Frontend
★追記： https://speakerdeck.com/ahomu/high-performance-web-frontend-2013-qiu のほうがブラッシュアップ版です WCAN 2013 Summer (7/6) で行われた、"High Performance Web Frontend"のセッション資料です。Network 1 : Render 2 : Compute 1 くらいの割合で、各パフォーマンス要因についてお話しました。
Cacoo - Web上で図の作成とリアルタイムコラボレーション
Online diagramming tool for collaborating on wireframes, flowcharts, and more
High Performance Web Design ~デザインから考えるハイパフォーマンスWebサイト~ | warikiru
2009-11-24 High Performance Web Design ~デザインから考えるハイパフォーマンスWebサイト~ ラベル: performance CSS Nite in ISHIKAWAで話をしてから1ヶ月経ったので、薄れゆく記憶の復習も兼ねて思いの丈を綴ってみたｗ High Performance Web Design 1. What's High Performance?ここでいうパフォーマンスというのはWebサイトの表示高速化についてです。つまり、ページをいかに早く表示させるかという課題です。でも、そうゆうのってサーバー側の問題でしょ？システムエンジニアの管轄じゃないの？と思われがちですが「ハイパフォーマンスWebサイト」の著者であるSteve Soudersの調査によると、80:20。一般的にユーザーの待ち時間の実に80%がブラウザ側、フロントエンドで費やされて
don’t use @import | High Performance Web Sites
April 9, 2009 12:32 am | 90 Comments In Chapter 5 of High Performance Web Sites, I briefly mention that @import has a negative impact on web page performance. I dug into this deeper for my talk at Web 2.0 Expo, creating several test pages and HTTP waterfall charts, all shown below. The bottomline is: use LINK instead of @import if you want stylesheets to download in parallel resulting in a faster
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Web Frontend Rendering Performance Knowledge & Tips