การอ้างอิงจาวาสคริปต์ภายนอกกับการโฮสต์สำเนาของฉันเอง


42

บอกว่าฉันมีเว็บแอปที่ใช้ jQuery เป็นการดีกว่าถ้าจะโฮสต์ไฟล์ javascript ที่จำเป็นในเซิร์ฟเวอร์ของฉันพร้อมกับไฟล์เว็บไซต์ของฉันหรืออ้างอิงกับ CDN ของ jQuery (ตัวอย่าง: http://code.jquery.com/jquery-1.7.1.min.js ) ?

ฉันเห็นข้อดีทั้งสองด้าน:

  • ถ้าอยู่บนเซิร์ฟเวอร์ของฉันนั่นคือการพึ่งพาจากภายนอกน้อยกว่า ถ้า jQuery ลงหรือเปลี่ยนโครงสร้างการโฮสต์หรืออะไรทำนองนั้นแอพของฉันก็จะแตก แต่ฉันรู้สึกว่ามันจะไม่เกิดขึ้นบ่อยครั้ง ต้องมีไซต์เล็ก ๆ จำนวนมากในการดำเนินการนี้และทีม jQuery จะต้องการหลีกเลี่ยงการทำลายไซต์เหล่านั้น
  • ถ้าอยู่บนเซิร์ฟเวอร์ของฉันนั่นเป็นข้อมูลอ้างอิงภายนอกที่น้อยกว่าที่ใครบางคนสามารถเรียกได้ว่าเป็นปัญหาด้านความปลอดภัย
  • หากมีการอ้างอิงจากภายนอกฉันไม่ต้องกังวลเกี่ยวกับแบนด์วิดท์เพื่อให้บริการไฟล์ (แม้ว่าฉันรู้ว่ามันไม่มาก
  • หากมีการอ้างอิงจากภายนอกและฉันกำลังปรับใช้เว็บไซต์นี้ไปยังเซิร์ฟเวอร์จำนวนมากที่ต้องมีสำเนาของไฟล์ทั้งหมดของตัวเองแล้วมันเป็นไฟล์ที่น้อยกว่าที่ฉันต้องจำไว้เพื่อคัดลอก / อัปเดต

สองคะแนนแรกจะมีผลก็ต่อเมื่อคุณกังวลว่า Google จะลงหรือถูกแฮ็ค
user16764

1
@ user16764 - หรือคัดลอก jQuery ด้วยเหตุผลบางประการ (การเมืองใครจะรู้)
นายเจฟเฟอร์สัน

2
เหตุผลที่ไม่ให้เป็นความเป็นส่วนตัว การใช้เนื้อหาที่โฮสต์โดยบุคคลที่สามจะช่วยให้บุคคลที่สามสามารถติดตามผู้ใช้ที่พวกเขาไม่สามารถยกเลิกได้อย่างง่ายดาย
Ian Newson

บาง CDNs โฮสต์ google เป็นพิเศษบางครั้งก็มีแนวโน้มที่จะ จำกัด ไฟล์จากบางประเทศ
azerafati

คำตอบ:


58

คุณควรทำทั้งสองอย่าง:

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

จากนั้นเพิ่มการอ้างอิงทางเลือกไปยังเซิร์ฟเวอร์ของคุณเองในกรณีที่ CDN ไม่ทำงาน (ไม่น่าจะปลอดภัย แต่ปลอดภัย) ทางเลือกที่เข้าใจง่าย แต่ต้องปรับให้เหมาะสมกับสคริปต์ที่ใช้:

<script src="https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.18/jquery-ui.min.js"></script>
<script>
    if (!window.jQuery) document.write('<script src="/path/to/jquery-ver.sion.min.js"><\/script>');
</script>

ตรวจสอบให้แน่ใจว่าคุณไม่ได้เขียน</script>ที่ใดก็ได้ภายใน<script>องค์ประกอบเพราะจะเป็นการปิดองค์ประกอบ HTML และทำให้สคริปต์ล้มเหลว <\/script>การแก้ไขที่ง่ายคือการใช้เครื่องหมายเป็นหนี:


อีกหนึ่งเหตุผลที่ต้องทำทั้งสองอย่าง:

หากคุณเลือก CDN ยอดนิยมมันไม่น่าเป็นไปได้อย่างมากที่จะมีช่วงเวลาหยุดชะงักอย่างไรก็ตามในอนาคตอันไกล (ประมาณ 18 เดือนนับจากนี้ได้รับกฎหมายของมัวร์ ) เมื่อรูปแบบการโฮสต์เปลี่ยนแปลงหรือปรับที่อยู่หรือ เครือข่ายถูกวางไว้ด้านหลัง paywall หรืออย่างอื่นเป็นไปได้ว่าลิงก์ของคุณจะไม่ทำงานตามที่เป็นอยู่ หากคุณใช้ทางเลือกสำรองก็จะให้เวลาเล็กน้อยในการปรับรูปแบบใหม่สำหรับการโฮสต์ก่อนที่จะย้อนกลับไปทุกเว็บไซต์ที่คุณเคยสร้างขึ้นและเปลี่ยนลิงค์ CDN


เหตุผลอื่นที่ต้องทำทั้งสองอย่าง:

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


+1 ช่วยให้คุณได้รับประโยชน์จาก CDN และครอบคลุมถึงข้อผิดพลาดที่อาจเกิดขึ้นเช่นกัน
quentin-starin

5
uptime คืออะไร? หากเว็บไซต์ของเขาไม่ได้ขึ้นมี js ออนไลน์แทบจะไม่ได้รับประโยชน์ :)
บอริส Yankov

3
@BorisYankov หาก CDN หยุดทำงานและไซต์ของคุณหยุดทำงานและคุณไม่ได้ใช้ทางเลือกในท้องถิ่นเว็บไซต์ของคุณจะไม่ทำงาน นั่นคือความเกี่ยวข้องของสถานะการออนไลน์ หากไซต์ของคุณไม่ทำงานไซต์ของคุณจะไม่ทำงานและสำเนาในเครื่องจะไม่สำคัญ
zzzzBov

CDN จะมีเซิร์ฟเวอร์อยู่ทั่วทุกแห่งดังนั้นคุณจะได้รับทรัพยากรจากโหนดที่อยู่ใกล้ที่สุด
hanzolo

35

ฉันมีคำถามเดียวกันจากนั้นฉันอ่านบทความนี้และฉันขายให้กับ Google เพื่อให้โฮสต์ jQuery Library ของฉัน

บทความระบุถึงประโยชน์หลักของการให้ห้องสมุดของคุณโฮสต์โดยเครือข่ายการจัดส่งเนื้อหาของ Google (CDN):

  • ความล่าช้าที่ลดลง - ผู้ใช้ที่ไม่ได้อยู่ใกล้กับเซิร์ฟเวอร์ของคุณจะสามารถดาวน์โหลด jQuery ได้เร็วขึ้นจาก Google มากกว่าถ้าคุณบังคับให้พวกเขาดาวน์โหลดจากเซิร์ฟเวอร์ที่อยู่ของคุณ
  • เพิ่มความเท่าเทียม - เบราว์เซอร์ จำกัด จำนวนการเชื่อมต่อที่สามารถทำได้พร้อมกัน ขีด จำกัด นี้อาจต่ำเพียงสองการเชื่อมต่อต่อชื่อโฮสต์ทั้งนี้ขึ้นอยู่กับเบราว์เซอร์ใด การใช้ Google AJAX Libraries CDN กำจัดหนึ่งคำขอไปยังไซต์ของคุณทำให้สามารถดาวน์โหลดเนื้อหาในเครื่องของคุณได้มากขึ้นในแบบคู่ขนาน
  • Better Caching - การใช้ไลบรารี Google AJAX ผู้ใช้ของคุณอาจไม่จำเป็นต้องดาวน์โหลด jQuery เลย ในทางตรงกันข้ามหากคุณโฮสต์ jQuery ในพื้นที่ผู้ใช้ของคุณต้องดาวน์โหลดอย่างน้อยหนึ่งครั้ง ผู้ใช้ของคุณแต่ละคนอาจมีสำเนา jQuery ที่เหมือนกันหลายสิบสำเนาในแคชของเบราว์เซอร์ แต่สำเนา jQuery เหล่านั้นจะถูกละเว้นเมื่อพวกเขาเข้าชมไซต์ของคุณ

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


4
อาฉันแน่ใจว่าฉันสามารถทำงานคงที่ได้ดีกว่าสินทรัพย์คงที่มากกว่า google ;)
Xeoncross

