સ્વ-હોસ્ટિંગ તૃતીય-પક્ષ સંસાધનો: સારા, ખરાબ, નીચ

તાજેતરના વર્ષોમાં, ફ્રન્ટ-એન્ડ પ્રોજેક્ટ્સને ઑપ્ટિમાઇઝ કરવા માટે વધુ અને વધુ પ્લેટફોર્મ સ્વ-હોસ્ટિંગ અથવા તૃતીય-પક્ષ સંસાધનોને પ્રોક્સી કરવાની તકો પ્રદાન કરે છે. અકામાઈ તમને સેટ કરવાની પરવાનગી આપે છે ચોક્કસ પરિમાણો સ્વ-નિર્મિત URL માટે. Cloudflare એજ વર્કર્સ ટેકનોલોજી ધરાવે છે. Fasterzine કરી શકો છો ફરીથી લખો પૃષ્ઠો પરના URL જેથી તેઓ સાઇટના મુખ્ય ડોમેન પર સ્થિત તૃતીય-પક્ષ સંસાધનો તરફ નિર્દેશ કરે.

જો તમે જાણો છો કે તમારા પ્રોજેક્ટમાં ઉપયોગમાં લેવાતી તૃતીય-પક્ષ સેવાઓ ઘણી વાર બદલાતી નથી, અને તેમને ક્લાયન્ટ સુધી પહોંચાડવાની પ્રક્રિયામાં સુધારો થઈ શકે છે, તો તમે કદાચ આવી સેવાઓને પ્રોક્સી કરવાનું વિચારી રહ્યા છો. આ અભિગમ સાથે, તમે આ સંસાધનોને ખૂબ જ સારી રીતે તમારા વપરાશકર્તાઓની નજીક લાવી શકો છો અને ક્લાયંટ બાજુ પર તેમના કેશિંગ પર વધુ સંપૂર્ણ નિયંત્રણ મેળવી શકો છો. આ, વધુમાં, તમને તૃતીય-પક્ષ સેવાના "ક્રેશ" અથવા તેના પ્રદર્શનના અધોગતિને કારણે થતી મુશ્કેલીઓથી વપરાશકર્તાઓને બચાવવા માટે પરવાનગી આપે છે.

સારું: સુધારેલ પ્રદર્શન

કોઈ બીજાના સંસાધનોને સ્વ-હોસ્ટ કરવું એ ખૂબ જ સ્પષ્ટ રીતે પ્રદર્શન સુધારે છે. બ્રાઉઝરને ફરીથી DNS ઍક્સેસ કરવાની જરૂર નથી, તેને TCP કનેક્શન સ્થાપિત કરવાની અને તૃતીય-પક્ષ ડોમેન પર TLS હેન્ડશેક કરવાની જરૂર નથી. તમે નીચેના બે આંકડાઓની તુલના કરીને જોઈ શકો છો કે કોઈ બીજાના સંસાધનોને સ્વ-હોસ્ટિંગ કેવી રીતે પ્રભાવને અસર કરે છે.

તૃતીય પક્ષ સંસાધનો બાહ્ય સ્ત્રોતોમાંથી ડાઉનલોડ કરવામાં આવે છે (માંથી લેવામાં આવે છે અહીંથી)

તૃતીય-પક્ષ સંસાધનો એ જ જગ્યાએ સંગ્રહિત થાય છે જેમ કે સાઇટની બાકીની સામગ્રી (માંથી લેવામાં આવે છે અહીંથી)

પરિસ્થિતિ એ હકીકત દ્વારા પણ સુધરી છે કે બ્રાઉઝર મલ્ટીપ્લેક્સ કરવાની ક્ષમતાનો ઉપયોગ કરશે અને HTTP/2 કનેક્શનમાંથી ડેટાને પ્રાથમિકતા આપશે જે પહેલાથી જ મુખ્ય ડોમેન સાથે સ્થાપિત થયેલ છે.

