タイで最速のウェブサイトを作成した方法

画像







まえがき



このプロジェクトに携わってこの記事を書くことは、「 reactjsでページを高速化し若くて遊び心のある人 」に影響を与えました。 サイトpingdom.comから、「 インターネット上のページがかなり大きくなっている」というセンセーショナルな記事を誰かが覚えている場合、イメージの重みが主にページの重みに追加される前に、「脂肪」に投げ込まれたという結論に達しましたおよびjavascript。 遊び心のある若い男性のページはあまり実用的な利点を与えません-それは彼の脳のためのよりウォームアップです。 私は彼女の品揃えから最も人気のある製品の販売で私のガールフレンドを助けることにしました。









私はすでに非常に最小限のサイトを作ろうとしました。 このようなプロジェクトは、フレームワークを超えて、おそらくプロジェクトをより早く終了したいという願望によって引き起こされました。 このアプローチは私の友人の間で非常に人気があります -KISS(Keep It Simple、Stupid)の人気は報われています。 主にバックエンドプログラマであるため、サーバー側のコードの最適化に多くの時間を費やしています。 実際、このような変更を盲目的に行うのではなく、メトリックを使用してそれらを強化することが重要であることに気付きました。







準備する



フロントエンドフレームワーク



私はフロントエンドのプログラマーではありません。フロントエンドのフレームワークに頼らなければなりません。 多くの場合、これはすべての「良い」ブートストラップを意味します。 ブートストラップコンポーネントは選択的に使用できますが、それでもjQueryを携帯することになります。 私はすでに、jqueryなしで機能する十分なネイティブjavascriptライブラリを見てきました。 ブートストラップのサイズとそのコンポーネントも私には向いていませんでした。必要以上に「定型化」されているように思えました。







そのため、少しくすくすと、自分自身をミニマルに位置付けるフレームワークを見つけました。 ここに私が考えていたもののサンプルリストがあります









基本フレームワークを選択しました。 理由のほとんどは個人的なものです。







  1. 私はすでに以前のバージョンで働いていました
  2. 私はjavascriptコンポーネントを必要としないように思えたので、必要に応じて自分で選択したいと思います。 ベースは、純粋にCSSフレームワークです。
  3. gulpをビルドツールとして使用します。 私はそれについて多くの良いことを聞いたが、何人かの職人はそれをレールに統合しようとさえした(私はしばしば対処する)。
  4. 私の目的に合ったフレームワークの作者からテンプレートを見つけました。 正直なところ、私は多くのレイアウトを台無しにしたくありませんでした。このプロジェクトの目標は異なっていました。 したがって、私は喜んでこのために著者に数ドルを与えました。


したがって、Baseのみを推奨するのではなく、リストを発行します。 しかし、グリッドシステム(たとえば、sussyグリッド)でのみ、さらに最小限に開始できるように予約する必要があります。







ホスティング



動的なコンテンツを作成するつもりはありませんでした。 そして、購入フォームを作成することは論理的に思えますが、私が見たタイの店のほとんどはこれを避けました。 購入フォームは銀行と統合しなければならないという事実によってさらに複雑になり、タイには銀行セクターの明確なリーダーがいません。 そのうちの10以上があり、それらはすべて多かれ少なかれ需要があります。私の外国人/タイ人の友人の間でさえ、銀行の選択は大きく異なります。 多くの購入は、インターネットバンキングおよびラインメッセンジャーを通じて直接行われます。 したがって、通常のパターンを壊さないことを決定しました。さらに、それによってタスクが大幅に簡素化されます。







静的コンテンツのホスティングのみが必要です。 ここで最も人気のある選択肢は、githubページとAWSです。 トラフィックの制限のため githubページを使用するのが怖かったので、AWSは私にとって最も安価なソリューションではないように思えました(私の非常に失礼な見積もりによると、1か月あたり約4ドル)。 すでにほぼfreespeech.netで実行されている3つのサイトがありましたが、1年以上使用するには10ドルで十分でした。 安いほど良いというわけではありませんが、この場合はすでに経験があり、苦情はありません。







画像







重要な修正


_ コメントは、私の地理的なサーバーの選択はタイのサイトにとって最も合理的ではないと指摘しました。 また、Apacheがどんなに軽量であっても、接続ごとに新しいスレッドを作成します







メートル法



私は当初、自分の「感情」に依存しないことに同意しました。 そして、私は社会的に認知されたツールに依存します。







gtmetrix.com-サイトの「速度」を測定するためのメインツールとして選択しました。 google page speedとyslowの2つの最も人気のあるツールが含まれていました。 元のページ速度ではまだ少しエラーが見つかったことが判明しました。 これにより、100%gtmetrixおよび同様のツールに依存することはおそらく最良のアイデアではなく、「最も一般的な」エラーのスクリプトによるチェックであるという結論に至りました。 あなたはいつでもさらに進むことができます。