การไม่ใช้ทั้งสอง (CDN + local fallback) เป็นเรื่องเหลวไหล ความอับอายนี่คือคำตอบที่ดีที่สุด
quentin-starin

@qes ยุติธรรมมากฉันได้เพิ่มประโยคใหม่เมื่อสิ้นสุดคำตอบ
CFL_Jeff

17

โดยส่วนตัวแล้วฉันใช้คิวจากhttp://html5boilerplate.com/

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js"></script>
<script>!window.jQuery && document.write(unescape('%3Cscript src="includes/js/libs/jquery-1.6.1.min.js"%3E%3C/script%3E'))</script>

สิ่งนี้จะดึงไฟล์ jQuery หลักจาก Google แต่ถ้ามันไม่โหลดด้วยเหตุผลบางอย่างบรรทัดถัดไปจะโหลดจากเซิร์ฟเวอร์ของคุณเอง


5
สิ่งนี้มีประโยชน์เพิ่มเติมในการช่วยให้คุณพัฒนาออฟไลน์
RSG

การใช้ URL ที่สัมพันธ์กับโพรโทคอลนั้นไม่มีประโยชน์อีกต่อไปเหมือนเดิม (ดูpaulirish.com/2010/the-protocol-relative-url ) https://ก็สมควรที่นี่เพื่อเพียงชนิด
GKFX