જો તમે તૃતીય-પક્ષ સંસાધનોને હોસ્ટ કરતા નથી, તો પછી તેઓ મુખ્ય કરતા અલગ ડોમેનમાંથી લોડ કરવામાં આવશે, તેથી તેમને પ્રાથમિકતા આપી શકાતી નથી. આનાથી તેઓ ક્લાયન્ટની બેન્ડવિડ્થ માટે એકબીજા સાથે સ્પર્ધા કરશે. આના પરિણામે પૃષ્ઠ બનાવવા માટે મહત્વપૂર્ણ સામગ્રી માટે લોડિંગ સમયમાં પરિણમી શકે છે જે આદર્શ સંજોગોમાં પ્રાપ્ત કરી શકાય તે કરતાં ઘણું લાંબુ છે. અહીં HTTP/2 પ્રાથમિકતા પર વાત કરો જે આ બધું ખૂબ સારી રીતે સમજાવે છે.

એવું માની શકાય છે કે બાહ્ય સંસાધનોની લિંક્સમાં વિશેષતાઓનો ઉપયોગ preconnect સમસ્યા હલ કરવામાં મદદ કરશે. જો કે, જો વિવિધ ડોમેન્સ પર આમાંની ઘણી બધી લિંક્સ હોય, તો તે ખરેખર સૌથી નિર્ણાયક ક્ષણે સંચાર લાઇનને ઓવરલોડ કરી શકે છે.

જો તમે તૃતીય-પક્ષ સંસાધનોને જાતે હોસ્ટ કરો છો, તો તમે ક્લાયંટને આ સંસાધનો બરાબર કેવી રીતે આપવામાં આવે છે તે નિયંત્રિત કરી શકો છો. એટલે કે, અમે નીચેના વિશે વાત કરી રહ્યા છીએ:

• તમે સુનિશ્ચિત કરી શકો છો કે ડેટા કમ્પ્રેશન એલ્ગોરિધમ કે જે દરેક બ્રાઉઝરને શ્રેષ્ઠ અનુરૂપ છે તેનો ઉપયોગ કરવામાં આવે છે (બ્રોટલી/જીઝીપ).
• તમે એવા સંસાધનો માટે કેશીંગ સમય વધારી શકો છો જે સામાન્ય રીતે ખાસ કરીને લાંબા ન હોય, સૌથી વધુ જાણીતા પ્રદાતાઓ સાથે પણ (ઉદાહરણ તરીકે, GA ટેગ માટે અનુરૂપ મૂલ્ય 30 મિનિટ પર સેટ કરેલ છે).

તમે સંસાધન માટે TTL ને તમારી કેશીંગ મેનેજમેન્ટ વ્યૂહરચના (URL હેશ, વર્ઝનીંગ, વગેરે) માં સંબંધિત સામગ્રીનો સમાવેશ કરીને એક વર્ષ સુધી વધારી શકો છો. અમે નીચે આ વિશે વાત કરીશું.

▍તૃતીય-પક્ષ સેવાઓ અથવા તેમના શટડાઉનના સંચાલનમાં વિક્ષેપો સામે રક્ષણ

સ્વ-હોસ્ટિંગ તૃતીય-પક્ષ સંસાધનોનું બીજું રસપ્રદ પાસું એ છે કે તે તમને તૃતીય-પક્ષ સેવાઓના આઉટેજ સાથે સંકળાયેલા જોખમોને ઘટાડવાની મંજૂરી આપે છે. ચાલો ધારીએ કે તમે ઉપયોગ કરી રહ્યાં છો તે તૃતીય-પક્ષ A/B પરીક્ષણ સોલ્યુશનને બ્લોકિંગ સ્ક્રિપ્ટ તરીકે લાગુ કરવામાં આવ્યું છે જે પૃષ્ઠના મુખ્ય વિભાગમાં લોડ થાય છે. આ સ્ક્રિપ્ટ ધીમે ધીમે લોડ થાય છે. જો સંબંધિત સ્ક્રિપ્ટ લોડ કરવામાં નિષ્ફળ જાય, તો પૃષ્ઠ ખાલી રહેશે. જો તે લોડ થવામાં ઘણો લાંબો સમય લે છે, તો પૃષ્ઠ લાંબા વિલંબ સાથે દેખાશે. અથવા, ધારો કે પ્રોજેક્ટ તૃતીય-પક્ષ CDN સંસાધનમાંથી ડાઉનલોડ કરેલી લાઇબ્રેરીનો ઉપયોગ કરે છે. ચાલો કલ્પના કરીએ કે આ સંસાધન નિષ્ફળ થયું છે અથવા કોઈ ચોક્કસ દેશમાં અવરોધિત છે. આવી પરિસ્થિતિ સાઇટના તર્કના ઉલ્લંઘન તરફ દોરી જશે.

