प्लेटफ़ॉर्म में संसाधनों को रोकना: यह वास्तव में क्या बचाता है

TL;DR:

• "छवियों को अवरुद्ध करना बैंडविड्थ बचाने पर पूरी तरह निर्भर करता है।" तीन पृष्ठों पर मापा गया, छवियों, मीडिया और फ़ॉन्ट को अवरुद्ध करने से एक छवि-भारी कैटलॉग में स्थानांतरण में 67% की कमी आई, एक लेख पृष्ठ पर लगभग 25%, और एक पाठ-केवल सूची पर कुछ भी नहीं जो कि छवियों के बिना है।
• पाठ-केवल पृष्ठ पर स्टाइलशीट ही भार थी। अवरोधित सूची में stylesheet जोड़ने से यह 2,121 बाइट्स तक गिर गया — केवल HTML दस्तावेज़ — क्योंकि इसके चार में से तीन अनुरोध CSS हैं।
• बाइट की बचत विश्वसनीय है; समय की बचत नहीं। हर अवरुद्ध प्रोफ़ाइल ने कम डेटा ट्रांसफर किया, लेकिन दीवार-घड़ी का समय दोनों दिशाओं में चला गया, क्योंकि हर अनुरोध को रोकना अपनी लागत रखता है।
• अवरोधन से कोई डेटा लागत नहीं होती। निकाली गई तत्वों की संख्या सभी नौ माप में समान थी — 20 उत्पाद, 10 उद्धरण, 36 पैराग्राफ — इसलिए कुछ भी उपयोगी नहीं फेंका गया।
• अविकल बाइट्स को मापें, प्रतिशत नहीं, और एक बार से अधिक मापें। यहां एक पृष्ठ में एक द्विकामी आधार रेखा है जो इसके स्पष्ट बचत को 1% से 65% के बीच स्विंग करता है जबकि इसकी सामग्री नहीं बदलती।
• मुफ्त में शुरू करें। स्क्रैपलेस ब्राउज़र का एक मुफ्त स्तर है, और इस पोस्ट में संपूर्ण मापन नौ पृष्ठ लोड है।

प्लेव्राइट स्क्रैपलेस स्क्रैपिंग ब्राउज़र से एक वेब सॉकेट CDP एंडपॉइंट पर कनेक्ट करता है, जिसका अर्थ है कि एक क्लाउड ब्राउज़र सत्र स्थानीय एक की तरह व्यवहार करता है — और दूरस्थ एक की तरह बिल करता है। हर छवि, फ़ॉन्ट और स्टाइलशीट जो एक पृष्ठ खींचता है वह ट्रैफ़िक है जिसे आपने स्थानांतरित करने के लिए भुगतान किया।

मानक सलाह यह है कि छवियों को अवरुद्ध करें। यह सलाह हर जगह बिना किसी संख्या के साथ दोहराई जाती है, इसलिए इस पोस्ट में एक संख्या जोड़ी गई है: वही स्क्रिप्ट, तीन पृष्ठ, तीन अवरोधन प्रोफ़ाइल, प्रोटोकॉल से बाइट्स गिने गए।

एक ब्राउज़र सत्र का वास्तव में खर्च क्या होता है

एक ब्राउज़र सब कुछ लाता है जो एक मानव देखेगा। निष्कर्ष हेतु, इसका अधिकांश हिस्सा बर्बाद है — कोई भी वेब फ़ॉन्ट को पार्स नहीं करता। वेब में पृष्ठ का वजन सार्वजनिक रूप से HTTP आर्काइव पृष्ठ वजन रिपोर्ट द्वारा ट्रैक किया जाता है, और ऐसे समग्र आंकड़े हैं जिन पर छवियों को अवरोधित करने की सलाह निर्भर करती है।

समग्र आंकड़े हैं जहाँ यह सलाह गलत हो जाती है। आप औसत पृष्ठ को स्क्रैप नहीं करते; आप एक लक्ष्य को स्क्रैप करते हैं, जिसका संपत्ति मिश्रण औसत की तरह दिखाई नहीं दे सकता है।

पूर्वापेक्षाएँ

