შეიძლება დაემატოს კიდევ ზოგიერთი script-ის გადატანა head-დან body-ს ბოლო ნაწილში (რაც შენ ისედაც გაქვს გამოყენებული GeOlymp ზე ;)). ამ ტექნიკის საშუალებით მომხმარებელი უფრო მალე იღებს დახატულ გვერდს, შესაბამისად შეუძლია დაიწყოს მოქმედება და არ დაელოდოს ყველა სკრიპტის ჩამოტვირთვას.
@არჩილა :)) მართალი ხარ 🙂 უბრალოდ სკრიპტების თანმიმდევრობის შესახებ არ შემიძლია რამე ზოგადად დავწერო. ყოველთვის სპეციალურად მიწევს ხოლმე მაგათი დალაგება.
მაგალითად asp.net mvc თვის არის ბიბლიოთეკა, რომელსაც აქვს საშუალება მინიფიკაცია, გაერთიანება, თანმიმდევრობის დალაგება და კიდევ ბევრი რამ (Cassette automatically sorts, concatenates, minifies, caches and versions all your JavaScript, CoffeeScript, CSS, LESS and HTML templates) გააკეთოს ავტომატურად. ძალიან კარგი რაღაცაა ნამდვილად – http://getcassette.net/
head.js-ზე მეც ჩავატარე ტესტირება და კარგი შედეგები მივიღე. ოპტიმიზაციის გარდა კარგი ორგანიზება შეიძლება labelებით და სკრიპტის ჩატვირთვისას callbackებით. +1 head.js-ს 🙂
1) HTML/DOM ელემენტეიბს რაოდენობა, რაც ნაკლები მით უკეთესი…
2) Expire header-ები თუ არა Etag-ების დამატება…
3) სხვა სერვერზე request-ების შემცირება… DNS lookup.
მადლობა საინტერესო პოსტისთვის.
ყველაფერი იდეალურადაა აღწერილი, ერთი ორს მეც დავამატებ:
1. თუ იყენებთ FB -ს API-ს და გიწევთ JS ფაილის ან IFRAME ის ჩასმა FB დან ჯობია ასინქრონულად ატვირთოთ.
2. ყველაფერი (js, css, img), ფაილები უმჯობესია იყოს განსხვავებულ დომენზე, ან ქვედომენზე, რადგან HTTP request ის დროს cookie ები არ გაჰყვება ქსელში. თუმცა ეს ნამეტანი advanced ოპტიმიზაციის დროს სეიძლება გაითვალისწინოს კაცმა.
3. სერვერის მხარეზე თუ დაწერ პოსტს კარგი იქნება, ერთერთი უმნიშვნელოვანესი სერვერის მხარეს ჩემი აზრით ქეშირებაა ))
კარგი სტატიაა ელენე! ძალიან! სწორი მიდგომაა დეველოპმენტის მხრიდან. უდაოდ. ბევრს ვურჩევ ამის წაკითხვას.
ჩემი მხრიდან, როგორც ვებადმინი ერთ-ორ სიტყვას დავამატებ რაც დეველოპერებისთვის საინტერესო იქნება (ყველაფერს ვერ მოვყვები, ეგ ჯობს ადმინებს მიუგდოთ (: ):
სტატიკური კონტენტი:
1. ტრაფიკის დედუპლიკაცია:
etag – თანამედროვე ვებსერვერები მას თავად ამატებენ და თუ ფაილის ცვლილება ხდება ლოკალურად და კონტენტი დინამიური არ არის – ავტომატურად კლიენტი შესაბამის კონტენტს თავიდან აღარ გადოიწერს. დამატებით ამ საკითხის დინამიური საშუალებებით მოგვარება უარესია – მეტი რესურსების გამოყენებისკენ იწვევს.
რეკომენდირებულია relatime პარამეტრის გამოყენება ფაილური სისტემისთვის, თუ access time-dependent კონტენტი არ არის სერვერზე. ზოგ შემთვევაში მისი დათვლა inode-ითაც ხდება (დიდი აზრი არ არის).
ცალკე ფაილებისთვის expires-ის მითითების დიდ აზრს ვერ ვხედავ თუ საუბარი არ არის რაღაც კონკრეტული ტიპის ფაილზე (ფილმი, მუსიკა), ჩვეულ ფაილებში პრობლემებს/მოუხერხებლობას უფრო გამოიწვევს ვიდრე მოაგვარებს.
ყურადღება მიაქციეთ იმას, რომ ეს ეხება სტატიკურ კონტენტს.
ვერდიქტი: expire დაამატეთ მხოლოდ დიდ ფაილებს, რომლებსაც ნამდვილად არ გამოცვლით. თქვენი ნერვები და დრო მეტი ღირს ვიდრე სერვერის და ტრაფიკის 1 კილობაიტი. Try to not use etag. 🙂
2. gzip, deflate – ერთი და იგივეა თითქმის. არავითარ შემთხვევაში არ გამოიყენოთ არატექსტურ ფაილებზე (სწორად წერია სტატიაში), რადგან ეს დატვირთვის გაზრდას გამოიწვევს. ქსელი უფრო იაფია ვიდრე სისტემური რესურსი. gzip-ს უფრო ხშირად მაშინ იყენებენ, როდესაც harware encoder არის სერვერზე (მაგ. http://www.aha.com/).
ვერდიქტი: ადმინმა მიხედოს, ფორსირებას ნუ მოახდენთ სხვა მეთოდებით, ზედა დონეზე კომპრესია არაეფექტურია.
ბ. დინამიური კონტენტი
1. ყოველთვის გამოიყენეთ გარე ინტერფეისი (CGI) დინამიური კონტენტის დასამუშავებლად – ეს უსაფრთხოებასაც ზრდის, მოქნილობასაც და ზოგად წარმადობასაც. mod_php = ვებადმინის მტერი სათამაშო.
ვერდიქტი: ადმინ, გააკეთე
2. Opcode caching is a good thing (c) – Zend Guard, APC
ვერდიქტი: ადმინ, გააკეთე
გ. ზოგადი
1. HTTP 1.1-related
პრობლემა: MS ISA, MS IE-ზე არ მუშაობს ნორმალურად, მაგრამ კლიენტი ამას ვერ შეამჩნევს.
არ არის Keepalive-ზე რეკომენდირებული დიდი პარამეტრების დაყენება – შეიძლება ადვილად დაიფლუდოთ.
ვერდიქტი: ადმინ, გააკეთე
2. Apache? Good. Worker or prefork?
სტაბილურობა = prefork
რესურსები = worker
შესაბამისად ერთ სერვერზე ჯობს პრეფორკი გამოიყენოთ, კლასტერზე უდაოდ ვორკერი მოიგებს. მითი: “იქ php არ მუშაობს”. მუშაობს. თუ აქვს პატარა წითელი ველოსიპედი.
შეიძლება დაემატოს კიდევ ზოგიერთი script-ის გადატანა head-დან body-ს ბოლო ნაწილში (რაც შენ ისედაც გაქვს გამოყენებული GeOlymp ზე ;)). ამ ტექნიკის საშუალებით მომხმარებელი უფრო მალე იღებს დახატულ გვერდს, შესაბამისად შეუძლია დაიწყოს მოქმედება და არ დაელოდოს ყველა სკრიპტის ჩამოტვირთვას.
@არჩილა :)) მართალი ხარ 🙂 უბრალოდ სკრიპტების თანმიმდევრობის შესახებ არ შემიძლია რამე ზოგადად დავწერო. ყოველთვის სპეციალურად მიწევს ხოლმე მაგათი დალაგება.
მაგალითად asp.net mvc თვის არის ბიბლიოთეკა, რომელსაც აქვს საშუალება მინიფიკაცია, გაერთიანება, თანმიმდევრობის დალაგება და კიდევ ბევრი რამ (Cassette automatically sorts, concatenates, minifies, caches and versions all your JavaScript, CoffeeScript, CSS, LESS and HTML templates) გააკეთოს ავტომატურად. ძალიან კარგი რაღაცაა ნამდვილად – http://getcassette.net/
head.js ჯერჯერობით არ არის google-ს CDN-ში
http://code.google.com/apis/libraries/devguide.html#Libraries
http://code.google.com/p/google-ajax-apis/issues/detail?id=548
ვაჰ, thread-მა შემაცდინა 🙂 მადლობა
head.js-ზე მეც ჩავატარე ტესტირება და კარგი შედეგები მივიღე. ოპტიმიზაციის გარდა კარგი ორგანიზება შეიძლება labelებით და სკრიპტის ჩატვირთვისას callbackებით. +1 head.js-ს 🙂
კარგი პოსტია. სასიამოვნოდ იკითხება და ინფორმიაციით არის დახუნძლული.
მალაჩინა! 🙂
შენის ნებართვით ერთი-ორს მეც მივამატებ:
1) HTML/DOM ელემენტეიბს რაოდენობა, რაც ნაკლები მით უკეთესი…
2) Expire header-ები თუ არა Etag-ების დამატება…
3) სხვა სერვერზე request-ების შემცირება… DNS lookup.
მადლობა საინტერესო პოსტისთვის.
ყველაფერი იდეალურადაა აღწერილი, ერთი ორს მეც დავამატებ:
1. თუ იყენებთ FB -ს API-ს და გიწევთ JS ფაილის ან IFRAME ის ჩასმა FB დან ჯობია ასინქრონულად ატვირთოთ.
2. ყველაფერი (js, css, img), ფაილები უმჯობესია იყოს განსხვავებულ დომენზე, ან ქვედომენზე, რადგან HTTP request ის დროს cookie ები არ გაჰყვება ქსელში. თუმცა ეს ნამეტანი advanced ოპტიმიზაციის დროს სეიძლება გაითვალისწინოს კაცმა.
3. სერვერის მხარეზე თუ დაწერ პოსტს კარგი იქნება, ერთერთი უმნიშვნელოვანესი სერვერის მხარეს ჩემი აზრით ქეშირებაა ))
შენიშვნა:
ჯობია ასინქრონულად ჩატვირთოთ*
ოთო, უჩა,
კარგი შენიშვნებია 🙂 ეს fb-ს სკრიპტები სულ ჭედავს ხოლმე ყველაფერს.
კარგი სტატიაა ელენე! ძალიან! სწორი მიდგომაა დეველოპმენტის მხრიდან. უდაოდ. ბევრს ვურჩევ ამის წაკითხვას.
ჩემი მხრიდან, როგორც ვებადმინი ერთ-ორ სიტყვას დავამატებ რაც დეველოპერებისთვის საინტერესო იქნება (ყველაფერს ვერ მოვყვები, ეგ ჯობს ადმინებს მიუგდოთ (: ):
სტატიკური კონტენტი:
1. ტრაფიკის დედუპლიკაცია:
etag – თანამედროვე ვებსერვერები მას თავად ამატებენ და თუ ფაილის ცვლილება ხდება ლოკალურად და კონტენტი დინამიური არ არის – ავტომატურად კლიენტი შესაბამის კონტენტს თავიდან აღარ გადოიწერს. დამატებით ამ საკითხის დინამიური საშუალებებით მოგვარება უარესია – მეტი რესურსების გამოყენებისკენ იწვევს.
რეკომენდირებულია relatime პარამეტრის გამოყენება ფაილური სისტემისთვის, თუ access time-dependent კონტენტი არ არის სერვერზე. ზოგ შემთვევაში მისი დათვლა inode-ითაც ხდება (დიდი აზრი არ არის).
ცალკე ფაილებისთვის expires-ის მითითების დიდ აზრს ვერ ვხედავ თუ საუბარი არ არის რაღაც კონკრეტული ტიპის ფაილზე (ფილმი, მუსიკა), ჩვეულ ფაილებში პრობლემებს/მოუხერხებლობას უფრო გამოიწვევს ვიდრე მოაგვარებს.
ყურადღება მიაქციეთ იმას, რომ ეს ეხება სტატიკურ კონტენტს.
ვერდიქტი: expire დაამატეთ მხოლოდ დიდ ფაილებს, რომლებსაც ნამდვილად არ გამოცვლით. თქვენი ნერვები და დრო მეტი ღირს ვიდრე სერვერის და ტრაფიკის 1 კილობაიტი. Try to not use etag. 🙂
2. gzip, deflate – ერთი და იგივეა თითქმის. არავითარ შემთხვევაში არ გამოიყენოთ არატექსტურ ფაილებზე (სწორად წერია სტატიაში), რადგან ეს დატვირთვის გაზრდას გამოიწვევს. ქსელი უფრო იაფია ვიდრე სისტემური რესურსი. gzip-ს უფრო ხშირად მაშინ იყენებენ, როდესაც harware encoder არის სერვერზე (მაგ. http://www.aha.com/).
ვერდიქტი: ადმინმა მიხედოს, ფორსირებას ნუ მოახდენთ სხვა მეთოდებით, ზედა დონეზე კომპრესია არაეფექტურია.
ბ. დინამიური კონტენტი
1. ყოველთვის გამოიყენეთ გარე ინტერფეისი (CGI) დინამიური კონტენტის დასამუშავებლად – ეს უსაფრთხოებასაც ზრდის, მოქნილობასაც და ზოგად წარმადობასაც. mod_php = ვებადმინის მტერი სათამაშო.
ვერდიქტი: ადმინ, გააკეთე
2. Opcode caching is a good thing (c) – Zend Guard, APC
ვერდიქტი: ადმინ, გააკეთე
გ. ზოგადი
1. HTTP 1.1-related
პრობლემა: MS ISA, MS IE-ზე არ მუშაობს ნორმალურად, მაგრამ კლიენტი ამას ვერ შეამჩნევს.
არ არის Keepalive-ზე რეკომენდირებული დიდი პარამეტრების დაყენება – შეიძლება ადვილად დაიფლუდოთ.
ვერდიქტი: ადმინ, გააკეთე
2. Apache? Good. Worker or prefork?
სტაბილურობა = prefork
რესურსები = worker
შესაბამისად ერთ სერვერზე ჯობს პრეფორკი გამოიყენოთ, კლასტერზე უდაოდ ვორკერი მოიგებს. მითი: “იქ php არ მუშაობს”. მუშაობს. თუ აქვს პატარა წითელი ველოსიპედი.
ვერდიქტი: ადმინ, გააკეთე
@GioMac
🙂 მადლობა. ნამდვილად ძალიან საინტერესო კომენტარია 🙂 უფრო ვრცლად ვნახავ მაშინ მაგ თემებს