કેટલીક બાહ્ય સેવા અનુપલબ્ધ હોય ત્યારે તમારી સાઇટ કેવી રીતે કાર્ય કરે છે તે શોધવા માટે, તમે SPOF વિભાગનો ઉપયોગ કરી શકો છો webpagetest.org.

webpagetest.org પર SPOF વિભાગ

▍બ્રાઉઝર્સમાં સામગ્રીના કેશીંગમાં સમસ્યાઓ વિશે શું? (સંકેત: તે એક દંતકથા છે)

તમે વિચારી શકો છો કે સાર્વજનિક CDN નો ઉપયોગ આપમેળે વધુ સારા સંસાધન પ્રદર્શન તરફ દોરી જશે, કારણ કે આ સેવાઓ એકદમ ઉચ્ચ-ગુણવત્તાવાળા નેટવર્ક ધરાવે છે અને વિશ્વભરમાં વિતરિત કરવામાં આવે છે. પરંતુ બધું ખરેખર થોડું વધુ જટિલ છે.

ચાલો કહીએ કે અમારી પાસે ઘણી જુદી જુદી સાઇટ્સ છે: website1.com, website2.com, website3.com. આ બધી સાઇટ્સ jQuery લાઇબ્રેરીનો ઉપયોગ કરે છે. અમે તેને CDN નો ઉપયોગ કરીને તેમની સાથે કનેક્ટ કરીએ છીએ, ઉદાહરણ તરીકે - googleapis.com. તમે બ્રાઉઝર લાઇબ્રેરીને એકવાર ડાઉનલોડ અને કેશ કરવાની અપેક્ષા રાખી શકો છો અને પછી ત્રણેય સાઇટ પર તેનો ઉપયોગ કરી શકો છો. આ નેટવર્ક પરનો ભાર ઘટાડી શકે છે. કદાચ આ તમને ક્યાંક નાણાં બચાવવા અને સંસાધન પ્રદર્શનને સુધારવામાં મદદ કરશે. વ્યવહારિક દૃષ્ટિકોણથી, બધું અલગ દેખાય છે. ઉદાહરણ તરીકે, સફારી નામની સુવિધા ધરાવે છે બુદ્ધિશાળી ટ્રેકિંગ નિવારણ: કેશ દસ્તાવેજના સ્ત્રોત અને તૃતીય-પક્ષ સંસાધનના સ્ત્રોતના આધારે ડ્યુઅલ કીનો ઉપયોગ કરે છે. અહીં આ વિષય પર સારો લેખ.

જૂના અભ્યાસ યાહૂ и ફેસબુક, તેમજ વધુ તાજેતરના અભ્યાસ પોલ કેલ્વાનો, બતાવો કે જ્યાં સુધી આપણે અપેક્ષા રાખી શકીએ ત્યાં સુધી બ્રાઉઝર કેશમાં સંસાધનો સંગ્રહિત થતા નથી: “પ્રોજેક્ટના પોતાના અને તૃતીય-પક્ષ સંસાધનોના કેશીંગ સમય વચ્ચે ગંભીર અંતર છે. અમે CSS અને વેબ ફોન્ટ્સ વિશે વાત કરી રહ્યા છીએ. એટલે કે, 95% નેટીવ ફોન્ટની કેશ લાઈફ એક અઠવાડિયાથી વધુ હોય છે, જ્યારે 50% તૃતીય-પક્ષ ફોન્ટની કેશ લાઈફ એક અઠવાડિયાથી ઓછી હોય છે! આ વેબ ડેવલપર્સને ફોન્ટ ફાઇલો જાતે હોસ્ટ કરવા માટે એક આકર્ષક કારણ આપે છે!

પરિણામે, જો તમે અન્ય લોકોની સામગ્રીને હોસ્ટ કરો છો, તો તમે બ્રાઉઝર કેશીંગને કારણે કોઈપણ પ્રદર્શન સમસ્યાઓની નોંધ કરશો નહીં.

