Generic First CSS: คิดใหม่บนมือถือก่อน

ฉันคิดว่ามันปลอดภัยที่จะพูดว่า Responsive Web Design ของ Ethan Marcotte เป็นการเปิดเผยที่น่ายินดีสำหรับนักพัฒนาเว็บทั่วโลก มันก่อให้เกิดคลื่นลูกใหม่ของการคิดเชิงออกแบบและเทคนิคส่วนหน้าใหม่ที่ยอดเยี่ยม รัชสมัยของเว็บไซต์ m dot ที่มักถูกดูหมิ่นก็สิ้นสุดลงเช่นกัน ในยุคเดียวกันและเกือบจะมีอิทธิพลเท่ากับวิธีการ Mobile First ของ Luke Wroblewski ซึ่งเป็นการปรับปรุงที่มั่นคงซึ่งสร้างขึ้นจากรากฐานที่น่าประทับใจของ Marcotte

เทคนิคเหล่านี้เป็นรากฐานที่สำคัญของนักพัฒนาเว็บส่วนใหญ่ และพวกเขาได้ให้บริการเราเป็นอย่างดี แต่อนิจจา เวลาเปลี่ยนไป และนักพัฒนาก็ทำซ้ำอย่างต่อเนื่อง เมื่อเราเพิ่มประสิทธิภาพของวิธีการของเราและความต้องการของโครงการมีความซับซ้อนมากขึ้น ความผิดหวังใหม่ๆ ก็เกิดขึ้น

การเดินทางสู่คนทั่วไปก่อน

ฉันไม่สามารถระบุได้อย่างชัดเจนว่าอะไรทำให้ฉันเปลี่ยนวิธีที่ฉันเขียน CSS ของฉัน เพราะมันเป็นความก้าวหน้าตามธรรมชาติสำหรับฉันที่เกิดขึ้นเกือบโดยไม่รู้ตัว เมื่อมองย้อนกลับไป ฉันคิดว่าเป็นผลพลอยได้จากสภาพแวดล้อมการพัฒนาที่ฉันทำงานอยู่ ทีมงานที่ฉันทำงานด้วยมีเวิร์กโฟลว์ SCSS ที่ดีเกิดขึ้นด้วยมิกซ์อินเล็กๆ น้อยๆ ที่ดีเพื่อเพิ่มจุดสั่งหยุดภายในการประกาศ CSS ของเรา คุณอาจใช้เทคนิคที่คล้ายกัน