負荷がかかった状態でサイトが開く速さを測定するつもりはありませんでした。 したがって、Apacheで発生する可能性のあるパフォーマンスの問題を無視しました。 しかし、検討する価値があるかもしれません。







最適化



Gzip



実行できる最も簡単な最適化は、gzip形式の静的ファイルを提供することです。 私は以前に働いていたすべてのプロジェクトでこれを行いました。 そのため、彼は.gzファイルの作成プロセスを自動化するタスクをgulpfile.jsに非常に迅速に投入しました。







var gzip = require('gulp-gzip'); gulp.task('gzip', function (){ return gulp.src('./public//**/*.+(js|css|html)') .pipe(gzip()) .pipe(gulp.dest('./public/')) });
      
      





そして、彼はすぐに.htaccessファイルを投げました。これはアーカイブされたファイルをブラウザに振り分けます。







  Header add Vary accept-encoding RewriteEngine on RewriteCond %{HTTP:Accept-Encoding} gzip RewriteCond %{REQUEST_FILENAME}.gz -f RewriteRule ^(.*)$ $1.gz [L]
      
      





また、このファイルをパパのビルドに大きな変更なしでコピーする必要がありました。 さらに簡単になりました。







  gulp.task('htaccess', function () { return gulp.src('./src/**/.htaccess') .pipe(gulp.dest('./public/')); });
      
      





また、タスクを更新してビルドする必要がありました







  gulp.task('build', function() { runSequence('clean', 'sass', 'build-img', 'jsmin', 'inlinesource', 'htaccess', 'gzip'); });
      
      





これはページを最適化する最も簡単な方法だと思います。怠zyな人だけが彼のプロジェクトでこれを行いません。 多くの最新のエンジンでは、これはすべて無効になります-プラグインを追加するか、オプションを有効にします。







キャッシング



キャッシング用のヘッダーを指定するタスクはそれほど簡単ではありませんでした。 AWSでは、これらはすでに自動化されています。 私は最後にいつそれをやったかを思い出そうとしましたが、いつか思い出しませんでした。 そのため、Googleの魔法の力、2、3の試みの助けを借りて、私はまだgtmetrixに100%受け入れられる何かをしました。







  <IfModule mod_expires.c> ExpiresActive On ExpiresByType image/jpg "access plus 1 year" ExpiresByType image/jpeg "access plus 1 year" ExpiresByType image/gif "access plus 1 year" ExpiresByType image/png "access plus 1 year" ExpiresByType text/css "access plus 1 month" ExpiresByType application/pdf "access plus 1 month" ExpiresByType text/x-javascript "access plus 1 month" ExpiresByType text/javascript "access plus 2 month" ExpiresByType application/javascript "access plus 2 month" ExpiresByType application/x-shockwave-flash "access plus 1 month" ExpiresByType image/x-icon "access plus 1 year" ExpiresByType image/icon "access plus 1 year" ExpiresByType application/ico "access plus 12 month" ExpiresDefault "access plus 2 days" </IfModule>
      
      





しかし、2つの試みを避けるために、 html5-boilerplateプロジェクトのサーバーテンプレートを使用することをお勧めします。 次回は間違いなくそれを行います:)







画像



Photoshopをコンピューターにインストールしていない人にとっては、画像の操作は大きな問題です。 画像の問題の半分は、既製のテンプレートを選択したという事実により解決されました。スプライト、ベクターに煩わされる必要はありませんでした。 しかし、これは私のすべての問題を解決しませんでした-私は他のアイコンと他の画像が必要でした。







画像の正しい形式の選択



私は、犯す可能性のある間違いのうちで最も重大な間違いを犯しました。 画像のデフォルト形式として.pngを選択しました。pngはWeb用に最適化されているという考えがありました。 実際、色で飽和した画像(写真など)の場合-jpegは依然として最適な形式のままなので、アイコン用にpngを残しました。







このトピックに関するより多くの教育プログラムは、Googleページで見つけることができます (私よりも理解している人から)。







ロスレス圧縮



エンジニアリングのバックグラウンドを持つ人として、専門ツールの価格を知っています。 非常に多くの場合、万能ツールよりも作業を容易にします。 あなたはメモ帳でプログラムできますが、より頻繁にそれが私たちの主な作業ツールになります-崇高なテキスト、ルビミン。 この場合、imageoptimは適切ですが、十分ではありません。 私は多くのjpegファイルを持っていたので、ロスレス圧縮の比較分析を見つけました-jpegtran獲得しました







一口で、これは非常に簡単であることが判明しました:







 var jpegtran = require('imagemin-jpegtran'); gulp.task('build-jpg', function () { gulp.src('./src/img/*.+(jpg|jpeg)') .pipe(jpegtran({ progressive: true })()) .pipe(gulp.dest('./public/img')); });
      
      





