あるAnonymous Coward 曰く、ニコニコ動画が、4月26・27日に開催される「ニコニコ超会議3」にて、スマートフォンサイトのフロントエンド側（クライアント側）のコード（HTML、JavaScript、CSS）をチューニングするイベント「超チューニング祭」を開催する。ドワンゴが誇るエンジニア、戀塚昭彦氏や江添亮氏、そして山田将輝氏、水島宏太氏らも参加するとのこと。ルールはまだ公開されていないが、スピードだけで無くUIの使い勝手なども評価される模様。
サーバー側はよく見るが (スコア:2)
HTMLとかJavaScriptとかのチューニングは気になるな。
さすがに圧縮やリクエスト数の低減は普通にやるだろうから、それ以外でどんなチューニングが出てくるのか期待してる。
# やっぱりサーバー側にnode.jsとかそれ系仕込んでフロントエンド側も高速化という感じなのかと思ったが新規性はないな
改善案の例 (スコア:2, 興味深い)
ニコニコ動画は好んで拝見しておりますので改善はうれしいですね。動画配信を多くのユーザに
提供するという膨大なスループットが長年の努力で達成できていますので、後は「サクサク感」に
影響する小さいファイルの配信、応答速度、通信の往復回数の削減などをして欲しいですね。
このあたりが対応の手間や変更のリスクが少なく効果が大きい案でしょうか。
・css や js などの静的ファイルを配信している res.nimg.jp で gzip 圧縮を有効にする（今は無効になってるっぽい）
・複数の .css を統合して１つにする
・複数の .js を統合して１つにする（1kB 程度の物が大量にあり、通信時間よりも TTFB がほとんどを占めているっぽい）
・css と js を minify する
・png ファイルを最高圧縮しておく（例えば http://res.nimg.jp/images/logo/logo-s.png [res.nimg.jp] は1.9kB ほど削減でき、半減する。optipng などのコマンドで、静的ファイルのディレクトリ配下の png を全部圧縮しなおせば良いだけなので簡単だろうし）
・css や js のキャッシュ時間を現在の 20 分よりも長くする（ファイルを更新したときに変更がすぐにブラウザに伝わるように、ちゃんと .cookie.js?1377581665 のように URL の末尾にバージョン識別番号のようなものが付いているので、たぶん何の変更も加えずにキャッシュ時間だけ延長できそう）
次点というかたぶん評価もされずに却下されるだろう案としては、キャッシュヒット率が低いサムネ
画像を datauri で全部 html 内に埋め込んでしまうというのもアイデアとしてはありますね。リクエストと
レスポンスの往復回数が激減するのが改善効果です。html が大きくなってしまうことと配信する http
サーバにかなりの負担がかかること、サムネをキャッシュする memcache とか redis を用意しないと
いけないのでサーバ構成にまで改善案が波及することがデメリットですね。
ともあれ、がんばって欲しいですね。楽しみです。
フロントエンドのチューニングポイントは既にわかってる (スコア:1)
うちの会社のMITEを使ってローカル環境で計測して、MWPでNTT DoCoMoとSoftBankの3G回線で計測してみて、既に何がボトルネックかがわかっているので…
積極的に参加したいような、でも、遠慮すべきか…
ここで何が問題で何を直すと良いかを書くと、このイベント自体の存在意義が無くなりそうだから、遠慮しとこうかな…
Re: (スコア:0)
処理のボトルネックと体験のボトルネックは別なんだよね。
外挿で性能上げるのは努力。式ごと書き換えるのが才能。
足し算の各項を精査して、わかったつもりになるのは、それはそれで意味はあるけど、
自分で自分の才能の限定定義しなくていいじゃない。
Re:フロントエンドのチューニングポイントは既にわかってる (スコア:3)
> 処理のボトルネックと体験のボトルネックは別なんだよね。
これは、全く同意です。
今回のイベントの告知で、「表示速度のみの判定ではありません！」と書いてありますから、ダウンロード並びに表示速度のみの問題ではないと考えます。
> 外挿で性能上げるのは努力。式ごと書き換えるのが才能。
> 足し算の各項を精査して、わかったつもりになるのは、それはそれで意味はあるけど、
> 自分で自分の才能の限定定義しなくていいじゃない。
この部分は、大変申し訳ないのですが、何をおっしゃりたいのか、よくわかりません。
Re: (スコア:0)
別ACだが、
ここで何が問題で何を直すと良いかを書くと、このイベント自体の存在意義が無くなりそうだから、
ってのは、ここにちょろっと書けるようなアイデアレベルで「イベント自体の存在意義が無くなりそう」といえるだけの、スピードだけで無くUIの使い勝手なども含めて他の追随を許さないようなものってことで、それってのは典型的な「わかったつもり」だと思います。
とくにUIって言葉で納得を一番得難いものだと思うし。
Re:フロントエンドのチューニングポイントは既にわかってる (スコア:2)
なるほど、自分の最初の文章が言葉足らずでした。
「パフォーマンスに関しては」、何が問題であるか、分析のデータを持っています。
「競技者の方がチューニングしたサイトの速度計測するiOSアプリを作ります。」と書いてあったので、パフォーマンスを主に意識したものだと思っていました。
「UIの使い勝手なども含めて他の追随を許さないようなもの」という意図はありません。
Re: (スコア:0)
>典型的な「わかったつもり」だと思います。
そんな深い話じゃなくて、「みんなでせーので競争しよう」なのに、
ココでアイデア書いちゃったら自分だけ不利になって競争にならないじゃん、でしょ。
Re: (スコア:0)
いや、それは暗黙のうちに、「俺のアイデアが最高」って前提を含んでるでしょ。
どれくらいの手間をかけたのか知らないけど、この人が外部の人間である以上、
それは他の人にも取れるはずのデータなんだから、自分の思いつくことは他人も思いつくって。
本当に良いアイデアだと思ってるなら、事前に公開してハードル上げといたほうが楽しい。
それにマニアックに面白くなるのは、完成度を50%から90%に上げるところより、
90%から99%、99%から100%に持っていくところでしょう。
「俺の最初のアイデアだけで性能はもう40ポイント良くなったから、後は大した工夫じゃないね」なんて、
仕事でもないのにそんなこと言い出すのは野暮の極み。
ちょっと測ればすぐ分かるようなボトルネックなんか事前にどんどん情報出して、
当日はもっと下らないネタで盛り上がってもらえばいいと思うね。
Re:フロントエンドのチューニングポイントは既にわかってる (スコア:2)
私、「俺のアイデアが最高」なんて書いてませんし、思ってもいません。
「何がボトルネックかがわかっている」と書きました。
それは、「アイディア」ではなくて、定点観測から導き出されたデータとしての「事実」です。
その「事実」を元に、どのような解決策に導くかは、アイディアだと思います。
こちらが持っているデータを競技前の参考情報として提供するという提案はドワンゴにしたので、あとは向こう次第です。
Re: (スコア:0)
気持ち悪いなぁ…
Re: (スコア:0)
> このイベント自体の存在意義が無くなりそうだから
とか最初はまるで一人でイベントまるつぶしにするかのようなすごい上から目線だったのにしょぼくれてきちゃったなぁ。
Re:フロントエンドのチューニングポイントは既にわかってる (スコア:2)
「ここで何が問題で何を直すと良いかを書くと、このイベント自体の存在意義が無くなりそうだから」と書いたのは、計測データに顕著に現れている遅延要因が、今回のイベントで直接にコントロール可能なフロントエンド処理に起因していないからです。
Re: (スコア:0)
「スピードだけで無くUIの使い勝手なども評価される」
と書いてあるのだから、主催の意図はスピードが主であり、使い勝手が従なのは明らか。
そこに「スピードはクライアントで頑張っても無駄」とかいうデータを暴露したら
そら「このイベント自体の存在意義が無くなりそう」と言って何の過言もないだろ。
絡んでる奴が勝手に誤読しておいて見苦しい言い訳付け足してるだけで根幹なんも変わってねえよ。
Re: (スコア:0)
最初からそう書こうよ。
情報の後出しは格好悪いぞ。
Re:フロントエンドのチューニングポイントは既にわかってる (スコア:2)
ブログにまとめました。
http://takehora.hatenadiary.jp/entry/2014/04/17/072838 [hatenadiary.jp]
違うそこじゃない (スコア:0)
スマホ版じゃなくてPC版の方をチューニングさせて下さいよ…。
Re: (スコア:0)
同意
ただPC版が遅いのは、ページ構築のほとんどをjavascriptにやらせてることが大きいので、
サーバー側の協力がないと無理そう。
イベント化するには向きませんわ
スマフォサイトなら (スコア:0)
HTML５対応だからクライアントストレージを目一杯活用
CSS、スクリプトをHTML側に埋め込むか非同期にする
バックグラウンドスレッドを活用するとか（もう使ってるかも？）
サーバとの通信回数、サイズの削減
なんだかクラサバの謳い文句を思い出した
ニコニコはなぁ (スコア:0)
リンク踏んでもFlashインストールしてないと見られないんだよね。(Youtubeも時々見られない物がある）
そういうのが続くとだんだんどうてもよくなっちゃうんで今後はWeb標準でがんばって貰いたいかんじ。
#プレミアム会員になってもFlash ぶち殺しだとニコニコ静画の一部しかみられないよ！
Re: (スコア:0)
Re: (スコア:0)
Flashなしが特殊とか言われなくなるのはあとどれくらいかかるだろうか。
早く死んでほしい。
Re: (スコア:0)
簡単ですよ。
Flashよりもあらゆる面で優れた技術を開発し公開すれば良いだけです。
何故それを誰もやろうとしないのか、個人的に不思議で仕方が無いんですけれど。
Re: (スコア:0)
速度面などはJSのネイティブ実行がもう少し進むと変わってくるのかもしれません（でもJSも結局統一されてないのでそこが問題か。Flashの利点の一つだったわけだし）。
あとはコード丸出し、コード書き換えの敷居低下にどれくらい耐えられるのか…。
Re: (スコア:0)
ブチ殺しとか死ねとかMacユーザはほんと言葉が汚いな
UIと安定性にはもはや期待せず (スコア:0)
少なくとも数秒間は飛ばせない強制広告があるYoutubeよりはマシかと思っていましたが、
最近はニコニコにもそれが導入されたようですね。
プレミアム会員を優遇する要素を増やすのは仕方ないですが、未だに売り物っぽい動画素材の投稿をしょっちゅう見掛けるのはそれでいいのか…
Re: (スコア:0)
プレミアム会員でも再生スタート時に動画広告が割り込んできたので驚きました。
これまた分かり辛い場所にある設定を探すとオフにできましたが、何のためのプレミアム会員なのかと…。
コメントログの下に出てくる広告とかもそうですが、プレミアム会員でも広告を完全には排除できないので、どうもお得感に欠けるんですよね。
月額課金ユーザーになっても不満は尽きないというか、優遇してもらいたいのはそこじゃない！というか…。
Re: (スコア:0)
Re: (スコア:0)
お金を払ってまでCMを見るとか、有料のCSのチャンネルが流行らないわけがよくわかりますね！
電opt君は出ないの? (スコア:0)
人間は手書きアセンブラでコンピュータ(gcc/clang/msvc)の最適化に勝てるか! みたいな。
Connection:closeするのはどんな時？ (スコア:0)
パフォーマンスの話題なんで便乗。
APIサーバみたく、大抵のアクセスが断続的で数秒程度以上の間隔があくような場合は、そりゃConnection:closeした方がいいのは知ってるけど
ごく稀に、ただの静的なファイルを配信してるだけなのにConnection:closeなサーバがあるんだよね。
ちょうど、ニコニコ静画のサイトがそうなってるっぽい。
静的ファイルの配信でも、いちいちcloseしないとコネクションを捌けない、なんて事はよくある事なんだろうか？
それとも殆どの場合は単純なサーバの設定ミスと考えていいんだろうか？
コストパフォーマンス (スコア:0)
という点では彼らの大勝利でないか、これ。
旨いアイデアだと思うわ。
Re: (スコア:0)
何だかんだドワンゴってボランティアを駆り出させるのが上手いですよね。
# 「旨い」アイデアとは言いえて妙
「超チューリング祭り」に空目した (スコア:0)
なんだ、チューニングか
Re: (スコア:0)
それが何か？
Re: (スコア:0)
そうした経緯があっての上で、
「じゃあお前らがやれよ」
が今回と言うことなのでしょう。
賛否はあるかもしれないけど私はこの方向性嫌いじゃないな。