დაახლოებით ერთი თვის წინ GeOlymp-ის საიტის გარეგნული მხარე განვაახლეთ თუმცა ბრაუზერის მხარეს სწრაფად ჩატვირთვისთვის საჭირო ოპტიმიზაცია არ გამიკეთებია. ამ პოსტში შევეცდები იმ თემებზე ვისაუბრო, რასაც ამ პროცესზე აქვს გავლენა; ამასთან, რეალურად შევასრულო ისინი საიტზე და ჩატვირთვის დროები შევადარო.

ახლა ქრომი მაჩვენებს, რომ ჯეოლიმპის ერთ-ერთი მთავარი გვერდის გახსნის დროს სერვერზე 42 მოთხოვნა იგზავნება, 307.9 კილობაიტი იტვირთება და 1.2 – 2.3 წამს ანდომებს გვერდის ჩატვირთვას. შევეცდები ამის გაუმჯობესებას..

1. ნაკლები რაოდენობის HTTP მოთხოვნის გაგზავნა სერვერზე
ერთ-ერთი ყველაზე მნიშვნელოვანი წესი, რომელსაც შესამჩნევი შედეგი აქვს, სერვერზე გასაგზავნი HTTP მოთხოვნების შემცირებაა. ეს მოთხოვნები იგზავნება თვითონ html ფაილის და ასევე თითოეული კომპონენტის წამოსაღებად, რასაც საიტი შეიცავს (სურათები, css და javascript ფაილები, ა.შ.).

http მოთხოვნა საკმაოდ მძიმე ოპერაციაა, რადგან მის შესასრულებლად საჭიროა DNS სერვერთან მისვლა, დომენის შესაბამისი ip მისამართის მიღება, მიღებული მისამართის საშუალებით ჰოსტ სერვერის მიგნება და ბოლო ბოლო ვებსერვერიდან რესურსის წამოღება. თუ ეს პუნქტები გეოგრაფიულადაც დაშორებულია (მაგალითად სხვადასხვა ქვეყნებში), მოთხოვნას უფრო მეტი სერვერის და ქსელის გავლა უწევს და დრო შესაბამისად იზრდება (ილუსტრაცია: როგორ მუშაობს ინტერნეტი).

მართალია, ბრაუზერს შეუძლია დომენიც და რესურსებსაც კეშში შეინახოს, მაგრამ როდესაც მომხმარებელი პირველად ხსნის გვერდს ან კეში ცარიელი აქვს, მისთვის საიტის ჩატვირთვა ბევრად დიდ დროს წაიღებს. მე პირადად არ შემიდგენია სტატისტიკა, თუმცა, მაგალითად, Yahoo-მ ჩაატარა გამოკვლევა, რომ ენახა რამდენი მომხმარებელი ნახულობდა საიტს ცარიელი კეშით და იმ დროს მათი რაოდენობა საშუალოდ მომხმარებლების 40-60% პროცენტი გამოვიდა.

საიტის სხვადასხვა კომპონენტების ჩამოტვირთვას კიდევ ერთი ცუდი თვისება აქვს. ისინი პარალელურ რეჟიმში არ იტვირთებიან, არამედ ერთმანეთს ელოდებიან.

HTTP / 1.1 სპეციფიკაციის მიხედვით რეკომენდირებულია, რომ კლიენტიდან ერთ დომენთან პარალელურად მხოლოდ ერთი ან ორი კავშირი არსებობდეს. თუმცა ახალი ბრაუზერები ამ რეკომენდაციას არ ითვალისწინებდნენ და 4-მდე ან 6-მდე აქვთ რაოდენობა შეზღუდული. ეს პარამეტრი მომხმარებელს შეუძლია თავისი ბრაუზერის კონფიგურაციიდან შეცვალოს და კავშირების ლიმიტი გაზარდოს. შესაბამისად, მეტი რესურსი ჩამოტვირთოს პარალელურად.

