Getting filepath of a specific asset
I think this class is largely fine as a display/view generation helper class, but worry about its broader utility.  Let me ask, if the PHP script in your usage example already owns the logic for the specific filename that it wants to include, shouldn't it also know the specific for the path to the file at this point already?  This HTML-rendering logic already knows know the most specific information about the asset that is to be included (the asset filename) but defers the more general information about the asset (its directory location) to the class.  That seems like an odd division of responsibility.  Additionally, your approach seems limited to only using asset files which are hosted on the same domain as the page being rendered, as I don't see how your solution supports full URL references.

Since you are going down the path of trying to dynamically inject what are basically config-driven values into this HTML template, I would suggest you truly decouple the configuration of included assets from the HTML template, perhaps striving more towards a solution like:

&lt;html&gt;
&lt;head&gt;
    &lt;!-- Other HTML HEAD contents --&gt;
&lt;?php
// You could obviously use templating library as well,
// but raw PHP "spaghetti code" shown here for demonstration
foreach(Assets::getCssIncludes() as $url) {
?&gt;
    &lt;link rel="stylesheet" href="&lt;?php echo $url; ?&gt;"&gt;
&lt;?php
}

foreach(Assets::getJsHeadIncludes() as $url) {
?&gt;
    &lt;script type="application/javascript" src="&lt;?php echo $url; ?&gt;"&gt;&lt;/script&gt;
&lt;?php
}
?&gt;
&lt;/head&gt;
&lt;body&gt;
    &lt;!-- BODY content --&gt;
&lt;?php
foreach(Assets::getJsEndOfBodyIncludes() as $url) {
?&gt;
    &lt;script type="application/javascript" src="&lt;?php echo $url; ?&gt;"&gt;&lt;/script&gt;
&lt;?php
}
?&gt;
&lt;/body&gt;
&lt;/html&gt;


With this sort of approach you can totally decouple your template from needing to have any hard-coded references to it's asset dependencies.  You could derive these from configuration and expose via "Assets" (or similar class).

This is advantageous as you begin to want to deploy different configurations of a page into different environments (i.e. dev, staging, production).  You could have production configured to inject the current stable production assets, while pre-prod environments can injects other assets versions or new assets that are not suitable or not yet deployed to production.