Diagnozu tajm-limojn de Puppeteer-prokurilo laŭ peto kaj paĝa mejloŝtono

Uzu requestfailed por retaj fiaskoj kaj HTTPResponse-statuson por servilaj respondoj antaŭ ol kulpi prokurilon pro malrapida tutpaĝa navigado.

Rapida respondo de curl aŭ Axios estas kutime unu rimedo. Puppeteer ankaŭ povas alporti skriptojn, bildojn, kadrojn kaj API-ojn el pluraj gastigantoj kaj atendi pli postan paĝan mejloŝtonon.

Ĉar la prokurilo jam estas agordita en la ekzistanta paĝo, observu unuopajn fiaskojn dum la navigado:

page.on("requestfailed", request => {
  console.log(request.url(), request.failure()?.errorText);
});

await page.goto(targetUrl, {
  waitUntil: "domcontentloaded",
  timeout: 30000,
});

Rulu tion en la nesinkrona laborfluo kun la reala targetUrl. La ekzemplo atendas DOMContentLoaded, kiu estas pli frue ol la finiĝo de ĉiu bezonata bildo aŭ posta aplikaĵa respondo. Komparu tiun mejloŝtonon kun tiu, kiun la origina navigado atendas: ĉefa dokumento, DOM, load aŭ reta senaktiveco estas malsamaj rezultoj.

Respondo 403 aŭ 500 ne estas okazaĵo requestfailed. Legu la statuson ankaŭ per HTTPResponse.

Uzu la observojn por identigi malrapidan aŭ rifuzitan rimedon, ripetitan aŭtentikigon aŭ pli postan atendantan kondiĉon. Pli longa tajm-limo nur plilongigas la atenton; ĝi nek malpliigas la laboron de la retumilo nek pruvas, ke ĉiu rimeda konekto estis akceptita.

Rilataj artikoloj