JS: טריק לא מוכר לשיפור זמן התגובה של DOM: createDocumentFragment

נדמיין לעצמנו את הלולאה הבאה:

var arr=[……];
  
for(var i=0;i<arr.length;i++)
{
var d=document.createElement("div");

d.innerHTML=arr[i].html;
document.getElementById("divonpage").appendChild(d);

}

מי מאיתנו לא כתב לולאה כזו או דומה לה בחייו. עכשיו נדמיין מה קורה בפנים:

בכל איטרציה של הלולאה, מחושב מחדש arr.length, אחר כך נוצר div חדש, מתווסף לו תוכן והוא נוסף לדף, מה שמרענן מחדש את התצוגה ואת הטבלאות הפנימיות של הדפדפן.

אני מציע את השינוי הבא, והסברים בהערות:

var arr=[……],len=arr.length; // שמירה של כמות המשתנים במערך
var frag = document.createDocumentFragment(); // עיין בקישור


for(var i=0;i<len;i++)
{
var d=document.createElement("div")

d.innerHTML=arr[i].html
frag.appendChild(d) // שמירה "בצד" של מערך מוכן לשימוש

}
// ועכשיו נעדכן את התצוגה של הדפדפן רק פעם אחת
document.getElementById("divonpage").appendChild(frag);

זה נכון שבדפדפנים החדשים יותר יש אופטימיזציות לפתרון בעיות מהסוג הזה, מצד שני, לרוב המוחלט של הגולשים (לפחות בישראל) יש IE6/7 שלא מסתכלים אפילו לכיוון הזה, אז עדיין שווה לעבוד. עובד על כל הדפדפנים מ-IE6 ומעלה (לא בדקתי IE5 וכנופייתו).

PageSlow של גוגל – שימוש ראשוני

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

לקחתי לניסוי את המתחרה החדש (יחסית) שלו מבית גוגל, והרצתי על אתר הבית שלנו בעבדית. כמה נקודות שהוא מגלה ו-YSlow בינתיים לא:

• בקשות DNS מבוזבזות – דומיינים מהם נטען רק רכיב אחד שאפשר לחסוך (כך גיליתי רכ.
• מקטין תמונות ומציע הצעות קונקרטיות על כל התמונות במערכת – חוסך טעינה של תמונה תמונה לתוכנה גרפית.
  הצרה הצרורה – הוא מציג רשימה ארוכה של תמונות בהן ניתן לחסוך. תחזיקו חזק! 37 byets. היה יעיל יותר אם הוא היה מתעלם מהן.
  הקטנה ידנית של תמונות ב-YSlow (איטי ולעיתים לא עובד) נותנת קובץ מעט קטן יותר לעיתים. זניח.
• PageSlow עוקב גם אחרי CSS וביצועים של Selectors בדפדפנים שונים. נחמד.
• Remove Unused CSS – נשמע נחמד להסיר רכיבים לא שימושיים של CSS, אבל בפועל לא שימושי בעליל. הרעיון הוא לייצר קובץ CSS בודד ולשים אותו ב-Cache של הלקוח, גם אם הוא מכיל קצת רכיבי עיצוב של דפים פנימיים.
• בסעיף Cookie Size הכלי מתעלם מהרכיב המייצר Cookie הכי ארוך והכי כבד במערכת שלנו – Google Analytics. שאר העוגיות הם סוג של SessionID קטנים וזניחים במונחים של תקשורת או רוחב פס.
  הרכיב האחרון אחראי ל-Cookie של לא פחות מאשר 100Bytes, תכפילו את זה בכמות הבקשות ותבינו שזה המון.
  התמונות שלנו יושבות על דומיין אחר זה נכון, ובכל זאת.
• PageSlow מתעלם מנושא ה-CDN. העניין דווקא חיובי מכיוון שזה שינוי שמורכב יחסית לבצע, השינויים האחרים שהוא מציע פשוטים יותר ויעילים לא פחות.
• PageSlow מוצא URL שונה לקבצים זהים. למשל Home.js ו-home.js. ברכיכי AJAX הוא לעיתים מטעה אבל שווה תשומת לב.

השאר פחות או יותר לא שונה בהרבה: GZIP, זמן פקיעה (Expire ו-Cache Control), צמצום (Minify) של קבצי טקסט.

ההמלצה שלי: תשתמשו בשתיהן. מן הסתם התחרות תעשה להן ולאתר שלכם רק טוב.

גירסאות IE בטאבים

למי שעדיין אוכל קש מאחיזת 30% של IE6 בדפדפנים הישראליים ונזקק מדי פעם לפיתוח על הדפדפן הזה או גרועים ממנו

IETester היא תוכנה שמיועדת להציג בטאבים גירסאות שונות של IE. ניסיתי והתלהבתי.

ממליץ עליה בחום למי שמפתח בצד לקוח הרבה. אמנם לא מושלם כמו Virtual PC כלשהו אבל יעיל כשמדובר בשגיאות טפשיות.

בצילום: חדשות ערוץ 7 ללא שקיפות PNG.

תוכנה דומה יש גם מבית Microsoft, עם קצת פחות  פיצ'רים

לוח שנה ותאריך עברי ב-.NET

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

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

HebrewCalendar

ב-.NET, החל מגירסא 1 קיימת המחלקה System.Globalization.HebrewCalendar, המספקת לוח שנה עברי בדומה ללוחות נוספים מרחבי העולם, הממומשים במחלקות היורשות מ-System.Globalization.Calendar.
לכל הלוחות יש שיטות משותפות, בסגנון ה-GetX, כמו למשל GetDayOfMonth, GetMonth וכו', וכולם עובדים עם DateTime הסטנדרטי של הסביבה.

המרת תאריכים מעברי ולועזי ולהיפך:

Dim d as new DateTime(13,11,1987, new HebrewCalendar() 

ב- d יהיה אובייקט DateTime סטנדרטי.

d.ToString() יתן לנו 13/11/87, שזה התאריך הלועזי הרלוונטי.
כמובן שבמקרה העברי צריך להתחשב גם בשקיעה שיכולה להזיז את התאריך העברי יום קדימה.

הצגת תאריך עברי

Public Shared jewishCulture As System.Globalization.CultureInfo = System.Globalization.CultureInfo.CreateSpecificCulture("he-IL")

Public Shared Function ShortDate(ByVal dDate As Date) As String

    jewishCulture.DateTimeFormat.Calendar = HebCal

    Return dDate.ToString("dd MMMM", jewishCulture)
End Function 

בדיוק כמו תאריך לועזי, רק עם לוח שנה מתאים ואחר. גם שאר האפשרויות של DateTime.ToString() תעבודנה פה

חישובי תאריך עברי

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

בגוגל מצאתי למשל את המחלקה הזו שמסבירה את החישוב המדוייק, כנראה מפרוייקט mono, ובהמשך גם את קוד המקור של המחלקה המקורית של מיקרוסופט, שמשתמשת בטבלה כדי לזרז את החישובים.

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

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

לוח השנה של ערוץ 7 – פותח לפני כשנתיים על בסיס המחלקה הזו ונוספות, וכולל יכולות מאוד מעניינות נוספות.

דפים כמעט סטטיים זוחלים. למה ?

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

אבל עדיין דף הבית שלו זחל, ואני נשאלתי – למה!

התחברתי לשרת שלו והרצתי DebugDiag, שאימת את ההשערה שלי. הסתבר כי הרבה מאוד בקשות שנתקעו למשך שניות אחדות, כלל לא הגיעו למנגנון של ASP ונתקעו הרבה קודם.

אז למה?

ל-ASP ול-ASP.net יש בתוך Application Pool בסך הכל 25 (ניתן לשינוי) Threadים בזמן נתון, כאשר כל אחד כזה מקבל דף, מעבד אותו ומשחרר. במידה ויש איטיות באתר ה-Threadים האלה מתמלאים מהר מאוד והבקשות הבאות פשוט מתפנות בהמתנה ל-Thread. בעצם, כאשר דף אחד או שניים זוחלים זו שיטה בטוחה לגרום לכל האתר לזחול ובהמשך להתקע.

הפיתרון לבעיה הספציפית ההיא היה הפיכת חלק מהדפים לדפים סטטיים לגמרי, html, שמתעדכנים דרך ממשק הניהול של האתר. הללו מסופקים ישירות על ידי IIS, ללא צורך בתיווכים מתיווכים שונים, ולכן מגיעים ישר ללקוחות. כפועל יוצא – הלחץ על ה-Threadים יורד במעט מה שמקל באופן כללי על העומס בשרת.

כצ'ופר, על הדרך, אנחנו מקבלים גם שיפור מאוד נחמד בביצועים, גם ברמת IIS וגם ברמת יתרונותיו של Cache.

פיתוח מהנה.

עוד באותו עניין:
איטיות בסביבת ייצור

צנזורה שאבד עליה הכלח

כידוע לכולכם, לפני דקות קצרצרות הותר לפרסום כי יעקב טייטל משבות רחל, עולה מארה"ב שנעלם מעל פני האדמה לפני כשבועיים נאשם על ידי השב"כ באי-אלו פשעים. בראשית השבוע שעבר נחטפה אשתו באלימות מצומת תפוח שבשומרון בדרך להפגנה ודיון בבית המשפט בפתח תקווה. כתבה בנושא הוסרה מאתר ערוץ 7 ו-"וואלה", אבל בגוגל אפשר היה בקלות למצוא את הכתבות המחוקות או מידע שפורסם ב-Twitter.

במהלך השבועות האחרונים, מנהלת הצנזורה מלחמה מטופשת וחסרת תועלת להסרת פרסומים. כך למשל, הם היו מתקשרים מדי 23:00-24:00 בלילה, כדי לדרוש למחוק מהפורומים של ערוץ 7 את השרשורים שעסקו בנידון ופורסמו לאורך היום. הכל נכתב ופורסם, אבל הצנזורה הטפשית חשבה שבאמת אפשר להסתיר משהו.

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

אז עכשיו זה הותר לפרסום. נו שויין.

• תושב שבות רחל חשוד בביצוע פיגועים (חדשות ערוץ 7)
• הכתבה שנאסרה לפרסום לפני עשרה ימים (חדשות ערוץ 7)