Vueの秘密のパフォーマンステク9選紹介 - Qiita
VueConf USでのさまざまな発表 今年の3月に VueConf US が開催されました。最近になってビデオが公開されて初めて知ったこともあるので本記事ではその紹介をします。 いろいろ面白いトピックがあるのですが、特にVueコアチームのGuillaume Chauさんによるパフォーマンス改善テクニックはまじかーという感じだったのでここにまとめたいと思います。 "9 Performance Secrets Revealed with Guillaume Chau" プレゼン動画: http://www.youtube.com/watch?v=5B66qer8cZo スライド: https://slides.com/akryum/vueconfus-2019#/ デモサイト: https://vue-9-perf-secrets.netlify.com ソース: https://githu
「入門 監視」を読んでからの取り組みを紹介します - WILLGATE TECH BLOG
「入門 監視」を読んだ フロントエンド監視 なぜフロントエンド監視が必要なのか どうやってフロントエンド監視をしているのか Runbookを作ろう なぜRunbookが必要なのか Runbookをどう使っていくか 監視の民主化 勉強会開催 今後 こんにちは！インフラチームの小林です。 今回はインフラチームが現在取り組んでいる、運用環境の改善施策を紹介します。 「入門 監視」を読んだ 2019年01月 に「入門 監視」という本が O'Reilly Japanから出版されました。 www.oreilly.co.jp 『システムをどう監視したらよいのか』『監視の仕組みをどう作ったらよいのか』について紹介している本です。 実践したい事、反省する事だらけですが、フロントエンド監視とRunbook作成から始めています。 フロントエンド監視 なぜフロントエンド監視が必要なのか Webサイトの表示スピード
実録パフォーマンス改善 - 高速化のためアーキテクチャやアルゴリズム選択から見直すSansanの事例 - エンジニアHub｜Webエンジニアのキャリアを考える！
実録パフォーマンス改善 - 高速化のためアーキテクチャやアルゴリズム選択から見直すSansanの事例 インフラの特性をふまえ、ミドルウェアの挙動を理解し、プロファイリングによってボトルネックを把握し、要求に合ったアーキテクチャを選択する。そういった工夫を重ねることでアプリケーションのパフォーマンスを改善する事例を、Sansanの千田智己さんに聞きました。 アプリケーションの設計・実装方法を変えることで、性能が格段に向上するケースは数多くあります。有名IT企業のエンジニアは、どのような方針のもとでアーキテクチャあるいはアルゴリズム選択などでパフォーマンスを改善しているのでしょうか？ 法人向けクラウド名刺管理サービス「Sansan」や個人向け名刺アプリ「Eight」を提供するSansan株式会社の千田智己さんに、これまで取り組んできた事例と、そのノウハウを教えていただきました。 千田 智己（せ
フロントエンドのパフォーマンスを徹底解説！ブラウザの気持ちで理解するHTML/Javascript/CSSの話 | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
HTMLフロントエンドcssdomcssomパフォーマンスJavaScript こんにちは、羽山です。 今回はウェブシステムにおけるフロントエンドのパフォーマンスの話です。 皆様はウェブのパフォーマンスを気にしていますか？ おそらく大抵の方はSQLのチューニングやロジックの改良などをした経験があるのではないでしょうか？ しかしプログラムをチューニングしても、期待ほどはページ表示速度が改善しなかったことはありませんか？ 昨今のウェブサイトは大量のCSS/Javascriptファイルで構成されているページが大半です。例えばHTMLを100～300msほどで生成してブラウザに転送できたとしても、ページ表示が完全に完了するのに4～5秒かかるということも珍しくありません。 「なんか遅いけど沢山いろいろ読み込んでるから仕方ないな・・・」と諦めないでください。ブラウザがどのようにHTMLを解釈して、CS
![フロントエンドのパフォーマンスを徹底解説！ブラウザの気持ちで理解するHTML/Javascript/CSSの話 | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/6e392d4350342045b699dea4e2a6421740d16647/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2018%2F04%2Fphoto_47592_20151013_min.jpg)
LinuxのI/OやCPUの負荷とロードアベレージの関係を詳しく見てみる - Qiita
大人気TBSドラマ、「逃げるは恥だが役に立つ」でも話題になったインフラエンジニアという言葉ですが、今ではインターネットインフラを知らないまま開発をするのも難しい状況になっています。クラウドが一般化されたからといって単にリソースの調達が簡単になっただけで、つまりハードウェアの知識が無くても何とかやっていけるようになっただけであり、インフラの知識が要らなくなったなどということは全くなく、むしろdevopsの掛け声とともに、ソフトウェア開発者にインフラを見なければならない新たな責務が課せられたという、なかなか痺れる状況なのだろうと思います。 そういった中で、先日のさくらインターネットのAdvent Calendar最終日に「いまさら聞けないLinuxとメモリの基礎＆vmstatの詳しい使い方」という記事を書かせて頂きましたが、今回はLinuxサーバの「負荷」と、ロードアベレージに関して、掘り下げ
たった一行で重いスクロールが軽快に！will-change属性を付けるとFPSが上がる理由 - Qiita
HTMLやCSSのパフォーマンスチューニングを皆さん普段意識されているでしょうか？ フロントエンドはJavaScriptの進化と共にアプリケーションが年々複雑化してきたこともあり、パフォーマンスチューニングのトピックを目にする機会が増えました。 しかしHTMLやCSSも同様にレンダリングの仕組みを少し知り、それに応じた実装することでパフォーマンスを大きく上げることも可能です。 今回は最もシンプルかつ分かりやすい事例として、will-changeプロパティについて紹介したいと思います。 サンプルを使ってFPSを実際に測定してみる 今回はサンプルとして、TwitterのツイートにあたるHTML構造と同じものを4000個縦に並べ、高さ400pxでスクロールできる領域を用意し、スクロール時のFPS(Frame Per Second)を測定してみました。 // この実装は実質たった3行！ const
Webパフォーマンス虎の巻
Webパフォーマンス向上施策のために、今更ながら超速本1を読んだので、今までの自分の知見と合わせてまとめてみます。 なるべく柔らかく、改善施策ってまず何をどうすればいいの？という疑問を持った人に向けて書いています。 ▪️格言 そもそもWebは速い。遅くしているのは我々です。大抵は技術の問題ではなくて、人の問題。 引用元： テクニックではなく、今、本気で取り組むべきWebパフォーマンス （html5jパフォーマンス部 部長 竹洞さん） 心得 パフォーマンス向上に対する施策は大別すると以下の２通り 軽量化 （単純にやりとりするデータ容量を小さくすること） 圧縮 削除 最適化 （その時に最も適している実装・実行をとること） 経路・順番の変更 非同期 もっとも遅くしている原因を探して、それを対策するのが原則。「対効果」が絶対的正義である。手段から入るのは愚策。まず先に原因を知ることが重要。 ▪️1
バーストパフォーマンスインスタンスに関する主要な概念と定義 - Amazon Elastic Compute Cloud
従来の Amazon EC2 インスタンスタイプの場合は CPU リソースが固定されています。一方バーストパフォーマンスインスタンスの場合は、CPU 使用率にベースラインレベルを定義した上で、そのレベルを超えて CPU 使用率をバーストさせることが可能となっています。これにより料金は、ベースラインの CPU 使用率に加えて、バーストとして追加された分に対してのみ支払えば良いことになり、コンピューティングのコストを削減できます。ベースライン使用率とバースト機能は、CPU クレジットで管理します。バーストパフォーマンスインスタンスは、CPU 使用率にクレジットを使用する唯一のインスタンスタイプです。 各バーストパフォーマンスインスタンスは、CPU 使用率がベースラインを下回っている間は継続的にクレジットを獲得し、ベースラインを上回っている間は継続的にクレジットを消費します。獲得または消費された
I/O負荷の正確な状況はiowaitでは分かりません - Qiita
さくらインターネットのアドベントカレンダー9日目として、サーバ屋らしく、運用に関するコマンドの使い方を紹介します。 サーバの負荷が高まってきたときに、vmstatやtopなどのコマンドで調査する事が出来ますが、I/O負荷をwa(iowait)によって判断する人も多いと思います。 ただ、結論から言うと、iowaitは正確にI/Oの負荷を表しているわけではありません。 これらを、実際に演習をしながら見ていきたいと思います。 iowaitとidle iowaitとはあくまでも、CPUが空いているのにI/Oがボトルネックになっているプロセスを示しているだけで、CPUの利用率が高いときにはI/Oがボトルネックになっていてもiowaitが上がりません。 同様に勘違いされがちなのが、id(idle)はCPUの空きを示しているというものですが、idleは必ずしもCPUの空き時間を示しているものではありませ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
