本サイトの AMP 提供の停止とここまでの振り返り | blog.jxck.io
Intro 前回の記事で、奇遇にも本サイトの AMP 対応を落とすことになった。しかし、そうでなくても AMP をどこかでやめることは考えていたため、きっかけの一つが SXG 対応になったのは、順当な流れだと筆者は感じている。 これは AMP がなぜ始まり、なぜトーンダウンしつつあるのか、そしてこれからどうなっていくのか、という流れをまとめるいい機会でもある。 その過程で生み出され、本サイトでも検証を続けてきた Performance Timing API, Core Web Vitals, Signed HTTP Exchange 、そして今構想されている Bento AMP などを踏まえ、一連の流れを覚えている範囲で記録としてまとめておく。 ソースは筆者の主観であり、眺めてきた体感を mozaic.fm の Monthly Web などで話してきたものがベースなので、信頼性や正確性は期
2020年やったこと、考えたこと、触った技術のまとめ - mizchi's blog
今年の本業は、 3rd party script で、そこから呼ぶウィジェットを最適化するコンパイラを書く、その仕様を考えて、実装するという感じだった。要は Google Analytics と、最適化コンパイラ付き GTM みたいなものを作っていた。その内容は以下に書いた。 サードパーティスクリプトの極限環境向け Svelte パフォーマンス改善に Core WebVitals という大義名分を得た 今年は、 パフォーマンスのエンジニアをやっていた、と思う。サードパーティスクリプトの配信を生業にする会社のエンジニアとしては、来年の Core WebVitals というパフォーマンス関連の大きな変化で、波にのってやりたいことがやれたと思う。 Core WebVitals の導入で実際にどれぐらいの影響がでるか不明だが、パフォーマンスが SEO に影響する、というのは、 若干やりすぎと思いつ
Re: Rails を主戦場としている自分が今後学ぶべき技術について
この記事は、 Rails を主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ についてのアンサー記事です。 うなすけ君が Ruby on Rails で育ってきたように、僕も JavaScript とともに育ってきたという自覚があります。なので、これについて書くことは、ポジショントークは避けられない、という感覚があります。 冷静に比較しようとも思いましたが、やっぱり開き直って思いっきりポジショントークをすることにしました。そっちのほうが面白いと思うので。 自分の基本的な主張は、こちらの記事にあるとおりです。 Frontend Study #1: 基調講演 - Frontend 領域を再定義する 自分と Ruby on Rails 僕は、キャリアとしては Rails の会社で JavaScript を書いてきたことが多かったです。学生の頃は socket.io
Node.js徹底攻略 ─ ヤフーのノウハウに学ぶ、パフォーマンス劣化やコールバック地獄との戦い方｜ハイクラス転職・求人情報サイト AMBI（アンビ）
Node.js徹底攻略 ─ ヤフーのノウハウに学ぶ、パフォーマンス劣化やコールバック地獄との戦い方 Node.jsをうまく活用できている企業は、どのような方法でベストプラクティスを習得してきたのでしょうか。ヤフー株式会社でNode.jsの社内普及に務めてきた言語サポートチームに、同社の実施を紹介してもらいました。 Node.jsは「イベントループモデルで、ノンブロッキングI/Oを使用している」「問題発生時にHTTP/TCPやPOSIX APIなど低レイヤーの知識を求められる」といった特徴を持つ言語です。開発者が習得すべき技術領域が広いため、Node.jsらしい書き方の学習難易度は高いと言えます。 それでは、Node.jsをうまく活用できている企業は、どのような方法でNode.jsのベストプラクティスを習得してきたのでしょうか。ヤフー株式会社でNode.jsの社内普及に務めてきた言語サポート
Webパフォーマンス虎の巻
Webパフォーマンス向上施策のために、今更ながら超速本1を読んだので、今までの自分の知見と合わせてまとめてみます。 なるべく柔らかく、改善施策ってまず何をどうすればいいの？という疑問を持った人に向けて書いています。 ▪️格言 そもそもWebは速い。遅くしているのは我々です。大抵は技術の問題ではなくて、人の問題。 引用元： テクニックではなく、今、本気で取り組むべきWebパフォーマンス （html5jパフォーマンス部 部長 竹洞さん） 心得 パフォーマンス向上に対する施策は大別すると以下の２通り 軽量化 （単純にやりとりするデータ容量を小さくすること） 圧縮 削除 最適化 （その時に最も適している実装・実行をとること） 経路・順番の変更 非同期 もっとも遅くしている原因を探して、それを対策するのが原則。「対効果」が絶対的正義である。手段から入るのは愚策。まず先に原因を知ることが重要。 ▪️1
Webサイト高速化対策の現状
はじめに はじめまして、こんにちは。クラスメソッド株式会社でWebを担当している野中です。 この度、「これから身につけるWebサイト高速化テクニック」と題して記事を連載させていただくこととなりました。 本連載ではWeb担当者やWebデザイナー、コーダーの方々に向けて高速化に関する手法や技術について調べ、身につけたテクニックを細かな解説を加えて紹介していきます。中には少し難しいテクニックも含まれますが、できる限り分かりやすく、すぐに実践できるよう紹介していきたいと思います。とても長い連載ですが、よろしくお願いいたします。 なお、本連載はクラスメソッド開発ブログで連載されている「身につけておきたいWebサイト高速化テクニック」の増補改訂版です。 本連載の流れ 本連載はできるだけ多くの方に興味を持っていただけるように、最初に高速化対策の全体像と必要な知識を紹介します。その後、具体的な高速化対策と
ssig33.com - ネイティブアプリ並のウェブアプリを云々
なんか最近そういうの流行ってるようですね。僕も考えを書いてアクセス数を稼ぎます。 ページ遷移を過度に抑えようとするな 下手に AJAX 使いまくるぐらいならページ遷移したほうがマシであることが多いです。世の中にはページ遷移を抑えようとして酷いことになってる JS を沢山見ます。よく考えろ。 ローカルストレージを活用しない localStorage に画像とか放りこむの異常に重くなるのでオススメしません。認証持たないサービスで設定値保存するのに使うとかに留めた方がよいと思う。 非同期な API 絶賛してて気に食わない感じはしますがこの記事を一読することをお勧めします。 localStorage は小さなデータをいくつか入れる分には十分に高速です。大きなデータを入れると十分に低速です。 scroll イベントに対してリスナーを置かない scroll イベントの監視は実際最悪のアイディアです。こ
NoSQLとしてMySQLを使うDeNAが、memcachedよりも高速な75万クエリ／秒を実現
モバゲーで知られるDeNAは、バックエンドデータベースにNoSQLを使っていません。なぜか？ それはMySQL/InnoDB 5.1の環境で秒間75万クエリという、多くのNoSQLでも実現できないような高性能を実現しているから。DeNAの松信嘉範（まつのぶよしのり）氏は、自身のブログにこんな内容のエントリ「Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server」（英語）をボストしています。 Yoshinori Matsunobu's blog: Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server 松信氏が指摘するように、大規模なネットサービスを提供している企業の多くは分散環境で
Twitterがスケールに苦しむ理由 - スケールするサイトのアーキテクチャ考
Twitterのスケール関係で、面白い記事を発見したのでまとめ。 一時期「スケールしない」とか「動作が不安定」だとか言われ続けていたTwitter。5月ごろにslashdot.jpでも話題になっていた。論調は総じて「Twitterがスケールしないのは、Rubyを使っているから」というもの。 ところが同じ５月、「Why Can't Twitter Scale? Blaine Cook Tries To Explain（なんでTwitterってスケールしないの？）」という、blog紹介記事がSilicon Alley Insiderに掲載される。記事の元になったblogエントリは、Twitterの前チーフアーキテクトだったBlaine Cook氏によるもの。Cook氏によれば、TwitterのスケールとRubyは何の関係もないという。 Why Can't Twitter Scale? Blai
「はてな流大規模データ処理」を見てきた - もぎゃろぐ
KOF2008：関西オープンソース2008というイベントに来ています。 はてなの伊藤さんの講演があったので、講演メモを公開。 ＃ボクがメモした内容であって、100%言ったとおりに書いてあるわけじゃないので、参考としてご覧ください。 (続き) アジェンダ 大規模なデータ OSのキャッシュ MySQLの運用 大規模データアプリケーションの開発 データの例 はてなブックマークのデータ量：五千万件くらいのデータ量 このデータに対して何百万人がアクセスしてくる状況でどういう作りにするか レコード数 1073万エントリー 3134万エントリー 4143万タグ データサイズ エントリー2.5GB 何の工夫もなく普通にアクセスすると...200秒待っても結果が帰ってこない 大規模データの難しいところ 開発サーバで開発者が作っている時は快適に動いていても、多数の人間がアク
「ヨドバシ・ドット・コム」がリニューアル直後から表示が遅すぎて激重になる大規模障害が発生、一体何が起きているのか？
ヨドバシカメラの公式サイト「ヨドバシ・ドット・コム」が2008年10月21日（火）にリニューアルされました。個人的な感覚では「使いにくく、見にくく、お目当ての商品が探しにくく」なって改悪されたように感じられていたわけですが、それどころかあまりにも表示が遅すぎて激重になり、なんとお詫びページまで作られるほどになってしまいました。 そして既にリニューアルから1週間が経過したものの、いまだに改善されておらず、一体何がどうなっているのかよくわからない状態で、どれぐらいの損失が発生したのかが非常に気になります。何が起きているのでしょうか？ 戦慄の実態は以下から。 まず発端は10月21日（火）。リニューアル直後から重くなり始め、ついにはタイムアウトを連発。たまたまこの日は前日にヨドバシ・ドット・コムから「ポイント残高失効のお知らせ」が届いていたため、ポイントでLANケーブルを買おうと思っていたのですが
CGIでRailsをまともに動かす - Blog by Sadayuki Furuhashi
普通にRuby on RailsをCGI（dispatch.cgi）で動かすと遅すぎてやってられませんが、gateway.cgiを使うと、そこそこの速度で動くようになります。 最初に仕掛けを紹介してしまうと、1回目のアクセスがあったときに常駐プロセスを起動し、2回目以降のアクセスはその常駐プロセスに処理させるようになっています。CGI自体は常駐プロセスに処理を投げるだけなので軽い、というわけです。ただし、１回目のアクセスは通常通りCGIで動作させたくらいの遅さです。 常駐プロセスは一定時間アクセスがないと自動的に終了するので（次のアクセスがあったときにまた起動する）、いろいろ制限のある環境でも使える、かもしれません。 さて、そのgateway.cgiですが、Railsの標準パッケージの中に含まれています。まだexperimentalらしいですが、多少パッチを当てると動きます。 使い方は↓こ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Ruby から Java へのシフトで大統領選を乗り切った Twitter
Shibuya.pmでしゃべってきました - 最速転職研究会
http://neta.ywcafe.net/000938.html