ერთდროულად ჩატვირთების რაოდენობა მომხმარებლისგან დამოუკიდებლადაც შეიძლება გაიზარდოს, რადგან შეზღუდვა დომენის სახელს უკავშირდება. თუ ჩვენ რესურსებს სხვადასხვა სერვერზე ან დომენების ალიასებზე და ქვედომენებზე გავანაწილებთ, მაშინ ბრაუზერები მათ პარალელურად წაიღებენ. აქ უნდა აღინიშნოს, რომ ასეთი ჩატვირთვების რაოდენობის გაზრდის პროპორციულად კლიენტის პროცესორზე იზრდება დატვირთვა. რა თქმა უნდა, ეს ძალიან ფარდობითი მაჩვენებელია, რადგან სხვადასხვა პროცესორზე სხვადასხვა შედეგი იქნება.

როგორ შევამციროთ HTTP მოთხოვნების რაოდენობა?
1.1. საიტის დიზაინში ხშირად გამოიყენება პატარა ილუსტრაციები, ხატულები, სხვადასხვა გრაფიკული ელემენტები. მათი უმეტესობა ისეთი სახით გვხვდება საიტზე, რომ შესაძლებელია css-ში აღვწეროთ და css sprite-ის სახით შევინახოთ: ყველა ილუსტრაცია არის ფაილში და შემდეგ css-ის საშუალებით ”კოორდინატების” მითითებით გამოვაჩენთ ილუსტრაციის ნაწილს.

მაგალითად, Facebook-ის სპრაიტი ასე გამოიყურება:

FB icons

სპრაიტის შექმნის დროს ჯობია რაც შეიძლება ახლოს იყოს ფაილები განლაგებული, რომ ფაილის ზომა დიდი არ გამოვიდეს. სურათის ოპტიმიზაციაზე შემდეგ უფრო დეტალურად დავწერ.

ამ პროცესის ავტომატიზაციისთვის არსებობს რამდენიმე საიტი, მაგრამ მე ხელით მირჩევნია ხოლმე დალაგება და ზომების აღება.

1.2. HTTP მოთხოვნების რაოდენობა ასევე შეიძლება შევამციროთ css და javascript-ის ფაილების გაერთიანებით. მართალია, ხშირ შემთხვევაში კონკრეტულ გვერდზეა დამოკიდებული, თუ რომელი სკრიპტის და სტილის ფაილებს გამოიყენებს, მაგრამ მაინც შეგვიძლია გამოვარჩიოთ ისეთი ნაწილები, რომელიც ყველასთვის საჭიროა და შესაბამისად გავაერთიანოთ ფაილები.

მეორეს მხრივ ფაილების გაერთიანება სხვა პრობლემას ქმნის. თუ პარალელურად ახერხებს ბრაუზერი ჩატვირთვას, არ იქნება კარგი, ყველაფრის ერთ პროცესად ჩატვირთვა ვაიძულოთ. თანაც მას მოსდევს კიდევ ერთი გვერდითი ეფექტი. მაგალითად, iphone, სადაც iOS 3.1.3 ვერსიის სისტემა აქვს, ბრაუზერის კეშში ისეთ კომპონენტებს ინახავს, რომელიც 25.6 კბ-ს არ აღემატება შეკუმშვის გარეშე.

კომპონენტების ჩამოტვირთვის გასაპარალელებლად არსებობს სკრიპტი head.js, რომელიც თავის თავზე იღებს ჩვენი სკრიპტების ორგანიზებას და მათ ჩატვირთვას. ბიბლიოთეკა თავისი სიმარტივით გამოირჩევა და საკმაოდ გავრცელებულია. ბევრმა ჩაატარა შესამოწმებელი ტესტები (მაგალითად, Fero Novak-ის ბლოგზეა პოსტი ამის შესახებ) და უმეტეს შემთხვევაში მართლაც დიდი პროცენტით ასწრაფებს გვერდის ჩატვირთვას, თუმცა ზოგს პრობლემა აქვს მისი სხვა სკრიპტებთან ერთად გაშვების დროს.

მე პირადად არ გამომიცდია და თქვენ თუ იყენებთ ამ სკრიპტს, სიამოვნებით მოვისმენდი შთაბეჭდილებებს.

1.3. მოვერიდოთ Frame-ებს, რამდენადაც შეიძლება. თუ ორი frame გვაქვს, მინიმუმ სამი http მიმართვა იგზავნება – ერთი frameset-ის შიგთავსის წამოსაღებად და ორი მასში არსებული frame-ებისთვის.

