તમારી વેબસાઇટ કેવી રીતે ઝડપી બનાવવી: વ્યવહારુ ચેકલિસ્ટ

વેબસાઇટ ઝડપી બનાવવા માટે, પહેલા PageSpeed Insights થી તેને માપો, પછી તે દર્શાવે છે તે સૌથી મોટું કારણ ઠીક કરો — સામાન્ય રીતે મોટી ઇમેજ, ઘણું બધું JavaScript, ભારે ફોન્ટ અથવા થર્ડ-પાર્ટી સ્ક્રિપ્ટ. Google ના Core Web Vitals "સારા" લક્ષ્યો માટે પ્રયાસ કરો: મુખ્ય કન્ટેન્ટ 2.5 સેકન્ડમાં દેખાય, ટૅપનો પ્રતિસાદ 200 મિલિસેકન્ડમાં મળે, અને લેઆઉટ લગભગ ન કૂદે. મોટાભાગની સાઇટ થોડા ફેરફારોથી ત્યાં પહોંચે છે, ફરીથી લખવાથી નહીં.

કંઈ બદલતા પહેલાં માપો

અનુમાન લગાવવામાં સમય બગડે છે. બે મફત ટૂલ લગભગ દરેકને આવરી લે છે:

• PageSpeed Insights (pagespeed.web.dev) — લાઇવ URL પેસ્ટ કરો. તે વાસ્તવિક Chrome વપરાશકર્તાઓનો ફીલ્ડ ડેટા (જો તમારી સાઇટ પર પૂરતો ટ્રાફિક હોય) અને સિમ્યુલેટેડ લોડનો લેબ ડેટા બતાવે છે, ઉપરાંત ચોક્કસ સમસ્યાઓની યાદી.
• Chrome DevTools માં Lighthouse — એ જ લેબ ટેસ્ટ, કોઈપણ ખોલી શકાય તેવા પેજ પર, preview સહિત. મોબાઇલ મોડમાં ટેસ્ટ કરો; ધીમા નેટવર્ક પરના ફોન પર સમસ્યાઓ દેખાય છે.

જે આંકડા મહત્ત્વના છે તે Google ના Core Web Vitals છે. સપ્ટેમ્બર 2026 સુધી, web.dev પરનું Google નું દસ્તાવેજીકરણ આ "સારા" થ્રેશોલ્ડ આપે છે, પેજ લોડના 75મા પર્સેન્ટાઇલ પર માપેલા:

INP એ 2024 માં જૂના First Input Delay મેટ્રિકની જગ્યા લીધી. જો કોઈ ટૂલ હજુ પણ FID જણાવે છે, તો તે જૂનું છે.

શરૂઆતના આંકડા લખી રાખો. દરેક સુધારા પછી ફરીથી ટેસ્ટ કરો, જેથી ખબર પડે કે શું મદદરૂપ થયું.

સમય ક્યાં જાય છે: વિકલ્પો અને ટ્રેડ-ઓફ

દરેક સામાન્ય કારણનો ઉપાય છે, અને દરેક ઉપાયની કિંમત છે. ટોચ પરનાથી શરૂ કરો — તે સૌથી સસ્તા અને સૌથી સામાન્ય છે.

ઇમેજ

ઇમેજ સૌથી સામાન્ય સમસ્યા છે અને ઠીક કરવી સૌથી સરળ છે. 800 પિક્સલ પહોળાઈમાં બતાવેલો 4,000-પિક્સલનો ફોટો દરેક મુલાકાતીને તેઓ જે જુએ છે તેના કરતાં પાંચ ગણું ડાઉનલોડ કરાવે છે.

• ઇમેજ બતાવેલા કદમાં પીરસો, ફોન અને ડેસ્કટોપ માટે રિસ્પોન્સિવ srcset કદ સાથે.
• આધુનિક ફોર્મેટ (WebP અથવા AVIF) અને યોગ્ય કમ્પ્રેશન વાપરો.
• દરેક ઇમેજ પર width અને height સેટ કરો જેથી બ્રાઉઝર જગ્યા અનામત રાખે. આ એકલું મોટાભાગની લેઆઉટ શિફ્ટ ઠીક કરે છે.
• ફોલ્ડ નીચેની ઇમેજને loading="lazy" થી lazy-load કરો.
• પેજની ટોચની મુખ્ય ઇમેજને ક્યારેય lazy-load ન કરો. Google ની LCP માર્ગદર્શિકા આ બાબતે સ્પષ્ટ છે: LCP ઇમેજને lazy-load કરવાથી તે હંમેશાં વિલંબિત થાય છે. તેના બદલે તેને fetchpriority="high" આપો.

JavaScript

ઘણી AI-બનાવેલી સાઇટ સિંગલ-પેજ એપ (SPA) હોય છે: બ્રાઉઝર JavaScript બંડલ ડાઉનલોડ કરે છે અને પછી પેજ દોરે છે. બંડલ જેટલું મોટું, કોરી સ્ક્રીન એટલી લાંબી. મહેનતના ક્રમમાં ઉપાયો:

1. જે વાપરતા નથી તે કાઢો. ડિપેન્ડન્સીની યાદી માંગો અને એક વાર ઉમેરાયેલી અને ભૂલાઈ ગયેલી લાઇબ્રેરી કાપો — એક તારીખ માટે એક date લાઇબ્રેરી, પાંચ આઇકન માટે આખું આઇકન પૅક.
2. રૂટ પ્રમાણે વહેંચો. એડમિન ડેશબોર્ડનો કોડ ફક્ત ત્યારે લોડ કરો જ્યારે કોઈ તે ખોલે, હોમ પેજ પર નહીં.
3. જાહેર પેજને prerender કરો. વાસ્તવિક HTML તરીકે મોકલાતું માર્કેટિંગ પેજ કોઈ JavaScript ચાલે તે પહેલાં દેખાય છે. આ સર્ચ એન્જિનને પણ મદદ કરે છે; જુઓ AI-બનાવેલી વેબસાઇટ્સ માટે SEO.

ધીમું INP સામાન્ય રીતે એટલે કે એક લાંબું કાર્ય પેજને અટકાવે છે — દરેક કીસ્ટ્રોકે મોટી યાદી ફિલ્ટર કરવી, અથવા એક સેલ બદલાય ત્યારે આખું ટેબલ ફરી રેન્ડર કરવું. Chrome DevTools નું Performance પેનલ બતાવે છે કે કયું.

ફોન્ટ

દરેક ફોન્ટ પરિવાર અને વજન એક વધુ ફાઇલ છે. બે પરિવાર અને ત્રણ-ચાર વજન સામાન્ય રીતે પૂરતા છે. ફોલ્ડ ઉપર વપરાતો ફોન્ટ preload કરો, font-display: swap વાપરો જેથી લખાણ તરત દેખાય, અને જો બાહ્ય ફોન્ટ સેવા તમારા મુલાકાતીઓ માટે ધીમી હોય તો ફોન્ટ જાતે હોસ્ટ કરો.

થર્ડ-પાર્ટી સ્ક્રિપ્ટ

ચેટ વિજેટ, analytics, heatmaps, જાહેરાત પિક્સેલ, એમ્બેડ કરેલા વિડિયો અને સોશિયલ ફીડ બધા બીજા સર્વરથી કોડ લોડ કરે છે. દરેક નાનું લાગે છે; સાથે મળીને ઘણીવાર પેજનો સૌથી ધીમો ભાગ બને છે. જે ખરેખર જુઓ છો તે રાખો. બાકીનાને પેજ ઇન્ટરેક્ટિવ થયા પછી લોડ કરો, અને ભારે embeds (YouTube પ્લેયર, નકશો) ને હલકા પ્રીવ્યૂથી બદલો જે ક્લિક પર સાચું લોડ કરે.

સર્વર પ્રતિસાદ

Time to first byte (TTFB) — સર્વરને જવાબ આપવાનું શરૂ કરવામાં કેટલો સમય લાગે છે — બીજા દરેક મેટ્રિકની નીચે રહે છે. CDN (તમારા મુલાકાતીઓની નજીકના સર્વરનું નેટવર્ક; જુઓ CDN શું છે) પરથી પીરસાતાં સ્ટેટિક પેજ લગભગ બધે ઝડપી હોય છે. દરેક વિનંતી પર સર્વર દ્વારા બનતાં પેજ તે સર્વર અને તેના ડેટાબેઝ પર આધાર રાખે છે. પુનરાવર્તિત કામને કેશ કરવું અને ધીમી ક્વેરી માટે ડેટાબેઝ indexes ઉમેરવા સામાન્ય ઉપાયો છે.

કામ કરતા પ્રોમ્પ્ટ

ચોક્કસ રહો: પેજ, મેટ્રિક અને મર્યાદાનું નામ આપો. જો તમારી પાસે હોય તો PageSpeed Insights ના તારણો પેસ્ટ કરો.

PageSpeed Insights હોમ પેજ માટે મોબાઇલ પર 4.8 s નો LCP બતાવે છે, અને LCP એલિમેન્ટ હીરો ઇમેજ છે. હીરો ઇમેજને રિસાઇઝ કરીને WebP માં બદલો, રિસ્પોન્સિવ કદ પીરસો, width અને height સેટ કરો, તેને fetchpriority="high" આપો અને ખાતરી કરો કે તે lazy-load નથી. ફોલ્ડ નીચેની દરેક ઇમેજ lazy-load કરો. ડિઝાઇન બદલશો નહીં.

આ એપની ડિપેન્ડન્સી તપાસો. દરેક પેકેજની યાદી બનાવો, તે શું વાપરે છે અને બંડલમાં લગભગ કેટલું ઉમેરે છે. વપરાતા ન હોય તેવા કાઢો, અને /admin અને /settings રૂટને અલગ ચંક્સમાં વહેંચો જે ફક્ત મુલાકાત વખતે લોડ થાય.

