og:imageチェッカーを作りました

2017年3月30日 00:27 javascript — littlepad

ウェブページの og:image 画像をチェックするツールを作りました。
チェックしたい url を入れると各ページの og:image 画像をサムネイル表示します。
その際、title, url, description も合わせて表示しています。

起動方法

  1. 下記 url から git clone するか、ダウンロードする
    https://github.com/littlepad/ogimage-checker
  2. 初回だけ npm i で必要な node モジュールをインストールする
  3. npm start で起動
  4. ブラウザで http://localhost:3000/ へアクセス

作ろうと思った理由

  • サイトの META データ系を修正する際、title や description は grep で何とかなるが、og:image は割りと見落としがち
  • ページに設定されている og:image をひとつひとつ確認するのも手間
  • express を API 的な用途で試してみたかった

注意

html ファイルをスクリピングして情報を取得しているため、サーバー側には負荷がかかります。
ご利用は常識の範囲で。

inline-css化でスタイルが反映されずハマった

2016年12月24日 16:28 html/css,javascript — littlepad

gulp-inline-css を利用して、CSS のインライン化をする際、一部のスタイルが HTML タグに反映されていないケースがあった。
結論としては、CSS に charset が指定してあると、その直後のスタイルが反映されないっぽい。

ちなみに私の場合、css の書き出しに gulp-sass を利用していたが、gulp-sass (というか node-sass)では、scss 内にマルチバイト文字含まれていると、charset が明示的に記述されていなくても自動的にふられる。
例えば、font-family にマルチバイトが含まれている場合、下記のようになる。

scss

html {
  font-family: $font-family-default;
  font-size: $font-size-default;
  line-height: $line-height-default;
  color: $color-text-default;
}

css

