สรุป
SVGOMG: เฟรมเวิร์กหน้าเว็บที่ตอบสนองต่อผู้ใช้และสวยงามสำหรับ SVGO
สิ่งที่เราชอบ
SVGOMG สร้างขึ้นโดย Jake Archibald ของเราเอง และเป็นตัวอย่างที่เกือบสมบูรณ์แบบของเครื่องมือที่ตอบสนองและใช้งานได้อย่างเต็มรูปแบบซึ่งเขียนด้วยเทคโนโลยีเว็บ แพ็กเกจนี้ใช้ดีไซน์ Material Design ที่สวยสะดุดตา ServiceWorker ช่วยโหลดแอปได้อย่างรวดเร็วและพร้อมใช้งานแบบออฟไลน์ รวมถึงช่วยให้การเปลี่ยนผ่านบนอุปกรณ์เคลื่อนที่เป็นไปอย่างราบรื่น
การปรับปรุงที่เป็นไปได้
ข้อติเพียงอย่างเดียวที่เรามีคือ UX เริ่มต้นค่อนข้างสับสนเนื่องจากไม่มี UI หลัก นอกเหนือจากนี้ เยี่ยมไปเลย
ถามและตอบกับ Jake Archibald
เหตุผลที่ควรใช้เว็บ
ความขี้เกียจ สุดจะขี้เกียจ ฉันไม่ใช่ผู้เชี่ยวชาญในการพัฒนาแอปเนทีฟของ Windows, ไม่ใช่ผู้เชี่ยวชาญด้านแอปเนทีฟของ OSX และไม่ใช่ผู้เชี่ยวชาญในการสร้างแอปเนทีฟสำหรับ iOS, Android, Windows Phone หรือ Linux แต่ฉันทำเว็บได้ และชุดทักษะเดียวนี้ช่วยให้ฉันสร้างสิ่งต่างๆ ได้เพียงครั้งเดียวซึ่งใช้งานได้ในทุกแพลตฟอร์มเหล่านั้น
อะไรที่ใช้ได้ผลดีมากในระหว่างการพัฒนา
เราพึงพอใจกับประสิทธิภาพของแคมเปญมาก ฉันตรวจสอบว่าหน้าเว็บแสดงผลก่อน JS จะพร้อมใช้งาน อันที่จริงแล้ว หน้าเว็บแสดงผลครั้งแรกด้วย HTML เพียง 5 KB ที่มี CSS และ SVG บางส่วนที่ฝังอยู่ ระบบจะโหลดสคริปต์หลักและ CSS ทั้งหมดในเบื้องหลัง ซึ่งหมายความว่าเว็บไซต์จะโหลดใน 1.5 วินาทีแม้ใน 3G ที่มีแคชว่าง และส่วนใหญ่เป็น DNS และ SSL
หน้าจอเปิดนั้นเรียบง่ายมาก การทำในความละเอียด 5K จึงไม่ใช่เรื่องยาก เรารู้สึกไม่สบายใจอย่างยิ่งที่เว็บไซต์จํานวนมากรอ JS ในการแสดงผลครั้งแรก บางเว็บไซต์ยังกําหนดให้ JS ส่งคําขอเพิ่มเติมก่อนที่จะแสดงผล ซึ่งทำให้เวลาในการเรนเดอร์ของ 3G เพิ่มขึ้นเป็น 10 วินาที และในฐานะผู้ใช้อุปกรณ์เคลื่อนที่ เรารู้ว่าผู้ใช้จะไม่ทนกับเวลาในการเรนเดอร์ที่นานขนาดนั้น
JS หลักมีขนาด 15 KB แต่ไม่รวมส่วนที่แยกวิเคราะห์และบีบอัด SVG ซึ่งโหลดเป็นระยะการทำงานเพิ่มเติมในเบื้องหลัง ซึ่งถือเป็นวิธีที่ยอดเยี่ยมเนื่องจากชิ้นงานแบบอินเทอร์แอกทีฟจะแสดงผลอย่างรวดเร็ว และผู้ใช้จะไม่สังเกตเห็นการโหลดเพิ่มเติม หากผู้ใช้เลือก SVG ได้ก่อนที่สคริปต์จะพร้อมใช้งาน การโหลดสคริปต์นั้นจะเป็นส่วนหนึ่งของเวลาในการประมวลผล
เรายังใช้ ServiceWorker เพื่อให้ทั้งระบบทำงานแบบออฟไลน์ได้อีกด้วย การทำงานแบบออฟไลน์เป็นฟีเจอร์ที่เจ๋งมาก แต่ฉันใช้เพื่อประสิทธิภาพเป็นหลัก การเข้าชม SVGOMG ครั้งต่อๆ ไปจะแสดงผลเกือบจะในทันที ไม่ว่าผู้ใช้จะมีการเชื่อมต่อแบบใดก็ตาม ข้อมูลนี้มีประโยชน์อย่างยิ่งเมื่อพิจารณาถึงความหลากหลายของการเชื่อมต่ออุปกรณ์เคลื่อนที่
หากมี API ใดก็ได้ที่จะปรับปรุงแอปของคุณได้ คุณจะเลือก API ใด
ฉันใช้ Babel เพื่อให้ใช้ฟีเจอร์ JavaScript ในอนาคตได้ คงจะดีมากหากมีฟีเจอร์บางอย่างที่ทำงานในแพลตฟอร์มได้โดยตรง กล่าวโดยละเอียดคือ รูปแบบ async/await, ฟังก์ชันลูกศร, อาร์กิวเมนต์เริ่มต้น และการแยกโครงสร้าง
ฉันต้องใช้ไลบรารีเพื่อบีบอัดเอาต์พุตด้วย Gzip เพื่อดูขนาดที่บีบอัดแล้ว การใช้ไลบรารีสําหรับการดำเนินการนี้ค่อนข้างน่ารําคาญเนื่องจากโค้ดดังกล่าวอยู่ในเบราว์เซอร์สําหรับ HTTP อยู่แล้ว เพียงแต่ไม่มี API ตามหลักการแล้วควรเป็นสตรีมการเปลี่ยนรูปแบบประเภทใดประเภทหนึ่งเพื่อให้เรานับขนาดของเอาต์พุตได้โดยไม่ต้องเก็บข้อมูลทั้งหมดไว้ในหน่วยความจำ