હવે જ્યારે અમે તૃતીય-પક્ષ સ્વ-હોસ્ટિંગની શક્તિઓને આવરી લીધી છે, ચાલો આ અભિગમને ખરાબમાંથી કેવી રીતે સારો અમલ કરવો તે વિશે વાત કરીએ.

ખરાબ: શેતાન વિગતોમાં છે

તૃતીય-પક્ષ સંસાધનોને તમારા પોતાના ડોમેન પર ખસેડવું એ સુનિશ્ચિત કર્યા વિના આપમેળે થઈ શકતું નથી કે આવા સંસાધનો યોગ્ય રીતે કેશ થયેલ છે.

અહીં મુખ્ય સમસ્યાઓ પૈકી એક કેશીંગ સમય છે. ઉદાહરણ તરીકે, સંસ્કરણ માહિતી તૃતીય-પક્ષ સ્ક્રિપ્ટ નામોમાં આના જેવા શામેલ છે: jquery-3.4.1.js. આવી ફાઇલ ભવિષ્યમાં બદલાશે નહીં, અને પરિણામે તેના કેશીંગમાં કોઈ સમસ્યા ઊભી થશે નહીં.

પરંતુ જો ફાઇલો, કેશ્ડ સ્ક્રિપ્ટો સાથે કામ કરતી વખતે અમુક વર્ઝનિંગ સ્કીમનો ઉપયોગ કરવામાં આવતો નથી, તો જેનાં સમાવિષ્ટો બદલાય છે જ્યારે ફાઇલનું નામ યથાવત રહે છે, તે જૂની થઈ શકે છે. આ એક ગંભીર સમસ્યા હોઈ શકે છે, કારણ કે તે, ઉદાહરણ તરીકે, ક્લાયંટને શક્ય તેટલી ઝડપથી પ્રાપ્ત કરવાની જરૂર હોય તેવી સ્ક્રિપ્ટ્સમાં સ્વચાલિત સુરક્ષા પેચો ઉમેરવાની મંજૂરી આપતું નથી. ડેવલપરે આવી સ્ક્રિપ્ટોને કેશમાં અપડેટ કરવાનો પ્રયાસ કરવો પડશે. વધુમાં, આ એ હકીકતને કારણે એપ્લિકેશન નિષ્ફળતાનું કારણ બની શકે છે કે કેશમાંથી ક્લાયંટ પર વપરાયેલ કોડ કોડના નવીનતમ સંસ્કરણથી અલગ છે જેના માટે પ્રોજેક્ટનો સર્વર ભાગ ડિઝાઇન કરવામાં આવ્યો છે.

સાચું, જો આપણે વારંવાર અપડેટ થતી સામગ્રી વિશે વાત કરીએ (ટેગ મેનેજર્સ, A/B પરીક્ષણ માટેના ઉકેલો), તો CDN ટૂલ્સનો ઉપયોગ કરીને તેને કેશ કરવું એ એક કાર્ય છે જે ઉકેલી શકાય છે, પરંતુ તે વધુ જટિલ છે. કમાન્ડર્સ એક્ટ જેવી સેવાઓ, ટેગ મેનેજમેન્ટ સોલ્યુશન, નવા સંસ્કરણો પ્રકાશિત કરતી વખતે વેબહુક્સનો ઉપયોગ કરે છે. આ તમને CDN પર કેશ ફ્લશને દબાણ કરવાની ક્ષમતા આપે છે, અથવા વધુ સારી રીતે, હેશ અથવા URL અપડેટને દબાણ કરવાની ક્ષમતા આપે છે.

▍ગ્રાહકોને સામગ્રીની અનુકૂલનશીલ ડિલિવરી