2. Content Delivery (Distribution) Network-ის გამოყენება
CDN კომპიუტერების ქსელია, სადაც ერთი და იგივე ინფორმაციის ასლები ინახება. სერვერები ფიზიკურად სხვადასხვა ადგილებშია განლაგებული და როცა მომხმარებელი ინფორმაციის წამოსაღებად მიმართავს სისტემას, მოთხოვნას უპასუხებს მომხმარებელთან ქსელის თვალსაზრისით ყველაზე ახლოს მყოფი სერვერი.

დიდ ინტერნეტ კომპანიებს ხშირად საკუთარი CDN ქსელები აქვთ. თუ აპლიკაციას ძალიან ბევრი მომხმარებელი ჰყავს და სწრაფქმედება მნიშვნელოვანია, მან შეიძლება ასეთი ქსელის პროვაიდერების სერვისი გამოიყენოს (მაგალითად, Amazon CloudFront).

გუგლის CDN ქსელით ჩვენც შეგვიძლია ვისარგებლოთ – Google Libraries API ჯავასკრიპტის გავრცელებულ open-source ბიბლიოთეკებს ინახავს. მაგალითად, თუ საიტზე jQuery გვჭირდება, შეგვიძლია ჩვენი ჰოსტის მაგივრად სკრიპტი გუგლის CDN-დან წამოვიღოთ. ასეთ ჩატვირთვას რამდენიმე უპირატესობა აქვს:

იქიდან გამომდინარე, რომ ფაილი CDN ქსელშია, ის მომხმარებლის ბრაუზერამდე მოკლე დროში მიაღწევს;
რადგან სკრიპტი საიტისგან განსხვავებულ დომენზეა, ბრაუზერი მას სხვა რესურსების პარალელურად ჩატვირთავს;
იგივე მისამართს სხვა ათასობით საიტი იყენებს ბიბლიოთეკის ჩასატვირთად. თქვენი საიტის მომხმარებელს დიდი ალბათობით ფაილი უკვე ბრაუზერის კეშში ექნება და წამოღება აღარ დასჭირდება.

3. CSS და Javascript კოდები გარე ფაილებში
სასურველია, რომ css სტილები და ჯავასკრიპტის კოდი რამდენადაც შეიძლება გარე ფაილებში იქნას გატანილი. როდესაც, მაგალითად, html ფაილში inline სტილებს ვწერთ, ამით ფაილის ზომასაც ვზრდით. გარე ფაილებს ბრაუზერი კეშში ინახავს. გვერდზე მეორედ შესვლის დროს ის მათ კეშიდან აიღებს და ხელმეორედ არ მიმართავს ვებ სერვერს.

4. Expires ჰედერი სტატიკურ ფაილებზე
როდესაც რაიმე რესურსზე ვგზავნით HTTP მოთხოვნას, ვებ სერვერი HTTP პასუხს აყოლებს Expires ჰედერს, რომელიც ბრაუზერს აცნობებს, რამდენი ხანი შეიძლება შეინახოს რესურსი თავის კეშში. ამ ჰედერს ითვალისწინებენ როგორც ბრაუზერები, ისე პროქსი სერვერები; რესურსებს შესაბამისად აკეშირებენ და მომხამრებელს ხშირად აღარ უწევს მათი ხელახლა წამოღება სერვერიდან.

შეგვიძლია ვებ სერვერი ისე დავაკონფიგურიროთ, რომ გარკვეულ ფაილებზე ან ტიპებზე შესაბამის Expires ჰედერში შორი მომავლის თარიღი მიუთითოს (თუმცა ერთ წელს არ უნდა გადააჭარბოს HTTP / 1.1 სპეციფიკაციის მიხედვით).

ამ მეთოდს უარყოფითი მხარე იგივე აქვს, რაც დადებითი. ბრაუზერი და პროქსი სერვერი ფაილებს არ წამოიღებს სერვერიდან, მაშინაც კი, თუ მათ განვაახლებთ, ამიტომ ასეთ განახლებებზე ფაილის სახელების შეცვლა იქნება საჭირო.

თუ აპაჩის ვებ სერვერს იყენებთ, mod_expires ან mod_header-ს მოდულების კონფიგურირება ამ ბმულზე შეგიძლიათ ნახოთ: Using a far future expires header

