Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

タグ

performanceに関するHolyGrailのブックマーク (68)

  • フロントエンドチューニングの箇条殴り書き

    普段気をつけてるよリスト "モバイルで、WebViewとブラウザのコンパチで、特にセオリー化されていないデザインモジュールのなか、装飾画像もふんだんに使うぞ系サービス開発" の文脈における、パフォーマンス確保のため気をつけてるよリスト。 よく、パフォーマンス「向上」とか「確保」とか申しますが、メンテナンスコストなどと天秤にかけて、「必要十分」のラインを狙うのが重要だと思う次第。 画像リソース 画像リソースを揃えるときのセオリ。圧縮率とか最適化とか細かいチューニングはあれど、大雑把に下記を守る。そしてImage Optim(or 相当の処理)。 JPEGはプログレッシブで画質60くらい(オレ目安) PNGは差し支えない範囲で色数をきちんと削る 50px未満のサムネイルは@2.0xなリソースにしない 案外、Androidあわせの@1.5xや@1.0xでも大丈夫なことすらある GIFアニメを入れ

    フロントエンドチューニングの箇条殴り書き
  • WebPagetest - Website Performance and Optimization Test

    Test. Experiment. Improve! WebPageTest. The gold standard in web performance testing. Lightning-Fast Web Performance Online CourseLearn to analyze performance, fix issues, and deliver fast websites from the start. Free! Start Course Now >> Introducing Carbon Control Experimental New in WebPageTest! Measure your site's carbon footprint and run No-Code Experiments to find ways to improve.

    WebPagetest - Website Performance and Optimization Test
  • Etsy Engineering | September 2013 Site Performance Report

    As we enter the fourth quarter of 2013, it’s time for another site performance report about how we did in Q3. Our last report highlighted the big performance boost we saw from upgrading to PHP 5.4, and this report will examine a general front-end slowdown that we saw over the last few months. Server Side Performance Here are the median and 95th percentile load times for signed in users on our core

    Etsy Engineering | September 2013 Site Performance Report
  • Etsy: サイトパフォーマンスの定期報告 - ワザノバ | wazanova.jp

    http://codeascraft.com/2013/10/14/september-2013-site-performance-report/ Etsyが四半期に一度のサイトパフォーマンスのレポートを発表してます。 1) サーバサイドパフォーマンス [グラフ] 9/18時点での主要各ページにおけるログインユーザのロード時間の中央値と、下位5%に位置する(もし全員で100人の場合は95人目)ユーザの値です。 データに大きな変化はなし。中央値が、62ms〜334msと、そこそこ良い水準にあるので、数値が悪化させないことだけに注力し、若干のコード変更をしたのみ。 2) シミュレーション基準のフロントエンドパフォーマンス [グラフ] WebPageTestのプライベートインスタンスを利用して計測。DSLコネクションで、IE8 / IE9 / Firefox / Chromeが対象。24時間計測

  • なぜあなたがウェブサイトをHTTPS化するとサイトが遅くなってユーザーが逃げていくのか - 射撃しつつ前転 改

    完全に釣りタイトルですけど中身は真面目に書くよ。 近年、ウェブサイトのHTTPS化が流行のようになっている。私の知る限り、Googleの各種サービスやTwitter、Facebookなどが完全にHTTPSで通信を行うようになっている。HTTPS、つまりSSLによる通信の暗号化によって、ユーザにこれまでよりも安全なウェブサイトを提供できる。 しかし、あなたが作っているサイトをふと思いつきでHTTPS化してしまうと、たぶん、これまでよりもサイトが遅くなる。ここでは、HTTPSで通信する場合の問題を解説する。 なぜ遅くなるのか HTTPで通信する場合、クライアントがサーバへと接続するためにはTCP/IPの3ウェイハンドシェイクという手順が必要になる。めんどくさいのでここでは詳しくは説明しないが、要するにクライアントがリクエストを投げる前にパケットを1往復させないといけないのである。パケットの往復

    なぜあなたがウェブサイトをHTTPS化するとサイトが遅くなってユーザーが逃げていくのか - 射撃しつつ前転 改
  • High Performance Web Design ~デザインから考えるハイパフォーマンスWebサイト~ | warikiru

    2009-11-24 High Performance Web Design ~デザインから考えるハイパフォーマンスWebサイト~ ラベル: performance CSS Nite in ISHIKAWAで話をしてから1ヶ月経ったので、薄れゆく記憶の復習も兼ねて思いの丈を綴ってみたw High Performance Web Design 1. What's High Performance?ここでいうパフォーマンスというのはWebサイトの表示高速化についてです。つまり、ページをいかに早く表示させるかという課題です。でも、そうゆうのってサーバー側の問題でしょ?システムエンジニアの管轄じゃないの?と思われがちですが「ハイパフォーマンスWebサイト」の著者であるSteve Soudersの調査によると、80:20。一般的にユーザーの待ち時間の実に80%がブラウザ側、フロントエンドで費やされて

    HolyGrail
    HolyGrail 2009/11/28
    まぁ、日本のYahooはスコアよりもレスポンスまでの時間を重視してるので。YSlowのスコアが低い=遅い、パフォーマンスを意識していない、ではないですよね。あとYSlowのスコアが高い=速いでもないですよ。
  • AutoPagerizeを軽量化するアイデア - 0xFF

    先に結論を言うと、AutoPagerizeは拡張版がオススメです。以下その理由と余談的なお話です。 拡張版のAutoPagerizeについてちょっと勘違いしてました。AutoPagerizeは軽量化できるという話に路線変更します。 AutoPagerizeってのは、次のページを今見ているページの下に継ぎ足して、ページ遷移することなく次のページを見ることができる、ブラウザの機能を拡張するスクリプトです。 このAutoPagerizeは派生スクリプトがたくさんあって、FirefoxだけでみてもGreasemonkey版のAutoPagerize(家)、cho45さんのjAutoPagerize、Add-onのAutoPagerize(家)、AutoPager(作者は日人ではなく、どちらかというと非日語圏向けかも)などなど。他にもかなりの数があります*1。 で、Opera、Google

    AutoPagerizeを軽量化するアイデア - 0xFF
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • IBM Developer

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    IBM Developer
  • https://jp.techcrunch.com/2009/06/05/20090604google-opens-up-internal-speed-tool-to-the-public/

    https://jp.techcrunch.com/2009/06/05/20090604google-opens-up-internal-speed-tool-to-the-public/
  • smush.it!

    Performance just got a little bit easier. Optimizing images by hand is time consuming and painful. Smush it does it for you. Image optimization is an art that not many people master. There are many good image editing tools that allow us to get the best visual result for a certain file size but "under the hood" a lot more optimization can be done. Smushit.com is a service that goes beyond the limit

  • Yahoo Developer Network

    Measure, monetize, advertise and improve your apps with Yahoo tools. Join the 200,000 developers using Yahoo tools to build their app businesses.

    Yahoo Developer Network
  • Yahoo!ニュース高速化へのサイトデザイン側からのアプローチ

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、Yahoo!ニュースのデザイナーの黒田・由衛です。 Yahoo!ニュースが2009年4月27日にリニューアルしました。今回のリニューアルでは、お客様に快適にサイトを利用していただけるよう最速でページを表示させることに重点をおきました。 お客様がウェブを閲覧するのは1日の中のほんの限られた時間です。その貴重な時間を割いてYahoo!ニュースに来ていただくわけですから、1ページでも多くの記事を「読みやすく」「ストレスなく」見ていただけるようにするのが、Yahoo!ニュースがお客様にできる最高のおもてなしだと考えています。そこで、今回のリニューアルでは、サイトデザイン側からのアプローチとして以下の2点の施策を行いました。 1

    Yahoo!ニュース高速化へのサイトデザイン側からのアプローチ
    HolyGrail
    HolyGrail 2009/04/28
    id:i_ogi>その向上施策の全体における割合は分かりませんが、少なくともニュースの体感速度は確実に向上してますし、パフォーマンスってわりとこういう小さいことの積み重ねだったりするのでいいんじゃないですかね。
  • 一番遅いところを速くしないと意味がない - ロックスターになりたい

    yahoo tech blog祭りに便乗してあんまりyahoo tech blogとは関係ないんだけどひとつ書くよ! 時間が掛かりすぎるので100回にしました。それでもEの例では4秒も掛かっています。 こういう1000回測ってこんだけ速い!っていうのはよく見る。ここでは100回で4秒なのでフォームを作るのに40msかかってる。けっこう遅い。複数これくらいの遅さのやつがあって100msオーダーになってくると多分体感速度でも違ってくる。amazonだと100msで売り上げが1%変わるとかって書いてあるので100msレベルで遅いのは努力して改善できるのなら改善するべき。 あなたのウェブサイトを高速化する方法 - page3 - builder by ZDNet Japan でも10,000回測って4秒(1回4ms)くらいのレベルだったら、そこに努力を注ぎ込むくらいならほかのところで努力した方がい

    一番遅いところを速くしないと意味がない - ロックスターになりたい
  • JavaScript の不思議な面白さ - 第四回

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog 前回の「第三回」ではよくある手法でプログラムの分離を試してみました。 そろそろこの連載も折り返し地点となります。 実はこの記事は、最初、小さな課題を与えられたプログラマが正攻法で突撃するもうまくいかず、策をろうしてやっと勝利、その知識を広めようとライブラリ化を行ったところで難題にぶち当たり、裏街道に突入。状況を打開する為にプログラム技術を駆使し、最終的にフレームワークとして完成させる、というストーリーになっています。 * さて、さっそく前回の答えですが「A」です。 まずは下のグラフをごらんください。 上記は、各実装でどれぐらい表示に時間が掛かるかを測定したものです。 単位は ms (ミリ秒=1000分の1秒)です。 重要なのは プ

    JavaScript の不思議な面白さ - 第四回
    HolyGrail
    HolyGrail 2009/03/26
    id:vantguarde>結局のところサービスの規模も含めたバランスじゃないでしょうか。例えばWindows95のようなユーザも割合で見れば極小でも実数で見たときにどうなんだろう、とか。ものの規模によって全然違うと思うんです。
  • スティーブ・サウダーズ氏がハイパフォーマンスWebサイトの続編を執筆中 – 秋元

    [am]0596522304[/am] 「さらに速いウェブサイト」 2009年6月発売予定だとか。 プレゼンで話し、それをまとめていってにするということで、プレゼン資料や動画は逐次公開されていくそうです。 via Google Code Blog [am]487311361X[/am]

    HolyGrail
    HolyGrail 2009/03/23
    ktkr!
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • Web ページを高速化する

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    Web ページを高速化する
  • 漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法

    ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基中の基であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_

    漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
  • あなたのウェブサイトを高速化する方法 - builder by ZDNet Japan

    そして同氏は、世界で最も高速なウェブサイトの1つであるGoogleのパフォーマンスにかかわる仕事をしているのである。 ウェブのパフォーマンスには2つの重要な側面、すなわち効率性と応答時間がある。効率性は、世界ランキング100位に入るようなウェブサイトを構築する際に出てくるスケーラビリティという難問に取り組むための武器である。あなたのウェブサイトが何百万人単位のユーザーと、何十億単位のページビューを擁するような規模のものである場合、バックエンドアーキテクチャ全体に対する理解を深めておくことが重要となるだろう。 ページの速度というものは、HTMLドキュメント内に記述する一連の指示によって決定されると言っても過言ではない。 iGoogleを例に挙げると、バックエンド処理に費やされる時間、すなわちデータがキャッシュされていないために毎回リクエストされることで費やされる時間は、ページ全体の処理時間の