વધુમાં, જ્યારે આપણે કેશીંગ વિશે વાત કરીએ છીએ, ત્યારે આપણે એ હકીકતને ધ્યાનમાં લેવાની જરૂર છે કે CDN પર ઉપયોગમાં લેવાતી કેશીંગ સેટિંગ્સ કેટલાક તૃતીય-પક્ષ સંસાધનો માટે યોગ્ય ન હોઈ શકે. ઉદાહરણ તરીકે, આવા સંસાધનો વપરાશકર્તા એજન્ટ સ્નિફિંગ (અનુકૂલનશીલ સર્વિંગ) તકનીકનો ઉપયોગ ચોક્કસ બ્રાઉઝર્સને તે બ્રાઉઝર્સ માટે ખાસ કરીને ઑપ્ટિમાઇઝ કરેલ સામગ્રીના સંસ્કરણો સાથે સેવા આપવા માટે કરી શકે છે. આ ટેક્નોલોજીઓ બ્રાઉઝરની ક્ષમતાઓ શોધવા માટે રેગ્યુલર એક્સપ્રેશન્સ અથવા HTTP હેડર માહિતીના ડેટાબેઝ પર આધાર રાખે છે. User-Agent. એકવાર તેઓ જાણતા હોય કે તેઓ કયા બ્રાઉઝર સાથે કામ કરી રહ્યા છે, તેઓ તેને તેના માટે રચાયેલ સામગ્રી આપે છે.

અહીં તમે બે સેવાઓ યાદ રાખી શકો છો. પ્રથમ googlefonts.com છે. બીજું એક polyfill.io છે. Google Fonts સેવા બ્રાઉઝરની ક્ષમતાઓ પર આધાર રાખીને, ચોક્કસ સંસાધન માટે, વિવિધ CSS કોડ પ્રદાન કરે છે (વૉફ2 સંસાધનોનો ઉપયોગ કરીને લિંક્સ આપવી. unicode-range).

જુદા જુદા બ્રાઉઝર્સમાંથી બનાવેલી કેટલીક Google ફોન્ટ ક્વેરીનાં પરિણામો અહીં છે.

ક્રોમમાંથી Google ફોન્ટ ક્વેરી પરિણામ

IE10 થી એક્ઝિક્યુટ કરાયેલ Google Fonts ક્વેરીનું પરિણામ

Polyfill.io બ્રાઉઝરને માત્ર તેને જરૂરી પોલીફિલ્સ આપે છે. આ કામગીરીના કારણોસર કરવામાં આવે છે.

ઉદાહરણ તરીકે, ચાલો જોઈએ કે જો તમે વિવિધ બ્રાઉઝર્સમાંથી નીચેની વિનંતી ચલાવો તો શું થાય છે: https://polyfill.io/v3/polyfill.js?features=default

IE10 થી એક્ઝિક્યુટ કરવામાં આવેલી આવી વિનંતીના જવાબમાં, 34 KB ડેટા પ્રાપ્ત થશે. અને તેનો જવાબ, Chrome માંથી એક્ઝિક્યુટ કરવામાં આવ્યો છે, તે ખાલી હશે.

ક્રોધિત: કેટલીક ગોપનીયતા વિચારણાઓ

આ બિંદુ ક્રમમાં છેલ્લું છે, પરંતુ ઓછામાં ઓછું મહત્વનું નથી. મુદ્દો એ છે કે પ્રોજેક્ટના મુખ્ય ડોમેન અથવા તેના સબડોમેઇન પર તૃતીય-પક્ષ સંસાધનોનું સ્વ-હોસ્ટિંગ વપરાશકર્તાઓની ગોપનીયતાને જોખમમાં મૂકી શકે છે અને મુખ્ય વેબ પ્રોજેક્ટને નકારાત્મક અસર કરી શકે છે.

જો તમારી CDN સિસ્ટમ યોગ્ય રીતે ગોઠવેલ નથી, તો તમે તમારા ડોમેનની કૂકીઝને તૃતીય-પક્ષ સેવાને મોકલી શકો છો. જો યોગ્ય ફિલ્ટરિંગ CDN સ્તરે ગોઠવાયેલું ન હોય, તો તમારી સત્ર કૂકીઝ, જેનો સામાન્ય રીતે JavaScript માં ઉપયોગ કરી શકાતો નથી ( httponly), વિદેશી યજમાનને મોકલી શકાય છે.

યુલેરિયન અથવા ક્રિટિઓ જેવા ટ્રેકર્સ સાથે આ બરાબર થઈ શકે છે. તૃતીય-પક્ષ ટ્રેકર્સે કૂકીમાં અનન્ય ઓળખકર્તા સેટ કર્યું હોઈ શકે છે. જો તેઓ સાઇટની સામગ્રીનો ભાગ હોય, તો જ્યારે વપરાશકર્તા વિવિધ વેબ સંસાધનો સાથે કામ કરી રહ્યા હોય ત્યારે તેઓ તેમના વિવેકબુદ્ધિથી ઓળખકર્તાને વાંચી શકે છે.