• Python 3.9 या बाद और pip install playwright
• SCRAPELESS_API_KEY वातावरण चर में एक स्क्रैपलेस API कुंजी

कोई स्थानीय ब्राउज़र डाउनलोड की आवश्यकता नहीं है। connect_over_cdp एक दूरस्थ सत्र से जुड़ता है, इसलिए playwright install इस कार्यप्रवाह का हिस्सा नहीं है।

कनेक्ट करें और बाइट्स गिनें

प्लेव्राइट CDP पर कनेक्ट करता है, और उसी पृष्ठ पर खोला गया एक कच्चा CDP सत्र उस ट्रैफ़िक की गणना करता है जो वायर के पार जाता है:

browser = await playwright.chromium.connect_over_cdp(ENDPOINT)
page = await browser.new_page()
cdp = await page.context.new_cdp_session(page)
await cdp.send("Network.enable")

transferred = {"bytes": 0}
cdp.on(
    "Network.loadingFinished",
    lambda event: transferred.__setitem__(
        "bytes", transferred["bytes"] + event.get("encodedDataLength", 0)
    ),
)

encodedDataLength वह माप है जो मायने रखता है। क्रोम देवटूल्स प्रोटोकॉल नेटवर्क डोमेन इसे एक अनुरोध के लिए प्राप्त कुल बाइट्स की संख्या के रूप में परिभाषित करता है, इसलिए यह संकुचित स्थानांतरण की गणना करता है न कि अव्यवस्थित दस्तावेज़ आकार की। यही वह है जो एक प्रॉक्सी मीटर करता है और जिस पर एक बैंडविड्थ बिल आधारित होता है।

इसे Network.loadingFinished के ऊपर जोड़ना प्रत्येक पृष्ठ लोड के लिए एक संख्या देता है, जिसमें पाईपलाइन में कहीं भी कोई अनुमान नहीं होता।

रूटिंग परत जोड़ें

अवरोधन एक अनुरोध के अनुसार एक रूटिंग निर्णय होता है:

BLOCKED = {"image", "media", "font"}


async def router(route):
    if route.request.resource_type in BLOCKED:
        await route.abort()
    else:
        await route.continue_()


await page.route("**/*", router)

अब हर अनुरोध router के माध्यम से गुजरता है, जो या तो इसे रोकता है या इसे आगे बढ़ने की अनुमति देता है — हैंडलर अनुबंध प्लेव्राइट पृष्ठ रूटिंग API में। एक हैंडलर जो न तो कुछ करता है, अनुरोध को तब तक लटकाए रखता है जब तक नेविगेशन समय समाप्त नहीं हो जाता, इसलिए प्रत्येक शाखा को abort या continue_ में समाप्त होना चाहिए।

resource_type ब्राउज़र के अपने वर्गीकरण से आता है कि एक अनुरोध क्यों किया गया, यही वह अवधारणा है जिसे फेच मानक एक अनुरोध गंतव्य कहते हैं। इसके साथ मेल खाना एक्सटेंशन द्वारा URLs से मेल खाने की तुलना में अधिक टिकाऊ होता है, क्योंकि /assets/a8f3c2 से बिना एक्सटेंशन के परोसा गया फ़ॉन्ट अभी भी font के रूप में वर्गीकृत होता है।
यह पढ़ने की ट्रैफ़िक को रोकने के बजाय पलटी छवि है - पृष्ठ द्वारा किए गए अनुरोधों से डेटा निकालने के लिए, एक पृष्ठ की छिपी हुई JSON API को इंटरसेप्ट करना देखें।

तीन पृष्ठ मापें

पूर्ण स्क्रिप्ट प्रत्येक लक्ष्य को तीन प्रोफाइल के अंतर्गत लोड करती है और बाइट्स, बचत, समय और अभी भी निकाले जा सकने वाले तत्वों की संख्या प्रिंट करती है। दो विपरीत सेटिंग्स यह बिंदु साबित करने के लिए पर्याप्त हैं; समान तरीके से इसे मापने के लिए अपने स्वयं के लक्ष्य को TARGETS में जोड़ें:

import asyncio
import os
import time

from playwright.async_api import async_playwright

ENDPOINT = (
    "wss://browser.scrapeless.com/api/v2/browser"
    f"?token={os.environ['SCRAPELESS_API_KEY']}&session_ttl=300&proxy_country=US"
)

TARGETS = [
    ("books.toscrape.com", "https://books.toscrape.com/", "article.product_pod"),
    ("quotes.toscrape.com", "https://quotes.toscrape.com/", "div.quote"),
]

PROFILES = {
    "baseline": set(),
    "media-only": {"image", "media", "font"},
    "media+css": {"image", "media", "font", "stylesheet"},
}

PAUSE_SECONDS = 5


async def measure(playwright, url, selector, blocked):
    """एक पृष्ठ लोड करें और (bytes पर वायर, सेकंड, तत्व मिलान) लौटाएँ।

    प्रत्येक माप का अपना कनेक्शन होता है इसलिए प्रोफाइल के बीच कोई HTTP कैश साझा नहीं किया जाता है; एक गर्म कैश वास्तव में एक ठंडी लोड की लागत को कम आंकता है।
    """
    browser = await playwright.chromium.connect_over_cdp(ENDPOINT)
    try:
        page = await browser.new_page()
        cdp = await page.context.new_cdp_session(page)
        await cdp.send("Network.enable")

        transferred = {"bytes": 0}
        cdp.on(
            "Network.loadingFinished",
            lambda event: transferred.__setitem__(
                "bytes", transferred["bytes"] + event.get("encodedDataLength", 0)
            ),
        )

        if blocked:
            async def router(route):
                if route.request.resource_type in blocked:
                    await route.abort()
                else:
                    await route.continue_()

            await page.route("**/*", router)

        started = time.monotonic()
        await page.goto(url, wait_until="load", timeout=120_000)
        elapsed = time.monotonic() - started
        matched = await page.locator(selector).count()
        return transferred["bytes"], elapsed, matched
    finally:
        await browser.close()


async def main():
    print(f"{'target':22}{'profile':12}{'bytes':>10}{'saved':>7}{'time':>8}{'matched':>9}")
    async with async_playwright() as playwright:
        for name, url, selector in TARGETS:
            baseline_bytes = None
            for profile, blocked in PROFILES.items():
                # लोड को अलग रखें: यह प्रत्येक माप के लिए एक नया सत्र खोलता है,
                # और बिना रुके नौ पृष्ठ लोड करना लक्ष्य के लिए विनम्र नहीं है।
                await asyncio.sleep(PAUSE_SECONDS)
                transferred, elapsed, matched = await measure(playwright, url, selector, blocked)
                if baseline_bytes is None:
                    baseline_bytes = transferred
                saved = round((1 - transferred / baseline_bytes) * 100)
                print(f"{name:22}{profile:12}{transferred:>10,}{saved:>6}%{elapsed:>7.2f}s{matched:>9}")


if __name__ == "__main__":
    asyncio.run(main())

इसका एक रन:

target                profile          bytes  saved    time  matched
books.toscrape.com    baseline       337,691     0%   4.22s       20
books.toscrape.com    media-only     111,939    67%   5.62s       20
books.toscrape.com    media+css       76,329    77%   2.56s       20
quotes.toscrape.com   baseline        26,731     0%   5.86s       10
quotes.toscrape.com   media-only      26,739     0%   5.22s       10
quotes.toscrape.com   media+css        2,125    92%   3.12s       10

ध्यान में रखें कि दो quotes.toscrape.com अवरुद्ध पंक्तियाँ: छवियों, मीडिया और फॉन्ट को अवरुद्ध करने से वहां कुछ भी बचत नहीं हुई, और उस पर स्टाइलशीट को अवरुद्ध करने से लगभग सब कुछ बच गया। अगली अनुभाग बताती है कि क्यों - और क्यों कुछ समय में उसी मीडिया प्रोफाइल से उसी पृष्ठ से 65% बचत की रिपोर्ट होती है।

संख्याएँ क्या कहती हैं

