- แม้จะปรับแต่ง Nextcloud บนเซิร์ฟเวอร์ส่วนตัวแล้ว สาเหตุที่ยังตอบสนองช้าคือโครงสร้างการโหลด JavaScript มากเกินไป
- ระหว่างการโหลดหน้าแรก มีการดาวน์โหลด JavaScript 15~20MB และแม้หลังบีบอัดแล้วยังเหลือราว 4~5MB ซึ่งยังหนักเกินไป
- สคริปต์ของแต่ละแอปมีขนาดใหญ่มาก เช่น
core-common.js (4.71MB), NotificationsApp.chunk.mjs (1.06MB), แอป Calendar 5.94MB, แอป Files 18.8MB, แอป Notes 20.91MB
- ด้วยโครงสร้างแบบนี้ แม้แต่บน iPhone 13 mini ก็ยังมีดีเลย์ 5~10 วินาทีในการเปิดแอป Tasks
- แม้จะเปลี่ยนบางฟังก์ชันไปใช้ Vikunja (JS 1.5MB) และ Immich แทน แต่ก็ยังแทนที่ทั้งหมดได้ยากเพราะความสามารถแบบบูรณาการของ Nextcloud
สาเหตุของประสิทธิภาพที่ลดลงของ Nextcloud
- Nextcloud รวมฟังก์ชันหลากหลายไว้ด้วยกัน เช่น ไฟล์ ปฏิทิน รายชื่อติดต่อ โน้ต งาน และรูปภาพ แต่ ความเร็วที่ผู้ใช้รับรู้นั้นช้า
- แม้อยู่ในสภาพแวดล้อมที่ฮาร์ดแวร์มีประสิทธิภาพเพียงพอ ก็ยังตอบสนองช้า
- จากการวิเคราะห์ด้วยเครื่องมือสำหรับนักพัฒนา พบว่า สาเหตุหลักของความหน่วงคือปริมาณ JavaScript ที่มากเกินไป
- ตอนโหลดหน้าแรกมีการดาวน์โหลด JavaScript 15~20MB
- แม้จะส่งแบบบีบอัดแล้วก็ยังอยู่ที่ระดับ 4~5MB ซึ่งใหญ่มากเมื่อเทียบกับเว็บแอปทั่วไป (1MB)
- แม้จะมีแคชของเบราว์เซอร์ แต่ก็ยังต้อง รันโค้ดจำนวนมากทุกครั้งที่เข้าใช้งาน ทำให้การโหลดล่าช้า
ขนาดของ JavaScript bundle หลัก
core-common.js : 4.71MB ทำหน้าที่เป็นฟังก์ชันร่วมสำหรับหลายแอปNotificationsApp.chunk.mjs : 1.06MB- แอป Calendar: เพียงแค่มุมมองปฏิทินพื้นฐานก็ต้องใช้ 5.94MB
- ในสภาพเครือข่ายที่ช้า อาจเกิดความล่าช้าในการโหลดเกิน 30 วินาที
- แอป Files: มีสคริปต์จำนวนมาก เช่น
EditorOutline (1.77MB), previewUtils (1.17MB), index (1.09MB), emoji-picker (0.9MB)
- รวมทั้งหมด 18.8MB และในสภาพแวดล้อมจริงอาจต้องรอโหลดเกิน 1 นาที
- แอป Notes: เฉพาะ
notes-main.js ก็มีขนาด 4.36MB และรวมทั้งหมดอยู่ที่ 20.91MB
ผลกระทบต่อประสบการณ์ผู้ใช้
- แม้แต่ตอนเปิด แอป Tasks ก็ยังมีดีเลย์ 5~10 วินาที
- ตัวอย่าง: เวลาเปิดรายการซื้อของในร้านค้า ก็ไม่แสดงขึ้นมาทันที
- สัดส่วนระหว่างฟังก์ชันกับขนาด bundle สูงผิดปกติ ทำให้เกิด ความไม่สมดุลระหว่างความสามารถกับประสิทธิภาพ
- ด้วยโครงสร้างของ Nextcloud ที่มีไลบรารีและเครื่องมือส่วนกลางจำนวนมาก จึงเกิด ประสิทธิภาพที่ลดลงเพื่อแลกกับประสบการณ์แบบรวมศูนย์
การใช้งานบริการทางเลือก
- บางฟังก์ชันถูกแยกไปใช้ Vikunja (จัดการงาน, JS 1.5MB) และ Immich (จัดการรูปภาพ)
- Vikunja อาจไม่สมบูรณ์แบบ แต่ด้วยขนาด JS ที่เล็กกว่า จึงให้ ความเร็วที่รู้สึกได้ดีกว่า
- อย่างไรก็ตาม ด้วย ความเป็นแพลตฟอร์มแบบบูรณาการและความสะดวกในการใช้งาน ของ Nextcloud จึงยากที่จะทดแทนได้ทั้งหมด
บทสรุปและมุมมองที่เปลี่ยนไป
- โครงสร้างปัจจุบันของ Nextcloud อาจมีข้อจำกัดในโลกความจริง เช่น เหตุผลที่สมควรหรือการขาดแคลนบุคลากร
- ถึงอย่างนั้น การถดถอยของประสบการณ์ผู้ใช้และการเข้าถึง ก็ยังเป็นปัญหาที่ชัดเจน
- บทความของผู้เชี่ยวชาญด้าน web performance อย่าง Alex Russell ทำให้ตระหนักถึงความสำคัญของ web performance และปัญหา ความละเลยในการดูแลเรื่องประสิทธิภาพและการเข้าถึง ของทีมพัฒนา
- ในการพัฒนาเว็บแอป ควรคำนึงถึงปัญหา performance inequality ด้วย
3 ความคิดเห็น
มันก็ช้าเฉย ๆ ไม่ใช่แค่ไคลเอนต์ที่ช้า แต่ฝั่งเซิร์ฟเวอร์ก็ช้าด้วย
บนเครื่อง 8745HS แค่สร้างภาพขนาดย่อของไฟล์ PDF ไม่กี่ร้อยไฟล์ก็ใช้เวลาหลายชั่วโมงแล้วยังไม่เสร็จเลย
ใช้ไฟล์เซิร์ฟเวอร์ตัวอื่นอะไรก็ยังดีกว่า ถ้าไคลเอนต์เป็น Windows ก็ใช้ smb ส่วนอย่างอื่นใช้ WebDAV server ผ่าน rclone หรือ dufs จะดีกว่าครับ
copyparty ดีเลยครับ
ความคิดเห็นบน Hacker News
ฉันอยากจะชอบ Nextcloud มาก ๆ คิดว่าการมีอยู่ของมันก็น่าทึ่งแล้ว
แต่ถึงภายนอกจะดูเหมือนทำงานได้ดี บางครั้งก็เกิด ข้อผิดพลาดที่กู้คืนไม่ได้ แบบพังไปเลย
เคยพยายามสำรองรูปครอบครัวอัตโนมัติด้วยแอป iOS/Android แต่แอป iOS บางครั้งขึ้นข้อผิดพลาด “locked webdav” หรือไม่ก็ซิงก์ค้างไปเฉย ๆ
สุดท้ายเลยต้องอัปโหลดรูป 80GB ใหม่ทั้งหมดตั้งแต่ต้น
มันไม่เสถียรพอสำหรับให้ครอบครัวใช้งาน จึงต้องการทางเลือกที่เชื่อถือได้ ซึ่งในทางปฏิบัติก็แทบไม่มีอะไรนอกจาก iCloud
ฉันวางไฟล์ผ่านการเชื่อมกับแอป Files แต่ไม่มีการซิงก์และข้อมูลก็หายไปโดยไม่มีคำเตือนใด ๆ
copyparty GitHub — มีเฉพาะฟีเจอร์ที่จำเป็นและไม่มีส่วนเกินที่ไม่จำเป็น
แต่ถ้าจะใช้แทน Dropbox ก็ยังไม่มีตัวเลือกที่เหมาะจริง ๆ
แอปทางการมีบั๊กเยอะ แต่ฝั่งเซิร์ฟเวอร์เสถียรดี
Nextcloud ช้าเพราะมีการเรียก JavaScript มากเกินไป
การรีเฟรชหน้าปฏิทินหนึ่งครั้งทำให้เกิด network call 124 ครั้ง และในนั้นมี 31 ครั้งที่ไม่ได้แคช
แต่ละปฏิทินใช้เวลามากกว่า 30ms ทำให้ยิ่งมีปฏิทินมาก ความหน่วงก็ยิ่งสะสม
แม้ในเครือข่ายภายในก็ยังใช้เวลา 1 วินาที และในสภาพแวดล้อม 4G ใช้มากกว่า 33 วินาที โครงสร้างการออกแบบเองก็ไม่มีประสิทธิภาพ
โครงสร้างแบบ REST ลักษณะนี้บนเครือข่ายมือถือจะมี latency จากการรับส่งไปกลับสูง จึงช้าเป็นธรรมดา
ฉันคิดว่าถึงเวลาใช้ WebSocket แทน REST แล้ว
การเพิ่มหรือแก้ไขนัดหมายไม่สะดวก และ UI ก็ดูเด็กลงด้วย ไม่มีเว็บปฏิทินโอเพนซอร์สที่ใช้งานได้ดีจริง ๆ
แนวทางแบบ Electric SQL น่าสนใจ
และข้อเสนอปรับปรุง JS อย่าง TC39 import proposal ก็อาจช่วยได้
ฉันเคยดูแล ซอฟต์ฟอร์ก ของ Nextcloud มาก่อน แต่โครงสร้างพื้นฐานมันซับซ้อนเกินไป
แค่ใส่แพตช์ปรับปรุงประสิทธิภาพไม่กี่ตัว ความเร็วในการเรนเดอร์ตัวจัดการไฟล์ก็เร็วขึ้นหลายเท่าแล้ว
แต่โค้ดเบสเป็น โครงสร้างแบบซ้อนเลเยอร์ทับกันไปเรื่อย ๆ จนไม่น่าไว้วางใจ
สุดท้ายฉันก็เลิกทำโปรเจกต์นี้ไป ความซับซ้อนแบบนี้ดูเหมือนจะเป็นปัจจัยที่ค้ำระบบนิเวศของผู้ให้บริการโฮสติ้งไว้
แต่ละฟีเจอร์เริ่มจากการเป็นปลั๊กอินอิสระ จึงไม่มีความเป็นเนื้อเดียวกัน
ตอนนี้มันกลายเป็นสัตว์ประหลาดตัวหนึ่งไปแล้ว และฉันคิดว่าน่าจะดีกว่าถ้าเอาเครื่องมือหลายตัวมา เชื่อมด้วย SSO
และจริง ๆ แล้วการดูแล Nextcloud ก็ไม่ได้ยากขนาดนั้น ตั้งค่าเสร็จครั้งเดียวแล้วการบำรุงรักษาก็ค่อนข้างง่าย
ฉันคิดว่าสาเหตุของความช้าไม่ใช่ ขนาด JS ตามที่บทความพูด แต่เป็น ลอจิกที่ไม่มีประสิทธิภาพ มากกว่า
ปัญหาคือมีการเรียก API มากเกินไปและมีการอัปเดต UI มากเกินไป
เมื่อก่อนแค่เกิน 200KB ก็ต้องตรวจเรื่อง optimization แล้ว แต่ Nextcloud มีถึง 15MB
ฉันใช้ Nextcloud สำรองรูปครอบครัวมา 7 ปีแล้ว
มันปกป้องความเป็นส่วนตัวได้ดีและค่อนข้างเสถียร แต่ ไม่แนะนำอย่างยิ่ง ถ้าจะใช้แทน Google Docs
การอัปโหลดไฟล์ใหญ่หรือการโหลด thumbnail ยังไม่เสถียรและช้า
ถึงอย่างนั้นก็ไม่มีตัวเลือกอื่น และฉันก็ไม่อยากฝากข้อมูลไว้กับ AI ของบริษัทใหญ่
อยากให้คนในครอบครัวใช้มันอย่างจริงจังมากกว่านี้
ฉันเคยใช้ self-hosted file manager มาหลายตัว
ไล่มาตั้งแต่ Ajaxplorer → Pydio → Nextcloud → FileRun และพอใจ FileRun มากที่สุด
มันเร็ว เสถียร และทำงานได้ดีบนเบราว์เซอร์มือถือด้วย
ตอนนี้เป็นแบบเสียเงินแล้ว แต่ก็คุ้มค่า
copyparty ก็เบาและเร็ว แต่ไม่ค่อยเป็นมิตรกับผู้ใช้ทั่วไป
ฉันคิดถึงฟีเจอร์ “file request” ของ FileRun
filebrowser GitHub
filebrowser-docker
ลิงก์เดโม
ฉันกำลังคิดจะใช้ร่วมกับ Syncthing แต่ก็กังวลเรื่องภาระ CPU
Nextcloud ช้าและใหญ่เทอะทะ แต่เสถียร
บริษัทขนาด 8 คนของเราใช้มาหลายปีโดยไม่มีปัญหา
เว็บแอปช้าจนแทบไม่ค่อยใช้ และใช้เดสก์ท็อปซิงก์ไคลเอนต์เป็นหลัก
ปลั๊กอินยืนยันตัวตนด้วย IMAP มีประโยชน์มาก ทำให้จัดการผู้ใช้ได้ง่าย
สามารถปรับแต่งได้อย่างอิสระด้วย uBlock, userstyle, userscript เป็นต้น
เมื่อก่อนฉันเคยพบ ช่องโหว่ในตัวดู PDF ของ Nextcloud แล้วรายงานไป
ปัญหาคือมันรวมตัวดู PDF แบบเก่าที่ทำด้วย JS ไว้ด้วย และตอนอายุ 16 ฉันได้เงิน $100
บทความในบล็อกของฉัน
divเหมือนกัน แต่สุดท้ายก็ต้องใช้ pdf.jsหลายคนไม่พอใจกับโปรเจกต์โอเพนซอร์ส แต่ มีน้อยคนที่ลงมือปรับปรุงเอง
ฉันรัก Nextcloud แม้มันจะช้า แต่ฉันเป็นเจ้าของข้อมูลของตัวเอง และเพราะเป็น โค้ด AGPL จึงแก้ไขเองได้ด้วย
ใช้งานฟรีได้ และยังเพิ่มส่วนขยายได้เหมือน “เลือกซื้อ”
ฉันใช้มานานกว่า 6 ปีโดยไม่มีปัญหาใหญ่ และอิสรภาพแบบนี้ยอดเยี่ยมจริง ๆ
มันไม่สมบูรณ์แบบ แต่ก็เป็นโปรเจกต์ที่น่าขอบคุณที่มีอยู่
ข้อดีของ Nextcloud คือ สามารถจัดการเครื่องมือทำงานร่วมกันทั้งหมดได้ในแพลตฟอร์มเดียว
ทั้งไฟล์ ปฏิทิน โน้ต ออฟฟิศ รูปภาพ Talk และประสบการณ์ที่รวมเป็นหนึ่งเดียว
แพ็กเกจ AIO ช่วยแก้ปัญหาเรื่องอัปเดตและเสถียรภาพไปได้มาก
แต่เพราะมันอยู่บน PHP ประสิทธิภาพจึงด้อยกว่า และ UI ก็น่าจะขัดเกลาให้เหมือน Synology DSM มากกว่านี้
ปัญหาคือ โครงสร้าง I/O ที่ไม่มีประสิทธิภาพ และการเรียก XHR จำนวนมาก
PHP เข้าถึงง่าย จึงเอื้อต่อการมีส่วนร่วมจากคอมมูนิตี้
เอกสารทางการ — แต่พึ่งพา Docker มากและมีข้อจำกัดด้านสภาพแวดล้อม