/products પર સર્ચ બોક્સ ધીમું લાગે છે. ફિલ્ટરને debounce કરો, દરેક કીસ્ટ્રોક પર આખી યાદી ફરી રેન્ડર ન કરો, અને યાદીમાં 200 થી વધુ આઇટમ હોય તો તેને pagination અથવા virtualise કરો.

પગલા દર પગલા

1. લાઇવ પેજ ટેસ્ટ કરો મોબાઇલ પર PageSpeed Insights માં. LCP, INP અને CLS, અને દર્શાવેલી ટોચની ત્રણ સમસ્યાઓ નોંધો.
2. પહેલા ઇમેજ ઠીક કરો: કદ, ફોર્મેટ, પરિમાણો, ફોલ્ડ નીચે lazy loading, હીરો માટે પ્રાથમિકતા.
3. ન વપરાતી થર્ડ-પાર્ટી સ્ક્રિપ્ટ કાપો, અને બાકીની મોડી કરો.
4. ફોન્ટ ઘટાડો ડિઝાઇનને જરૂરી હોય તેટલા સુધી.
5. JavaScript સંકોચો: ન વપરાતા પેકેજ કાઢો, રૂટ પ્રમાણે વહેંચો.
6. જાહેર પેજને prerender કરો જો તે હજુ ક્લાયન્ટ-રેન્ડર થાય છે અને LCP હજુ ધીમો છે.
7. સર્વર તપાસો: કેશિંગ, ડેટાબેઝ indexes, ભાગ્યે જ બદલાતા કન્ટેન્ટ માટે સ્ટેટિક હોસ્ટિંગ.
8. ફરી પ્રકાશિત કરો અને ફરી ટેસ્ટ કરો. PageSpeed Insights નો ફીલ્ડ ડેટા વાસ્તવિક મુલાકાતો આવતાં આગલા અઠવાડિયાઓમાં અપડેટ થાય છે, એટલે શરૂઆતનાં પરિણામો લેબ ડેટાથી આંકો.

સામાન્ય ભૂલો

• ફક્ત ઝડપી લેપટોપ પર ટેસ્ટ કરવું. તમારા મુલાકાતીઓ મધ્યમ શ્રેણીના ફોન અને અસ્થિર મોબાઇલ ડેટા પર છે. મોબાઇલ મોડમાં ટેસ્ટ કરો.
• સંપૂર્ણ 100 નો પીછો. લેબ સ્કોર માર્ગદર્શક છે. એકવાર Core Web Vitals સારી શ્રેણીમાં આવી જાય, પછી કન્ટેન્ટ અને ઉપયોગિતા છેલ્લા થોડા પોઇન્ટ કરતાં વધુ મહત્ત્વનાં છે.
• બધું lazy-load કરવું, હીરો ઇમેજ સહિત. તેનાથી LCP વધુ ખરાબ થાય છે.
• ઉપર સ્પીડ પ્લગઇન કે લાઇબ્રેરી ઉમેરવી. વજન ઘટાડવું લગભગ હંમેશાં તેને મેનેજ કરવા કોડ ઉમેરવા કરતાં સારું છે.
• લાઇવ સાઇટ નહીં, preview ને ઑપ્ટિમાઇઝ કરવું. ડેવલપમેન્ટ preview ઑપ્ટિમાઇઝ વગરના બિલ્ડ ચલાવે છે. પ્રકાશિત URL માપો.
• ઝડપ એકવાર ઠીક કરવી. દરેક નવું વિજેટ, ઇમેજ અને સુવિધા વજન ઉમેરે છે. મોટા ફેરફારો પછી ફરી ટેસ્ટ કરો.

ઝડપ ચેકલિસ્ટ

• મોબાઇલ પર LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1
• ઇમેજ રિસાઇઝ, કમ્પ્રેસ, આધુનિક ફોર્મેટ, width અને height સાથે
• હીરો ઇમેજ lazy-load નથી; ફોલ્ડ નીચેની ઇમેજ lazy-load
• કોઈ ન વપરાતી JavaScript લાઇબ્રેરી નથી; ભારે રૂટ અલગ
• બે ફોન્ટ પરિવાર કે ઓછા, મુખ્ય ફોન્ટ preload
• ફક્ત વપરાતી થર્ડ-પાર્ટી સ્ક્રિપ્ટ, મોડી લોડ
• જાહેર પેજ શક્ય હોય ત્યાં prerendered અથવા સ્ટેટિક
• પ્રકાશિત કર્યા પછી લાઇવ URL પર ફરી ટેસ્ટ

ઝડપ અને મોબાઇલ લેઆઉટ સાથે ચાલે છે; જુઓ વેબસાઇટ મોબાઇલ-રિસ્પોન્સિવ કેવી રીતે બનાવવી. સંપૂર્ણ લોન્ચ-પહેલાંના પાસ માટે, AI પ્રોટોટાઇપને પ્રોડક્શનમાં કેવી રીતે લઈ જવો બાકીનું આવરી લે છે.

Mythex પર ઝડપ

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

પ્રશ્નો