タグ

関連タグで絞り込む (13)

タグの絞り込みを解除

パフォーマンスと*htmlに関するyamadarのブックマーク (7)

  • 1ミリ秒でも早く届けたい! HTMLで画像読込を高速化するために取り組んでいること - ICS MEDIA


    ウェブサイトの表示スピードはサイトの健全性における重要な観点の一つです。Googleが提唱するCore Web Vitalsコア・ウェブ・バイタルズと呼ばれる指標の中にもサイト表示スピードに関する項目があり、表示されるまでの時間が単なるユーザー体験だけでなく、SEOでも無視できない存在です。表示スピード低下の要因はネットワークやサーバーサイド、そしてフロントエンドまで広範囲におよびます。本記事ではその中でも画像の読み込みについて改善できるテクニックを改善前と改善後を比べながら紹介します。 改善前サンプルを別ウインドウで開く 改善後サンプルを別ウインドウで開く 画像読み込みBefore / Afeter 上図はLighthouseによるチェックの結果です。Lighthouseはウェブサイト検査ツールで、ウェブページのパフォーマンス、アクセシビリティ、SEOなどの状態を計測できます。Googl
    1ミリ秒でも早く届けたい! HTMLで画像読込を高速化するために取り組んでいること - ICS MEDIA

  • 2022年におけるフロントエンド開発のベースライン


    LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog TL;DR:2022にフロントエンド開発で最も考慮すべきユーザー環境は、パフォーマンスでは低スペックのAndroid端末、標準仕様では2年前のSafari、そしてネットワークでは４Gです。それに対してはJSへの過剰依存などが原因で主にパフォーマンスの面でのウェブ全体の対応がよくありません。 こんにちは！LINEフロントエンド開発室のダバロス アランです。この記事のタイトルを見て﹁釣りタイトルですね〜﹂と考えている方がいると思いますが今回に限ってはそれを大目に見てください。それはなぜかと言いますと、2021年から2022年にかけて私たちフロントエンドエンジニアが全体的に考え方を改める必要が出るほど大きな変化がありました。 その変
    2022年におけるフロントエンド開発のベースライン

  • dev.toがなぜinsanely fastを実現出来ているか - Qiita


    INSANELY FAST Qiitaを読んでる人なら https://dev.to をほとんどの人が見たはず。見てない人は見てきてください、速すぎて驚くはず。またmizchiさんがdev.toに書いた なぜ dev.to がこんなにも速く、こんなにも自分にとって感動的なのか - dev.to を見た人も多いと思う。個人的にHeroku, Railsを採用してここまで爆速なサイトを構築出来ていることは今までの常識を覆す衝撃な出来事だった。こんな新しい発見をもたらしてくれたdev.toには本当に感謝してる。自分もこんなサイト作ってみたいなと思ってdev.toのことを色々調べてて少し知見がたまったので共有してみます。 この記事はOkinawa.rb Advent Calendar 2017 7日目の記事です。 Twitterやってるのでよかったらフォローしてください🙋‍♀️ @saboyut
    dev.toがなぜinsanely fastを実現出来ているか - Qiita

  • フロントエンドチェックリスト（日本語訳） - Qiita

    GitHubで公開されているフロントエンドチェックリストというドキュメントが、網羅されている内容が幅広く便利そうだったので、日本語に翻訳しました。 日本語版は、以下のGitHubリポジトリにあります。GitHub側と自動的に連携するようにしておりますので、誤訳や誤りなどがあれば GitHub のプルリクエストまたは Issue で報告していただけると幸いです。 https://github.com/miya0001/Front-End-Checklist 日本語版への貢献方法 最終更新日時: 2017-11-19 03:50:47+09:00 (未翻訳) Front-End Checklist The Front-End Checklist is an exhaustive list of all elements you need to have / to test before lau

    フロントエンドチェックリスト（日本語訳） - Qiita

  • Webフロントエンド表示速度、最速化手法まとめ - Qiita


    やりすぎても無駄になることがあるので、必要十分なバランスを見極めて実施する。主に社内のプログラマ向けのまとめ資料。他にもあれば追記していく予定。 ページの状態を調べる まず対象のページが、どういった状態なのかを調べる。 Google PageSpeed Insights これを100点満点にする必要はないが、赤くなっている項目に関しては、なるべく対応したほうが良い。モバイルサイトにも対応しているので便利。 https://developers.google.com/speed/pagespeed/insights/?hl=ja pingdom 実際にページにアクセスしてスピードを計測できる。海外サーバなので、けっこう遅い…。最適化前と最適化後で比較するのに使うといい。 http://tools.pingdom.com/fpt/ Chromeデベロッパーツール コンテンツの読み込み順序／速度
    Webフロントエンド表示速度、最速化手法まとめ - Qiita

  • GitHubのエラー・ページ


    GitHubのStyleguideにエラー・ページのセクションがあるのを知った。それによると外部ファイルに依存しないように書いているらしい。CSSはstyle要素で、JavaScriptはscript要素で、画像ファイルはBase64エンコードしてData URIで、それぞれHTMLに直接埋め込むというスタイル。 実際に404のテンプレートでもちゃんとそうなっていた。フロントエンド脳なので、HTTPリクエストを減らして、エラー・ページのコストを下げたいのかなと単純に考えてしまったけど、Not Foundの連鎖を避けることとか外部ファイルがCDN経由の場合の確実性を上げることとかの方が強い理由のようだ。エラー・ページを単独で機能するようにしておき、エラー時に余計な負荷を与えないようにすることにより、より速やかに復帰できるように、ということになりそう。 HTTPエラー・ページの意味も重要だけど
    GitHubのエラー・ページ
    yamadar
    yamadar 2013/10/07
    エラーページは外部ファイルを使わず単独で機能させる。「Not Foundの連鎖を避けることとか外部ファイルがCDN経由の場合の確実性を上げることとかの方が強い理由」
    リンク

  • Webデザイナーでもできる、サイトのパフォーマンスをあげる5つの方法


    Webデザイナーでもできる、サイトのパフォーマンスをあげる5つの方法 2011-08-28 Webデザイナーが、Webサイトのパフォーマンスを重視する傾向はあまり無いように感じますが重要なことです。 Googleでは、0.5秒遅くなると、検索数が20%減少する amazonでは、0.1秒遅くなると、売り上げが1%減少する という報告もあるようです。Webサイトのパフォーマンスはコンバージョンにも影響する大切な部分。 今回はWebサイトのパフォーマンスを上げる方法を取り上げます。 パフォーマンスアップの前に 応答時間の限界 0.1秒までなら、結果はコンピューターではなく、ユーザーによって引き起こされたように感じる。1秒までなら、"遅れている"と感じるが、ユーザーの思考は途切れずに、自由に動いていると感じる。10秒までになると、ユーザーがコンピューターに振り回されている気持ちになり、ストレ
    Webデザイナーでもできる、サイトのパフォーマンスをあげる5つの方法
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.