प्रतिशत इसे पढ़ने का स्वाभाविक तरीका है, और वे इसमें सबसे कम स्थिर चीज़ हैं। अवरुद्ध प्रोफाइल अत्यधिक पुनरावृत्त होने योग्य हैं; आधार रेखाएँ नहीं हैं, और प्रतिशत दोनों का अनुपात है।
कैटलॉग पृष्ठ लगभग पूरी तरह से बार-बार हो सके वाला है — इसके तीन मूल माप एक-दूसरे के भीतर 0.004% के भीतर आए। विश्वकोश लेख में चलने के दौरान लगभग 7% का वितरण था। और पाठ सूची में दो मोड निकले: अधिकांश लोड लगभग 26,700 बाइट्स ट्रांसफर करते हैं, लेकिन लगभग तीन में से एक लोड लगभग 75,820 बाइट्स ट्रांसफर करता है, क्योंकि कभी-कभी ब्राउज़र स्टाइलशीट द्वारा संदर्भित फ़ॉन्ट बाइनरी को खींचता है और कभी-कभी नहीं। उसके आधार पर मापा गया "बचत" उस आधार पर केवल 1% से 65% के बीच झूलता है, जबकि पृष्ठ की वास्तविक सामग्री अपरिवर्तित रहती है।

इसलिए पहले निरपेक्ष स्तंभ पढ़ें। तीन चलनों के मध्य, जिसमें वास्तविक दुनिया के विश्वकोश लेख को समान तरीके से मापा गया, तीसरे डेटा बिंदु के रूप में जोड़ा गया:

कैटलॉग पृष्ठ अपने वजन का दो-तिहाई एक तीन-प्रकार ब्लॉक सूची को खोता है, और स्टाइलशीट के लिए और दस अंक खोता है — एक 67% और 77% की कटौती एक ऐसे आधार रेखा के खिलाफ जो उन आंकड़ों पर भरोसा करने के लिए पर्याप्त स्थिर है।

जब मीडिया अवरुद्ध होता है तो पाठ सूची लगभग हिलती नहीं है, फिर स्टाइलशीट के भी प्रतिबंधित होने पर 2,121 बाइट्स में गिर जाती है। वह संख्या HTML दस्तावेज़ अपने आप में है, और यह CSS अवरोध की हर प्रोफ़ाइल की हर चाल में समान थी। प्रति-निवेदन breakdown बताता है कि क्यों: पृष्ठ चार अनुरोध करता है, और उनमें से तीन स्टाइलशीट हैं जो कुल मिलाकर लगभग 24,500 बाइट्स की होती हैं जबकि 2,121 बाइट्स का मार्कअप होता है। इस पर कोई छवियाँ नहीं हैं।

लेख पृष्ठ मीडिया अवरोध के लिए एक चौथाई छोडता है और फिर CSS के लिए कोई मापने योग्य नहीं — मध्य 305 बाइट्स हिला जबकि media+css रन खुद 29,000 के ऊपर रहे। इस पृष्ठ पर, स्टाइलशीट को अवरुद्ध करना कोई बचत नहीं है।

निकासी हर जगह जीवित रही। 20 उत्पाद, 10 उद्धरण, और 36 पैरा हर प्रोफ़ाइल के अंतर्गत वापस आए, इसलिए इनमें से कोई भी बचत एक क्षेत्र की कीमत पर नहीं है।

समय की जरूरत है कि वे अपनी चेतावनी का ध्यान रखें। हर प्रोफ़ाइल ऊपर छपे हुए रन में अपने आधार रेखा की तुलना में तेज़ था, जो ठीक वैसा परिणाम है जो आपको स्पीडअप का वादा करने के लिए आकर्षित करेगा। मध्य सेट के पार यह नहीं टिकता: कैटलॉग पृष्ठ ने media+css पर 4.66 सेकंड लिए जो कि 3.90 सेकंड की आधार रेखा के खिलाफ है, और विकिपीडिया ने 6.57 सेकंड में media-only पर 5.86 सेकंड के खिलाफ लिया — दोनों धीमी गति से कम ट्रांसफर करते हुए। प्रत्येक अनुरोध को एक पाइथन कॉलबैक के माध्यम से राऊटिंग करना हर अनुरोध पर एक राउंड ट्रिप जोड़ता है, और वह ओवरहेड इस बात से संबंधित नहीं है कि अवरुद्ध संपत्तियाँ कितनी बाइट्स ले जातीं। बाइट कमी को विश्वसनीय जीत के रूप में मानें और लेटेंसी को एक पारिस्थितिकी प्रभाव के रूप में मापें।