@charset "UTF-8";
html {
  font-family: "ヒラギノ角ゴ Pro W3", "Hiragino Kaku Gothic Pro", "メイリオ", Meiryo, "MS Pゴシック", sans-serif;
  font-size: 16px;
  line-height: 1.75;
  color: #222; }

なので、node-sass を利用して書き出された css に charset が含まれている場合は、gulp-inline-css を実行する前に、charset を取り除くなどの処理が必要になる。

CSS NITE LP47「Coder’s High 2016」に参加してきた

2016年9月25日 01:38 event,html/css — littlepad

CSS NITE LP47

CSS NITE LP47「Coder’s High 2016」に参加してきたので、印象に残ったセッションのメモと感想。

イマドキのコーダー環境構築

Node.jsのロードマップによると、現在は複数バージョンが入りみだれるタイミング(v7もうすぐ!)。
Nodeのバージョンによってパッケージが使えない、動かないなどを避けるには、anyenvを使ってnodeのバージョンをプロジェクトごとに管理するとよい。
依存モジュールのバージョンを固定するには、npm shrinkwrap。
ちなみに、数年前にgruntで管理していてた環境を、gulpとかに切り替えたいけど、この手のメンテは皆さんどうしてるのかな?って思った。
PostCSSは、Sassを上回るメリットをいまひとつ感じなかったので、まだ様子見かなって感じ。
必要な処理をプラグインで組み合わせていくっていうのは、敷居が高そうなイメージ(環境構築やメンテする人がチーム内で限定されそう)。
コーダーは怠惰であれ。

ハマるSVG

SVG、利用の仕方とOS/ブラウザバージョンの組み合わせによっては、いろいろ不可解な現象が起こるらしい。
私の場合は、SVGを実案件でロゴぐらいしか使用していないので、今のところ大ハマりしたことがないが、何かあったらまず本日の10選から目を通していきたい。
Reactでは、SVGでの使用要素に制限があるのは初めて知った。
gulp-svgo:アンカーポイント数が多い時、ファイルサイズ軽減のために座標値を整数化して容量を抑えてくれる。
まぼろし松田さんのスライドはいつも見やすいが、今回は特にタイトルロゴがかっこよかった。
デザインされていなくても良いところに手をかけられているのを見ると、いいなって思う。

本当に利用は必要か?デザイナーにとってのjQueryとJavaScriptフレームワーク

「漢なら黙ってjQuery」というセッションのオチもあったが、jQueryは学習コストも高くないし、情報も溢れているので体得するには一番敷居が低いと思う。
一時期、脱jQuery的な風潮(vanilla.jsとか)もあったけど、現場レベルではまだまだ現役だし、jQueryなら割とみんな書けるので共通言語としては必須な気がする。
その他フレームワーク/ライブラリが使えればモアベターだけど、それはあくまでプラスαの話。
少なくともデザイナーは。

esa.ioのBootstrap利用とCSSリファクタリング

えー、bootstrapがアップデートされるたびに、入れ替えてるの?ってところに驚いた。
sugoi。

モダン日本語フォント指定

貴重な情報の共有だった!!
最終的な形に落ち着くまでのストーリー(OSごとのフォントウェイトがバラバラ問題とか)もとても分かりやすかった。
これを調べるの、大変だったろうなぁ。実案件とかで、いきなりこれにぶち当たっても、なかなかここまでは調べきれないし、やりたくないw。
游ゴシックを使う機会があったら、今度からこれをコピペして使おう(公認)。
あと、フォント周りの設定は、基本的に前作ったサイトのものをコピペで再利用したり、一度設定するとなかなかいじらなかったりで、実はフォントまわりの仕様って、ふんわりとしか理解してないなぁと話を聞いていて感じた。
@font-familyのlocal指定は、ポストスクリプト名を調べたりしなくちゃいけないのかー、へぇ。

Enduring CSS

今日の話だけ聞いた印象をすごく大雑把にいうと、一昔前に共通部分はcommon.cssで、あとはページごとにユニークなcssを作って管理してたやり方を、ネームスペースを付けたり、モジュール(詳細度大きめ)をBEMでもっとちゃんと管理しようよって印象を受けた。
ケースバイケースかもしれないが、大きなサイトになればなるほど、デザインのレギュレーションを保つには、サイト全体でモジュールを統一して、再利用した方が良いんじゃないかと個人的には思った。
あと、どこで使われているか分からないので、うかつにCSSを削除できないといった話があったけれど、単純にgrepすれば良いのでは?と思ったけどそうゆう話じゃないのかな。
まあ、直感的ではないけれど。

その他

今回は、セッション全体を通して、まわりのWAI-ARIAへの意識が高くて驚いた。
WAI-ARIAに関しては、1年以上前に「コーディングWebアクセシビリティ – WAI-ARIAで実現するマルチデバイス環境のWebアプリケーション」を読んだだけで、今となっては内容的にもうる覚え。CodeGridの「WAI-ARIAを活用したフロントエンド実装」を読んでアップデートしておきたい。

ブログをAMP対応してみた

2016年1月11日 23:51 seo — littlepad

下記ページを参考に、WordPressにプラグインを追加して、AMP対応してみた。

海外SEO情報ブログ | WordPressのプラグインでブログをAMP対応にしてみた

結果

WordPressのプラグインの場合、記事ページをAMP対応ページとして書き出すのではく、元ページに対するAMP対応ページを別途書き出す。
この時、元ページにamphtml、AMP対応ページに元ページへのcanonicalが追加されることで、重複コンテンツとは判定されないのかな?

元ページ
http://www.littlepad.net/blog/2015/03/11/205716
AMP対応ページ
http://www.littlepad.net/blog/2015/03/11/205716/amp

各ページのコードについて

元ページ

下記が追加された

  • amphtml
    
    

AMP対応ページ

下記が追加された

  • 元ページへのcanonical
    
    
  • webフォント用CSS(外部読み込み)
    
    
  • AMP関連のJS読み込み(外部読み込み)
    
    
    
  • 装飾のCSS (head内に追加)

AMP(Accelerated Mobile Pages)について

23:42 seo — littlepad

AMP(Accelerated Mobile Pages)とは

  • GoogleとTwitterが協同して策定したモバイルウェブ高速化を目的としたプロジェクトである
  • AMP HTMLの仕様に沿ってモバイル向けページを構成することで超高速化を実現可能になる
  • AMPの仕様に従って構成されたウェブページは、Google/Twitter側にキャッシュされ、キャッシュからコンテンツを返すことによって、高速表示を可能とする

AMPの制約

  1. アクセス解析ツールを利用できない(表示速度に影響するJavaScriptを使うため)
  2. JavaScriptを自由に使えない(独自のインタラクティブな仕組みを使えない)
  3. 広告を表示できない(広告収入が大切なメディアサイトには死活問題)

1, 3 は対応されたっぽい。
AMPが広告とGoogleアナリティクスをサポート開始

制約に関する未来

  1. メジャーなアクセス解析ツールベンダーと協働し、今使っているアクセス解析ツールをAMPページでも利用できるように開発中
  2. “escape hatches”(エスケープ・ハッチ)と呼ばれる、AMP環境であっても、複雑な技術を使っている機能を特別に実行できる仕組みを準備中

参考/引用サイト

about

ハンドルネーム:littlepad
都内で WEB 制作(デザイン, html/css, Flash, MT, WordPress etc)をしているBOØWY研究家

category:

search:


archives:

GO TO PAGETOP