ساخت برنامه های پیچیده وب سریعتر

در وب، سرعت همه چیز است. واکنش‌پذیری مرورگر شما، مدت زمانی که طول می‌کشد تا یک برنامه وب ظاهر شود، و سرعت آن برنامه تعاملات کاربر را مدیریت می‌کند، همگی بر تجربه شما به عنوان یک کاربر وب تأثیر مستقیم دارند.

در مایکروسافت، ما عمیقاً به بهبود عملکرد وب اهمیت می دهیم و از چندین جهت در حال پیشرفت در آن هستیم:

بر اساس تجربه خودمان، می‌دانیم که برنامه‌های پیچیده نیاز به معماری‌های پیچیده‌ای دارند که گاهی اوقات به چندین پنجره، iframe یا رشته‌های کارگر متکی هستند. برای مقابله با کندی‌هایی که این زمینه‌های موازی متعدد می‌توانند ایجاد کنند، ما یک ویژگی جدید را برای توسعه‌دهندگان وب پیشنهاد می‌کنیم: API زمان‌بندی تأخیر پیام.

اگر یک توسعه دهنده وب هستید، برای کسب اطلاعات بیشتر به خواندن ادامه دهید پیشنهاد API زمان‌بندی پیام با تاخیر، و به ما اطلاع دهید اگر ممکن است به شما کمک کند برنامه وب خود را سریعتر بسازید، یا راه هایی را به اشتراک بگذارید که API می تواند بهتر باشد.

چه چیزی باعث تاخیر در ارسال پیام های متنی می شود؟

تأخیر ممکن است زمانی رخ دهد که یک برنامه پیام‌های زیادی را بین زمینه‌های مختلف خود مبادله کند، مانند پنجره اصلی برنامه، رشته‌های کارگر یا iframe. اگر آن پیام ها در صف قرار گیرند و به سرعت پردازش نشوند، تاخیر رخ می دهد.

این تأخیرها می‌توانند تجربه کاربر را با عدم پاسخگویی به برنامه کاهش دهند. در حالی که مشاهده این تاخیر آسان است، شناسایی علت اصلی آن با ابزارهای توسعه فعلی چالش برانگیز است.

بیایید سه نوع تأخیر را که هنگام تبادل پیام بین زمینه‌ها با آن رخ می‌دهد، مرور کنیم postMessage() API و اینکه چگونه API زمان‌بندی پیام تاخیری می‌تواند به تشخیص علت اصلی آن کمک کند.

کاهش سرعت 1 – زمینه دریافت مشغول است

همانطور که نمودار زیر نشان می دهد، زمینه ای که شما یک پیام را به آن ارسال می کنید ممکن است در حال پردازش یک کار همزمان طولانی باشد، به طور موثر رشته آن را مسدود کند، و باعث می شود پیام شما قبل از پردازش در صف قرار گیرد:

برای اینکه بفهمید گیرنده پیام مشغول کارهای دیگر است، باید بدانید که پیام چه مدت مسدود شده است.

برای انجام این کار، Delayed Message Timing API را معرفی می کند blockedDuration ویژگی، که نشان دهنده مدت زمانی است که یک پیام قبل از پردازش باید در صف منتظر بماند.

کاهش سرعت 2 – صف کار شلوغ است

یکی دیگر از دلایل احتمالی کاهش سرعت پیام های متقابل اسناد زمانی است که صف وظایف یک زمینه با بسیاری از وظایف کوتاه بارگذاری می شود.

در رشته اصلی یک صفحه وب، این اغلب ممکن است زمانی اتفاق بیفتد که صف با وظایف با اولویت بالا مانند تعاملات کاربر، مدیریت شبکه و سایر وظایف سربار سیستم داخلی مانند ناوبری، بارگذاری و رندر اشباع شده باشد. در یک کارگر، ازدحام ممکن است زمانی رخ دهد که بسیاری از پیام ها در مدت زمان کوتاهی پست شوند. در هر دو مورد، کارها یا پیام‌ها سریع‌تر از آن‌چه قابل پردازش هستند می‌رسند، و یک بک لاگ ایجاد می‌کند که پیام‌های بعدی، از جمله پیام‌هایی که ممکن است به زمان حساس باشند، به تأخیر می‌افتد.

اگرچه هر کار فردی طولانی نیست، اما با هم جمع می‌شوند و باعث ازدحام می‌شوند، که عملاً مانند یک کار طولانی عمل می‌کند.

برای کمک به تشخیص این وضعیت، Delayed Message Timing API را معرفی می کند taskCount و scriptTaskCount خصوصیات، برای نشان دادن چند کار که پیام را مسدود می کند.

کاهش سرعت 3 – سربار سریال سازی و سریال زدایی

قبل از عبور از مرزهای بین زمینه‌ها، پیام‌ها باید سریال شوند و پس از دریافت مجدداً از سریال خارج شوند.