5. CSS და Javascript ფაილების ზომის შემცირება
სტილების და ჯავასკრიპტის კოდის წერის დროს მნიშვნელოვანია, რომ კოდი სუფთად და დალაგებულად დაიწეროს. ეს პროგრამისტს მის მოდიფიკაციებს და დროთა განმავლობაში შენახვას გაუადვილებს, მაგრამ ბრაუზერისთვის არ აქვს მნიშვნელობა რა განლაგებით ეწერება ტექსტი ფაილში. არსებობს ბევრი სხვადასხვა მინიმიზატორი, რომელიც ჩვენი კოდიდან ცარიელ ადგილებს წაშლის, ლოკალურ ცვლადებს სახელებს დაუპატარავებს და ა.შ.
რაც არ უნდა გასაკვირი იყოს, ასეთი მინიმიზაციის შედეგად ხშირად კოდი ძალიან მცირდება ზომაში.
მაგალითად jQuery-ის 1.7 ვერსიის სრული სახით მოცემული ფაილი 229 კილობაიტია, როცა მინიმიზირებული და შემდეგ gzip-ით შეკუმშული ფაილი მხოლოდ 31 კბ.

6. ტექსტური ფაილების შეკუმშვა Gzip მეთოდით
ტექსტური ფაილების ზომა დაზიპვის შემდეგ ძალიან მცირდება – 10-ჯერ, 20-ჯერ..
კარგი იქნებოდა, რომ ბრაუზერთან დაზიპული ფაილები იგზავნებოდეს, რაც ცხადია ბევრად სწრაფად მივიდოდა. სწორედ ამას აკეთებს ვებ სერვერი, თუ შესაბამისად დავაკონფიგურირებთ. ის კუმშავს ფაილს და უგზავნის ბრაუზერს, რომელიც ზიპიდან სრულ ფაილს აღადგენს და დაარენდერებს.
მთელი პროცესი ორი ძირითადი ნაბიჯისგან შედგება:

თუ ბრაუზერს შეუძლია შეკუმშულ ფაილთან გამკლავება, ის ვებ სერვერთან გაგზავნილ მოთხოვნას შემდეგი სახის ჰედერს აყოლებს: Accept-Encoding: gzip, deflate
gzip და deflate შეკუმშვის მეთოდებია. ბევრ საიტზე წერია, რომ gzip ყველაზე კარგი არჩევანია, მაგრამ ტესტების მიხედვით მე პირადად ვერ მივხვდი, რატომ არის სხვებზე ბევრად უკეთესი. ტესტები და შედარება შეგიძლიათ ამ ბმულზე ნახოთ: Compression Tests
ასეთი ინფორმაციის მიღების შემდეგ, თუ სერვერს შეუძლია ფაილების შეკუმშვა, ის ბრაუზერს შეკუმშულ ფაილს დაუბრუნებს და ამას Content-Encoding: gzip ჰედერით შეატყობინებს, წინააღმდეგ შემთხვევაში ჩვეულებრივ გაგზავნის პასუხს.

ასეთი სახის შეკუმშვა უმჯობესია მხოლოდ ტექსტურ ფაილებზე გამოვიყენოთ, და არა, მაგალითად, სურათებზე ან pdf ფაილებზე, რადგან ისინი ისედაც შეკუმშულ ფორმატშია და ფაილის ზომა შეიძლება პირიქით გაიზარდოს.

Apache-ს ვებ სერვერის შემთხვევაში კონფიგურაციის ინსტრუქცია შეგიძლიათ ნახოთ საიტზე: How To Optimize Your Site With GZIP Compression

იმის გაგება, შეკუმშული მოდის თუ არა სერვერიდან ფაილები, პასუხის ჰედერებში შეიძლება. ან მაგალითად Http compression test საიტზე.

7. სურათების ფორმატები და შეკუმშვა
პირველ რიგში, ალბათ ისედაც არავინ აკეთებს, მაგრამ მაინც აღვნიშნავ, რომ სურათები html გვერდზე გამოყვანის დროს არ უნდა დავაპატარაოთ, არამედ სერვერზე უნდა გვქონდეს ის შესაბამის ზომებში შენახული და გვერდზე მხოლოდ საჭირო ზომის სურათი ჩავტვირთოთ.