jpegでの色の最適化で遊ぶ



しかし、適切な形式のみを選択するだけでは終わりませんでした。 とにかく画像はすべて大きすぎました。 私のヒーローのバックグラウンドは半メガバイト以上を占めました。







画像



私はフォトショップを持っていませんし、ここでそれなしで何をすべきか本当に理解していません。 しかし、友人たちは素晴らしいTinyJpgプロジェクトを助け、助言しました-すべてが単純すぎることが判明しました。







CSS



私はまだCSSをインライン化することにしました。 これは少し直感に反します。スタイルをキャッシュできるように、これらすべてを別のファイルに保存することをお勧めします。 特に人気のあるフレームワークを使用している場合は、ユーザーがこれらすべてを既にキャッシュしている可能性さえあります。







ブートストラップを使用する場合は、むしろそれを行います。 しかし、私はあまり一般的でないベースを使用し、彼らが私のサイトに戻ることを本当に期待していなかったので、余分なhttpリクエストを削除することにしました。







一口で、これはいつものように簡単であることが判明しました:







 <link rel="stylesheet" href="css/styles.css" inline>
      
      





フォント



私にとって興味深い予想外の状況は、Google Fontsの場合で、テンプレートには2つの異なるフォントが使用されていました。 そして、合理的に最適化されているようです:







  1. 彼らは1つのhttpリクエストでロードしました
  2. WebFontLoaderを使用しました 。これは、フォントを非同期でロードし、ロード後にページをレンダリングしました。


しかし、gtmetrixはフォントを誓い続けました-キャッシュヘッダーがありませんでした。 私は最初に紹介した記事ですでに提案されているパスをたどり、Googleフォントを削除することにしました。 すべてのデバイスには適切な組み込みフォントがあります。 したがって、私はそのようなセットをここに残しました:







 font-family: "Helvetica Neue", "Calibri Light", Roboto, sans-serif;
      
      





サーバーの位置情報



タイにいる間に、タイからの速度を確認する簡単なスクリプトをスケッチしました。







 require "uri" SERVERS = [ { :name => "nearlyfreespeach", :url => "http://euphorbia.soihok.com/" }, { :name => "AWS servers", :url => "https://d4s21h4msr5q2.cloudfront.net/" } ] SERVERS.each do |server| uri = URI.parse(server[:url]) puts "Performing HTTP speed test for #{server[:name]}" puts `wget -O /dev/null #{server[:url]} 2>&1 | awk '/\\/dev\\/null/ {speed=\$3 \$4} END {gsub(/\\(|\\)/,"",speed); print speed}'` end
      
      





そして、私は次の結果を得ました:







 $ rspec speed_test.rb Performing HTTP speed test for nearlyfreespeach 85.1KB/s Performing HTTP speed test for AWS servers 203KB/s Performing HTTP speed test for nearlyfreespeach 92.5KB/s Performing HTTP speed test for AWS servers 192KB/s $ rspec speed_test.rb Performing HTTP speed test for nearlyfreespeach 83.2KB/s Performing HTTP speed test for AWS servers 168KB/s
      
      





したがって、私の間違いをしないでください。 ターゲットオーディエンスに近いサーバーを持つホスティング事業者を選択します。 サイトは少なくとも2倍の速さで開きます!







結論



ここにそのようなウェブサイトがあります-http://euphorbia.soihok.com/

そして、こちらがgtmetrixの最新の指標です-https : //gtmetrix.com/reports/euphorbia.soihok.com/zhMn6OhU







多くのCEOによると、クイックサイトはGoogleにボーナスを提供します。 私はそれを正直に望んでいましたが、チェックしませんでした。 したがって、ここでは指標をカバーできません。







私は頻繁に旅行しますが、モバイル接続であれ、ホテルであれ、またはアジアのどこかで開発されたインターネットでなくても、非常に疑わしい接続で作業する必要があります。 また、モバイル版のサイトがなく、サイトがデスクトップ用にも最適化されていないことに非常に怒っています。







私は、多くのリソースを必要としない高速バックエンドの実行に多くを集中しました。 しかし、100%のインディケーターを持つことは不可能だと思ったからといって、フロントエンドにあまり集中しませんでした。 しかし、それは単純ではありませんでしたが、可能になりました。 さらに、「必要最小限」を超えてさらに加速することができます。 高速ページの構築におけるこれらの原則と経験はすべて普遍的であり、後続のサイトははるかに高速で高速化が容易です! あなたは潜在意識のどこかでそれについて考え始めなければなりません! そして、ユーザーはあなたに感謝し、戻ってきます。







私たち全員に速いサイトを望みます!







* 「タイで最も速いウェブサイト」は私の「派手な」見出しです。100%の確実性でこれを言うことはできません。 しかし、タイで見たほとんどのサイトは最速ではありません。








All Articles