این عملیات به صورت همزمان در همان رشته هایی که پیام ها ارسال و دریافت می شوند، انجام می شود. بنابراین، سریال‌سازی و سریال‌زدایی پیام‌ها می‌تواند سربار قابل توجهی ایجاد کند، به‌ویژه زمانی که داده‌های زیادی ارسال می‌شود. postMessage().

در حالی که عملیات سریال‌سازی و سریال‌زدایی داخلی در مرورگر است و نمی‌توانید آنها را تغییر دهید، API زمان‌بندی پیام با تاخیر serialization و deserialization خواص برای اندازه گیری دقیق مدت زمان آنها.

استفاده از Delayed Message Timeming API

API با ویندوز، تب ها، iframe یا کارگران کار می کند و پوشش خواهد داد پیام های بین اسنادی، پیام های متقابل/سند، پیام رسانی کانال، و کانال های پخش.

برای تجزیه و تحلیل کامل زمان‌بندی رفت و برگشت، باید ورودی‌های عملکردی را که از هر دو زمینه فرستنده و گیرنده جمع‌آوری می‌کنید، مرتبط کنید. برای یادگیری بیشتر، توضیح دهنده را بررسی کنید.

قطعه کد زیر نحوه استفاده از API پیشنهادی را نشان می دهد:

// Create a PerformanceObserver instance.
const observer = new PerformanceObserver((list) => {
  console.log(list.getEntries());
});

// Start observing "delayed-message" Performance entries.
observer.observe({type: 'delayed-message', buffered: true});

و در اینجا نمونه ای از ویژگی های موجود در ورودی عملکرد “پیام تاخیری” مربوطه است:

{
    "name": "delayed-message",
    "entryType": "delayed-message",
    "startTime": 154.90000009536743,
    "duration": 169,
    "traceId": 4,
    // The type of message-passing event.
    "messageType": "cross-worker-document",
    // The timestamp for when the message was added to the task queue.
    "sentTime": 155,
    // The timestamps for when the receiving context started and stopped
    // processing the message.
    "processingStart": 274.90000009536743,
    "processingEnd": 324.7000000476837,
    // The time the message spent waiting in the receiver's task queue.
    "blockedDuration": 119.90000009536743,
    // The time needed to serialize and deserialize the message.
    "serialization": 0,
    "deserialization": 0,
    // The number of queued tasks blocking the postMessage event.
    "taskCount": 38,
    // The number of entry-point JavaScript tasks, including those with
    // a duration lower than 5ms.
    "scriptTaskCount": 2,
    // The time needed to run all script.
    "totalScriptDuration": 119,
     // The list of PerformanceScriptTiming instances that contribute to the
     // delay.
    "scripts": [
        {
            "name": "script",
            "entryType": "script",
            "startTime": 154.90000009536743,
            "duration": 119,
            "invoker": "DedicatedWorkerGlobalScope.onmessage",
            "invokerType": "event-listener",
            "windowAttribution": "other",
            "executionStart": 154.90000009536743,
            "forcedStyleAndLayoutDuration": 0,
            "pauseDuration": 0,
            "sourceURL": "...",
            "sourceFunctionName": "runLongTaskOnWorker",
            "sourceCharPosition": 267
        }
    ],
    // The PerformanceMessageScriptInfo instance which provides details
    // about the script that sent the message.
    "invoker": {
        "name": "invoker",
        "sourceURL": "...",
        "sourceFunctionName": "sendMessage",
        "sourceCharPosition": 531,
        "sourceColumnNumber": 14,
        "sourceLineNumber": 13,
        "executionContext": {
            "name": "",
            "type": "window",
            "id": 0
        }
    },
    // The PerformanceMessageScriptInfo instance which provides details 
    // about the script that handled (or is handling) the message.
    "receiver": {
        "name": "receiver",
        "sourceURL": "...",
        "sourceFunctionName": "runLongTaskOnWorker",
        "sourceCharPosition": 267,
        "sourceColumnNumber": 41,
        "sourceLineNumber": 9,
        "executionContext": {
            "name": "",
            "type": "dedicated-worker",
            "id": 1
        }
    }
}

نظر خود را با ما در میان بگذارید

Delayed Message Timing API در مراحل اولیه خود است و ما دوست داریم نظرات شما را در مورد این پیشنهاد بشنویم. ممکن است سناریوهای دیگری وجود داشته باشد که در آن کاهش سرعت متقابل امروزی در برنامه‌های شما اتفاق می‌افتد و به اشتراک گذاشتن تجربیات خود با ما به ما در طراحی API مناسب برای شما کمک می‌کند.

نگاهی به پیشنهاد ما و نظرات خود را با ما در میان بگذارید باز کردن یک شماره جدید در مخزن MSEdgeExplainers.