სურათის ზომა მნიშვნელოვნად არის დამოკიდებული იმაზე, თუ როგორ ფორმატში შევინახავთ. ამის შესარჩევად უნდა ვიცოდეთ რომელი ფორმატი როგორი სახით ინახავს მას.
Clever PNG optimization techniques
Clever JPEG optimization techniques

ზოგადად მე ასეთ წესს ვიყენებ, რომ თუ ფოტოს მსგავსი გამოსახულებაა, jpg-თი ვკუმშავ, ხოლო გრადაციებს ან ცოტა ფერიან, მარტივ გამოსახულებებს png-ში და gif-ში ვამოწმებ. შედეგს ვადარებ და ვირჩევ.

თურმე კიდევ შეიძლება მიღებული png სურათის გაუმჯობესება. მაგალითად, არსებობს ასეთი საიტი Smush it! რომელიც ატვირთულ ფაილებს დანაკარგის და ხარისხის გაფუჭების გარეშე აოპტიმიზირებს.

ჯეოლიმპის შემთხვევაში გავაერთიანე წვრილ წვრილი პატარა ზომის ჯავასკრიპტის ფაილები. ზოგან შეუკუმშავს ვიყენებდი და გამოვასწორე..
ძირითადი css ფაილი მინიმიზაციის შემდეგ 27%-ით შემცირდა ზომაში და 53.2კბ-დან 38.5კბ-ზე ჩამოვიდა.

.png ფაილები smushit საიტზე გატარების შემდეგ ჯამში 140.76 კბ-ით ანუ 49.68%-ით შემცირდნენ.

განახლებულ საიტზე იგზავნება 29 http მოთხოვნა, ჯამში 173 კბ და მთლიანი ჩატვირთვის დრო საშუალოდ 0.8 – 1.0 წამია.

ანუ, კეშირების გარეშე ასეთი სურათია

	ძველი	ახალი	გაუმჯობესება
მოთხოვნები	42	29	30.9%
ფაილების ზომა	307.9	173	43.81%
ჩატვირთვის დრო	1.2 – 2.3	0.8 – 1.0	~40%

აქ gzip-ით შეკუმშვა არ შედის, იმიტომ, რომ მანამდეც ჩართული იყო ის, მაგრამ შეკუმშვის გარეშე 173 კილობაიტის ნაცვლად დაახლოებით 432 კილობაიტი გამოვიდოდა.

იმავე გვერდის refresh-ის შემდეგ კეშირების წყალობით მხოლოდ 15 კილობაიტი იტვირთება და onload-მდე დრო საშუალოდ 0.4 წამია.

დრო ორჯერ შევამცირეთ, მაგრამ სამწუხაროდ ეს საკმარისი არ არის რომ იგივე დროში ორჯერ მეტ მომხმარებელს მოემსახუროს საიტი. ამისთვის სერვერის მხარეს იქნება ცვლილებები საჭირო.

File input ველი html-ში

05 თებერვალი, 2010 by samurai_girl

4 კომენტარი

ბლოგზე მაინც დავწერო რამე, გულს გადავაყოლებ..

ყველაზე ბოლოს რაც მახსოვს, html file input-ის ღილაკზე მინდოდა სტილის დადება (არ მითხრათ flash-ით გექნაო )

ნუ, თურმე, რაც არ უნდა თავი მოიკლას კაცმა, მაგ ღილაკს სტილს ვერ შეუცვლის.. ვერც ტექსტს (choose file…). ამ ტექსტს ბრაუზერი სვამს და თან სხვადასხვა ბრაუზერში სხვადასხვაა ხოლმე.

გუგლმა რაღაც ჰაკებამდე მიმიყვანა.. ხალხი css-ით და javascript-ით აღწევს იმას, რომ ამ file input-ს გამჭვირვალეს ასვამს თავზე ჩვეულებრივ ღილაკს და input ველს (ანუ fileinput ზევიდანაა).

და მერე ჯავასკრიპტით იღებს ფაილის სახელს..

ერთი კი ვიფიქრე, ამხელა ამბები რად უნდა თქო.. იმიტომ რომ ერთი შეხედვით სამ ხაზში გამოდიოდა ყველანაირად მარტივი პასუხი:

<button type="submit" id="fake-btn" onclick="document.getElementById('real').click();"> ატვირთვა</button>
<input type="text" id="filename_in"/>
<input type="file" id="real" style="display:none" value="some" onchange="document.getElementById('filename_in').value = this.value;"/>

ანუ, ვმალავ ნამდვილ ამტვირთავ ინფუთს, მაქვს ჩემი ღილაკი და ტექსტური ინფუთი და როცა ვინმე დააჭერს ჩემს ღილაკზე, ვაჭერინებ დამალულზეც click() მეთოდით. ხოლო მერე რა value-საც მიიღებს დამალული ელემენტი , ის გამომაქვს ჩემს ტექსტურ ინფუთში (onchange ივენტის საშუალებით).

მაგრამ მერე გამოჩნდა რატომაც არ გამოდიოდა ესე მარტივად. მოზილას და ოპერას click() მეთოდი (რომლითაც პროგრამულად ვაკეთებთ ელემენტზე მაუსის დაჭერის შემცვლელ მოქმედებას) არ აქვთ file input-ისთვისთვის.. გამონაკლისია ეს. ალბათ უსაფრთხოების მხრივ, მაგრამ რა დიდი ზარალი ეგ არის, ერთი ფაილ დიალოგი გამოვიდეს და მორჩა.. მოკლედ არ ვიცი რატომ არ აქვთ მაგრამ ფაქტია.. და კიდევ არც onchange ივენთი არ ესმით მაგისთვის.

ჰაკებსაც არ ადგიათ კარგი დღე. თუ ვინმე გადაწყვეტთ ამ ფაილ ინფუთის გალამაზებას, ბევრი ბრაუზერის ხუშტურების გათვალისწინება მოგიწევთ მგონი ყველასი სათითაოდ

ყოველი შემთხვევისთვის ერთ-ერთი გავრცელებული გზა ეს არის: Quirksmode.org

ისე კარგი ამბავიც არის – html5-ში multiple file ამტვირთავი იქნება ეს ელემენტი. ახლა ეს შესაძლებლობა არ აქვს და flash-ის uploader-ებს იყენებენ ხოლმე.

რომ დავფიქრდი, მგონი ყველაზე მეტი ამ ელემენტმა მაწვალა მე კიდევ jquery-ის ვაწვალებდი. აი მაგალითად აჯაქს რიქვესთით კი ვერ ატვირთავთ სურათს აუცილებლად უნდა გადავიდეს საბმიტის გვერდზე. jquery.post-ით ფორმის მონაცემებს რომ ვგზავნით, არ იგზავნება ეს. არც jQuery-ის serialize() ფუნქცია მოქმედებს მაგაზე, ფორმის სერიალიზებას როცა ვაკეთებთ..

გამოსავალი iframe ელემენტია ან ისევ flash uploader-ი.

და ბოლოს, რომ გამოვკეთდები ეს პოსტი რომ არ წავშალო, სიმღერასაც დავამატებ… : D i love it

CSS და ტექსტის ზომა

13 მაისი, 2009 by samurai_girl

5 კომენტარი

როდესაც ფონტის ზომის მითითება მჭირდება საიტის აწყობისას, სულ სხვადასხვა გზით ვუთითებ ხოლმე, მერე უბრალოდ ვამოწმებ როგორ ჩანს. არადა არ არის ეს კარგი.

სულ მავიწყდება, რომ ერთხელ და საბოლოოდ გავარკვიო როდის, რა და როგორ ჯობია.

ახლა თქვენთან ერთად გავარკვევ : )

ზოგადი მიმოხილვა

ფარდობითი ერთეულები

em
% – პროცენტი
ex – ამ ერთეულს ‘x-height’-ს ეძახიან, 1ex დაახლოებით პატარა x-ის სიმაღლის ტოლია. სიდიდე განსაზღვრულია იმ ფონტებისთვისაც, რომლებიც საერთოდ არ შეიცავენ x-ს.

ფიქსირებული ერთეულები

px – პიქსელი
mm – მილიმეტრი
cm – სანტიმეტრი
in – დიუმი (= 2.54სმ)
pt – point. CSS 2.1-მიხედვით ის დიუმის 1/72 ნაწილს უდრის.
pc – pica. 1 pica = 12 points

