カテゴリー
www ツール

Catchpointによる表示速度検査を受けました

遅くなって申し訳ありませんでした。Webパフォーマンス Advent Calendar 2019 – Qiitaの記事です

AdventCarendarに参加するということで、Catchpointでの計測を行って頂きました。

計測して頂くのはどのページにしようかと考えたんですが、弊社内で、アプリの紹介ページが重いという意見があり、せっかくの機会なのでそのページをということになりました。

で、竹洞さんに連絡したら、「そのページまでの動線で計測したほうが良い」と言って頂き、動線の中で一番ボリュームが多い、ログイン→マイページ→アプリ紹介ページという動線で計測して頂きました。この導線で見るというのが、当初とは別の課題の発見につながったので、なるほど、流石だと感動しました。

Catchpointのありがたいところ

定時のチェックを行うのはPSIのスコアレベルなら行えますが(弊社は、定期的にPSIのAPIを利用してスコアを取得しています)この精度で見ることができないのでとてもありがたいです。

下は、First Contentful Paintの統計。実際の回線(今回はDoCoMo)やエミュレートした回線(ノイズが少ない)でのデータが見れています。

このようなウォーターフォールも15分ごとに見ることができます。

制作時にDevToolsでも確認できることはありますが、このように定期的に取れるのはこういうサービスでこそということですね。

竹洞さんにいろいろ指摘をいただく

ありがたいことに、ご意見頂きました。ざっとまとめると。

  • DNS
    • Route53を利用することで出てくるレイテンシ
    • その場合のレイテンシは最低で約100ms以上
  • サーバー返答時間(TTFB)
    • 改善の必要あり
    • プログラムのチューニングが主になる
  • HTTP/2
    • 利用している
    • いわゆる「つまり」は確認できた
  • サードパーティー
    • Googleタグマネージャー
    • Karte
    • 改善の要求をすべき

Catchpointでわかったこと

冒頭に書いたようにページに到達する導線で計測してもらって気づけた課題があります。

それは、ログイン→マイページの動線でのサーバー待機時間についてでした。

  1. ログインの判定
  2. リダイレクト
  3. マイページのサーバー待機

という流れが1.5秒近くかかっていました。

言われてみれば確かにという問題ではあるんですが、改善ポイントとしてピックアップすべき事象ですね。

これからの改善ポイント

  • サーバー返答時間
    • 現状、ページにより1000ms近く、またはそれ以上になっているので改善ポイントを探して対応していく
  • サードパーティー
    • 改善の依頼を継続して行う
    • 使い方を確認していく
  • フロントエンド
    • 効率的なHTML/CSS/JavaScriptの記述
    • 画像などのコンテンツの読み込み順を考えていく
  • DNS/CDNなど
    • AWS以外の選択肢(Cloudflareなど)も「あと100ms」ぐらいになった段階で検討していく
    • CDNは静的ファイルだけでなく、コンテンツキャッシュでも利用しているので、そのあたりも含めた検討が必要
  • スピード監視
    • 本気で検討したい
    • 社内の議論に改めて上げていく

最後に

普段から竹洞さんの情報を見ている立場ですが、このような形でやりとりさせて頂きありがとうございました。これからも参考にさせていただいて、少しずつでもサービスの改善に努めていきます。

カテゴリー
www ツール

Twitter Cardsのキャッシュ更新の方法を整理

ちょっとオミカレの仕事でやったのでメモとしてまとめておきます。

Twitter Cards使うこと多いと思います。こんなやつですね。

いわゆるLP的な単発の場合、手でソースを書いたりするんですが、ちょいちょい間違えたりするじゃないですか、人類って(主語でかい)。

CDN使ってて間違えてそっち書いたりとか(Twitter Cardsに入れる画像はリンク先と同じドメインじゃないとダメというのを忘れがち)。あと純粋にURL間違えたりとか。

そこでTwitter Cardsに関連したmetaを直して、さて更新となるんですが、TwitterでCardの情報がキャッシュされているので、まあ、反映されない。

https://cards-dev.twitter.com/validator

Card Validator通すとキャッシュクリアされるってよく言われていますが、まあ、されない。「それでしばらく待ちましょう」ってことなの?と思いつつも本家のドキュメント見ると書いてました。ちゃんと明記してました。

https://developer.twitter.com/en/docs/tweets/optimize-with-cards/guides/troubleshooting-cards#refreshing

要は、bit.lyで対象のURLのショートURLを作成して、そのbit.lyで生成したURLをTweetすると、元URLのキャッシュも書き換えられるということなんですね。

実際にサクッとTwitter Cardsの内容が更新されたので今後はこれでサクサク行けそうです。やはり頼るべきは公式のドキュメントですね!

カテゴリー
www

このページはモバイルファーストインデックス対象ページなのか?3ステップで確認する方法 at Search Console(新バージョン)

Googleの検索結果の半分以上がモバイルファーストインデックス(以下MFI)になったそうです。

Official Google Webmaster Central Blog: Mobile-First indexing, structured data, images, and your site

Google、検索結果の半数以上のページが MFI に移行したと発表 ::SEM R (#SEMR)

今年の3月から本格運用とのことでしたが、世界中のウェブサイトの数を考えと、約9ヶ月で半数を越えたというのを、速いととるか、遅いと取るかは人それぞれでしょうか?

そうなると、気になるのは

で、自分の(面倒見ている)サイトはMFIの対象なんだろうか?

ということではないでしょうか?

Search Consoleを利用するとサクッと確認できるので紹介しておきます。
※ 新バージョンでの確認方法です。

カテゴリー
markup www

Google Fonts のレギュラーに Noto Sans JP が加わりました

はい、加わりました。

Noto Sans JP – Google Fonts https://fonts.google.com/specimen/Noto+Sans+JP

軽く試してみようということで、このブログをNoto Sans JPにしてみました!

とりあえず、気になるところを‥‥

カテゴリー
others www

Photoshopの「アセットの初期設定の指定」にフォルダー名はいらないよ、という話

もう、タイトルで完結っちゃ完結なんですが補足。

カテゴリー
markup www

label要素はbuttonにも適用できるの?

マテリアルデザインのスタイルガイドを見ていたら、ボタンの高さは36dpとあり、さらにクリッカブルな領域は48dpにするという記述を見つけました。

https://material.io/guidelines/components/buttons.html#buttons-style

スクリーンショット 2017-04-08 16.34.43

だとすると、button要素内に透明の領域を‥‥、とかspanやdivなど親要素つけてそこに判定を‥‥、というよりはlabel要素使うのがマークアップとしては素直かな?と思いました。

カテゴリー
www

ブラウザーのアクセシビリティチェックツール

Web Accessibility Advent Calendar 2016の14日目の記事です。

普段は受託でウェブサイトやウェブアプリケーションの制作を行っていますが、制作時には気をつけているつもりでも、やはり抜けもあります。余裕がなくなってくるとなおさらです。実際には実装屋のみでできる範囲には限界はありますが、それでも、実装屋でもなんとかなる範囲だけでもやろうと思った際に、コード書くときの心構えだけではなかなかうまく行きません。

そういった面において、Developer Toolsなどで一緒にチェックできるツールというのは、ひとつの助けになるだろうということで紹介します。