มิกซ์อิน SCSS เล็ก ๆ ที่ยอดเยี่ยมนี้ทำให้ง่ายต่อการเขียนข้อความค้นหาสื่อที่ละเอียดมาก ใช้บล็อกชีวประวัติสมมุติที่มีลักษณะดังนี้:

 .bio { display: block; width: 100%; background-color: #ece9e9; padding: 20px; margin: 20px 0; @include media('>=small') { max-width: 400px; background-color: white; margin: 20px auto; } @include media('>=medium') { max-width: 600px; padding: 30px; margin: 30px auto; } @include media('>=large') { max-width: 800px; padding: 40px; margin: 40px auto; } @include media('>=huge') { max-width: 1000px; padding: 50px; margin: 50px auto; } }

รูปที่ 1 มือถือทั่วไปก่อนด้วยการสืบค้นสื่อแบบเรียงซ้อน

ใช้งานได้ดี — ฉันเคยเขียน CSS แบบ นี้มาหลายครั้งแล้ว อย่างไรก็ตาม อยู่มาวันหนึ่งฉันนึกขึ้นได้ว่าการเขียนทับการประกาศ CSS เนื่องจากความกว้างของอุปกรณ์เพิ่มขึ้นนั้นไม่สมเหตุสมผล เหตุใดจึงประกาศคุณสมบัติ CSS เพื่อให้ถูกเขียนทับในการประกาศต่อไปนี้เท่านั้น

นี่คือสิ่งที่ทำให้ฉันเริ่มเขียน ข้อความค้นหาสื่อแบบแบ่งส่วน ตรงข้ามกับวิธีการค้นหาสื่อทั่วไปที่เรียงต่อกันขึ้น (หรือลง) ดังตัวอย่างในรูปที่ 1

แทนที่จะเขียนคิวรี่สื่อที่เรียงตามขนาดหน้าจอที่เพิ่มขึ้น ฉันเริ่มสร้างคิวรีสื่อเป้าหมายที่จะสรุปรูปแบบตามความกว้างของหน้าจอที่ต้องการ มิกซ์อินคิวรี่สื่อจะเป็นตัวของมันเองที่นี่ ตอนนี้ข้อความค้นหาสื่อ SCSS ของฉันเริ่มมีลักษณะดังนี้:

 .bio { display: block; width: 100%; padding: 20px; margin: 20px 0; @include media('>=small', ' < medium') { max-width: 400px; margin: 20px auto; } @include media('>=medium', ' < large') { max-width: 600px; padding: 30px; margin: 30px auto; } @include media('>=large', ' < huge') { max-width: 800px; padding: 40px; margin: 40px auto; } @include media('>=huge') { max-width: 1000px; padding: 50px; margin: 50px auto; } }

รูปที่ 2 ตัวอย่างของการสืบค้นสื่อแบบแบ่งส่วน

วิธีการใหม่นี้ทำให้ฉันรู้สึกเข้าใจง่ายขึ้น ช่วยลดความจำเป็นในการรีเซ็ตสไตล์จากเบรกพอยต์ก่อนหน้า และทำให้ CSS อ่านง่ายขึ้น ที่สำคัญกว่านั้นคือทำให้การสืบค้นสื่อจัดทำเอกสารด้วยตนเองอย่างมีนัยสำคัญยิ่งขึ้น

ฉันยังคงไม่พอใจ 100% กับสิ่งที่กล่าวมาข้างต้น ดูเหมือนว่าจะยังมีปัญหาใหญ่ที่ต้องเอาชนะ

ปัญหากับมือถือก่อน

ปัญหาของมือถือต้องมาก่อนคือตามคำจำกัดความแล้ว คุณมักจะต้องแทนที่สไตล์ที่เน้นมือถือเป็นหลักในการสืบค้นสื่อที่ตามมา นี้รู้สึกเหมือนบิตของรูปแบบการต่อต้าน

ดังนั้น — สำหรับฉัน — คำตอบนั้นชัดเจน: ลองนำแนวคิดของการแบ่งส่วนข้อความค้นหาสื่อไปเป็นข้อสรุปเชิงตรรกะ — เราจะแบ่งรูปแบบเฉพาะสำหรับอุปกรณ์พกพาออกเป็นข้อความค้นหาสื่อของตนเองด้วย ฉันรู้ ฉันรู้ สิ่งนี้ขัดกับธรรมเนียมปฏิบัติทั่วไปที่เราได้เรียนรู้ตลอดหลายปีที่ผ่านมา “Mobile First” เป็นที่แพร่หลายมากจนเป็นหนึ่งในคำถาม “ทักษะ” ที่ผู้จัดการฝ่ายว่าจ้างจะถาม แน่นอนว่าทางเลือกอื่นต้องผิด จริงไหม? ซึ่งมักจะเป็นส่วนที่ผู้คนส่ายหัวมาที่ฉันในขณะที่พูด มือถือก่อนครั้ง แล้วครั้งเล่า

ตกลง เราจะเจาะลึกความเชื่อแรกสำหรับอุปกรณ์พกพา และแบ่งรูปแบบทั้งหมดของเราออกเป็นข้อความค้นหาสื่อที่เกี่ยวข้อง สิ่งที่เราเหลือในตอนนี้คือสไตล์ทั่วไปล้วนๆ ที่ประกาศในตัวเลือก CSS โดยที่สไตล์เฉพาะของอุปกรณ์อื่นๆ ทั้งหมดถูกห่อหุ้มไว้ในคิวรีสื่อที่ใช้กับขนาดหน้าจอที่เกี่ยวข้องเท่านั้น ตอนนี้เรามี Generic First CSS :

 .bio { display: block; width: 100%; @include media('>=0', ' < small') { padding: 20px; margin: 20px 0; } @include media('>=small', ' < medium') { max-width: 400px; margin: 20px auto; } @include media('>=medium', ' < large') { max-width: 600px; padding: 30px; margin: 30px auto; } @include media('>=large', ' < huge') { max-width: 800px; padding: 40px; margin: 40px auto; } @include media('>=huge') { max-width: 1000px; padding: 50px; margin: 50px auto; } }

รูปที่ 3 ตัวอย่างของ Generic First CSS

ใช่ มีการสืบค้นข้อมูลสื่อเพิ่มขึ้นเล็กน้อย อย่างไรก็ตาม ฉันเห็นว่าสิ่งนี้เป็นประโยชน์ ตอนนี้นักพัฒนาทุกคนสามารถดู CSS นี้ และดูว่ามีการใช้สไตล์ใดบ้างกับหน้าจอแต่ละขนาดและทุกขนาดโดยไม่ต้องเสียค่าใช้จ่ายในการแยกแยะสื่อ ความจำเพาะของแบบสอบถาม

นี่อาจเป็นสิ่งที่ดีสำหรับผู้ที่ไม่คุ้นเคยกับฐานรหัสหรือแม้แต่อนาคตของคุณ!

เมื่อไม่แบ่งแยก

ยังมีบางครั้งที่การแบ่งส่วนแบบสอบถามสื่อเป็นภาระ และในบางกรณี แบบสอบถามสื่อ >= แบบเก่าก็ใช้ได้ จำไว้ว่าสิ่งที่เราพยายามทำคือหลีกเลี่ยงการเขียนทับคุณสมบัติ

Dev Tool Bliss

ผลที่ตามมาโดยไม่ได้ตั้งใจที่สำคัญอย่างหนึ่งของการเขียน Generic First CSS แบบแบ่งส่วนคือประสบการณ์ที่คุณจะได้รับจากแผงสไตล์เครื่องมือสำหรับนักพัฒนาของคุณ หากไม่มีคาสเคดคิวรีสื่อ คุณจะมีภาพรวมที่ชัดเจนขึ้นว่าสไตล์ใดถูกนำไปใช้ — คุณจะไม่มีแผงสไตล์ที่เต็มไปด้วยการประกาศที่ขีดทับจากกฎการสืบค้นสื่อที่เขียนทับ — เสียงรบกวนหายไป! นี่ — สำหรับฉัน — เป็นหนึ่งในประโยชน์ที่ใหญ่ที่สุดของเทคนิค Generic First CSS มันนำความรู้พิเศษเล็กน้อยมาสู่ประสบการณ์การดีบัก CSS และสิ่งนี้ก็คุ้มค่ากับน้ำหนักของมันในทองคำ ขอบคุณฉันในภายหลัง.

ผลกระทบด้านประสิทธิภาพ

ดังนั้นผลประโยชน์ Generic First CSS ทั้งหมดเหล่านี้จึงเริ่มฟังดูค่อนข้างดี แต่ฉันคิดว่ามีคำถามสำคัญข้อสุดท้ายที่ฉันคิดว่าจำเป็นต้องได้รับการแก้ไข เป็นเรื่องของการเพิ่มประสิทธิภาพการทำงาน ตอนนี้ฉันยังไม่รู้แน่ชัด แต่ฉันมีความเฉลียวฉลาดว่าการสืบค้นสื่อแบบแบ่งส่วนอย่างสมบูรณ์อาจมีประโยชน์ด้านประสิทธิภาพเล็กน้อย

เบราว์เซอร์ทำงานการแสดงผลที่เรียกว่าการ คำนวณรูปแบบการคำนวณ เป็นวิธีการคำนวณของเบราว์เซอร์ที่ต้องใช้กับองค์ประกอบในช่วงเวลาที่กำหนด งานนี้ดำเนินการเสมอในการโหลดหน้าเริ่มต้น แต่ยังสามารถดำเนินการได้หากเนื้อหาของหน้ามีการเปลี่ยนแปลงหรือหากมีการกระทำอื่น ๆ ของเบราว์เซอร์เกิดขึ้น การเพิ่มความเร็วของกระบวนการใดๆ ก็ตามที่คุณเพิ่มได้จะเป็นการดีสำหรับการโหลดหน้าแรก และอาจส่งผลต่อวงจรชีวิตของหน้าเว็บไซต์ของคุณ

กลับไปที่ CSS แรกทั่วไป: มีปัญหาด้านประสิทธิภาพใด ๆ ที่เกี่ยวข้องกับเบราว์เซอร์ที่ต้องค้นหาความจำเพาะของ CSS ของการสืบค้นสื่อแบบเรียงซ้อนจำนวนมากหรือไม่?

เพื่อตอบคำถามนั้น ฉันได้คิดค้นกรณีทดสอบที่สามารถใช้เพื่อวัดข้อดีด้านความเร็วหรือจุดอ่อนอย่างแท้จริง

กรณีทดสอบ

กรณีทดสอบประกอบด้วยหน้า HTML พื้นฐานที่ส่งออกบล็อก "ชีวภาพ" 5,000 ครั้ง มาร์กอัปเหมือนกันสำหรับแต่ละบล็อก แต่คลาสแตกต่างกันเล็กน้อย (ตัวสร้างความแตกต่างของตัวเลข) CSS สำหรับบล็อกนี้จะถูกส่งออก 5,000 ครั้งด้วย โดยมีชื่อคลาสเป็นสิ่งเดียวที่จะแตกต่าง CSS ที่ส่งออกไปนั้นถูกส่งผ่านเครื่องมือที่เรียกว่า CSS MQPacker ซึ่งช่วยลดขนาดไฟล์ของ CSS ที่ใช้คิวรีสื่อแบบอินไลน์จำนวนมากโดยการรวมอินสแตนซ์ที่แยกจากกันของคิวรีสื่อเฉพาะเข้าไว้ด้วยกัน — เป็นเครื่องมือที่ยอดเยี่ยมที่อาจเป็นประโยชน์ โค้ดเบส CSS ที่ทันสมัยที่สุด — ฉันใช้มันเป็นเครื่องมือ cli แบบสแตนด์อโลนผ่านงาน npm ในโครงการทดสอบ package.json คุณยังสามารถใช้เป็นปลั๊กอิน postcss ซึ่งดีและสะดวก!

กรณีทดสอบแรกคือตัวอย่างการสืบค้นสื่อแบบเรียงซ้อนอันดับแรกสำหรับมือถือ กรณีทดสอบที่สองคือ CSS แบบแบ่งส่วนแรกทั่วไป CSS สำหรับกรณีเหล่านี้ค่อนข้างละเอียดและอาจเขียนได้กระชับกว่ามาก แต่จริงๆ แล้วเป็นเพียงตัวอย่างคร่าวๆ ในการทดสอบอาร์กิวเมนต์

การทดสอบดำเนินการ 20 ครั้งสำหรับรูปแบบ CSS แต่ละรายการในเดสก์ท็อป Google Chrome v70 ไม่ใช่ชุดข้อมูลขนาดใหญ่ แต่เพียงพอที่จะให้แนวคิดคร่าวๆ เกี่ยวกับประสิทธิภาพที่เพิ่มขึ้น/ลดลง

เมตริกการทดสอบที่ฉันเลือกใช้คือ:

• เวลาในการโหลดหน้าโดยรวม
  ตัวชี้วัดพื้นฐานเพื่อตรวจสอบเวลาในการโหลดหน้าเว็บโดยใช้ตัวทำเครื่องหมาย Performance API ที่จุดเริ่มต้นของ <head> และส่วนท้ายสุดของ <body>
• สไตล์การคำนวณใหม่
  เวลาจากภายในบานหน้าต่างประสิทธิภาพของเครื่องมือ dev
• การแสดงผลหน้าโดยรวม
  เวลาจากภายในบานหน้าต่างประสิทธิภาพของเครื่องมือ dev

ตารางผลลัพธ์ (เวลาทั้งหมดเป็นมิลลิวินาที)

รูปที่ 6 การทดสอบ 20 ครั้งเพื่อวัดการโหลด/การเรนเดอร์ของคีย์ของ CSS มือถือก่อนเทียบกับ CSS ทั่วไปก่อน

จากชุดข้อมูลขนาดเล็กที่ยอมรับได้ของฉัน ดูเหมือนว่าความสงสัยในขั้นต้นของฉันอาจถูกต้อง โดยเฉลี่ยแล้ว ฉันเห็นว่างานคำนวณรูปแบบใหม่ใช้เวลาน้อยลง 42ms ซึ่งเพิ่มความเร็ว 7.6% ดังนั้นเวลาในการแสดงผลโดยรวมจึงลดลงด้วย ความแตกต่างไม่ได้เหลือเชื่อ แต่เป็นการปรับปรุง ฉันไม่คิดว่าชุดข้อมูลมีขนาดใหญ่พอที่จะสรุปผลได้ 100% และกรณีทดสอบไม่สมจริงเล็กน้อย แต่ฉันดีใจมากที่ไม่เห็นประสิทธิภาพการทำงานลดลง

ฉันสนใจมากที่จะได้เห็นวิธีการแรกทั่วไปที่ใช้กับ codebase ที่มีอยู่ในโลกแห่งความเป็นจริงซึ่งถูกเขียนขึ้นในลักษณะที่มือถือเป็นอันดับแรก — ตัวชี้วัดก่อนหลังจะมีความสมจริงมากขึ้นในการปฏิบัติในชีวิตประจำวัน

และหากใครมีข้อเสนอแนะเกี่ยวกับวิธีทำให้การทดสอบนี้เป็นแบบอัตโนมัติสำหรับการทำซ้ำในวงกว้าง โปรดแจ้งให้เราทราบในความคิดเห็น! ฉันคิดว่าต้องมีเครื่องมือที่สามารถทำได้

บทสรุป

เพื่อสรุปเกี่ยวกับประโยชน์ของวิธีการพัฒนาใหม่นี้...

• CSS ที่ทำตรงตามที่ตั้งใจไว้ ไม่มีการคาดเดาครั้งที่สอง
• แบบสอบถามสื่อการทำเอกสารด้วยตนเอง
• ประสบการณ์เครื่องมือสำหรับนักพัฒนาที่ดีขึ้น
• หน้าที่แสดงผลเร็วขึ้น

ฉันอยากจะคิดว่าฉันไม่ใช่คนเดียวที่สนับสนุนการเขียน CSS ในรูปแบบนี้ หากคุณได้นำแนวคิดแรกทั่วไปมาใช้แล้ว ไชโย! แต่ถ้าไม่ใช่ ฉันคิดว่าคุณจะชอบผลประโยชน์ที่ได้รับจริงๆ โดยส่วนตัวแล้วฉันได้รับประโยชน์อย่างมากจากประสบการณ์เครื่องมือ dev ที่ไม่กระจัดกระจาย ซึ่งในตัวมันเองจะเป็นประโยชน์อย่างมากต่อผู้พัฒนาจำนวนมาก ลักษณะการทำเอกสารด้วยตนเองของวิธีการเขียนข้อความค้นหาสื่อของคุณจะมีประโยชน์ต่อตัวคุณเองและทีมงานในวงกว้างด้วย (ถ้าคุณมี) และสุดท้าย ประโยชน์เหล่านี้จะไม่ทำให้คุณเสียค่าใช้จ่ายใดๆ ในแง่ของประสิทธิภาพ และที่จริงแล้วได้แสดงให้เห็นแล้วว่าความเร็วเพิ่มขึ้นเล็กน้อย!

คำสุดท้าย

เช่นเดียวกับวิธีการพัฒนาทั้งหมด มันอาจจะไม่ใช่สำหรับทุกคน แต่ฉันเข้าสู่ Generic First CSS อย่างเป็นธรรมชาติ ตอนนี้ฉันเห็นว่ามันเป็นวิธีการทำงานที่มีคุณค่า ซึ่งให้ประโยชน์ทั้งหมดกับอุปกรณ์พกพาก่อนด้วยการเพิ่มสิ่งใหม่ๆ ในเชิงบวกที่ทำให้ งานที่ยากลำบากของการพัฒนา front-end ที่ง่ายกว่าเล็กน้อย

ทรัพยากร

กรณีทดสอบ Repo

หากคุณต้องการที่จะจุดไฟให้กับกรณีทดสอบและทดลองใช้เอง คุณสามารถค้นหาได้ใน GitHub ฉันชอบที่จะเห็นรายงานบางส่วนจากผู้อื่น

เครื่องมือ

• CSS MQPacker
• รวมสื่อ