სტილის წერის დროს კიდევ გვხვდება ზომები xx-small, x-small, small, medium, large, x-large, და xx-large. ასევე smaller და larger. ბოლო ორი ფარდობითია მშობელი ელემენტის ზომის მიმართ. წინებს კი ზუსტად არ ვიცი რა ზომები შეესაბამება პიქსელებში, თუმცა სხვადასხვა ბრაუზერებში საკმაოდ სტაბილურად აჩვენებენ.

თუმცა ეს დაყოფა კორექტულად შეიძლება ჩაითვალოს ვებ საიტის მიმართ. სხვა მხრივ, თუ იმ დივაისების მიმართ დავყოფ, რითიც საიტის გვერდი უნდა ვნახო, px-იც ფარდობითი იქნება.

ფარდობითი ნიშნავს, რომ ელემენტზე მითითებული ზომა გამოითვლება მშობელი ელემენტის ზომის მიხედვით.

font-size-1

რატომ არ უნდა გამოვიყენოთ px?

IE არ მისცემს მომხმარებელს ასეთი ფონტის ზომის შეცვლას, რაც მოუხერხებელია. იგივე ეხება სხვა ფიქსირებულ ერთეულებს (mm, cm, in ა.შ.).

რატომ არ უნდა გამოვიყენოთ ex?

ის ძალიან ცვალებადია ბრაუზერებს შორის (სხვადასხვანაირად არენდერებენ) და ამიტომ თავისტკივილია.

პროცენტის (%) გამოყენებას არაფერი უშლის ხელს, მაგრამ მაინცდამაინც კარგად აღქმადი არ არის კოდის წერა-კითხვის დროს.

თუმცა, ეს პიროვნულ არჩევანზეა დამოკიდებული.

და ბოლოს em

‘medium’ ზომის ტექსტი ბრაუზერებში default-ად 16px-ის ტოლია და ხანდახან რთული გამოსათვლელია ხოლმე აქედან em სიდიდე (იხ. ცხრილი).

ვებ დეველოპერებმა იპოვეს გზა ამ გამოთვლების გასამარტივებლად. მთელი საიტის ფონტის ზომას (body ელემენტში) ანიჭებენ ხოლმე 62.5%-ს. და ამის მერე 1em = 10px (რადგან em ფარდობითი გამოდის უკვე body-ის მიმართ). ასე რომ ნაცნობი პიქსელებიდან მარტივად შეგვიძლია გადავიყვანოთ em-ში 10-ზე გაყოფით.

აქვე გასათვალისწინებელია, რომ ეს ფარდობითობა მისდევს ელემენტების მთელს იერარქიას შვილს, მერე კიდევ იმის შვილს.. და ა.შ. ამიტომ კარგი იქნება რაც შეიძლება ნაკლები რაოდენობით თუ აღვწერთ font-size თვისებას. ისიც იერარქიების თავში.

არის კიდევ ერთი პატარა საკითხი : )

ბრაუზერები.

ბრაუზერებს აქვთ გვერდის ზომის და ფონტის ზომის რეგულირების შესაძლებლობა (თუმცა ქრომში ფონტის ზუმი ვერ ვიპოვე, მას მერე რაც მთელი გვერდის ზუმი ჩასვეს). უმრავლესობას (Google Chrome, Firefox, Opera, IE 7-8 …) default-ად აქვს მთელი გვერდის ზუმი.

რა განსხვავებაა?

ფონტის გადიდება/დაპატარავების დროს მარტო ფონტის ზომა იცვლება, ხოლო გვერდის ზუმის დროს გვერდი სურათივით იზრდება ერთიანად და ერთიანადვე პატარავდება.

კიდევ საკითხავია რომელი ჯობია, იმიტომ რომ ზოგს, მაგალითად, არ მოსწონს ჰორიზონტალური სკროლი რომ უჩნდება საიტს. მეორეს მხრივ დიზაინის ელემენტების არევაზე აღარ არის საფიქრალი. ფონტის ზომის ცვლილება კი ხშირ შემთხვევაში გვერდზე ულამაზო გადაადგილებებს იწვევს.