5

เป็นวิธีปฏิบัติที่ดีกว่าในการใช้ CDN และหาก CDN นั้นเกิดขึ้นกับ Google สิ่งที่ดีกว่า - เนื่องจากทั้ง @CFL_Jeff และ @Morons ได้จดบันทึกไว้

ผมเพิ่มคำตอบนี้จะชี้ให้เห็นบางสิ่งบางอย่างที่มักจะไปมองข้ามเมื่อชี้อื่น ๆ ซึ่งเป็นที่หลีกเลี่ยงคำเตือนเนื้อหาผสม ลองใช้ URL ที่ไม่ใช้โปรโตคอลเช่น:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.js" type="text/javascript">
</script>

ยังมีปัญหาบางอย่างในการสนับสนุนการใช้ URL ที่ไม่ใช้โปรโตคอลดังนั้นควรดูที่คำตอบในฉันสามารถเปลี่ยน http: // ลิงก์ทั้งหมดของฉันเป็นเพียง // ได้หรือไม่ บน SO แต่อย่างน้อยพยายามจัดการกับคำเตือนเนื้อหาผสมที่อาจเกิดขึ้นในบางวิธี


4

คุณควรจะอ้างอิงไปยังห้องสมุดของ Google APIs ..

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


0

ฉันอาจผิด แต่การใช้ document.write เขียนทับสิ่งที่ DOM มี เนื่องจากเป็นแนวปฏิบัติที่ดีที่จะวางไฟล์ JavaScript ไว้ที่ส่วนท้ายของเนื้อหา

ฉันเสนอวิธีการต่อไปนี้ตามคำตอบก่อนหน้า:

<script type="text/javascript" src="//ajax.googleapis.com/ajax/libs/jquery/2.1.3/jquery.min.js"></script>
<script type="text/javascript">

if(!window.jQuery)
{
    //Creates the script element
    var script = document.createElement('script'); 
    //Adds the type attribute with "text/javascript" value
        script.setAttribute('type', 'text/javascript'); 
    //Adds the source attribute and populates it
        script.setAttribute('src', 'Put_The_Relative_Path_To_Your_JavaScript_File_Here'); 
    //Adds it to the end of the body, as it is good practice, to prevent render-blocking.  
    document.body.appendChild(script);

}

//Note that there's no need for you to verify with an onload function, since all scripts
//must be loaded before going to the next one! 

</script>

0

ฉันต้องการเพิ่มว่าการโฮสต์สำเนาในเครื่องเป็นวิธีปฏิบัติที่ดีที่สุดเนื่องจากไม่มีสิ่งใดเกี่ยวข้องกับท่าที่ปลอดภัยโดยที่ที่ตั้งทางภูมิศาสตร์และการลงบัญชีรายชื่อที่เข้มงวดมีความจำเป็น ไม่ใช่การโฮสต์ไฟล์นั้นไว้ในเครื่องเพื่อกดการรักษาความปลอดภัยที่ลดลงไปยังไคลเอนต์ของคุณ


นโยบายความปลอดภัยที่บัญชีดำหรือ จำกัด CDN ของ Google of jQuery กำลังจะทำลายเว็บไซต์จำนวนมากไม่เพียง แต่ของผู้ถาม กล่าวอีกนัยหนึ่งมีปัญหาที่ใหญ่กว่าที่ต้องกังวล

2
@Snowman ... เช่น Great Firewall ในประเทศจีน (ซึ่งแบ่งไซต์ Exchange Exchange ที่ใช้ CDN เป็นประจำในสคริปต์)
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.