第十天：挑戰30天建10個B端獨立站（挑戰新平臺）

661 閱讀 0 評論 6 點贊

我是挑戰30天建站10個B端獨立站的SEO小平，今天是挑戰的第十天。今天又是從廣州搬磚了才回深圳建站的。堅持堅持，開搞吧。

現在開始匯報今天的建站工作：

我們群里的小伙伴一直問我用什么平臺搭建的網站？我一直是用WordPress搭建的，他們提出能不能試試別的平臺搭建，正好我看我們群里的一群技術大佬在成天探討某平臺建站多么的牛逼，也不知道他們去實際搭建了嗎？

今天SEO小平就嘗嘗鮮，用他們說的那個玩意兒搭建一個新網站。不要只說不做，執行! 執行! 執行! ? SEO小平昨天注冊域名，今天網站內容發布20個頁面，立即提交GSC，正式上線。24小時內完成從域名注冊到網站完整內容上線。我的執行結果如下：

首先注冊域名，我這里是昨天就把域名注冊好了

還是在我最愛的Namecheap網站去注冊域名。

看看我的域名，2024年12月27日注冊的。也就是昨天。接下來就是域名解析，這里略過。

第二步，就是用AI根據調研出來的關鍵詞寫作文案來布局關鍵詞了

調研關鍵詞用這個方法：給小白的寶典:SEO關鍵詞調研和布局-文字+視頻

布局關鍵詞要看這個：SEO 必備 HTML 代碼知識

這些掌握好之后接下來就是請出ChatGPT登場了，按照熟悉的SOP創建頁面，今天周末時間比較充足，所以我做的頁面數量有20個。老規矩上站點地圖看URL數量。

第三步，開通Google的GSC把網站提交給搜索引擎

第四步：檢測網站速度

他們都說這個平臺搭建網站比WordPress加載速度快，我迫不急的的想要測試測試了。

用谷歌官方推薦的測試網頁，在無痕模式下打開比較客觀的來測試一下。

https://pagespeed.web.dev/?utm_source=psi&utm_medium=redirect

測試結果如下：

桌面端測試結果截圖如下

手機端測試結果截圖：

從加載的資料耗時來看還是圖片消耗的資源最大，應該大家的網站都是這樣，也不用刻意去追求這個分數，用戶體驗才是第一的。

前幾年有個人給我展示他WordPress網站的加載速度也是滿分，我當時很崇拜他，結果發現那個屌*毛，是一個純博客網站網站全部是純文本，而且字很少，網頁就跟txt文本一樣，毫無樣式，沒有圖片，沒有視頻，就黑色的文字加白底，這種為了跑分犧牲用戶體驗的方法千萬不要學，只要網站能在用戶承受范圍內，不要去追求速度的滿分。

目前SEO小平親測了這個平臺的確加載速度比WordPress好很多，今天我已經添加到GSC了，過幾天看看SEO數據怎么樣，新事物還是要多觀察，多測試。

記住我們是要為了用戶體驗而且而去優化網站，并不是為了跑分去優化網站。為了SEO而且做SEO是毫無意義的努力。不值得提倡。

提到網站加載速度，我看我們群里很多人被這個困擾，總覺得WordPress速度是他SEO失敗的原因，我們今天就來分析一下WordPress網站是什么原因導致的加載慢。

WordPress （偽靜態）原理及加載速度慢的原因

技術架構

WordPress 是一個基于 PHP 和 MySQL 的內容管理系統（CMS）。它的頁面通常是動態生成的。當用戶請求一個頁面時，服務器會執行一系列的 PHP 腳本，這些腳本會從數據庫中獲取內容，如文章、頁面布局、插件數據等，然后將這些內容組合成一個 HTML 頁面發送給用戶瀏覽器。
偽靜態是通過服務器配置（如.htaccess 文件在 Apache 服務器上）將動態的 URL 重寫為看起來像靜態頁面的 URL。例如，將 “example.com/?p?= 123” 重寫為 “example.com/post?- 123.html”。但本質上，頁面還是動態生成的。

加載速度慢的因素

數據庫查詢開銷
：每次頁面請求都可能涉及多個數據庫查詢。例如，加載一個博客文章頁面，需要查詢文章內容、作者信息、分類信息、評論信息等。這些數據庫查詢操作會消耗一定的時間，尤其是在高并發或者數據庫性能不佳的情況下，會導致頁面加載延遲。
服務器端腳本執行時間
：PHP 腳本需要在服務器端執行，將各種數據組合成 HTML 頁面。這個過程包括解析模板文件、調用各種函數（如插件中的函數）來處理數據。如果插件或者主題代碼不夠優化，可能會導致腳本執行時間過長。
資源加載順序和插件數量
：動態生成的頁面可能會加載較多的 JavaScript 和 CSS 文件，而且這些文件的加載順序可能不夠合理。例如，一些插件（插件大多數是JavaScript 加載的）可能會在頁面頭部加載大量的腳本，導致頁面渲染被阻塞，用戶需要等待這些腳本加載和執行完成后才能看到完整的頁面內容。