იმ ბრაუზერში, რომელსაც მთელი გვერდის ზუმის საშუალება არ აქვს, ფიქსირებულ ზომიანი ტექსტი არაფრის დიდებით არ იცვლება. ასეთი რამ მომხმარებელს კონტროლის საშუალებას ართმევს (იქნებ ვერ ვხედავ კარგად და დიდი ასოები მინდა), ამიტომ არ ითვლება მიზანშეწონილად px-ის გამოყენება.

ისევ და ისევ, ეს IE-ს ძველ ვერსიებს ეხება, თორემ, მაგალითად, Firefox-ში ვერანაირად ვერ გააჩერებთ ფონტს ერთ ზომაზე. მაინც იქნება მისი გადიდების შესაძლებლობა.

საბოლოო ჯამში,

გადავწყვიტე, რომ ამის შემდეგ ყოველთვის em გამოვიყენო ან პროცენტი..

საინტერესო საკითხავი აღნიშნულ საკითხზე:
px – em – % – pt – keyword
CSS Font-Size: em vs. px vs. pt vs. percent

Update: არა, ყოველთვის px-ს ვიყენებ და ბედნიერი ვარ )

პირობითი კომენტარები HTML კოდში

05 მარტი, 2009 by samurai_girl

2 კომენტარი

ხანდახან მეტად გამაღიზიანებელია IE-ს საქციელი. წერ css სტილებს, ყველა ნორმალურ ბრაუზერში ნორმალურად მუშაობს, მაგრამ Internet Explorer-ში, რომელსაც ჯერ ჯერობით მაინც ძალიან ბევრი მომხმარებელი ყავს, რაღაცეები აბდა უბდა გამოდის.

ზოგიერთ ასეთ შემთხვევაში მოსახერხებელია პირობითი კომენტარების (conditional comments) გამოყენება რომლებიც მხოლოდ MS Internet Explorer-ში მუშაობს.

ამ კომენტარებს IE-ს ვერსიების გარჩევაც კი შეუძლიათ 5.0-დან ზევით.

მაგალითად:


<!--[if IE 6]>
ეს ტექსტი გამოჩნდება მხოლოდ მაშინ თუ საიტი IE 6-ში იხსნება.
<![endif]-->

სხვა ბრაუზერები კი მთელ ტექსტს კომენტარად აღიქვამენ (<!– –>) ნიშნების გამო.

რადგან ეს html სტრუქტურის ნაწილია, პირობით კომენტარებს css გვერდებში ვერ ჩავრთავთ, სამაგიეროდ შეგვიძლია ასეთი რამის გაკეთება:


<link rel="stylesheet" type="text/css" href="common.css" />
<!--[if IE]>
<link rel="stylesheet" type="text/css" href="all-ie.css" />
<![endif]-->
<!--[if IE 6]>
<link rel="stylesheet" type="text/css" href="ie-6.0.css" />
<![endif]-->

შესაძლო პირობები:


<p><!--[if IE]>
ეს Internet Explorer-ია<br />
<![endif]-->
<!--[if IE 5]>
ეს Internet Explorer 5-ია<br />
<![endif]-->
<!--[if IE 5.0]>
ეს Internet Explorer 5.0-ია<br />
<![endif]-->
<!--[if IE 5.5]>
ეს Internet Explorer 5.5-ია<br />
<![endif]-->
<!--[if IE 6]>
ეს Internet Explorer 6-ია<br />
<![endif]-->
<!--[if IE 7]>
ეს Internet Explorer 7-ია<br />
<![endif]-->
<!--[if gte IE 5]>
ეს Internet Explorer 5-ია ან მისი მომდევნო ვერსიებიდან ერთ-ერთი <br />
<![endif]-->
<!--[if lt IE 6]>
ეს Internet Explorer 6-ზე ძველი ვერსიაა<br />
<![endif]-->
<!--[if lte IE 5.5]>
Internet Explorer-ის ეს ვერსია ნაკლებია 5.5-ზე ან 5.5-ია<br />
<![endif]-->
<!--[if gt IE 6]>
Internet Explorer -ის ეს ვერსია 6-ზე ახალია<br />
<![endif]-->
</p>

Category Archives: HTML/CSS

რჩევები საიტის ოპტიმიზაციისთვის (Front end)