render-blocking

Use when auditing slow page loads, heavy assets, or rendering delays related to Eliminate render-blocking resources. Verify the actual bottleneck in DevTools, Lighthouse, or field data before recommending changes.

Quality

67%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/render-blocking/SKILL.md

Quality

Content

65%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A lean, well-structured overview body that uses progressive disclosure correctly — a short quick-reference with a real one-level reference file carrying the code examples. Its weaknesses are in-body actionability and workflow clarity: the Check/Fix sections describe what to do at a directive level without executable commands, and no explicit verification loop (measure -> fix -> re-measure) appears in the body itself.

Suggestions

Make the 'Check' section executable: name the specific measurement step, e.g., 'Open DevTools Network waterfall (or run Lighthouse and open the Eliminate render-blocking resources audit) and list CSS/JS requests before first paint'.

Add an explicit verify-after-fix step to the workflow, e.g., 'Re-run Lighthouse or re-record the waterfall and confirm FCP improved and no parser-blocking resources remain before first paint' — the reference file's Verification section already has this content, so a one-line pointer would also work.

Include one minimal inline code snippet for the core fix (e.g., `<script defer src="/app.js"></script>` and a `media="print" onload="this.media='all'"` pattern) so the most common case is actionable without opening the reference.

Dimension	Reasoning	Score
Conciseness	The body is short and well-organized, with each section a tight directive list ("Load non-critical CSS and JS asynchronously using `defer`, `async`, or media queries"). The one instance of over-explanation is the opening sentence teaching what render-blocking resources are — a concept Claude already knows — which keeps it at anchor 4 rather than the every-token-earns-its-place anchor 5.	4 / 5
Actionability	The body names concrete mechanisms (`defer`, `async`, media queries, `@import`, critical CSS, FCP) but contains no executable code, commands, or measurement steps — e.g., 'Check' says to "Review the page's resources and identify any CSS or JavaScript files" without saying how (which DevTools panel, which Lighthouse audit). This matches anchor 3 ('some concrete guidance but incomplete; missing key details') rather than anchor 4, since the executable detail lives in the reference file rather than the body.	3 / 5
Workflow Clarity	A rough sequence is present (Check -> Fix -> Explain -> Code Review), but validation checkpoints are only implicit — the frontmatter description mentions verifying in DevTools/Lighthouse/field data, yet the body's Check and Fix sections never instruct re-measuring or confirming the fix improved FCP. This fits anchor 3 ('steps listed but validation gaps; checkpoints missing or implicit') rather than anchor 4, which requires most checkpoints present.	3 / 5
Progressive Disclosure	The body is a concise overview with clearly signaled, one-level-deep references: "For full implementation details, code examples, and framework-specific guidance, see `references/rule.md`" — and that file exists and contains exactly the promised code examples and validation guidance. The split (quick reference inline, details in the reference) is appropriate, matching anchor 5 exactly; not anchor 4, which tolerates organization gaps that are absent here.	5 / 5
	Total	15 / 20 Passed

Description

70%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A solid description with an explicit 'Use when' trigger clause, natural trigger terms, and a concrete verify-before-recommending methodology with named tools. Its main weakness is that the capability statement is procedural and thin — it audits and verifies rather than enumerating what the skill concretely does.

Suggestions

Lead with 2-3 concrete capability statements in third person (e.g., 'Audits pages for render-blocking CSS/JS, flags blocking requests, and applies defer/async/critical-CSS fixes') before the 'Use when' clause to raise specificity.

Add common synonym trigger terms users naturally say, such as 'page speed', 'white screen', 'First Contentful Paint (FCP)', or 'Lighthouse render-blocking audit', to broaden trigger coverage.

Narrow the broad trigger phrases ('heavy assets', 'slow page loads') toward render-blocking-specific cues to reduce overlap with sibling performance skills.

Dimension	Reasoning	Score
Specificity	The description names the domain ("Eliminate render-blocking resources", "slow page loads") and one or two concrete actions ("Verify the actual bottleneck in DevTools, Lighthouse, or field data"), but does not list several distinct capabilities. It fits the anchor 'Names domain and 1-2 concrete actions, but not comprehensive' better than anchor 4, which requires several specific actions.	3 / 5
Completeness	The 'when' is explicit ("Use when auditing slow page loads, heavy assets, or rendering delays related to Eliminate render-blocking resources") and the 'what' is present ("Verify the actual bottleneck in DevTools, Lighthouse, or field data before recommending changes"). The 'what' is procedural rather than a clear capability statement, so it matches anchor 4 ('both present; when could be more explicit or what is implicit') but not the fully explicit both-phrases of anchor 5.	4 / 5
Trigger Term Quality	Good natural-term coverage: "slow page loads", "heavy assets", "rendering delays", "render-blocking", "DevTools", "Lighthouse", "field data" are phrases users would actually say. A few common synonyms (e.g., "page speed", "FCP", "white screen") are missing, so it fits anchor 4 rather than the comprehensive coverage of anchor 5.	4 / 5
Distinctiveness Conflict Risk	The description is scoped to a clear niche ("related to Eliminate render-blocking resources") with distinct triggers and named tools. There is minor overlap risk with sibling performance-audit skills via broad phrases like "heavy assets" and "slow page loads", matching anchor 4 rather than the minimal-conflict anchor 5.	4 / 5
	Total	15 / 20 Passed

Validation

93%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
metadata_version	'metadata.version' is missing	Warning

	Total	15 / 16 Passed

Repository: thedaviddias/Front-End-Checklist
Path: skills/render-blocking/SKILL.md
Commit: 7bfd868

Reviewed: 1 day ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.