מקודד לשוא וידויים של מוח מקוון

22יוני/100

HTML5 Client Side Storage

[ התוכן שמופיע כאן מועמד לסטנדרטיזציה ב html5  יתכן וחלק מהדברים לא יעבדו כרגע על כל דפדפן ]

ישנם שני ממשקים שתפסו את עיני לגבי שמירת נתונים דרך הדפדפן

  1. אכסון נתונים - מאפשר שמירת נתונים בדפדפן בצורת key - value .
  2. אכסון מקומי  בצורה עבודה  לא מכוונת - אפשרות לשמור נתונים במבנה sql מקומי (משתמש ב sqlite).

אכסון מבנה נתונים פשוט

שמירת הנתונים נעשית דרך api חדשים בשם localStorage sessionStorage שניהם ממשים את אותו ממשק ומבצעים את אותן הפעולת אך תחום שמירת התנונים הוא שונה

עבור sessionStorage התחום הוא ה session ועבור localStorage הוא הדומיין (בדומה לשמירת cookies). ה api  מאוד פשוט וניתן להבין אותו בקלות לפי דוגמאת הקוד הבאה

אכסון מבנה נתונים מורכב

ניתן ליצור גם מסדי נתונים מקומיים לשמירת מבנה נתונים מורכב על בסיס sqlite בנית טבלאות , ניהול גרסאות  ,שאילתות וטאנסאקציות כולן אפשריות מול בסיס הנתונים המקומי.

שיטת העבודה היא מול מסד הנתונים היא טרנסאקציונאלית - יוצרים אוביקט מסד נתונים  דרכו יוצרים טרנסאקציה ובתוך הטרנסאקציה מבצעים את השאליתות (ניתן לראות בדוגמת הקוד)

מקורות

w3c Offline Web Applications

w3c Web Storage

19נוב'/092

כללי YSLOW \ PAGE SPEED

בעקבות המחקר והעבודה של סונדרס וצוותו הוציאו יאהו כלי בדיקות בשם YSLOW כתוסף דפדפן של פיירפוקס. מאז סונדרס עבר לגוגל וגם הם הוציאו כלי דומה בשם PAGE SPEED במהלך שמזכיר קצת את מיקרוסופט (ולא החלקים הטובים שלה)

בהתאם לממצאים של סונדרס וצוותו גובשו הכללים הבאים:

1. צמצום כמות קריאות HTTP ,זאת על ידי שימוש בטכניקות כמו CSS SPRITES ואיחוד קבצי CSS ו JS .

2. הפצת תוכן סטאטי על ידי שימוש ב CDN,המעבר להפצת תוכן סטטי בעזרת CDN קל יותר ומשפיע יותר משינוי ארכיטקטוני לפיצול המידע הדינאמי (את הטכניקה לפיצול מידע דינמי סקרתי בפוסטים קודמים)

3. שימוש נכון בתאריך תפוגה (expiration header) לכל משאב (לא רק לתמונות), במחקר שערכו גילו כי באתרים שונים הרבה משאבים קבועים (עד כ 70%) יכולים להיות עם תאריך תפוגה ארוך יותר. מעבר לתאריכי תפוגה ארוכים מחייב התייחסות ארכיטקטונית לעדכון גרסת משאב מסוים. לדוגמה - תיקון בקוד האתר דורש שינוי קוד ג'אוה סקריפט, מכיוון שאנו השתמשנו בתאריכי תפוגה ארוכים התיקון אף פעם (או עוד הרבה מאוד זמן) יגיע ללקוחות ותיקים הפתרון הוא חתימת גרסאות בשם הקובץ או כתובתו (URL)

4. שימוש ב GZIP (נכתב כחלק מפרוטוקול HTTP) נתמך ברוב הדפדפנים וחוסך כ 70% מהתעבורה אם משתמשים בו על כל המשאבים הטקסטואליים. בחלק גדול מהמקרים GZIP מופעל רק על קבצי HTML ומזניח שלא לצורך משאבי טקסט אחרים כגון CSS ו JS.

5. להעביר את הקישורים לקבציי CSS לראש העמוד. באקספלורר הדף לא מוצג עד שכל קבצי ה CSS נטענו ותוכנם נותח. בפירפוקס התצוגה תתרענן עם פענוח של CSS חדש.

6. להעביר את הקישורים לקבציי JS לתחתית העמוד, טעינת קובץ ג'אוה סקריפט חוסמת כל הורדה אחרת (בכל מצב אחר הדפדפן מבצע הורדות מקביליות) וחוסמת את רענון תצוגת המסך.

7. להימנע מביטויי CSS (ממשק שנתמך רק באקספלורר (גרסה 5 ומעלה) ומאפשר הפעלת ג'אוה סקריפט מתוך CSS) ביטויי ה CSS מחושבים בצורה מחזורית בכמויות מאוד גדולות ומאטים את פעילות הדפדפן.

8. שימוש בסקריפטים חיצוניים (שימוש בתגי SCRIPT ו LINK לטעינת משאבים חיצוניים) ובכך אחזור משאבים והאצת הטעינה על ידי שימוש במטמון הדפדפן.

9. צמצום חיפושי DNS, נעשה על ידי קריאה למשאבים מכמה שפחות מתחמים (דומיינים), על כל כתובת מתחם חדשה שהדפדפן טוען נעשית קריאה לחיפוש DNS. מצד אחד פיצול משאבים על שמות מתחם שונים גורם לדפדפן לטעינה מקבילית מרובה , מצד שני כל שם מתחם צריך לעבור אימות מול שרתי DNS (פעולה שלוקחת זמן) ההמלצה היא להשתמש בין שניים לארבעה שמות מתחם לתכנים בעמוד.

10. שימוש בכלי ניקוי קוד (minification)  להורדת הערות רווחים וקיצור קוד.

11. הימנעות מ REDIRECT אם בקריאות שרת כגון 301 ו 302 או שימוש בקוד HTML META או על ידי ג'אוה סקירפט ככל מקרה תהיה טעינה כפולה הראשונה של הדף המפנה ורק לאחר מכן כתובת היעד.

12. מחיקת סקריפטים כפולים, לפעמים קורה שישנה קריאה לאותם קבצי סקריפט כמה פעמים בעמוד. דבר הנובע בדרך כלל מחוסר תיאום בין צוותי פיתוח שונים באתר.

13. הגדרות ETAGS , תגיות יישות (ETags) הן מנגנון אשר שרתי אינטרנט ודפדפנים משתמשים כדי לקבוע אם רכיב בזיכרון המטמון של הדפדפן תואם אחד בשרת המקור (ישות יכולה להיות תמונות, סקריפטים, CSS, וכו ') .התגיות נוספו לספק מנגנון אימות גמיש יותר מאשר תאריך התפוגה.

14. הכנסת AJAX לזיכרון המטמון, בהרבה מקרים הקריאות הינם פרסונליות והאינסטינקט הראשוני הוא לא לשמור את המידע במטמון. אך למרות שהמידע אישי לא תמיד הוא משתנה לעתים קרובות. מומלץ להשתמש באותה טכניקה שמתוארת בסעיף 3.