शुरू करने के लिए किसी कार्ड की जरूरत नहीं है — नि:शुल्क योजना इस तरह के नौ लोड माप को कवर करती है।

प्रत्येक लक्षित प्रोफ़ाइल चुनें

माप लेने में प्रत्येक लक्ष्य के लिए लगभग एक मिनट लगता है और अनुमान लगाने का काम समाप्त करता है:

• एक प्रतिनिधि पृष्ठ के खिलाफ आधार रेखा और एक अवरोधित प्रोफाइल चलाएं — एक श्रेणी सूची, होम पृष्ठ नहीं, क्योंकि संपत्ति मिश्रण एक साइट के चारों ओर भिन्न होते हैं।
• डिफ़ॉल्ट रूप से image, media, और font को ब्लॉक करें। ये कभी भी पार्स नहीं होते हैं, और नुकसान सीमित होता है।
• stylesheet को अलग से परीक्षण करें बजाय इसके कि माना जाए। यह यहाँ एक पृष्ठ पर एकल सबसे बड़ा लाभ था और दूसरे पर अप्रासंगिक था। लेआउट-निर्भर निकासी को जांचने की आवश्यकता होती है: वर्गों और संरचना के लिए कुंजी वाले चयनकर्ता अप्रभावित होते हैं, लेकिन कोई भी ऐसा कुछ जो गणना की गई ज्यामिति या दृश्यता पर निर्भर करता है, वह प्रभावित होता है।
• कभी भी script या document को एक पृष्ठ पर ब्लॉक न करें जिसे आपको रेंडर करना है। एक क्लाइंट-निर्मित पृष्ठ अपना सामग्री निर्माण उन स्क्रिप्टों के साथ करता है जिन्हें आप अस्वीकार कर रहे होते हैं।
• जब लक्ष्य पुन: डिज़ाइन करता है तो फिर से मापें। प्रोफ़ाइल एक संपत्ति मिश्रण के लिए ट्यून की गई है, और संपत्ति मिश्रण बदलते हैं।

जहाँ पृष्ठ को रेंडर करने की आवश्यकता होती है लेकिन कोई इंटरैक्शन नहीं होता है, वहाँ एक HTTP रेंडरिंग कॉल पूरी तरह से ब्राउज़र सत्र से बचता है — स्क्रैपिंग ब्राउज़र उत्पाद पृष्ठ और कनेक्शन दस्तावेज़ीकरण कवर करते हैं कि कब एक पूर्ण सत्र अपने खर्च को अर्जित करता है।

समस्या निवारण

जैसे ही राऊटिंग सक्षम होता है, नेविगेशन टाइमआउट हो जाता है। हैंडलर के माध्यम से एक कोड पथ बिना abort या continue_ को कॉल किए समाप्त होता है। हर शाखा, जिसमें अपवाद पथ भी शामिल है, को मार्ग को हल करना होगा।

अवरुद्ध अनुरोध अभी भी बाइट गणना में प्रकट होते हैं। यदि Network.enable को page.route पंजीकरण के बाद भेजा गया था, या मापी जा रही पृष्ठ के लिए एक अलग CDP सत्र पर। पृष्ठ के अपने संदर्भ से सत्र बनाएं और नेविगेट करने से पहले डोमेन को सक्षम करें।
पृष्ठ खाली दिखाई दे रहा है और चयनकर्ताओं का कोई मेल नहीं है। स्क्रिप्ट या दस्तावेज़ ब्लॉक सूची में है। दोनों ग्राहक-निर्मित पृष्ठ पर आवश्यक हैं।

