はじめまして。サーバーサイドエンジニアの中野(@Hiraku)です。2015年12月からメルカリで働いています。 2016年1月27日(水)の第98回PHP勉強会@東京にて、composerを速くする取り組みについて発表をしてきました。 composerはPHPにおける実質スタンダードなパッケージマネージャです。 このcomposer、日本で実行すると非常に遅く感じます。この原因は普通ならこう表現すると思います。 githubやpackagistが日本から遠いから composerの実装がよくないから しかし発表ではあえて「光が遅いから」という主張をしました。 一般常識として、光の速さ(真空中で秒速約30万km)はとてつもなく速いものという認識だと思います。しかし一方で、地球や宇宙の規模など極限的な状況に携わる仕事をしている人であれば「全然速くない、むしろ遅い」というのが普通の感覚です。
今日はWebサイトやWebアプリの描画パフォーマンスをどう改善したらいいのか、ということについて取り上げようと思います。私たちWeb開発者にとって、この分野は比較的新しく注目し始めたエリアで、 ユーザエンゲージメントとユーザ体験 に影響があるため重要です。 フレームレートはWebにも影響がある フレームレートとは、 連続した イメージを端末がスクリーンに映し出すレートのことです。秒間フレーム数(FPS)が低ければ肉眼で個別のフレームを判別でき、FPSの数値が高ければユーザにとっては反応が速いと感じられます。ゲーム業界ではおなじみの概念となっているものですが、Webにも当てはまるのです。 長時間に及ぶイメージのデコード、不必要なイメージのリサイズ、重いアニメーションとデータ処理はすべてフレーム落ちを起こす可能性があり、結果としてフレームレートは下がり、jankが多いページになってしまいます。
スマホからウェブにアクセスするユーザが増え、ウェブサイトの表示速度の高速化がより重要な制作の課題になっています。1ページもののサイトなら、フロントエンド・エンジニアが一人で実装できるかもしれませんが、ある程度の規模のウェブサイトではワークフローやサイト全体の設計にも関わってきます。また、表示速度の高速化の方法を知らなければ、最適化しやすい、より高度なデザインは実現できないでしょう。エンジニアだけでなく、デザイナーやディレクターがこういった情報を知っていれば、よりスムーズに結果を出せるウェブサイト制作ができるはずです。 ページ表示速度の改善にはいろいろな方法がありますが、この記事では一番効果がありそうなところから攻めていきたいと思います。自分もまだまだ勉強中なので、まずはfilament groupのScottさんの記事 やClearleftのJeremyさんの記事 を参考に、フロントエンド
はじめに Webパフォーマンスはパフォーマンスエンジニアリングの1つの分野 Webパフォーマンス管理は、Webサイトの非機能要求の性能や可用性を扱います。 専門用語では、コンピュータの登場と時期を同じくして登場したパフォーマンスエンジニアリングという分野に属します。 パフォーマンスエンジニアリング パフォーマンスエンジニアリングとは、Wikipediaでは以下のように記載されています。 Performance engineering encompasses the techniques applied during a systems development life cycle to ensure the non-functional requirements for performance (such as throughput, latency, or memory usage) w
Gin Gonic The fastest full-featured web framework for Golang. Crystal clear. Performance and productivity can work together Gin is a web framework written in Golang. It features a martini-like API with much better performance, up to 40 times faster. If you need performance and good productivity, you will love Gin. Low Overhead Powerful API You can add global, per-group, and per-route middlewares,
まつけんです。 今回は、とれたまのコーナーで有名なテレビ東京さんの番組「ワールドビジネスサテライト」(以下、WBS)で紹介されるにあたって、どういう負荷対策をしたのかを紹介します。 WBSに紹介されて直後にサーバーアクセス殺到して落ちました、というような話は結構聞いていたので、機会損失という意味でも落ちるのはなんとか避けたいね、ということで対策をしましょうという話になりました。 前提 今回の負荷対策の前提となる条件を挙げます。 まず、ありがたいことにCerevoは最近、WBSに2度紹介されています。 LiveShellの紹介(映像はこちら)とCerevo DASHの紹介(映像はこちら)の2回です。 Cerevo DASHでは現在、iConvexというiPhoneアプリと連動する電子巻き尺ガジェットの支援を募集しています。是非、ご覧ください。 ということで、それぞれでの紹介内容にあわせて、別
Webサイトの表示高速化対策していますか? 日本は欧米諸国に比べWebサイトの表示高速化対策をしているサイトが少ないです。 特に、最近ではスマートフォンの普及によりモバイルサイトの需要も増え、高速化をしなければいけない機会も増えてるのかなと思います。 日本のモバイルデータ通信はLTEで高速になりつつあるとは言え、まだまだ「貧弱!貧弱ゥ!」です。 幸いなことに僕も最近鶴の一声によってクライアントからサーバー周りまで包括的な高速化対策を経験する機会を得ることができました。 それまでは、「手間がかかりすぎるからできればやりたくない」というのが本音でした。職務怠慢ですね(苦笑)。 でも、できるだけ楽したい!と思うのが人の常。 この連載ではできるだけ楽をしながらできる高速化手法と計測結果を1つ1つ紹介しようと思います。 基本的にはすべて受け売りの内容です。やってみた対策を羅列して、連載の中で自分で試
Make your pages load faster by combining and compressing javascript and css files As some of you may know, I am currently working on a content management system. Although I am not able to share all of the code – it is proprietary after all – I already made one debugging tool public. This tool can be used to test some common techniques which decreases the bandwidth generated by feed consumers. Toda
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く