આ દિવસોમાં, મોટાભાગના બ્રાઉઝર્સમાં આ પ્રકારના ટ્રેકર વર્તન સામે રક્ષણ શામેલ છે. પરિણામે, ટ્રેકર્સ હવે ટેકનોલોજીનો ઉપયોગ કરે છે CNAME ક્લોકિંગ, વિવિધ પ્રોજેક્ટ્સ માટે તેમની પોતાની સ્ક્રિપ્ટ તરીકે માસ્કરેડિંગ. જેમ કે, ટ્રેકર્સ સાઇટ માલિકોને ચોક્કસ ડોમેન માટે તેમની સેટિંગ્સમાં CNAME ઉમેરવાની ઑફર કરે છે, જેનું સરનામું સામાન્ય રીતે અક્ષરોના રેન્ડમ સેટ જેવું લાગે છે.

જોકે વેબસાઇટ કૂકીઝને તમામ સબડોમેન્સ માટે ઉપલબ્ધ કરાવવાની ભલામણ કરવામાં આવતી નથી (ઉદાહરણ તરીકે - *.website.com), ઘણી સાઇટ્સ આ કરે છે. આ કિસ્સામાં, આવી કૂકીઝ આપમેળે છૂપા તૃતીય-પક્ષ ટ્રેકરને મોકલવામાં આવે છે. પરિણામે, અમે હવે કોઈપણ ગોપનીયતા વિશે વાત કરી શકતા નથી.

ઉપરાંત, તે જ વસ્તુ HTTP હેડરો સાથે થાય છે ક્લાયન્ટ-સંકેતો, જે ફક્ત મુખ્ય ડોમેન પર મોકલવામાં આવે છે, કારણ કે તેનો ઉપયોગ બનાવવા માટે થઈ શકે છે ડિજિટલ ફિંગરપ્રિન્ટ વપરાશકર્તા ખાતરી કરો કે તમે જે CDN સેવાનો ઉપયોગ કરો છો તે આ હેડરોને યોગ્ય રીતે ફિલ્ટર કરે છે.

પરિણામો

જો તમે ટૂંક સમયમાં તૃતીય-પક્ષ સંસાધનોના સ્વ-હોસ્ટિંગને અમલમાં મૂકવાનું આયોજન કરી રહ્યાં છો, તો ચાલો હું તમને કેટલીક ટીપ્સ આપું:

• તમારી સૌથી મહત્વપૂર્ણ JS લાઇબ્રેરીઓ, ફોન્ટ્સ અને CSS ફાઇલોને હોસ્ટ કરો. આ તૃતીય-પક્ષ સેવાની ખામીને કારણે સાઇટ માટે મહત્વપૂર્ણ સંસાધન અનુપલબ્ધ હોવાને કારણે સાઇટની નિષ્ફળતા અથવા પ્રદર્શનમાં ઘટાડો થવાનું જોખમ ઘટાડશે.
• તમે CDN પર તૃતીય-પક્ષ સંસાધનોને કેશ કરો તે પહેલાં, ખાતરી કરો કે તેમની ફાઇલોને નામ આપતી વખતે અમુક પ્રકારની આવૃત્તિ સિસ્ટમનો ઉપયોગ કરવામાં આવે છે, અથવા તમે આ સંસાધનોના જીવનચક્રને મેન્યુઅલી અથવા CDN કેશને આપમેળે રીસેટ કરીને મેન્યુઅલી મેનેજ કરી શકો છો. સ્ક્રિપ્ટ.
• તમારા CDN, પ્રોક્સી સર્વર અને કેશ સેટિંગ્સ વિશે ખૂબ કાળજી રાખો. આ તમને તમારા પ્રોજેક્ટ અથવા હેડરને કૂકીઝ મોકલતા અટકાવવા દેશે Client-Hints તૃતીય પક્ષ સેવાઓ.

પ્રિય વાચકો! શું તમે તમારા સર્વર પર અન્ય લોકોની સામગ્રી હોસ્ટ કરો છો જે તમારા પ્રોજેક્ટના સંચાલન માટે અત્યંત મહત્વપૂર્ણ છે?

સોર્સ: www.habr.com