बाइट की गिनती विभिन्न प्रयासों के बीच कई प्रतिशत से अधिक भिन्न होती है। पृष्ठ हर लोड पर समान संसाधन नहीं ला रहा है। यहां मापी गई पाठ सूची पर, एक शैलीपत्र द्वारा संदर्भित फ़ॉन्ट बाइनरी कुछ लोड में खींची गईं और दूसरों में नहीं, बुनियादी रेखा को लगभग 26,700 बाइट से लगभग 75,820 बाइट तक ले जाते हुए। कई प्रयासों में एक माध्य लीजिए, और प्रतिशत के बजाय निरपेक्ष बाइट की तुलना कीजिए, क्योंकि गतिशील बुनियादी रेखा अनुपात को विकृत करती है।

बचत बड़ी दिखती हैं लेकिन रिकॉर्ड गायब हो जाते हैं। एक प्रोफ़ाइल पर भरोसा करने से पहले निकाली गई गिनती की तुलना बुनियादी रेखा से करें, जैसा कि उपरोक्त स्क्रिप्ट करती है। एक प्रोफ़ाइल जो बाइट और रिकॉर्ड कम करती है वह एक अनुकूलन नहीं है।

निष्कर्ष

हर पृष्ठ को इकट्ठा करते समय बैंडविड्थ बढ़ता है, और अधिकांश लागतों के विपरीत इसे लगभग एक मिनट में मापा जा सकता है। दो लाइनें CDP में एक संख्या पैदा करती हैं जो किसी दिए गए लक्ष्य के लिए ब्लॉक सूची को या तो औचित्य देती हैं या नहीं।

यहां जो संख्या है वह एक डिफ़ॉल्ट के खिलाफ तर्क करती है। एक पृष्ठ पर छवियों को अवरुद्ध करना निर्णायक था, दूसरे पर मध्यम था, और तीसरे पर अप्रासंगिक था जिसमें कोई छवियां नहीं थीं, जबकि सेट में सबसे बड़ा एकल लाभ ठीक उसी तीसरे पृष्ठ पर शैलीपत्रों को अवरुद्ध करने से आया। किसी भी ब्लॉक सूची को अपनाने से पहले अपने अपने लक्ष्य के खिलाफ बुनियादी रेखा चलाएं, जिसमें यह भी शामिल है — और इसे एक से अधिक बार चलाएं, क्योंकि इन तीन पृष्ठों में से एक बार-बार समान उत्तर नहीं देता है।

क्या आप अपने लक्ष्यों को मापने के लिए तैयार हैं? एक मुफ्त Scrapeless खाता बनाएं, अपने कुंजी का निर्यात करें, और उस पृष्ठ के खिलाफ स्क्रिप्ट चलाएं जिसे आप पहले से इकट्ठा करते हैं। योजना की सीमाएँ प्राइसिंग पृष्ठ पर हैं, और प्रॉक्सी कॉन्फ़िगरेशन उसी बिल के बाहर को कवर करता है।

सामान्य प्रश्न

प्रश्न: खुरचन करते समय कौन से संसाधन प्रकार अवरुद्ध करना सुरक्षित हैं?

छवि, मीडिया, और फ़ॉन्ट लगभग किसी भी निष्कर्षण कार्य पर सुरक्षित हैं, क्योंकि कोई पार्सर उन्हें नहीं पढ़ता। शैलीपत्र तब सुरक्षित है जब आपके चयनकर्ता कक्षाओं और संरचना पर निर्भर करते हैं न कि गणना की गई लेआउट पर, जो अधिकांश खुरचन को कवर करती है, और यह इन मापों में सबसे बड़ी बचत थी। किसी भी पृष्ठ पर स्क्रिप्ट, दस्तावेज़, xhr, और fetch को अकेला छोड़ दें जो सामग्री को क्लाइंट-साइड बनाता है।

प्रश्न: क्या छवियों को अवरुद्ध करने से वास्तव में बैंडविड्थ की बचत होती है?

