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