यह पूरी तरह से पृष्ठ पर निर्भर करता है, यही कारण है कि एकल आंकड़ा भ्रामक होता है। यहां मापी गई वही ब्लॉक सूची एक छवि सूची पर 67% बचत करती है, एक विश्वकोश लेख पर लगभग एक चतुर्थांश, और वास्तव में कुछ नहीं एक पाठ-केवल सूची पर जो कोई छवियां नहीं रखती। अपने स्वयं के लक्ष्य के खिलाफ बुनियादी रेखा चलाएं और निरपेक्ष बाइट की तुलना करें — एक मिनट का मापन किसी भी प्रकाशित प्रतिशत को मात देता है।

प्रश्न: क्या संसाधनों को अवरुद्ध करने से स्क्रैपिंग तेज होती है?

इससे कम विश्वसनीयता से यह बाइट को कम करता है। यहां हर प्रोफ़ाइल ने अपने बुनियादी रेखा से कम स्थानांतरित किया, लेकिन दीवार-घड़ी का समय दोनों दिशाओं में चला गया, क्योंकि प्रत्येक अनुरोध को एक हैंडलर के माध्यम से मार्गदर्शित करने में एक राउंड ट्रिप की लागत आती है। भारी संसाधनों वाले पृष्ठों पर वह ओवरहेड बचत को ऊपर कर सकता है, इसलिए विलंबता को कुछ सत्यापित करने के लिए मानें न कि मान लें।

प्रश्न: क्या मुझे page.route या CDP Network.setBlockedURLs का उपयोग करना चाहिए?

page.route संसाधन प्रकार पर मेल खाता है, जो आमतौर पर आपका वांछित होता है, और इसे लक्ष्यों के अनुसार परिवर्तन करना आसान बनाता है। CDP अवरुद्ध आदेश URL पैटर्न से मेल खाते हैं, इसलिए वे एक विशेष ज्ञात होस्ट को अवरुद्ध करने के लिए उपयुक्त हैं — मान लीजिए कि एक विश्लेषणात्मक अंत बिंदु है — न कि संपत्ति के पूरे वर्ग। यदि आपको दोनों की आवश्यकता है तो दोनों मिलकर काम करते हैं।

प्रश्न: क्या संसाधनों को अवरुद्ध करने से एक पृष्ठ वास्तविक ब्राउज़र से अलग व्यवहार करेगा?

हां, इस अर्थ में कि एक सत्र जो कभी छवियों का अनुरोध नहीं करता वह सामान्य रूप से जो ब्राउज़र करता है वह नहीं कर रहा है। ब्लॉक सूचियों को उसी तक सीमित रखें जिनकी आपकी निष्कर्षण को वास्तव में आवश्यकता है, और यदि किसी लक्ष्य का व्यवहार अवरुद्ध करने के बाद बदल जाता है, तो सूची को संकीर्ण करें और फिर से मापें, न कि इसे विस्तारित करें।

प्रश्न: मैं CDP सत्र के बिना बाइट्स की गिनती कैसे कर सकता हूँ?
आप इसे Playwright response हैंडलर में प्रतिक्रिया शरीर की लंबाई को जोड़कर अनुमानित कर सकते हैं, लेकिन ये उन संकुचित आकारों के बजाय हैं जो स्थानांतरित बाइट्स हैं, और ये उन अनुरोधों को चूक जाते हैं जो विफल होते हैं या कैश से सेवा की जाती हैं। एक इन-पृष्ठ विकल्प <a href="https://www.w3.org/TR/resource-timing/" rel="nofollow"><strong>W3C Resource Timing स्पेसिफिकेशन</strong></a> द्वारा परिभाषित transferSize विशेषता है, जो performance.getEntriesByType("resource") के माध्यम से पढ़ी जाती है, जो सही मात्रा के करीब है लेकिन यह क्रॉस-ओरिजिन प्रतिबंधों के अधीन है जो इसे तृतीय-पक्ष संपत्तियों के लिए शून्य बना देती है। Network.loadingFinished से encodedDataLength वही है जो ब्राउज़र ने हर अनुरोध के लिए नेटवर्क पर रिकॉर्ड किया है चाहे वह किसी भी स्रोत का हो, इसलिए यह अतिरिक्त दो पंक्तियों के लायक है।